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

Обобщенная идея универсального коммутатора каналов обмена для MCU. По мотивам "кротов, хомяков" -> http://caxapa.ru/771092.html
Итак, берем одну их описанных там FPGA с большим числом IO, и какую-нибудь внешнюю память HyperRAM, HyperBus. caxapa.ru/736367.html Старую, добрую статическую память IS61WV25616BLL-10TLI-TR SRAM - Asynchronous Memory IC 4Mb (256K x 16) Parallel 10ns 44-TSOP II $3 в партии 1к штук. Жрет, кстати, не больше 40 мА при 3.3В - прогресс в технологии сделал свое дело. И расставляем вокруг кучу микроконтроллеров под решаемые задачи. И какой-то один главный микроконтроллер для управления всем оркестром. Канал связи для каждого микроконтроллера выбирается под задачу * относительно низкоскоростные - I2C, UART, SPI (хотя SPI на 50 МГц, который есть у многих MCU, низкоскоростным интерфейсом не является) * среднешустрые - QSPI, SDIO * топ уровень - параллельная шина. Важно, то каждый канал имеет ровно 2 конца - MCU и наш коммутатор на FPGA. Только звезда! Что мы имеем: * нет необходимости адресовать устройство. Внутренние адреса (типа сокета) могут быть, а могут и не быть. Для простых задач заметная экономия байтов в пакете. * минимальная скорость, разные скорости для разных устройств. Упрощение разводки, разгрузка периферийного MCU от ненужной работы * для относительно скоростных интерфейсов четкое разделение на вход и выход позволяет улучшить согласование на печатной плате * снижается количество и протяженность цепей с высокой тактовой * EMI заметно улучшается - управляющий процессор, FPGA и внешнюю память можно под экран загнать. * периферийные MCU можно легко развязать по питанию. Пусть наш управляющий MPU имеет внешнюю шину 66 Мгц 32 бита 4 такта на транзакцию. Т.е. у него скорость обмена - 66 Мбайт/сек. NXP Kinetis K27, K28 могут и побыстрее caxapa.ru/767377.html Если считать что у нас информация обрабатывается пакетами по 512 байт (хороший запас), то задержка на передачу такого пакета - менее 8 мкс. И даже 2 задержки - 15...16 мкс (перегнали пакет, его обработали, выдали управляющее воздействие тоже таким же большим пакетом) не так и критичны для многих реальных задач. Если сделать унифицированный ряд форматов пакетов, то система будет универсальной. Совсем одним форматом обойтись не удастся - 51 однокристалка, которая просто тупо оцифровывает вход своим честным 14 битным АЦП, и "контроллер Ethernet со встроенными мозгами за $3" ( http://caxapa.ru/771771.html ) для эффективной работы должны иметь разные форматы пакетов. Преимуществ у такого подхода просто море. 1. Нет зависимости от MCU. При стандартизованном протоколе обмена замена одного на другой ничего не значит. 2. Разделение труда, использование атусорсеров. Задача аутсорсера четко определена - вот тебе протокол, вот целевая задача, вот устройство, которое будет дрочить тебя по этому протоколу. Решил задачу - получи деньги. 3. КПД использования мозгов разрабтчиков. Пишуший качественный DSP код, умеющий "нарисовать" любые времянки при помощи DMA event системы могут не иметь абстрактного уровня мышления "все есть пакет", который будет в управляющем MCU, а хорошо пишущий абстрактный код родит эпической говнокод с точки зрения hard RT 4. Разнотипность контроллеров и DSP в рамках одного устройства. Нет религии. Выбираем решение задачи и все. 5. Виртуализация и синтетические порты RTOS. Ethernet позволяет достичь латентности <20 мкс в User Space Linux, так что управляющее ПО можно разрабатывать в виртуализированной среде 6. Для целей отладки можно взять FPGA потолще, замутить там несколько софткоров прямо из встроенной памяти, и чтобы FPGA напрямую драйверила гигабитный или 10 гигабитный Ethernet на хост машину 7. Очень долгий срок службы наработанной базы кода. FPGA и управляющий MCU универсальны, их много вариантов и много поставщиков. Контроллеры в любом случае специфичны по периферии, но у них и задачи проще. Переписать обработку конкретных сигналов - решаемая задача. 8. Нет проблемы asm. Если периферийный чип реализует простой алгоритм обработки сигналов и простой протокол - даже full asm проект будет не страшен для поддержки в будущем 9. Точности синхронизации всей кучи MCU может быть любой - достаточно одного сигнала PPS на всех. В целом, я много раз описывал подобные идеи. Отличие - я здесь рассмотрел именно вариант коммутатора пакетов, а не общей шины. Прогресс технологии снизил стоимость такого решения и сильно повысил доступные скорости обмена даже для букашек за $1. Что касается цены - каждый выбирает под задачу. Меня сейчас интересует создание методологии для одного проекта со сроком жизни 15, лучше 20 лет. И это важнее экономии $50 на устройстве (вот $100 меня бы уже напрягли - но я показал, что стоимость оверхеда весьма невелика). Ставка даже не процессорную архитектуру, не говоря уже о семействе, в моем варианте излишне стремная.