TDD (Test-driven Development) применительно к embedded системам:

CUnit is a lightweight system for writing, administering, and running unit tests in C. It provides C programmers a basic testing functionality with a flexible variety of user interfaces.

CUnit is built as a static library which is linked with the user's testing code. It uses a simple framework for building test structures, and provides a rich set of assertions for testing common data types. In addition, several different interfaces are provided for running tests and reporting results.

##### Check #####

http://check.sourceforge.net/

Check: A unit test framework for C

Check is a unit test framework for C. It features a simple interface for defining unit tests, putting little in the way of the developer. Tests are run in a separate address space, so Check can catch both assertion failures and code errors that cause segmentation faults or other signals. The output from unit tests can be used within source code editors and IDEs..

Check was inspired by similar frameworks that currently exist for most programming languages; the most famous example being JUnit for Java (www.junit.org). There is a list of unit test frameworks for multiple languages at www.xprogramming.com/software.htm . Unit testing has a long history as part of formal quality assurance methodologies, but has recently been associated with the lightweight methodology called Extreme Programming. In that methodology, the characteristic practice involves interspersing unit test writing with coding (" test a little, code a little"). While the incremental unit test/code approach is indispensable to Extreme Programming, it is also applicable, and perhaps indispensable, outside of that methodology.

The incremental test/code approach provides three main benefits to the developer:

* Because the unit tests use the interface to the unit being tested, they allow the developer to think about how the interface should be designed for usage early in the coding process.

* They help the developer think early about aberrant cases, and code accordingly.

* By providing a documented level of correctness, they allow the developer to refactor (see www.refactoring.com ) aggressively.

* That third reason is the one that turns people into unit testing addicts. There is nothing so satisfying as doing a wholesale replacement of an implementation, and having the unit tests reassure you at each step of that change that all is well. It is like the difference between exploring the wilderness with and without a good map and compass: without the proper gear, you are more likely to proceed cautiously and stick to the marked trails; with it, you can take the most direct path to where you want to go.

#####

Все здорово, но применительно к embedded вещам надо:

* тестировать реальный код реального компилятора, с использованием реальных библиотек

* тестировать все это на реальном проце (либо на полноценном симуляторе оного)

* измерять временные характертистики кода

* не зависить (или слабо зависить) от embedded ОСи

* иметь предсказуемой поведение системы при полном креще тестируемого кода

Обе вышеописанные системы неплохи, но этим требованиям они не удовлетворяют. Хочется вместо тестирования plain C (которое, строго говоря, можно проводить на любой платформе) перейти сразу к целевому тестированию.

Понятно, что писать тестирование для С программ на самом С (пусть даже с использованием достаточной удобной либы как в CUnit) - это самоубийство. Нужен некий ОО скриптовый язык, который резко сократил бы количество писанины. При этом скорость работы tets engine волнует умеренно - все равно он будет выполняться на быстром пЫсюке.

=================== Мои идеи ===================

##### Тестирование одиночной функции #####

Есть функция test_func (). Ее надо протестить. Юзаем GDB.

Пишем test framework:

декларация всего необходимого для test_func ();

a=0;

for (;;a == 0){

пустрой оператор 1;

test_func ();

пустрой оператор 2;

}

Сама функция живет в отдельном файле. Framework живет в своем файле. Собируем, запускаем.

Ставим break points на пустые операторы (в идеале пользуемся аппаратным break points).

Дошли до 1. Через GDB задали значения для всего, что нужно для данного сеанса тестирования test_func. Go. Остановились на втором операторе. Задампили все значения переменных, задали новые. Надо завершить тест - задаем a=1. Go. Первый брейк-поинт может отсутствовать.

Основной кайф GDB состоит в том, что он позволит иметь _ОДИНАКОВЫЙ_ интерфейс к нашей тестируемой функции во всех случаях:

GDB -> виртуальный симулятор ядра (пример: PSIM)

GDB -(COM | Ethernet)-> GDB Stubs на виртуальном симуляторе ядра + периферии (пример: SID, skyeye.org, )

GDB -(COM | Ethernet)-> GDB Stubs на реальном железе

GDB -(JTAG)-> реальное железо

Еще один кайф состоит в том, что не надо "упаковывать" данные в printf (), а затем распаковывать их. Количество отадочного кода тоже резко уменьшается, и хотя он будет жить под #ifdef - все равно, чем меньше кода в боевом приложении, тем лучше. Вместо кода в основном приложении получаем код в тестовых скриптах, что гораздо правильнее.

##### Тестирование модуля - совокупности функций #####

То же самое, но test framework будет поразвесистее.

##### Тестирование драйвера #####

Аналогично тестированию функции (но не все дрова можно так протестить). Например, для COM порта делаем hardwarer loopback и пишем тест: отправить пакет - принять пакет. Ну и контроль целостности.

##### Тестирование в реальном времени #####

Собираем тестровую систему:

* embedded ОСь

* Dhrystone тест как отдельную задачу для контроля производительности

* драйвер; софтовый модуль

* test framework

Идея test framework:

a=0;

for (;;a == 0){

interrupt disable ();

timer_freeze ();

пустрой оператор 1;

interrupt enable ();

timer_release ();

test_func ();

interrupt disable ();

timer_freeze ();

пустрой оператор 2;

interrupt enable ();

timer_release ();

}

timer_freeze (); timer_release (); нужны для того, чтобы у ОСи крышу не сносило, пока мы по регистрам и по памяти проца лазим. Иначе таеймер тикает, и после "отпускаяния" ОСь попадент в неизвестное состояние.

Тестирование в части реального времени потребует free running timer (timer_test) нужной разрядности и выглядит примерно так:

* измерили Dhrystone на "чистом" проце - только ОСь и одна задача под ее управлением

* настроили все для тестирования

* запустили timer_test

* запустили процесс Dhrystone

* запустили test framework

* вернулись из test framework

* остановили процесс Dhrystone

* остановили timer_test

* посмотрели, какую производительность показал Dhrystone

* проверили результаты test framework

Очевидно, что при помощи test framework мы можем задать максимально возможную нагрузку на дрова системы, а затем оценить "запас по процессору".

Понятно, что автоматизировав процесс, мы можем проводить длительные тесты для обнаружения тонких аппаратных глюков.

=================== Автоматизация тестирования, или зачем нам DejaGNU ===================

Все описанные выше процедуры можно проводить вручную - но это для hardcore мазохистов. Любому нормальному человеку становиться понятно, что все это надо автоматизировать.

DejaGNU для этого и создана. Она:

* обеспечивает инвариантность взаимодействия с девайсом независимо от канала связи

* удобный механизм генерации тестровых воздействий

* такой же удобный механизм анализа отклика

* автоматизация ведения логов

Ручная же отладка потребуется только в случае неожидаемого провала теста - чтобы понять, что к чему.

Думаю, если сильно извратиться, то можно полностью автоматизировать процесс тестирования. Т.е. из репозитория собирать фнкцию, ее test framework, запускать, запускать соотсвтуюзий скрит GejaGNU и т.д. Конечно, попотеть придется, но оно того стоит.

=================== Замечание по средам и процессу отладки ===================

Вот, собственно, и приплыли. Начиная с этого момента GNU форЁвА! Ибо коммерческие тулзы такого класса, вероятно, существуют, но разденут даже богатую контору - в этом даже и не сомневаюсь, ибо это уже "взрослые" технологии разаработки (это Вам не в ИАРе недопатченном код дебажить). Наличие исходников тоже становится стратегически важным - ибо такая система внутри фирмы создает один раз на многие годы (десятилетия), и зависимость от кого бы то ни было стратегически не допустима!!!

Я не знаю, какая скорость прогона тестов в итоге получится - но меня это даже и не волнует. Ибо тут во всей красе предстает юниксовая идеология скриптов. Немного напрягли голову, нарисовали скрпиты - и все, дальше нас ничего не волнует. Пусть тесты идут хоть несколько часов, хоть несколько дней - все равно есть чем другим заняться. Иногда переключаешься в окошко теста и смотришь - а какой там % выполнения, и не закрешилось ли все.

=================== Взаимоотношения с аутсорсерами ===================

Сильно упрощаются. Перед написанием каждой фукции пишется тест для нее. Также тесты для модулей.

If тест неполный - $--, ибо это уже нарушение договора.

If мухлеж с тестами - "асфальтная болезнь" в хронической форме.

Причем работы полностью автоматизирован: прошли тесты - получил бабло; не прошли - получил по шее.

Тесты для функций пишут авторы функуцйи. Тесты для важных модулей пишут други люди (не разработчики).

=================== Выбор контроллера ===================

С топовым контроллером все понятно - PPC. Вопрос в мелких контроллерах для lite вариантов. Базовые требоваия к такому контроллеру: Ethernet, много памяти.

##### FLASH #####

Если каждый раз тестовый код прошивать по FLASH - дырка там протрется очень быстро. Отпадает.

##### FLASH + SRAM #####

STR91 + внешний SRAM был бы идеальным вариантом, если бы не медленная работа с внешним SRAM.

##### FLASH + SDRAM #####

Это и есть идеальный выбор контроллера. FLASH хорошо бы внутренний, но можно без него, а вот SDRAM контроллер + Ethernet необходим.

Варианты:

* AT91RM9200 - контроллер на все времена. Ему бы еще Public порт eCos...

* EP930xx - как-то недолюбливаю я Cirrus.

* LH7952(4 |5) - замечательные контроллеры, но на них нет порта eCos, RTEMS, что печально.

* Samsung S3C4510B, S3C4530A - отлично, есть eCos, но нет -40, производительности может не хватить

* ColsdFire - замечательная вещь для данной идеологии. По сотношению цена/ресурсы им трудно найти конкуренцию. Например, 100 Мгц Coldfire c внешней шиной, DMA, MAC 32 бита, 64 к SRAM на кристалле, 8К универсального кеша, много, много всего MCF5270AB100 (PQFP!) в партии 25 штук на http://www.digikey.com стоит 12$ - почувствуйте разницу...

Кстати, BGA у ColdFire на редкость продуманные - 1 мм, 4 ряда - так что на 4-х слоке 4 класса разведется без вопросов (образцы до 5 кв. дм при заказе в PCB Technology будут стоить 250$ - можно пережить). Свинцовые корпуса также досупны - а при таком раскладе запаять его на плату сможет квалифицированный ремонтник сотиков

Например, на MCF5282 есть полный порт RTEMS с GDB Stubs. На eCos полный порт есть только от eCoscentric. Но зато на eCos есть порт для MCF5272 (но без Ethernet) - тоже отличный камень.

Более подробно о ColdFire:

FreeScale (Motorola) ColdFire - наши мольбы о !BGA услышаны?

http://www.caxapa.ru/echo/arm.html?id=63110

http://electronix.ru/forum/index.php?showtopic=18754

Собственно, вначале я осознал все описанные тут идеи, потом стал шерстить по контроллерам, нашел много интересного в ColdFire - поэтому и появился пост про ColdFire. :)

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

dmivs 0

20 июля, 2006

Опубликовано 20 июля, 2006 · Жалоба

Хочу еще обратить ваше внимание, что исторически первый порт ucLinux был именно на Coldfire (5272), и, как я понимаю, ColdFire все еще в лидерах в данном проекте.

По поводу того что "его производит только одна фирма".

На сайте Freescale все еще можно купить 68000 процессоры! Не забываем год старта 68000 - если я не ошибаюсь, 1979.

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Evgeny_CD 0

20 июля, 2006

Опубликовано 20 июля, 2006 · Жалоба

Хочу еще обратить ваше внимание, что исторически первый порт ucLinux был именно на Coldfire (5272), и, как я понимаю, ColdFire все еще в лидерах в данном проекте.

Да, 5272 - замечательный камень! Хоть и древненький, но по возможностям даст жару многим современным ARM'ам.

uClinx на ColdFire действительно весьма популярна.

По поводу того что "его производит только одна фирма".
На сайте Freescale все еще можно купить 68000 процессоры! Не забываем год старта 68000 - если я не ошибаюсь, 1979.

:a14: FreeScale! Вот это серьезный подход к делу!

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Evgeny_CD 0

20 июля, 2006

Опубликовано 20 июля, 2006 · Жалоба

Догнал - II: все то же самое, но гораздо проще :)

Пишем функцию или кучку функций. На нашем специальном макроязыке описываем, какие у всего этого хозяйства входные и выходные переменные.

При помощи COG

http://www.nedbatchelder.com/code/cog/index_ru.html

http://www.onembedding.com/articles/cog-n-make/

http://www.onembedding.com/articles/cog-n-make/examples.htm

автоматически (по заранее разработанной универсальной программе) генерим test unit, который:

* принимает по внешнему каналу связи от пЫсюка данные, запихивает их во входные переменные

* тестирует код с этим набором данных

* выгружает переменные во внешний пЫсюк.

* повторяет, если надо

Вся эта загрузка-разгрузка данных может быть довольно геморройной (пример - структуры, они могут быть по разному упакованы; индейцы), но в общем это конечной сложности задача.

Тогда задача для тестировочного скрипта на пЫсюке выглядит так:

* генерация кода test unit

* сборка тестового проекта (make и пр.)

* обресетить плату

* длождаться загрузки монитора

* по TFTP загрузить модуль, запустить

* по заданному каналу связи установить связь с test unit

* передать/принять данные

* анализ, новые данные. Работа с данными тестирования производится "подскриптом", который разработан в процессе разработки тестируемого модуля.

Основной кайф такого подхода состоит в том, что он не зависит ни от чего: ни от отладчиков, ни от ОСей, ни от компилеров. Гавное, чтобы на целевой плате были:

* Ethernet

* памяти побольше

* монитор, который TFTP понимает.

Что касается работы с Ethernet из тестируемого приложения, то либо использовать функции монитора, либо прикрутить LwIP - не так уж он страшен.

В результате можно создать совершенно монстровую тестовую конструкцию без обращения к тяжелым ОСям (eCos, RTEMS).

В качестве скриптового языка для автоматизации всего этого процесса Python подходит просто идеально. При некотором усердии, полагаю, можно полностью автоматизировать тестирование целого проекта. Есть списком модулей, далее автоматически запускаются и собираются тесты....

"Нас не догонят...!"

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Evgeny_CD 0

20 июля, 2006

Опубликовано 20 июля, 2006 · Жалоба

А в свете этого MCF527 (0 | 1) выглядят просто хитом сезона.

У него немного более простой DMA, чем у 5208. Зато сами чипы уже продаются. 100 Мгц Coldfire c внешней шиной, DMA, MAC 32 бита, 64 к SRAM на кристалле, 8К универсального кеша, много, много всего MCF5270AB100 (PQFP!) в партии 25 штук на http://www.digikey.com стоит 12$ - почувствуйте разницу...

Портировать uCOS на него (можн переписать порт MCF5282 -камни похожи) - и вперед, lite контроллер готов!

Схема отладочной платы на MCF5271 есть (правда, BGA вариант - но это не страшно), исходники dBUG имеются - так что все готово!

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Evgeny_CD 0

20 июля, 2006

Опубликовано 20 июля, 2006 · Жалоба

По поводу того что "его производит только одна фирма".
На сайте Freescale все еще можно купить 68000 процессоры! Не забываем год старта 68000 - если я не ошибаюсь, 1979.

Верно, 79.

http://groups.google.ru/group/comp.sys.m68...6ada34aaf5ae7e6

Motorola introduced its first microprocessor in 1974: the 8 bit MC6800 with 
an extensive line of support peripherals soon available.  The MC68000 was 
introduced in 1979 and was soon followed by a host of 16 bit peripheral 
chips.  The 6800 and 68000 families soon became very popular due to their 
straightforward architecture and simple and easy to use bus connections.   
The original 6800 evolved into the 6502 (MOS Technology ie Apple ][), 6802, 
6805, 6809, HC11 and the HC16 series.  Motorola also manufactured an unusual 
one (1) bit CPU called the MC14500 Industrial Control Unit (ICU).  It is 
still listed in their current Master Selection Guide.

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Evgeny_CD 0

21 июля, 2006

Опубликовано 21 июля, 2006 · Жалоба

Развитие идей по упрощенной отладке.

Оставим пока в покое ОСи.

Вот есть у нас модуль, который надо оттестировать.

Натравливаем на него ctag - получаем файл с именами всех сущностей. Вручную "парсим" его (Ctl-Y), оставляя только то, что надо для тестирования. После парсинга должны остаться:

* список include для тестовой main

* список имен переменных (элементы структур приводятся с полными именами)

* шаблон для обращения к тестируемому модулю

(надо придумать, как сюда засунуть данные о типе переменной - пока можно и руками)

Запускаем специальный скрипт, в качестве параметра ему - этот файл.

Скрипт автоматически генерит при помощи COG тестовый main.

Перво-наперво разбираемся с переменными: составляем массив структур вида (для каждого элемента списка переменных)

const char name = "имя переменной №1 из списка по порядку"

* address = имя переменной №1 из списка по порядку // указатель на переменную

size = sizeof (имя переменной №1 из списка по порядку) // длина переменнной

Далее по шаблону обработка команд - RUN, STOP, DUMP, ну и прочее.

Также вставляем в тело собственно сам код для тестования модуля :)

Компиляция, сборка, загрузка, запуск, ждем команды на входе в тестовый кусок.

Вначале просим list переменных. В этом листе как имя, так и emun для переменной - чтобы потом было проще к ним обращаться. Нам отправляют блок данных, мы проверяем - то ли мы вообще тестируем :)

Далее формируем пакет на установку переменных в нужное нам состояние. Выдаем его, команду установить и т.д.

Запускаем тест. Сами слушаем сокет (или другой интерфейс) - ага, вышли из теста.

Скачиваем к себе переменные, анализируем. Повторяем по новой с новым набором данных или пересбока для другого теста.

После файла сущностей мы пишем тестировочный скрипт. Типа чего задавать, чего анализировать, как принимать решения. Этот скрипт вызывается некоей "большой сущностью" test suite для полной автоматизации процесса.

При некоторых ограничениях (типы переменных) выглядит очень здорово, согласитесь.

Если все сделать правильно в плане автоматизации, то можно вообще оптимизировать "нипадеццки" Например, мы отлаживаем блок DSP, надо (кроме правильности) выжать еще и скорость. И тут возникает ковеер, кеш, и много чего - что на симуляторе очень трудно отсимулировать (и всегда есть вероятность того, что симулятор не то симулирует).

В тестовый main добавляем работу с таймером, запоминаем таймер перед входом в тестирование и после выхода. Пишем несколько вариантов кода, и после завершения работы всех скриптов (пусть они хоть час крутятся!!!) мы получаем аккуратую табличку - время выполнения в зависимости от варианта и опций компилятора. За время тестирования мы написали следующйи кусок кода, и процесс отлично конвейризуется!!!

Заодно становится понятны временные характеристики кусков системы (причем, затем, до того, как собрана вся система!!!). Можно по ходу менять структуру системы, приоритеты и пр. Т.е. результат разработки становится все более и более предсказуемым.

Эту идею можно несколько расширить для "отладочной печати". Т.е. вот отлаживаем кусок кода - а он нифига на идет! Ставим в него debug_printf (), debug_scanf (), , автоматически собираем вокрух этого куска тестовый main, и запускаем все это на исполнение. Скрипт автоматически из нашего "разрабатываемого файла" делает тестовый файл, дополняет его внешними прогами и пр. make - рулез!!!!!

Вообще, делатели JTAG в моем понимании должны как огня бояться идеологии мониторов. Ибо при помощи простейшего монитора, который может принять прогу извне и запустить ее на исполнение, получается абсолютно универсальная среда разработки для embedded систем (с учетом описанной выше скрпитовой идеологии от монитора большого ума не требуется - он может быть примитивен). И нет необходимости платить несколько k$ за JTAG (я говорю о "взрослых" JTAG) за каждую архитектуру и каждое рабочее место.

Остается еще много тонких вещей, связанных со стеком и пр.

!!!! Эту идеологию отладки можно расширить и до низкого уровня. Как отладочная печать (приведено выше), ставим COG кусок - задампить регистры процессора (и периферии - если надо). COG вставлят нам кусок кода, который это делает. Опять же при помощи скрипта можно обработать эти дампы - чтобы не искать нужные данные в куче экранов или длинных файлах логов.

Я изобрел "Unix". :)))

Над всем процессом разработки и отладки приложения есть верхний уровень - скриптовое управление. И если разработчик научится при помощи скриптов управлять всем этим, то его возможности резко повышаются.

О вреде стереотипов мышления. :))

Когда-то я сам заводил Радио-86РК. И идеология мониторов для меня не новинка.

Потом были 51 и мелкие AVR, там тяжело сменить программу без перепрошивки чипа, и это все как-то забылось. Кстати, заметим, при помощи Avreal эта идеология вполне будет и на AVR работать - только контроллеры нужно признать "расходным материалом" по причине протирания дырки во флеше. :)

Потом ARM, и JTAG как нечто доступное только "взрослым пацанам".

Тепепь я понимаю, что если "разуть мозги", то все это условности.

Самое главное для высококлассного разработчика - мыслить обобщенными категориями. Прописная истина, но увы, про нее так легко забыть. И скатиться на уровень мышления "а в IAR это делается так".

Понятие скрпитового объектно ориентированного языка становится главенствующим. Будет это Python, или какой-нибудь REXX - это же дело вкуса. Все сводится к:

* редактор - универсальный редуктор для работы со всеми видами текста

* компилятор и прочий тулчейн - это нечто, что при помощи скриптовой оболочки приведено к удобному и единообразному виду

* интерактивный шелл. Тут сказать особо нечего - желающие смотрят http://ipython.scipy.org/

И стиль мышления должен быть такой. Надо мне нечто откомпилировать. Я не вспоминаю F что мне надо нажать в IDE. Или в какую менюшку слазить. Я просто в интерактивной консоли задаю compile (ну ли в каком-нибудь конструкторе графических интерфейсов рисую безумно красивую кнопку compile - если мне делать больше нефиг). И оно все само должно сделать!

Разумеется, нет никакой необходимости задавать все эти горы параметров командной строки. Нужно в каждый момент времени думать только над одной задачей.

Есть понятие обобщенного компилятора. Делаем объект в питоне. Берем конкретный компилятор - и встраиваем его в нашу систему, задавая все необходимые опции. Все, отложили доку по компилеру в сторону - начали с исходниками работать. Настроили рабочую среду - работаем с таким-то компилером, такой-то вариант конфиграции, репозиторий кода там-то, директория проекта вот здесь, либы, хидеры - тута. comlipe - и все само срабатывает. Открывается редактор и показывает, где кто обматерился. test - и описанная выще процедра автоматического тестирования понеслась.

****************** Выводы ****************

1. Все истинно профессиональное должно быть с командной строкой. GUI - на любителя, но оно не должно быть определяющим.

2. Мышление должно быть структурированным. В каждый момент времени количество сущностей по вертикали (различная степень детализации) и горизонтали (над которыми размышляешь одновременно) должно быть минимально. Так сказать, "объем мышления" должен быть минимален. Нужно натренировать мозги, чтобы очень быстро переключаться между "точками зрения".

3. Учить скриптовые языки. Они должны стать "продолжением мысли". И основным "рабочим местом" должен быть не IDE, а окно шелла и окно редактора.

4. Выработать практику "конвейризации работы". Т.е. думаешь над одним, в это время в фоне собирается что-то другое, автоматически тестируется третье и т.д. В каждый момент времени ты не отвлекаешься, а затем по командам внутренного шедулера переключашься между задачами.

5. Надо следить за собой, отдыхать и отвлекаться, чтобы в результате бесконечной работы над собой не оказаться в дурдоме.

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Doka 4

21 июля, 2006

Опубликовано 21 июля, 2006 · Жалоба

=================== Книги по теории XP (Extreme Programming) ===================

http://rapidshare.de/files/7262311/Extrema...ek.pdf.rar.html

9.84 MB

Кент Бек

Экстремальное программирование: разработка через тестирование

Test-driven Development by Example

http://rapidshare.de/files/7288810/extreme...amming.rar.html

2.19 MB

Экстремальное программирование

Extreme Programming Explained

у меня вопрос банально-бытовой =)

: в какой последовательности их читать?

.

PS: еще, но это совсем не по теме, но к автору: во всех этих ОСях не копенгаген, и вообще пока опыта работы с ними не имею, наверняка тема поднималась уже (тогда если возможно - ссылку на нее) . вопрос такой: критерии выбора и eCos круче других?! (eCos vs uC/OS-II vs uCLinux)

я так понимаю основное преимущество: наличие порта под конкр. проц и возможность полноценной отладки прог под ней на РС?

т.е. непонятно от какой печки плясать:

от проца, на котором хотелось бы...

или

от самой концепции проекта и продуманности тестирования и отладки (пусть даже нет порта под проц - типа затраты на портирование будут перекрыты удобствами (в т.ч. и отладки) выбранной ОС).

Цитата

Войти

Evgeny_CD 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

dmivs 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Evgeny_CD 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Evgeny_CD 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Evgeny_CD 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Evgeny_CD 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Evgeny_CD 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Doka 4

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Присоединяйтесь к обсуждению

Обзор

Активность