ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
19 мая
265649
Evgeny_CD, Архитектор (05.08.2011 13:30, просмотров: 1435)
Гибридные embedded Оси. Спустя много лет после знакомства с концепцией RTAI подсознание выдало нечто. Наше светлое будущее? https://www.rtai.org
Берем современный FLASH контроллер за $15. В нем можно найти: • FLASH 512к…2М (У Renesas есть) • SRAM – 128к, у грядущих будет 256 • Процык 100….200 DMIPS • SDRAM контроллер • Кеш – очень редко, скорее без него. • Еще есть очень перспективные связки Cortex-M4 & Cortex-M0 в рамках одной системы И пытаемся натянуть его на задачи. Получается что-то типа • Быстрая возня с окружающим миром – таймера, АЦП и пр • Средняя тяжесть DSP приложений – голос пожать, эхо подавить, фильтрануть чего • Низкоуровневая коммуникация – USB, UART, Ethernet. В смысле быстро обработать данные от прерывания и DMA, чтобы процесс автоматической прокачки не прерывался. • Высокоуровневые вещи – стеки протоколов, GUI и пр. Причем последнее требует весьма небольшой вычислительной мощности. Пример. Пусть в нас 3G мудем, и ему настолько хорошо, что он дает 2 Мбита в дуплексе. Т.е. 256Кбайт\сек данных. Для поддержания такого потока (складывать пакеты в буфер / выбирать оттуда) для самой что ни на есть POSIX Оськи 1MIPS хватит. (мы не говорим про обработку самих данных!) Но любая POSIX –like ОСька в указанные набортные ресурсы влезет очень хреново. Т.е. она влезет, но места (особенно в ОЗУ) для прикладных целей будет маловато… А что, если сделать так? Берем махонькую, компактную RTOSку, которая отожрет совсем чуть-чуть ресурсов. Под ней сделаем все низкоуровневое. Обработчики прерываний в ОЗУ и пр. LLRTOS далее. Берем HLRTOS, RTEMS например. Нафаршировываем ее по полной. И запускаем как часть Idle таска LLRTOS. HLTROS живет только в SDRAM (не страшно, что кеша нет – там супер-скорость не нужна). Код, быть может, частично, во FLASH. Все дрова этой HLRTOS виртуализированы и работают со структурами в памяти, которые родили потоки LLRTOS. Причем связь может быть и в обратную сторону  Т.е. HLRTOS дает некое API на основе структур для сокетов, например, а LLRTOS загоняет туда данные, полученные в результате низкоуровневой обработки. В результате имеем все преимущества обоих Осей при малом потреблении критичных ресурсов и малой латентности. Процедуры преключения контекста У Осей можно согласовать. Заметим, что Оси могут быть сделаны в разных тулчейнах -проц то один. Т.е. собираем мы RTEMS в elf с неким дексриптором (чтобы слинковать LLRTOS), LLRTOS в яре, грузим HLRTOS при помощи LLRTOS в память, и вуаля – они живут не пересекаясь. Критика?