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

Большая размышлизма про извращенные пути уменьшения требований по памяти. http://caxapa.ru/304157.html
http://www.gii.upv.es/tlsf/
ATSAM4S16CA-AU 100 - $6.42 (дижикей). 120MHz, Cortex™-M4, 1MB FLASH 128K RAM, 100LQFP. На складе нет. Можно предположить, что SAM4SD32C (2MB FLASH 160K RAM, HCACHE 2KB) будет в опте стоить менее $10, например $8. EP4CE6F17C9LN CYCLONE IV FPGA, 6272 LE, 276480 bit RAM, 179 IO, 256-FBGA (17x17, 1mm) 90 - $14.94 (на складе нет). Маложрущая, но медленная FPGA. EP4CE6F17C8N - более быстрая, но более жручая. Имеет встроенный контроллер памяти до DDR3. Цена та же. EP3C5F256C8 IC CYCLONE III FPGA, 5136 LE, 423936 bit RAM, 182 IO, 256-FBGA (17x17, 1mm), 14.90 на складе в розницу. Меньше LE, но больше памяти. Суть идеи. 120MHz, Cortex™-M4 2MB FLASH 160K RAM HCACHE 2KB - это взрослое изделие. На нем можно многое сделать. Но ОЗУ на множество задач при классическом вытесняющем подходе не хватит. У камня есть внешняя шина, 8 бит, порядка 35Мбай/сек при минимальных задержках. Угробит перфоманс нахрен при использовании под ОЗУ. DMA есть только PDC, память-память нет. Зато есть SD|MMC контроллер 8 бит до 50 Мгц (!). Думаю, при карточке совсем без задержек 30-40 Мбайт/сек выдаст. Делаем так. 64к - RTOS и RT задачи в режиме вытеснения. Обрабтка прерываний. 32к - служебная память для менеджера объектов 64к - ресурс пула задач, выполняющихся в кооперативном режиме. А память расширяем при помощи хитрого свопа. Память однобанковая, однопортовая, но. 32 бита, 120 Мгц - 480Мбайт/сек. 40Мбайт/сек от PDC - это менее 10% торможения по ОЗУ, при этом не каждая операция проца лезет в ОЗУ. Чтобы прокачать 64к, надо около 2 мсек. Процом по внешней шине - жалко ресурс терять. DMA память-память нет. Но!!! У нас есть MMC контроллер! Берем FPGA. * SDRAM контроллер. Специализиролванный, блочный, очень простой. * NIOS-II с работой из внутреннего ОЗУ. 32к под код и данные хватит. Может, часть в SDRAM. * Аппаратная реализация SPI протокола для сопроцессоров * MMC контроллер. Очень простой. Одна команда - записать|считать блок. В ней часть битов адреса сектора - служебная информация. * простой форматтер для приема данные от TV деколера и записи их блоками в SDRAM. А далее водим понятие объекта. Объект имеет номер, максимальный размер, и указатель на элемент объекта. Некое подобие файла. Как устроены задачи в кооперативном пуле. MMU на пограммном уровне :) Задача знает, что за ней закреплены такие-то объекты. Это распределено при компиляции. Есть менежер памяти этого 64к кооперативного пула. Отдельно от всего. Задача, получив вызов "продолжить выполнение", делает следующее. Она вызывает менеджер памяти коопертивного пула и говорит - дай указатель на буфер. Далее она вызывает ОСь и говорит - объект такой-то начиная со смещения такого-то, длина блока такая, помести мне по указателю. Вызовы асинхронные. ОСька при помощи MMC свопа прокачивает нужный блок и выставляет флаг - объект готов. Пример JPEG кодека. Задача говорит - дай мне блок 8 строк изображения. И дай мне второй блок 8 строк. И дай мне большой блок под выходное изображение (будем считать для простоты, что мы жмем в файл меньше 64к, хотя это не принциапиально в рамках рассматриваемого подхода) Ждем готовности первого блока. разбиваем 8Х8, зигзаг, обработка. Закончили - тут глядишь, и вторая пачка строк прокачалась. ОСька решает, что пора эту задачу вытеснить нахер. Посылает ей сообщение "замри". Задача в процессе выполнения постоянно контролирует флаги. При обнаружении замри: * очищает стек вызовов - топает в корневую функцию. Например, абортировав текущее сжатие блока 8 Х 8 * записывает статус - жму такой-то блок и проч в специальный блок статус "задачи" * дает ОСи команду - начать своп таких-то объектов * освобождает регионы вызовом менеджера пула кооперативной памяти. * отдает управление. Далее ОСька запускает другую кооперативную задачу, а процессы свопа объектов идут в фоне. Задча либо сразу запускается в работу по мере готовности своих объектов, либо ждет завершения свопа от предыдущей задачи. Софткор в FPGA занимается менеджментом своего SDRAM по алгоритму типа TLSF (Two-Level Segregate Fit) ->. С аппаратной поддержкой для ускорения Памяти для этого надо совсем немного. Он ставит в соответстиве ID объектов и адреса в памяти, контролирует максимальный размер и проч. По MMC ему приходит команда - 32 бита номер сектора и 512 байт - сектор. 14 бит - ID объекта (16к объектов для реальной системы за глаза), 18 бит - смещение (объекты максимального размера 256к тоже нормально). Либо 12 бит - 20 бит (4к - 1М). MMC можно сделать прозрачным :) Задавать адрес сектора больше реального размера карточки. Данные транзитом идут через FPGA. Если команда укладывается в карточку, то FPGA ничего не делает. Есди нет - то она обрабатывается внутри FPGA, а карточка говорит - "что за херню мне прислали", такой ответ идет в никуда. Контроллер для SPI сопроцессоров устроен примерно так. 2 буфера блочной памяти. Перед началом акта обмена софткор программирует контроллер, что перед началом он должен в выходной буфер положить блок, начиная с адреса такого-то, потом произвести обмен, потом полученный блок положить по адресу такому и выставить запрос софткору. SPI сопроцессор является SPI мастером - удобно программить и SPI скорость максимальная будет. Что мы в итоге имеем: * FPGA как "клей" для интеграции кучи всего * большой объем дешевой SDRAM. Можно сделать блочный обмен с простой ECC типа Хемминга (12,8). Т.е. сознательно похерив часть емкости одной микросхемы SDRAM, повысим надежность. 8М памяти данных достаточно для большинства задач, 128Мбит SDRAM стоит менее $2, при Хемминге (8, 4) получим простоту реализации и аццкую надежность ценой потери половины емкости. * очень экономное использование IO FPGA, что является очень дорогим ресурсом в классе дешевых FPGA. * НЕ трату ресов FPGA на то, что можно взять в контроллерах за 1-2$ - UART, I2C и еще много чего. * почти неограниченые возможности расширения. Можно прикрутить десяток SPI сопроцессоров. * Разумная экономика. 8$ (MCU) + 14$ (FPGA) + 2$ SDRAM = $24. При этом возможности гораздо шире навороченного контроллера за $25. Самокритика. * Сложность программизма будет нехилая. Опять segment:offset маячит :) Отладка всех этих оверлеев тоже не сахар. Оценка перспектив. Вычислительных ресурсов 120MHz, Cortex™-M4 2MB FLASH 160K RAM HCACHE 2KB хватит для очень многих эмбеддерсих задач на годы вперед. Максимум, что нам грозит к 14 году - это 4M FLASH 512k SRAM, что меньше по ресурсам, чем я описал. Но если к такому контроллеру присобачить мои оверлеи - итог будет еще более впечатляющим :) Насчет "мы возьмем китайский 2*Cortex-A9 + 2G SDRAM за $30" - его еще запрограммить надо, и SPI сопроцессоры к этому лялиху будет ох как непросто подрубить... Для реализации задач по графике мой подход не годится - им надо много линейно адресуемой памяти, там точно проще "китайский 2*Cortex-A9 + 2G SDRAM за $30". Вот пусть и будет такой модуль SPI сопроцессор для GUI, экран все рано дороже будет :), а целевую логику будем делать на "контроллерах профессионального уровня". Кучка сопроцессоров очень удобна вот почему. Мы можем не просто добавить в систему мост SPI<->UART, а сделать контроллер modbus на однобаксовос контроллере. И По верхнего уровня будет оперировать только пакетами, а одельный контроллер modbus и написать проще, и автономно отладить можно "во все щели". Мой подход способствует групповой разработке, в том числе силами распределенной команды. Есть небольшой набор внутренних стандартов, компоненты системы испытываются отдельно и независимо. Система получается модульная. Конечно, руки чешутся поставить вместо FLASH контроллера за $8 MCF54xxx 250 МГц и $6 + $5 DDR2 чип памяти, но надежность.... в контроллере все на кристалле, а там ECC на SDRAM нету. Для одиночных изделий нижнего ценового диапазона мой подход покажет результаты "не очень", зато если делать линейку продуктов с жизненным циклом лет 15 (как раз до моей пенсии :) ) - алтьтернатив ему просто нету. Гибкость и слабая зависимость от внешних поставщиков у моего подхода вне конкуренции. SPI контроллеры за 1$ можно вообще менять от партии к партии при полной программное совместимости host кода :), FPGA можно заменить, хост процессор тоже. При грамотном написании кода и ориентации на GCC-like среды ПО будет полностью переносимым. В идеале, конечно, надо вкурить таки C++, чтобы легче портировать базу кода. С оверлеями или нет, все остальное чтобы тоже было модульным. Ну и напоследок :). --> MPXD1010VLU64 40 - $10.71 e200z0h 64 MHz Flash (ECC) 1 MB RAM (ECC) 48 KB Graphics RAM 160 KB QFP176 Последние данные. MPXN2020VMG116 - $14.7. Это совершенно неубиваемый камень с диким перфомансом, который стоит так мало по причине обрезанности внешней шины. Применение к нему механизма "оверлеев" позволит творить чудеса :)