|
|
предыдущие посты
посты по MPC5200
http://www.telesys.ru/wwwboards/mcontrol/907/messages/18204.shtml
http://www.telesys.ru/wwwboards/mcontrol/908/messages/18473.shtml
http://www.telesys.ru/wwwboards/mcontrol/909/messages/19207.shtml
посты по RT OS
http://www.telesys.ru/wwwboards/mcontrol/909/messages/19261.shtml
===
Собственно, я пытаюсь сам для себя выработать идеологию (и не хочу делать ее секретом, посему и поднял разговор) распределенной во времени и пространстве разработки __любых___ приложений.
Из моего скромного опыта следует, что месяц труда самого заштатного программера стоит больше __любого__ микроконтроллера. А конкурентоспособность фирмы определяется не гордой записью в company profile "Изделие N выпускается тиражем 1м экземпляров в месяц", с скоростью, с которой можно сделать законченную разработку. Полностью законченную, без глюков и с __документацией__.
И самым главным секретом тут является reuse, но даже не кода (это не так уж часто получается, особенно при использовании разных архитектур), а идеологии. Код - он вторичен :)
Простой пример. Та же BCH коррекция. Есть алгоритм Мэггета быстрого вычисления BCH. Он много где лежит с иходниками. Но мало кто знает, что в тех исходниках есть ошибка :). У нас есть вариант, который был честно "в лоб" проверен численными методами (тупой перебор всех возможных комбинаций данных и помех). И мы твердо знаем, что ошибок там нет. Была написана реализация на ASM AVR (было в 2000 году - тогда не было 20 мгц кристаллов, да и на C мы не умели хорошо писать - будем честными). И все круто. Но вот теперь придется переписывать на С, и снова, на всякий случай, проверять. Потому что на ARM как-то тяжело запустить AVR асмовый код :)
А теперь самое главное размышление. Есть проект. Его можно сделать двумя путями.
1. Дешевый кристалл (пусть для примера 10$), и 4 человеко месяца труда (300 $ этот самый человек мес - предположим, я нашел инженеров, годных к употреблению за такие деньги). Пусть тираж прибора - 100 экз. Общая себестоимость 100*10=1000 + 4*300=2200
2. Дорогой кристалл - 20$. 2 человеко-мес труда (остальное взято за счет reuse). 100*20=2000+2*300=2600.
Итого, мы проиграли 400$. Вроде бы можно повеситься :( Но все хитрее, если посмотреть полную картину.
Никогда не быват полного потока заказов. И самое главное - это распределить текущую нагрузку между core team, оутсорсерами и взятыми временно на работу.
Когда есть reuse идеологии, то core team очень маленькая, и ее можно прокормить в "сухой сезон" Когда приходит заказ, __не надо разрабатывать всю идеологию__ проекта с нуля. Берется идеология, куски кода, пишется грамотное разделение задач и вперед.
Секрет использования студентов состоит не в том, чтобы они быстро и задешево что-то сделали (нет задачи, которую бы студенты не решили - ответственно говорю), а чтобы через полгода другая группа студентов не сказала "Это отстой, мы все переделаем, и все будет круто".
И вот если подсчитать расходы конторы в течении года, те самые 400$ очень легко покроются за счет сэкономленного труда писателя доки, например.
В этом смысле мне очень импонирует идеология Unix. Не халявностью, (IMHO, *nix - одна из самых дорогих ОС при реальном использовании за счет труда программистов), а выверенностью идеологии. На протяжении 30 лет эта идеология была под ударом критики различных людей, которые не только критиковали, но и созидали. И то, что устояло, имеет все права на жизнь. Именно этим для меня ценен open source.
Но Linux на AVR (пока?) не поставишь, а разница 3$ за контроллер или 30 иногда важна (далеко не всегда - смею заверить). Вот и стал я искать общие и универсальные куски идеологии все этих OS - от Linux до uCOS, которые не зависят от ОС.
Простой пример. Стеки TCP/IP. Когда в лоб читаешь описание IP - становится понятно, что это нечто страшное. Но когда читаешь описание с "картинками" о реализации этого в BSD, становится чуть менее страшно. А когда читаешь описание http://www.ethernut.de/en/software.html , где четко описано name space, устройство внутренней операционки, то все вообще становится просто.
Самое главное - понять структуру задачи. ___Чтобы в каждый момент времени думать об ограниченоом количестве уровней задачи__. Пусть внутри задачи ест чудовищные по своей сложности подзадачи, которые понять __невозможно__. И это не мешает. Ибо у такой задачи есть интерфейс с внешним миром (а их сложных не быват), как функция в C или архитектурное тело в VHDL. И мы всегда можем написать "заглушку" для такой функции. и отлаживать всю остальную часть в ожидании пока яйцеголовый профессор и 10 его студентов напишут вевлет алгоритм компрессии, которому нет равных в мире. И что самое главное, мы можем взять код от этой группы, и поручить __ другой группе__ проверить его на тестовых векторах. Везде ли там правильно * расставлены :) И если все сделать грамотно, договориться о названиях, все не очень стандартные слова вроде __flash писать как __spword__flash, иметь два spword_IAR.h и spword_gcc.h, то тогда можно будет пускать и на AVR, и на PowerPC 64 бита.
А затем подключить это к нашему проекту и радоваться жизни. При этом математики никогда не узнают о тонкостях устройства RT OS, а Вы никогда не узнаете, как написать вейвлет компрессию. Оно вам надо?
Тот пример с приемом POCSAG, при правильном написании, совершенно не зависит от чипа и ос. Все куски кода можно отлаживать на PC (если код написан грамотно), затем написать маленький примитивный драйвер, и все на ура пойдет где угодно. А отладить драйвер ввода/вывода в порт на контроллере - это как раз и есть задача для студента.
За счет метода конвейризации задач небольшой проигрыш С кода против асма не важен. Памяти при конвейризации надо больше - но постепенно этот вопрос снимается. Если есть mega48 с ценой менее 2$ и 512 байт озу - зачем искать еще что-то? (кроме специальных случаев).
Последнее звено в этой цепи - FPGA/CPLD на хитрый ввод/вывод. Чтобы тупые битовые задачи возложить на железо, оно же обеспечить хоть пикосекундную привязку к реальному времени.
Меня, например, бесит следующее. Есть MMC. 1G карта стоит 200$ и менее, скорость записи у Twinmos до 1.6М_байт_ в секунду. Круто, да?
Интерфейс описан, ничего страшного тем нет, но при программной реализации большой скорости не получить. Точнее, процессор только и будет заниматься, что этой картой.
Есть spartan3 от ксила. 200 к вентилей кристалл стоит менее 20$. Корпуса есть не бга. Я не вижу причин, чтобы не сделать следующий контроллер.
1 часть - обычный сериализатор/десериализатр, как LH7A404, с какой-то примитивной логикой. Для начальной настройки карты и т.д. Для всего, что сложное, но происходит редко.
2 часть - блоковый контроллер. UDMA. есть буфера на 512 байт + ECC. Даем команду передать сектор # такой в буфер № такой. И получаем прерывание - передача завершена. А потом по DMA перекачиваем этот буфер в память основного процессора. И что самое гдавное, ECC аппаратно считам. Запись в карточку аналогично. Затраты процессора при таком реэиме работы - ничтожно малы.
В Spartan2e 300к вентилей влазит JPEG компрессор http://elphel.com, так что не думаю, что такое сделать невозможно!
Что это дает? Простой пример :) Охранная камера. Сработало нечно, и она делает снимки. JPEG? Фиг вам!
Стоит обычный АЦП от филипса. И выдает свои YIV со скоростью 27м отсчетов в в секунду. Пусть кадр будет VGA 640*480=307.2 к байт. 1.5м байта/300к байт = можно писать со скоростью 5 кадров в секунду! 1G/300к=3.5 тысяч кадров!!!, 600 секунд, 10 минут. Охранная информация всегда анализируется постфактум. :) После того, как мы записали кучу кадров, у нас будет много времени, торопиться нам некуда, и, например, LPC22хх программно ужмет все это хоть в JPEG2000. У нас есть__ часы__ времени. Или даже сутки. Надо быстро - выдернули карту, воткнули в картридер, и все быстро на 3ггц писюке просмотрели.
Но нет такого контроллера! Почему? Или я не нашел?
Вот, собственно, почти все мои воззрения на эту тему.
E-mail: 
info@telesys.ru
