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

"Нет ребята, все не так, все не так, ребята!" Простите, немного забегаю вперед. Соотв. материал пишется. 1. Линух не должен быть самоцелью. Может, от Вам и нужен, может и нет - это от задач зависит. 2. POSIX подобные оси - это да. RTEMS, eCos,... 3. Гораздо более важными являются следующие сущности: -- модульное программирование -- синтетические порты Модульное программирование - это когда каждый осмысленный кусок кода - автономный модуль. В нем четко выделены 4 сущности -- конфигурирование на этапе компиляции в зависимости от желаемых параметров; в том числе под хост и таргет -- import - какие внешние сущности (кроме ОС) использует модуль - другие модули, глобальные переменные, либы и пр. -- export - что этот модуль отдает во внешний мир -- OS - какие именно сервисы ОС он использует (запуск задач с приориртетами и пр) Еще один очень важный момент - виртуальные дрова. Из каждого реального устройста нужно делать объект с методами (С++ тут ни при чем). Не просто считать/записать регистр, а, например, команда - считать сектор номер и поместить по указателю и т.д. Тогда все легко виртуализировать. При эмуляции дрова будут сектор из файла читать, а не из флешки - но для остального софта это пофиг. Кстати, например, отлаживать ECC на реальном устройстве упаритесь. А так записали сектор в файл, прошлись "обсирателем", который битики запоганил, и затем смотрите, как Ваша FS с ошибками борется. Все, что касается платформенно зависимых вещей - асмовые вставки, intrinsic functions и пр - в коде должны быть четко обособлены. Т.е. если это не драйвер, то код модуля должен идти на любом хосте и под любым компилером (чего хочешь делай, но должен быть вариант кода для plain C99). Синтетически порты - обязательное условие успеха. Чтобы можно было под win32/Cygwin/Linux поднять "почти" боевую систему с эмуляцией дров. Это кардинально упрощает отладку сложных вещей (чисто алгоритмические вещи отлаживать на target платформе просто глупо - от скорости JTAG это не зависит). Виртуальные драйвера - это пусть как к синтетическим портам, так и к полувирутальным системам, когда железо живет на одном проце, а вся система - на другом. Очень мощная штука! Самое главное, настроить мозги и ограничивать машление (в хорошем смысле слова!!!) Т.е. если пишем модуль - четко прописали, какими сервисами пользуетесь, и ни на шаг от этого. А под какой ОСью пойдет - на самом деле, пофиг :)))) Если четко структуризировать задачу, то все становится линейно. В смысле, результат предсказуем, хотя это не значит, что он легко достижим. Далее, создание корпоративного стандарта на модули кардинально решает проблему аутсорсеров. Задача четко поставлена, тесты четко определены - можно нанимать малознакомых людей, разбивать задачу на мелкие куски. Важно!!! Писать все на С. Не стоит сваливаться в С++ - лишнее оно в embedded (IMHO!). Не стоит забывать про кодогенераторы - очень мощная штука при умелом использовании. http://www.nedbatc …code/cog/index_ru.html http://www.onembed …m/articles/cog-n-make/ http://www.onembed …og-n-make/examples.htm "Кароче", все описанные пункты гораздо важнее спора "Linux or !Linux". После настройки моска становится пофиг, какую Ось использовать. Не в смысле, что Вы их будете как перчатки менять, а в смысле, что они потеряют такое определяющее значение. Как высшим матерством я бы счет создание корпоративного стандарта на обобщенную Ось. Типа такой хитрожопый хидер, в котором описаны прототипы функций для всех осей, который мы можем использовать. И все обращения к ОСи - это макросы или COGины. А зависимости от того, какую ОСь выбрали, все генерится в реальные обращения к ОСи. Естественно, в хидере есть понятие OS_LEVEL=1, OS_LEVEL=2... . Типа если мы пишем простой модуль - нехер ему полный POSIX использовать, пусть юзает то, что есть в uCOS (или даже в FreeRTOS). Если пишем сложный модуль - ну что же, не стоит изобретать велосипед, используем полный сервис. После всего этого на ОСь становится насрать. Запомните - Вы продаете юзеру его ощущения от работы с устройством, а не ОСь. Напоследок - решение проблемы асмовых вставок. Не верите, что это очень просто? А вот и не правы! Что такое процессор? Это некая структура в памяти (регистры + память) + код, который дрочит эту структуру. Не так сложно написать на С эмулятор проца, которы будет корректно управяться с этой структурой. Более того, таких симуляторов написано дофига. То же верно и для всяких MAC и прочих сильно специфичных вещей. Вот нужно написать код, который будет идти на MAC ColdFire. Прежде чем мы начнем бенчмаркить код для достижения максимальной производительности, нехило было бы добиться того, чтобы код в принипе заработал :)) В реальной системе MAC управлятся набором макросов. И есть либы, который оперируют этими макросами. Кульно! Пишем на С эмулятор MAC. Не сильно сложно. Пишем "макрос для макросов", который вместо обращений к реальному MAC вставляет С операторы, который работают с вирутальными регистрами MAC. Отлаживаем код. Потом запускаем _______тот же самый код, но с другим хидером_______ на боевой платформе, и начинаем его оптимайзить на скорость (если надо). COG для такого приспособить - самое то. Последняя часть - не мое изобретение. Это называется JIT - Just In Time compilation. Примянется для ускорения питонов и прочих языков. Просто я применил это для embedded. Блин, тезисное изложение статьи получилось! Просто и понятно даже мне:))))))))))