Мы делаем приборы на STM32f103 но сейчас нужно расширить выпуск продукции
поменять ЖК дисплей на TTF, добавить памяти и прочее
Притащил плату дисковери с 429 STM и TTF дисплеем.
в принципе переделывать старый код под него не особо трудно,
но хотелось бы добавить в новый прибор: WiFi, Ethernet и что то еще
если потребуется - например какой нибудь ZigBee или BlueTooth.
Сейчас для увеличения функциональности приходится добавлять
отдельные платы WiFi, GPS модема и пр
Я предложил сделать одну плату на Linux а все программы уже писать на уровне
операционной системы - что намного проще,
а не на уровне прерываний и ввода вывода.
Хочу у знатоков узнать примерно время разработки под Linux
относительно такого же времени разработки под "голую" железку.
С Linux я в принципе хорошо знаком, очень давно писал какие то драйверы
когда еще ядро было 2.4 и существовала шина ISA.
Те времена конечно давно прошли, но не думаю что концепция сильно изменилась.
Сейчас подбираю отладку под Linux
из вариантов только Atmel SAMA5D3
или какой нибудь TexasInstruments
Склоняюсь к атмелу, но последние слухи о кончине этой компании
не особо радуют.
С техасами дело имел, но не с техасовскими армами.
Кто что может посоветовать и прикинуть время перехода на эти процы!

срок жизни проекта не менее 5 лет
просто хотелось бы с микроконтроллеров (STM) перейти на что то более серьезное -
проблема в том, что программить для контроллеров на уровне ввода-вывода/IRQ
намного сложнее чем на уровне операционной системы.
просто переделка приборов, какие то исправления
уже делать невозможно - хотелось бы сделать базовую систему
написать основные драйверы - и управлять устройствами которые к
базовой плате подключаются
достоточно одного ядра, sata не нужно - достаточно что программа будет исполняться из flash
объем Ram - наверное гигабайта-двух вполне достаточно
естественно TTF дисплей с графикой и тачсрином - сейчас стоит ЖК икран с кнопками
а такая концепция уже устарела.
нужны интерфейсы как минимум: I2C, SPI, не менее 3-4 UART и возможно CAN
сам проект можно реализовать и на ST новых моделей -
благо что проекты работают и на 103.
Но хотелось бы работать именно с "верхней" программой,
а не исправлять появляющиеся ошибки в низкоуровневых частях.

Ну не знаю.... Вы хоть какие-нибудь более-менее сложные драйвера под оси самостоятельно делали?
Это не одно и тоже, что настроить всяческие http сервера и т.д.

насколько сложные-не совсем понятно?
для контролеров без mmu делал драйверы различной периферии
делал для Linux драйверы еще когда была шина ISA

С использованием прерываний, ДМА и прочей прелести, с учетом многозадачности системы.

АЦП собирал данные по ДМА отправлял их "ждучей" задаче

Эт вы что-то напутали.
Либо с JTAG/SWD не освоились, либо среду разработки плохо выбрали.

вот поэтому у меня такой вопрос

Ну почему? Если ТС умеет писать драйвера и отлаживаться в линухе - то проще, конечно, если не требуется реалтайм в проектах..

да, реалтяйма не требуется
к плате нужно подключить до 8 различных датчиков медленно опрашиваемых (1 раз в 1-2 секунды)
датчики сейчас сделаны на STM и имеют выход на UART
сейчас сделано типа чипселекта чтобы "главная плата"
их последовательно выбирала.
я полагаю можно поробовать CAN
и главную плату сделать на полноценном арме.
сейчас пришлось добавить WiFi и GSM - взяли модули
SIM900 и EPS8266. но хотелось бы полноценного WiFi
потому что все эти модули - просто однозадачные модемы.

Вы не поверите, но то же самое можно (и нужно!) делать и на обычном Cortex-M с простой ОС (или вообще без оной).
Для грамотного построения ПО с разделением его на уровни, абстрагированием от периферии, разделением на low-level драйвера с ISR, middleware/стеки и прикладное ПО,
нужен не линух, а профессионализм и голова на плечах.
И Вы сильно ошибаетесь - если Вам сложно написать драйвера под простую систему, то под линух это будет многократно сложнее.

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


Судя по всему, ТС не умеет это делать даже на простом STM32 под простой ОС. Так что до написания дров под линух ему как пешком до Луны.


И что мешает написать полноценные дрова к ним под тем же uCOS???

Про какие "дрова" вы тут говорите?
Вся аппаратная часть у приличных ARM'ов уже есть в ядре. Никаких модулей ядра писать не надо! Разве что вы какую-то хитрожопую железку приделываете, которую почти в реальном времени надо опрашивать, или вносите изменения в синхронизацию NTP по внешним PPS сигналам (т.к. из юзерспейса нет доступа к прерываниям).

Остальные задачи элементарно в юзерспейсе решаются! Да, прямой доступ к GPIO сделан через жопу — нужны права рута. Вот для этого и не помешало бы модуль FUSE написать один раз, чтобы всем было хорошо.

как пример GPS - можно писать свое а можно воспользваоться GPSD
второе намного привлекательнее
короч теперь вопрос стоит какую плату и с каким процом контроллером выбрать
или ситару или atmel sama3d

Ну уж не заливайте.
Эт наверно прямо кайф получить никому не нужное внутреннее TCP соединение и параллельно разбираться в дебрях XML, Python и JSON , не говоря уже о скриптах Bash шела.

Кстати парсер GPSD без всей этой шелухи вроде бы спокойно портируется на любую RTOS. Стоит занести в закладки.

я делал парсер NMEA - но GPSD мне нравица намного больше
только зачем разбираться в XML и питоне - не понятно?
есть libgpsd - там все просто устроено: открыл-прочитал-закрыл
да и в операционках типа linux
общение с устройством намного лучше сделано:
open - ioctl-write-read-close

ладно, мы отвлеклись от темы,
так что мне посоветуете: амел или ситару?

Атмел по организационным причинам вычеркивайте.
Еще изучите ассортимент freescale: imx и vybrid