Средства и методы разработки

Размышлизма про правильные RTOSы в свете выхоящего в свет нового поколения FLASH контроллеров. Итак, совершенно четко наметилась тенденция нового поколения контроллеров: * FLASH - 1мбайт и более * SRAM - 128 Кбайт и более, разделено на несколько болоков для одновременного доступа * FPU - одинарной точности и более * внешнаяя шина * DMA * много шин или шинный коммутатор, чтобы все работало параллельно. Представители этого поколения Renesas RX600 http://caxapa.ru/184354.html Renesas SH-2A FPU 200 МГц http://caxapa.ru/184308.html AVR32 имеет 128 К SRAM, анонсирована версия с FPU, FLASH на борту имеет пока только 256 К - но это кандидат на новое семейство. PIC32 имеет 128 К SRAM, FLASH 512к, мультипексированную шину, FPU не имеет (пока?) - в общем, тоже где-то рядом. Венцом этого класса можно считать автомобильные контроллеры от ST и Freesacle - http://caxapa.ru/169047.html http://caxapa.ru/169257.html Ну и недоступные пока ренесасы SH7450 Series http://www.renesas …450/sh7450_landing.jsp http://caxapa.ru/184362.html 512 к ОЗУ на кристалле + 2М FLASH - это, конечно, дрим чип, но он пока не шибко доступен. При такие объемах памяти он, вероятно, смог бы вместить все типовые задачи (микроконтроллерная периферия, Ethernet, USB и пр). Рассмотрим явно выходящие в мейнстрим контроллеры 1M FLASH/128k SRAM. 1M FLASH - это много, хватит для любых задач. Можно ставить POSIX оську и наслаждаться программизмом. Но! RAM для такого счастья точно не хватит. При внимательном анализе задач такого контроллера видно 3 класса процессов с точки зрения RT: * прерывания - тут все понятно. События возникают асинхронно, долгосрочное планирование шедулера вперед малореально. * высокоприоритетные задачи - как правило, POSIX тут не нужен, хватит простого API типа uCOS (uTRON), главное - быстро и компактно. События возникают асинхронно, долгосрочное планирование шедулера вперед малореально. * задачи управления - тут RT не так важен, +- несколько мс ничего не изменят. Можно делать планирование вперед, т.е. когда шедулер пееключает на такую задачу, он, вообще говоря, может и вычислить - какой из такого рода задач отдать приоритет в будущем кванте времени. Т.е. по сути дела щедулеру надо решать 2 класса задач: hard RT и soft RT. Можно попробовать сделать такую штуку: * RT задачи живут во FLASH и SRAM * POSIX задачи живут во FLASH и внешней памяти. Старый добрый своп :) Пропускная способность внешних шин контроллеров - не мнеее 20 мбайт/сек. Т.е. за 1 мс по шине можно успеть "откачать" 10 кбайт данных "старой" задачи и всосать 10 кбайт для будущей задачи. На слив/залив 64 кбайта уйдет 6.4мс. Вполне близко к типовому тику 10 мс для POSIX задач. За счет многошинной структуры это не будет мешать работе процессора, но возникает одна противная задачка на тему MMU. Желательно, чтобы при каждой выдаче кванта времени POSIX задаче ее данные находились по одним и тем же адресам :) Если MMU нет, но сразу после исполнения одной POSIX задачи мы не можем переключиться на другую - нужно ждать свопа памяти. Если блоки памяти можно перестраивать по адресам как это сделано в CF, то проблемы нет. А вот в ренесасах проблема есть. MMU там нет, и боки памяти фиксированы по адесам. Либо устраивать интерливинг по адресам POSIX задач, что задачу шедулера далет просто чудовищно сложной, либо идея не канает.