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

Попробую пояснить суть своих идей, они шире, чем просто «прикручивание FPGA». Для моих задач помимо микроконтроллерных RT потоков с небольшими объемами памяти (которые надо запускать в классическом вытесняющем окружении и не париться) нужно иметь 3 не совсем RT задачи • IP • Специализированную БД • Высокоуровневую управляющую прогу. В 2М кода влезет все, что я могу себе только вообразить (без GUI)… IP живет поверх GSM модема и не рассчитано на скорости более 10Кбайт/сек (т.е. оно может начать ограничивать скорость 10 кбайт/сек дуплексно – никто не обидится). • Всегда один сокет с сервером. Но сокет извращенный, со всякими хакерскими подходами к «взбадриванию» канала. Несколько лет отрабатывали эти алгоритмы… • IP реализация должна быть очень качественная, «натянутая по полной», SACK - RFC 2018 и много чего еще. • https|IPsec Если эту задачу кормить IP пакетами, и принимать от нее IP пакеты для отправки через мудем, и иметь буфер под пакеты, то задачу можно активизировать раз в 100 мс. Голос никто через этот сокет передавать не будет. Памяти для стека и кучи этой задаче 64к просто выше крыши. БД тоже требует не более 64к линейно адресуемой памяти и большое количество блочной памяти в SDRAM (8 и более M блоками по несколько сотен байт). Эту задачу нужно активировать в среднем раз в 50 мс. Управляющая логика – штука непростая. В идеале, а это некий скриптовый язык, интерпретатор некого байт-кода. В общем, это скорее 128к линейной памяти, хотя и в 64 можно втиснуться. 200мс и медленнее – период активации. Фишка в том, что все 3 задачи иметь в памяти в «вытесненном состоянии» мне нафиг не надо! Задачи могут как ативироваться, так и деактивироваться с «джиттером» в 10 мс (типовой тик RTOS), чего хватит на своп всех моих объектов. Еще может быть файловая система, которую можно поделить на 2 части – медленная часть работы с файловыми структурами и быстрая часть – дать указатель на следующий сектор для записи или чтения уже открытого файла. Медленная часть вызывается раз в 100 мс и аллокирует кучу секторов для уже открытых файлов, а RT часть просто достает указатели из связанного списка и выдает их приложению. Посему идеи OS Contiki – как раз гибрид вытесняющей многозадачности и прототредов – живут и побеждают. Гибридные RTOS – вытеснение + кооперативка – рулят для нового поколения контроллеров. Жопа в том, что их еще предстоит написать. Как и код под них. Вытесняющая часть должна быть очень компактна по ОЗУ, никакого POSIX, стандартов на кооперативку + оверлеи просто нет :) Linux в микроконтроллерах все же лишний. Вот как графический сопроцессор – пусть рисует… Ваще GUI суть зло, не место им в эмбеддед сегменте. Вон путь на 100500 ядерных дроидах живет… В некотором смысле это новый виток старой спирали. Все это начинает напоминать программизм под DOS со всякими XMS (там 640к, у нас уже 512к почти повседневность :) ), создатели Palm с 2Мбайт ОЗУ тоже почти наверняка над чем-то таким бились ночами… Также понятно, что такой подход очень перспективен именно для микроконтроллеров. Что будет после 4М FLASH|512k SRAM – сказать трудно. Когда будет 8M FLASH|1M SRAM – трудно сказать. И будет ли вообще… Ибо, как мы понимаем, одновременно контроллер 1М обрабатывать не будет, значит, какая-то недешевая часть кристалла будет простаивать бестолку. Лучше пару мегов FLASH досыпать вместо вторых 512к ОЗУ. А уж если вместо вторых 512к ОЗУ поставить аппаратный менеджер объектов и менеджер памяти, вообще сказка будет. Если оверлейная идеология пойдет, и будут написаны такие оси и либы, то 1М SRAM может долго не быть – 28 нм в контроллерах станут массовыми ох как не скоро… Также понятно, что C++ будет ключевой фишкой нового поколения программизма. Выписывать все эти оверлеи и системы управления объектами лучше всего на С++, чтобы написал, потрахался, и используешь очень долго. По крайней мере, так думаецца в начале :) Курим С++ :) Разумеется, реализовывать все это надо, начиная с малого. Вначале вообще программная симуляция всего. FPGA первоначально просто блочное устройство, управление памятью и объектами – программно, как одна из задач RTOS. По мере отработки алготримов можно более точно ставить задачу для FPGA кодинга... SAM4S привлекательны: • относительной простотой кристалла. Сравните доку на них и Hercules от TI… • Неплохая дока • Малая Errata • Хорошая поддержка распространенными средами Опять же, для дешевой отработки можно сделать плату all TQFP – SAM4S, Cyclone-III TQFP240 :), SDRAM 32 bit TSSOP есть. Хотя это извращение в наше время :) Вот как-то так получацца.