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

Ну что же, сделаем последний шаг к мировому господству. Доведем до конца мои красивые идеи по отладке. Делаем протокол и шину: * отправленный пакет ложится в память "с другой стороны" с CRC, подтверждением и пр. Скорость 10Мбайт/сек на 1кб пакетах хватит для большинства случаев. * все устройства на шине синхронизируются с точностью несколько тактов тактовой шины. На MachXO2 делаем реализацию периферийного контроллера протокола. Собственно, сам микронтроллер, который дрочит конечное устройство, можно сделать на LatticeMicro8 или на любом внешнем контроллере, тогда FPGA будет для него выделенным контроллером протокола. Делаем лабораторный адаптер нашей бортовой сети: * FPGA * USB для связи с PC. USB 3.0 и WinUSB самое то http://ru.wikipedia.org/wiki/WinUSB * софткор в FPGA * реализации шины и протокола. Софткор решает два класса задач: * обмен между шиной и пЫсюком * если какие из периферийных процессоров требуют низкой латентности управления, и алгоритм этого управления не шибко сложен и отработан, то код этого управления запускаем на софткоре, чтобы избежать пЫсюковой латентности. Собственно, можно и мощный процессор сюда поставить, если надо. Запускаем софт на пЫсюке. * хороший менеджер памяти типа TLSF http://rtportal.upv.es/rtmalloc/ * обработчик данных USB. В конечном итоге данные их некоторой области памяти пЫсюка отображабтся на паять контролеров шины, при этом происходит преобразование всего в C структуры, удобыне для обработки на x86 * синтетический порт uCOS (как пример) * опционально - дополнительнеые процессы со всякими Matlab и пр. Как работает софт на писюке: * реальные задачи написаны портируемо на C и крутятся под управлением uCOS. * отдельный поток "шлюзует" данные между памятью и USB * софтовый эмулятор "менеджера больших объектов" - описанные ранее сблоки больших обектов из связанных списков кусочков памяти * потоки под управлением uCOS - адаптеры внешних процессов. Например, нужно мне преобразовать изображение, а писать боевой код пока некогда. Я запускаю отдельный просесс с ImageMagic, и некий драйвер как поток под uCOS. Поток получил сигнал - картинка в памяти готова, записал ее в файл на диск (RAM Drive и быстрые SSD рулят), передал параметры ImageMagic, получил ссылку на готовый файл, и записал его в память - типа поток под uCOS обработал файл. * всякие разные дебаггеры и логгеры в большом изобилии. Отладили код более-менее и переходим ко второму этапу :) * запускаем эмулятор целевого проца * целевой код запускаем на нам * в отдельных потоках запускаем эмуляторы всякого будущего железа: контроллер нашей супершины и пр. * система сбора статистик и мониторинга - code coverage, использование памяти и пр. ну а далее можно переходить к железу Что мы имеем: * полное распараллеливание задач при разработке. Каждый разработчик дрочит свой контрроллер. Во многих случах, при низкой скорости обмена, допустимой приличной латентности перифериные контроллеры могут общаться с хостом через интернет :) Синхронизировать адаптеры локальной сети можно через навигационный приемник. В иделе надо написать какой-нибудь "сокет маппер" на выделенном серваке в инете: типа один открыл сокет на сервак, другой открыл сокет там же, а сервак программно читает из одного сокета и кидает в другой :) + какой-интерфейс управления, на iPhython, например. * удобство отладки простых RT задач на периферийных контроллерх - никаких сложных осей, во многих слачах вообще без них. Можно использовать умеренно продвинутый народ при отлаженности контроллера шины * непревзойденное удобство отладки сложныз задач на писюке. Это не по JTAG FLASH шить :) Тут все под рукой, можно оперировать гигабайатми данных мониторинга, скажем засосать их в SQL базу и потом дать команду - а сколько таки-то событий было, когда и пр. Это не глазками в терминалке гавно искать :) Ну вот, таки придумал я настоящее :) Придумал я его давно, а Lattice позволил сказку сделать былью...