А почему в один день он не мог попасть на машину клиента где оторвало одну из кнопок hjkl. Это не аргумент, это все отмазы. Если бы это была крутая фишка резервирования, то эти бы клавиши дублировали стрелки, а не были бы независимыми...




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

Нынче делают не так.
Делают свою лабуду на Arduino. А если нужна наикрутейшая графика, то сверху ставят шилд, даже не думая что там внутри шилда.
А шилд этот может быть Intel Edison или Raspberry Pi или FTDI EVE, никого не интересует.
Так что расширения никуда не убегут. Главное RTOS!

Э... Поясните, пожалуйста. Ничто и никогда не будет запущено, если Вы не указали в каких либо конфигах, что ЭТО следует запускать тогда то. Линукс сам по себе, после старта ядра, запускает /sbin/init, и всё. Никакой самодеятельности. А дальше - Вы можете сами себе написать этот init, и получите свое единственное приложение. А можете поконфигурировать далее, добавив того или этого.


И зачем? Если все RT у товарища, судя по всему, в FPGA сделано.

То есть моя задача должна выглядеть так.

Прием езернет трафика Прерывание + ДМА и укладка в буфер
Отправка также по ДМА и прерываниям

Операционная система крутить ТСР стэк вяло разбирает пришедшие данные и формирует из них очередь команд.

Как только появляются данные для FPGA просыпается процесс отправки их в FPGA, который их перепихивает в SPI и засыпает, возвращая опять ресурсы задаче что крутит стэк.

По прерыванию от FPGA просыпается другая быстрая задача которая собирает данные и кладет их в буфер на отправку.

А в оставшееся время большая длинная задача прокручивает стэк и перекладывает данные из разных очередей... Дальше если надо подержать еще интерфейс типа CAN, то мы просто делаем еще одну задачу которая крутит кан, перекладывая данные в очереди, и между этими задачами ОС будет делить процессорное время запуская на 10 мСек каждую из них или как только у одной не будет что делать, все перекидывать на другую, но в полной загрузке по 10 мСек. так?

Теперь вопрос чтобы все не загадилось на время разбора очереди задача должна запрещать прерывания, чтобы они вдвоем не записали что-то в один и тот же буфер. Этот кусок надо делать каким-то приоритетным-монопольным? Потому что если в этот момент будет переключение задачи, то заблокированное прерывание может с ней уйти на долгий срок...

Как вообще правильно такое делается в ОС?

Все примерно так, только, желательно, без лишнего копирования буферов - принялось в буфер - ссылку на этот буфер в очередь на отправку, без копирования данных, по возможности. А очередь разделяется объектом синхронизации типа mutex, или spinlock, так что одновременно никто туда не сможет ничего записать.

Именно что причём

1. Ну и так много что само запущено изначально, самое голое ядро линукса все же несет в себе кучу всего. Если мы говорим не о переписи линукса.
2. Потом если есть линукс то всегда найдется придурок который обновит какой-нибудь драйвер или запустит какую-то службу, чтобы сделать устройство лучше, и даже вам не скажет. А вы потом будете смотреть на устройство которое вдруг стало себя вести как-то не так...
3. У меня кончились отмазки почему линукс 100% зло Но линукс это не то что я бы сейчас хотел ставить на проц, тем более у меня все же кортексы м3, мне он просто не интересен.







ну ТСР все равно все что пришло должен разобрать, что-то служебный трафик, что-то данные пользователю выше, что-то вообще порезать. Так что что приняли отдать дальше точно не выйдет.
И что делать с конфликтом одновременного доступа к данным? Критические секции и семафоры?

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


КАК? Если Вы в свой дистрибутив включили, допустим, только ядро, свое приложение, и, допустим, ssh-демон для того, чтобы посмотреть логи. И ничего более? Крайне странное у Вас представление о линуксе во встраиваемом устройстве.


Критическая секция или mutex для долгих кусков кода, spinlock для коротких.

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


Сейчас такого рода пакости делают другие члены команды. У нас есть распбери в одной системе, с линуксом, так вот наличие линукса позволило всем изначально РС програмерам тоже что-то в нее дописывать, и как они любят с миллиардом потоков и прочей нечистью. Потому что есть возможность запускать программы пользователя. Для этого их надо просто туда положить, и запустить, максимум в конфиге прописать. То есть порочна сама возможность что-то докладывать в готовую систему. РТОСы как я понимаю представляют собой полную сборку, и что-то в нее доложить уже так просто не выйдет, то есть подписанный файл прошивки однозначно определяет что будет крутиться, или я не прав?


Если время от времени внешнее устройство присылает N байт по UART, например, и надо на это среагировать как можно быстрее. В начале пакета стоит заголовок с длинной данных. Как такое делают в РТОСах?
Настраивается ДМА на прерывание по длине заголовка, потом по прерыванию определяется сколько еще допринять, опять настраивается ДМА. А потом по прерыванию выставляется какой-то семафор на запуск задачи - обработки принятого сообщения?

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

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

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


Что касается уарта, то это же медленный интерфейс, как правило все можно решить в прерывании от наличия в его FIFO данных, или в DPC (workitem, и т.п.), запущенной из этого прерывания.

Компы то разные. На ИБМ вон карактеры были 36 бит, например.
Терминалы разные, ну и так далее.



Понятно. В игнор.

А скажите, если все же не линукс, то что надо чтобы операционку на проц запихать?

FreeRTOS она вроде как пишут под кортексы заточена (в том числе)
а Freescale MQX все же под колдфаеры, и просто АРМ.

Как я понимаю основное что там от проца зависит это таймер и переключение контекста. То есть надо это либо писать ручками под свой проц, либо искать портированную систему под конкретный проц. И как я понимаю в силу того что FreeRTOS в том числе по кортексы М3 заточена, есть шансы что она заработает из коробки, правильно? А большой ли это шанс?

Это именно так, и касается всех ОС на равных, и линукса в том числе. Лучше всего найти порт конкретно под Ваш проц (или проц конкретно под удачный порт). В таком случае шанс стремится к единице. Иначе есть такой же шанс крепко погеморроиться с портированием (что противоречит использованию ОС для собственного удобства и скорости реализации проекта).

Кроме озвученного, от проца зависят еще все драйверы всего его железа... Ну там SPI, UART, USB, и т.д., а также атомарные операции.

А что такое "из коробки"?
Интересно в каком месте эта FreeRTOS по кортексы заточена.

да кто ее знает в каком.
Из коробки имеется ввиду взял файлики, воткнул и поехали...
У FreeRTOS есть релизы под кортекс м3, это позволяет надеяться что ассемблерный код переключения задач будет уже готов, а так же будет использован системный таймер и так далее что ей нужно для жизни... То есть я надеюсь что это позволит брать файлы, включать в проект кортекса м3 (любого) и запускаться.

Или это очень наивно? И для порта на конкретный проц надо будет много чего полопатить?

С вашим опытом чтобы запустить MQX на произвольном проце, что надо сделать?