Всем привет
Есть задачка разработать автомобильное устройство с линуксом на борту. Процу большая производительность не нужна. Надо выбрать с минимальным токопотреблением и возможно готовым фреймворком управления питаем и частотой.
Если кто нибуть проходил данный путь, посоветуйте плиз. Мои познания пока ограничены асортиментом план с starterkit. Как вариант iMX233 думаю применить..

Вы уверены, что без Linux в данном случае не обойтись ?

Так это же главный и единственный пункт ТЗ. Как же можно обойтись?
Главное - чтоб там линух был, остальное - не нужно.

По соотношению цена-производительность + поддержка производителя одним из лидеров отсаются Самсунговские АРМы (S3C2410) и его последователи. Из нового относительно и достаточно мощного DM3730 от Техаса, относительно недорогой кит Биглборд ХМ. Большая часть остальных кандидатов - (Broadcomm, семейство Allwinner) - отсеиваются из за отстутсвия нормалной документации. Так что при всем многообразии выбор не так уже велик. iMX - не особо в теме..опыт общения с Freescale достаточно негативен - кривость SDK и отладочных средств (могу ошибаться)

EnergyMicro - микропотребляющие ARMы....

Бегло глянул - они без MMU - Linux не поднять.Это в принципе. Ну и ресурсы микроконтроллерные, слабоватые.
Критикам "Линукс на борту" - главное преимущество - готовые наработки, а не как в теме про STM народ то FS пишет, то стеки IP, то еще какой-то велосипед по 100500 разу в истории изобретает. А время идет..

To DASM
Спасибо за наводку. Буд ковырять даташиты гнусмаса.


Остальное нужно, CAN одно из этого остального. Но его даже если встроенного нет, я внешний поставлю.


Совершенно верно. Мне уже надоело каждый раз заново прикручивать FS, PPP, TCP/IP и радоваться тому что удалось пакетик в сеть передать или файлик создать на SD карте. Пол линухом я привык что это все у меня есть по умолчанию.
Попробовав встраиваемый Linux, мне уже не охота возвращаться обратно...

А я вообще раньше не был знаком с Линкусом, пришлось изучать ради эмбеддед, но буквально через месяц я уже и на десктопе сменил систему на убунту (хотя чуствую что пора уже более взрослый дистр ставить) а всякие пикады и прочее запускаю под VirtualBox c виндой. По Гнусмасу гляньте кит mini2440
Но в наше время лучше DM3730 - нааамного мощнее, Full HD h264 только в путь тянет на своих 6400 MMACS

С самсунговскими S3C24xx надо смотреть внимательно на предмет статуса EOL.
У Freescale лучше смотреть серию iMX28, есть контроллеры в том числе и с CAN на борту.
Ну и мелкие TI не забудьте - серии AM17xx и AM18xx.

DM3730 это и есть AM (3715)но с ускорителем на борту
Самсы да, старые, не очень в этом плане советую

Да, я в курсе Просто ТС упоминал в качестве варианта iMX233, что гораздо ближе к AM1, чем к AM3.

Я делал линукс-плату на i.MX233. Удобно, что стабилизаторы напряжения - на кристалле процессора.
Нужно всего три микросхемы: процессор, DDRAM, NAND.
Но линукс был портирован плохо. Обратите внимание, что Data Sheet от 2009 года и до сих пор Preliminary.

Итэлма делает процесорные модули с imx233 для навигатора Калины и Приоры, делает тысячами, комлекты и на вторичный рынок попадают. В модуле есть DDR, NAND, eMMC. С документацией там все нормально, процессор достался Freescale от Sigmatel, а вот у самого Freescale бардака в доках хватает, например, Display Processor один и тот же идет в нескольких поколениях imx51-imx53-imx6, а раздел про него так и не дописан.

А что, iMX славится низким потреблением? Какое то шестое чувство подсказывает мне, что до омапов, квалкомов и самсов не близко.

А автору очевидно нужен готовый модуль типа биглбона, а не процессор. А еще лучше сказали бы что за задача.

Подробности описывать не могу, нельзя на всеобщее обозрение выносить.
Это автомобильный контроллер, с возможностью автономной работы от встроенного акумулятора. Линух нужен для упрощения реализации, на обычном МК реализовать будет тяжело. Процык нужен не прожорливый, документирован и с хорошо отлаженным BSP.
Из инфы выше понял что самсунг 2410 староват. Буду изучать как с остальными дела обстоят которые назвали.

Вот это меня всегда интриговало, как люди определяют, что на линуксе будет проще реализовать.
Да еще в автомобиле с совершенно непредсказуемой электромагнитной обстановкой.

Да еще и с Единой Россией во главе. Какой уж тут Линукс. Еще бы связь понять.

Такие люди не хотят (как будто боятся) изучать глубоко CPU, периферию, как с ней работать, ожидают что некие "чудесные драйвера линукс" написанные хрен знает кем с хрен знает какой кривости руками всё чудесным образом за них сделают. В результате получается монстр, внутри у которого что-то творится (что именно - такие кодеры понятия не имеют), оно то работает, то вдруг глючит в совершенно неожиданных местах. Начинаются шаманства с задержками, перемещениями по областям памяти, заменами дров и версий в попытках это заставить хоть как-то работать...
И это всё с огромными ресурсами (производительности, памяти, лишних микросхем и т.п.) потраченными сверх всякой меры на данную простую задачу...
А потом ещё оказывается, что некоторые задачи (простые без наличия линуха), но требующие реалтаймовости (которую линух не может дать) или нестандартной работы с периферией (не заложенной в индусских дровах), никак невозможно реализовать на данном жирном CPU из-за наличия линуха, и приходится схемотехникам добавлять ещё отдельный контроллер для решения этих задач (что сразу порождает необходимость в дополнительном программисте и всякие проблемы типа - протокола взаимодействия, обновления ПО этого контроллера в работающей системе и т.п.)...
В результате - получается поделие с кучей неадекватных ограничений типа: невозможности выключать питание в произвольное время (из-за FS), временем старта системы порядка минуты (когда подобная задача реализованная без линуха стартует менее чем за секунду) и в это время тож нельзя питание отрубать, требованиями жирного CPU + всякие NAND и NOR с параллельными шинами и т.п.
Реальное время разработки такого поделия (с поисками различных плавающих багов из-за чужих дров) в результате значительно превышает время решения "stand alone", которое если бы было реализовано, давно бы уже нормально работало.
Зато можно гордо заявить заказчику "Linux embedded!"....

PS: К сожалению очень часто приходится в последнее время сталкиваться с этим в моей практике...

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

Ребята! Разговор ни о чём. Всё зависит от квалификации и опыта разработчика.
Если вы не не копенгаген в чём-то то это не означает что и остальные тоже.
Для справки - линукс тоже можно при должном умении загрузить за секунду...

Гм... Это типа шутка такая? Как будто написание программы - это изучение CPU и периферии. Ну давайте по порядку:
1. FS. Пусть это тривиальная FAT12/16/32. Здесь нужно разобраться не столько с драйвером флеш-памяти (SD, SPI, EMC), сколько с реализацией файловой системы. Она хоть и не очень сложная, но повозиться месяцок придётся.
2. Сеть. Драйвер MAC штука не тривиальная, но по сравнению с документом RFCxxx на несколько сотен страниц - детский лепет. А "дополнительные" протоколы типа PPP и т.п.?
3. USB. Там можно застрять на долго, если нет опыта.
4. Графика на дисплей. Ещё месяцок...

Потом всё это дебажить, искать ошибки.

Можно взять готовые реализации файловой системы как FatFS, для сети есть куча свободно выложенных стеков таких, как uIP; даже для USB можно найти готовые и бесплатные реализации стеков. Но чем это будет отличаться от драйверов Линукса, которые

Т.е. в любом случае Вы рекомендуете писать всё ПО самому с нуля, если нет предыдущих наработок.

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

ну вот, пока излагал свои речи, уважаемый demiurg_spb сказал кратко, и по делу!:)

Если ни разу не ходить по длинному пути то никогда не придешь к люниксу за 300 мСек.

А при еще большем умении и за 6 часов тыц

А он Вам нужен за 300 мсек? Прелесть линукса вовсе не в загрузке за 1 секунду. Это полноценная ОС, которая имеет право существовать в своём сегменте устройств.

Самый главный вопрос - ЗАЧЕМ???
В ТЗ на устройство не говорится к примеру что нужна FS, а нужно просто хранение данных в энергонезависимой памяти. Либо вообще не нужно никакого хранения, а только ПО запустить.
Но ставится линукс, и вот - нужно уже и файловую систему поднимать, чтобы он жил.
И всё что Вы перечислили - это требования поставленной задачи? Или всё-таки требования линукса?
Зачем мне всё это реализовывать если по ТЗ это не нужно, а нужно только для линукса??
И потом - в контроллер управления кофемолкой ставим линукс и пошло поехало - и проц жирный нужен и FS нужна и езернет для отладки и куча всего остального.
Потом оказывается, что кофемолке оказывается нужно минута чтобы загрузиться, а если нетерпеливый пользователь передумает и выключит её не дождавшись, то у неё может эта самая FS слететь....

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

Ага, чаще всего и не говорится. Только вот упрвляться с сотней имиджей (если у Вас присутствует дисплей), десятком вариантов настроек, таблицами коеффициентов и прочей ерундой без FS - очень себя не любить...

Простите, а Вы это ТЗ видели? Автора темы как раз и просили его опубликовать, но он не может в силу коммерческих ограничений.

Ну почему же они кривые? Набирайте некривые, а прямые. А кривые можно и выпрямить.
Вы предлагаете РТОСы, стеки писать с нуля? Я не о Линуксе. Давайете рассмотрим процы класса ARM7, Cortex-Mx.
Как правило рано или поздно сталкиваешься с тем, что нужна многозадачность, сервисы межпроцессного взаимодействия и т.п. Одним словом нужна РТОС. Чтоже делать? Писать с нуля, или взять готовую (scmRTOS, FreeRTOS, ucOS, ... и т.п.)? Я возьму готовую. Да в ней есть баги. Но эти баги годами выуживали оттуда, и выпускали патчи, пресс-релизы, правки, что угодно. Вероятность появления там бага много раз ниже, чем в нашей, с нуля написанной системе. И это я не говорю об основной программе, ради которой железка клепалась.

З.Ы. Конечно, у меня были "передовые" идеи написать свою ФС на Си++ именно с нуля. Даже кой-чего сделал. Стек TCP/IP начинал делать на Си++. И все это с поддержкой ООП. Да, очень удобно. Да, современно. Да, многое контролируется и упрощается, чем если писать на Си (холивар не разводим). Но я выдохся. У меня не осталось сил на основную программу, котороую должная была железка делать. А ещё нужен был USB, стек PPP для связи через модем с инетом... В общем я чихнул на всё, и задумался о Линуксе. Профи, у которого за плечами богатый опыт, и куча наработок вправе выббрать иной путь. У меня такого опыта нет. Да и не хочу. Я лучше другие вопросы поковыряю, более интересные мне


Плюспясот

А где Вы видели что я призываю обходиться вообще без ОС и чужих стеков? Это неизбежно в наше время. Но не нужно на каждую сковородку ставить монстра типа линукса.
Я сам все последние годы много раз использовал ОС и готовые стеки протоколов (USB, TCP/IP) и библиотеки и под ARM7/9 и под Cortex и под DSP.
И почти всегда как брал что-то чужое - находил в них баги и в конце-концов - почти полностью переписывал
И считаю - раз даже в этих простых исходниках всегда есть баги, то сколько же их в огромном по сравнению с ними линухе???

А ведь в последнее время на любой чих сразу начинается "ставить линух, файловая система и т.п."
Но для большинства задач, которые озвучиваются тут на форуме, ОС (даже простая) либо вообще не нужна, либо даёт только небольшой бонус, имхо.


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

Индусы уже давно пишут приличный код, вы их с китайцами видимо путаете, хотя и те подтягиваются. Сколько математиков у индусов я вообще молчу. Удивительное русское зазнайство. Ну да ладно. Можно пример "индусского" кода из ядра Линукс ? А то языком то бла-бла все горазды. Вашего "неиндусского" кода не прошу, ибо мне и так все ясно

Оффтоп:
Есть такой проект - ChromeOS. В основе лежит ядро linux.
Вон гугл платит 1 миллион долларов за взлом ChromeOS. Что же вы тут сидите с таким секретным знанием?
С линуксом хорошо, что если нравится - берёшь. Не нравится, пишешь сам или берёшь другое.

Вот тут Вы сейчас маленько перегнули... Я не знаю, кто пишет FreeRTOS, но над нашей родной scmRTOS работают уважаемые люди форума, на котором Вы сейчас находитесь... поливать огульно всех и вся - некрасиво...


Да и в Китае есть специалисты с большой буквы. Они везде есть.

____________________________
Блин, меня всегда удивляет, когда говорят о неком "индусском коде", "вьетнамском коде", "сингапурском код", как будто по качеству ширпотреба, ввозимого из тех стран, можно судить о специалистах.


А вот это уже откровенное хамство в адрес людей, которые могут быть на этом форуме (зная русский язык)... Стыдно, товарищ!

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

индуский код - нарицательное название малокачественого кода пошло вроде бы со времен библиотек микрочипа.

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

Объем исходников больших библиотек велик, и весь его переписать лень, особенно бесплатно, вот и ползают там жуки оставленные студентами.

Как ни парадоксально, но в коде написанном за деньги жуков зачастую больше. Хотя понимаю, тоже пишу хороший код только если интересно, от денег не зависит.

Это какой-то вид фобии к opensource?

В контексте темы топика:
1) Студенту, не имеющему долговременных связей с мантайнерами ядра линукс в реальности нет никаких шансов внедрить свой патч к официальному ядру.
Это относится не только к студенту, но и к любому другому программисту.
2) Многие библиотеки пишутся разработчиками стандартов на форматы и протоколы. Например, libpng - это эталонная реализация для работы с растровой графикой в формате PNG.
3) В ОС, основанной на ядре линукс есть интересное свойство. Практически для всех подсистем есть несколько альтенатив (во многих случаях эти альтернативы можно, даже сочетать):
а) Набор UNIX-утилит командной строки: "легковесный busybox" или "полноразмерный, с расширенным функционалом набор утилит GNU"
Файловые системы: Журналируемые, нежурналируемые, с реализацией программного RAID, оптимизированные для NAND flash, сетевые, в оперативной памяти, с контролем метаданных, с контролем самих данных и т.д, и т.п.
(если выбрать правильную ФС, то прибор с линуксом можно смело выключать в любой момент времени).
с) Интерактивность системы: есть обычный линукс, и есть realtime линукс. Как пример: LinuxCNC - управление станками с ЧПУ (необходима быстрая реакция на концевики и прочее)
d) Драйвера: для одного устройсва, часто существуют несколько альтернативных драйверов. Выбирайте на свой вкус или можете написать свой.
e) и т.д.

Разумеется есть задачи, куда пихать линукс неразумно.
Аналогично, есть задачи, которые разумнее всего решать с использованием ОС линукс.
Многие критики считают, что линукс используют те, кто не умеет программировать "голое железо".
Однако как раз наоборот, те кто имеет большой опыт программирования "голого железа" как раз выбирают Линукс для решения подходящих к нему задач.

Конечно же я имел в виду переносное значение. Но в библиотеках DSPLIB для 5000-го семейства TI написанных очень криво и неоптимально, находил именно индийские фамилии авторов. Может - просто совпадение?

Это Вы похоже перегнули. Где Вы видели что я говорил обо всех? Я писал только про основную массу тех, с которыми мне приходилось иметь дело.
С перечисленными вами не имел дела, но в портах uCOS находил очень глупые ошибки (в последних версиях кстати они их исправили, но долго тянулось).

Вам знакомо понятие "нарицательное наименование"?

Нисколько. Ибо говорил о том, что реально видел. И не надо передёргивать.

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

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

У меня только один вопрос: Какой опыт применения и программирования под линукс у Вас?

Откуда взялся миф, что новички используют линукс? Ардуино наверняка, но вот линукс...

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

А вы попробуйте. Вляпать и начать. Продолжаем молоть ерунду, как и ожидалось без знакомства с предметом.
У довольно простого SoC DM3730 TRM занимает около 4000 страниц и отнюдь не картинок. При том что за рамки его вынесен C64x+ DSP - на него отдельные TRM того же объема, отдельные TRM на кеши pipeline (а без этого написанный код рискует быть медленнне в разы) и полностью убрано OpenGL ускорителя (оно вообще NDA). Сколько времени доку только читать будем ? Сколько времени потратим чтобы хотя бы на консоль приветствие вывести ?Дальше больше - возьмем недорогой OMAP4460 . Мультипроцессорность у нас "неленивые" хорошо знают ? С нуля начнем ? На самом деле хороший инженер от плохо тем и отличается - хороший инженер - ленивый инженер, он будет искать пути решения проблемы кратчайшим путем. И не стоит говорить, что для слабеньких процев Линукс не нужен. Доля таких процев падает и будет падать дальше. Если на борту есть ethernet но нет ресурсов для минимального *nix - втопку этот процессор, он инжереного труда в партиях меньше сотен тысяч больше сожрет, а главное - продукт опоздает с выходом на рынок (читай пойдет в утиль сразу). Так что можете думать и говорить что угодно конечно, индусы будут только рады отсталости и ограниченному кругозору конкурентов.

В который уже раз - нафига???

Как вы всё гладко теоретизируете...
А я вообще-то писал и под OMAP без всяких *никсов. Хотя вас это так пугает. Читал доку и организовывал взаимодействие ядер, портировал uCOS на ARM9-ядро OMAP-а, писал USB-стек для него, писал дрова для прочей периферии. И что? Нет там ничего такого архисложного. Стартовал быстро. А с линуксом думаю - увяз бы надолго (как другие товарищи, пошедшие параллельным крусом на том же OMAP-е с линухом).
И к тому же теперь - полностью прозрачно знаю где у меня и сколько и на какие нужды тратится ресурсов, могу переконфигурить так или иначе (в зависимости от новых задач которые придётся ещё добавлять в работающую систему).
Ну нет ничего сложного там! Всё есть в даташитах (если производитель нормальный). Всё можно сделать и за реальные сроки.
А не как - в одном знакомом проекте поставили linux на ARM9 ядро, так он не только там сожрал прилично ресурса быстродействия ядра, но ещё и начало периодически сбоить пинг-понг DMA (с потерями данных), так как где-то в недрах линукса какой-то кривой драйвер изредка почему-то запрещает прерывания на пару сотен мсек. И найти его они не смогли. Начали заплаты лепить

Для вас наверное это действительно адский труд - разобраться в простом TCP/IP стеке.
Если Вы занимаетесь прогаммированием только для себя, то попробуйте представить что есть люди, которые пишут ПО для изделий, идущих потом в серийное производство и где каждый рубль себестоимости учитывается. А слабенькие процессоры (и дешёвые) - они всегда будут.
А если технология улучшается, то может лучше разместить на кристалле дополнительные модули (DSP-ядра, ПЛИС, RF-модули, ...) вместо тяжелого процессора, необходимого для линуха. Это позволит уменьшить кол-во корпусов в изделии и понизить его цену.

Не о том мы тут беседуем, и на личности уже скатились....


Лично я против опенсорса, но не в плане что "никогда и ничего, и все сам напишу". Я против взять оттуда код, пихнуть его не глядя в проект, а потом заплатками баги затыкать.

Пример:
Плата с РС232 на выходе, схемотехническая ошибка забыли конденсаторы у преобразователя уровня заземлить, в процессоре взятый из примера код передачи данных по прерыванию. Результат - схема работает со сбоями и потерей данных
Решение проблем, программистом до меня: Уменьшить скорость, увеличить таймауты, уменьшить длину пакетов сообщений, ввести контрольную сумму.

Мое решение:
1. тесты уарта, тыканье осцилографом, нашел кондеры, восстановил связь до стабильной работы 115200.
2. редизайн протокола, ввод команд, ответов, кодов ошибок.
3. проверка кода отправки, некоторые отзывы в сторону колеги что взял чужой код не глядя, исправление детских ошибок,

Результат на фирме остался надежный модуль связи с вычищенным кодом, его можно использовать в следующих изделиях, его не надо больше писать заново и он не теряет 50% мощности на заплатках.


Для меня любой опен сорс должен быть проверен, оттестирован, и рабочий отлаженный и "безопасный" вариант должен быть сохранен для фирмы. Не надо делать все заново, но знать как оно работает программист обязан.

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

Ошибки в моих приборах очень дороги, так что пока обхожусь без операционок.

Ещё раз - почему Вы судите по своему уровню о других? Я имею в виду то, что для Вас легко, не обязано быть лёгким для других. Извините, но смахивает на козыряение: я один такой крутой, а остальные... ленивые После вашей фразы стоит смайлик, похоже, что Вы иронизируете. Тогда скажем по другому: пусть для меня легко разобраться с TCP/IP стеком (кстати я разбирался). Но начальник ставит задача запустить изделие в срок 1 месяц. И что? Мне с нуля разбираться в куче стеков?


А РТОСы применяете? Или самописные? А многозадачность (или всё суперлупов + прерывания)? А мьютексы, очереди, флаги событий?


Кстати, ошибки в авионике ооочеень дороги. Но там используют операционки. Не помню какие, но используют.
Ошибки в промавтоматизации тоже недёшево стоят. Но в сименсовских контроллерах стоит оська
А вообще Ваше утверждение бьёт по именитым фирмам, которые делают QNX, ThreadX, WxVorks... Смотрите, они обидятся

все время забываю, что форум не только взрослеет, но и обновляется - приходит молодежь, через 10 лет иначе запоют, но и новые придут. Так что все своим чередом идет.
В который уже раз - нафига???
Ну нет ничего сложного там!
Ой спасибо, а я то так боялся, куда мне, IQ маленький.
Для вас наверное это действительно адский труд - разобраться в простом TCP/IP стеке.
Конечно, просто неподъемный.
Если Вы занимаетесь прогаммированием только для себя - конечно, а вообще я дворник.
то попробуйте представить что есть люди, которые пишут ПО для изделий, идущих потом в серийное производство - неужели ?

А если технология улучшается, то может лучше разместить на кристалле дополнительные модули (DSP-ядра, ПЛИС, RF-модули, ...) вместо тяжелого процессора, необходимого для линуха. Это позволит уменьшить кол-во корпусов в изделии и понизить его цену. - Вас еще Texas Instrument с руками не оторвал ? Такие гениальные идеи, как обидно, что они никому еще в голову не приходили
А пока что у в моем телевизоре - Линукс, в моих телефонах - Линукс, в роутерах и модеме, в камерах наблюдения во дворе, на десктопе, на планшете, в медиплеере, в осциллографе, - Линукс. Все это делали такие же идиоты как и я , с низким IQ и без возможности, как следствие, разобраться в стеке TCP-IP. Такая уж у нас, идиотов, участь.

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

Есть уже свои наработки, это не полноценные операционки, а самописные конечные автоматы которые в целом как операционка разделяет ресурсы. Я не могу вызвать функцию на 15 тактов, а потом другую. Но вся программа разбита на функции которые работают ограниченное время, то есть если она не доделала работу она выходит с кодом что она еще работает, и общая супер петля которая по очереди вызывает функции и следит за тем какая что за кончила.

+ прерывания, тоже короткие.

Так что я всегда знаю в каком месте у меня программа, и что она делает. У меня нет зациклов и циклов ваил. Но и общая цель написание когда не зависимого от времени. Что-то не получается нормально описать как это... Общий смысл такой: есть программы с огромным количеством флагов, которые сохраняются восстанавливаются и так далее, то есть каждый раз запуск функции тащит за собой хвост от которого зависит ее результат. Стараюсь такого не допускать, то есть если есть настройки они проверяются перед запуском функции.
Вообщем это сложно описать, но позволяет детерминировать пути программы. То есть тыкнув в любую точку кода и начав двигаться дальше вы точно знаете куда вы попадете, не будет такого что вы не будете знать куда дальше идти потому что не известно состояние каких то дремучих флагов.


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

Не выдёргивайте из контекста. Это был ответ на конкретную фразу уважаемого DASM, где он пишет что невозможно прожить ethernet-у без великого и могучего *nixa. Ну просто никак нельзя! Несчастные производители Cortex-M чипов - они же не знают этого!
Вообще думаю надо издать закон - ставишь ethernet в процессор, будь добр - прошей ему в ROM линух.

Думаю - Вы сами знаете ответ. Если есть наработки в этой области (к примеру: уже делалось устройство с этим стеком на данном проце) это реально.
Если нет - может поменять начальника?

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