Jump to content

    

Потребления ресурсов пустой системой

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

 

 

 

Но - ведь речь о простоте и быстроте реализации, наплевав на ресурсы памяти и стоимость проца!

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

Share this post


Link to post
Share on other sites
И в части расширения на будущее - к примеру, почти любой Cortex-A содержит в себе сразу сильный видеоконтроллер, вдруг захочется поднять некое видео - и за день работы можно "поднять" любое разрешение, от мелкого QVGA до Full HD. Ну и т.п.

 

Нынче делают не так.

Делают свою лабуду на Arduino. А если нужна наикрутейшая графика, то сверху ставят шилд, даже не думая что там внутри шилда.

А шилд этот может быть Intel Edison или Raspberry Pi или FTDI EVE, никого не интересует.

Так что расширения никуда не убегут. Главное RTOS!

Share this post


Link to post
Share on other sites
Если есть линукс, то всегда найдется какое-то ненужное приложение которое будет запущено и в не нужный момент что-то сделает...

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

 

Главное RTOS!

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

Share this post


Link to post
Share on other sites
10 мс и не меньше. Если тик 2 мс или меньше на Cortex-M, то значит хотите нагрузить RTOS чем-то ей несвойственным.

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

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

 

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

 

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

Отправка также по ДМА и прерываниям

 

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

 

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

 

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

 

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

 

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

 

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

 

 

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
А опасения связаны в первую очередь с тем что будет как всегда - тестировать никто не тестирует,

...

ПыСы кокос тут не причем

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

Share this post


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

1. Ну и так много что само запущено изначально, самое голое ядро линукса все же несет в себе кучу всего. Если мы говорим не о переписи линукса.

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

3. У меня кончились отмазки почему линукс 100% зло:) Но линукс это не то что я бы сейчас хотел ставить на проц, тем более у меня все же кортексы м3, мне он просто не интересен.

 

 

 

 

 

 

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

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

И что делать с конфликтом одновременного доступа к данным? Критические секции и семафоры?

Share this post


Link to post
Share on other sites
1. Ну и так много что само запущено изначально, самое голое ядро линукса все же несет в себе кучу всего. Если мы говорим не о переписи линукса.

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

 

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

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

 

Критические секции и семафоры?

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

Share this post


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

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

 

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

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

 

 

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

Настраивается ДМА на прерывание по длине заголовка, потом по прерыванию определяется сколько еще допринять, опять настраивается ДМА. А потом по прерыванию выставляется какой-то семафор на запуск задачи - обработки принятого сообщения?

 

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

Share this post


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

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

 

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

 

 

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

Share this post


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

 

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

Терминалы разные, ну и так далее.

 

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

 

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

 

Share this post


Link to post
Share on other sites

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

 

FreeRTOS она вроде как пишут под кортексы заточена (в том числе)

а Freescale MQX все же под колдфаеры, и просто АРМ.

 

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

 

 

 

 

Share this post


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

 

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

 

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

Share this post


Link to post
Share on other sites
А скажите, если все же не линукс, то что надо чтобы операционку на проц запихать?

 

FreeRTOS она вроде как пишут под кортексы заточена (в том числе)

а Freescale MQX все же под колдфаеры, и просто АРМ.

 

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

 

А что такое "из коробки"?

Интересно в каком месте эта FreeRTOS по кортексы заточена. ;)

Share this post


Link to post
Share on other sites

да кто ее знает в каком.

Из коробки имеется ввиду взял файлики, воткнул и поехали...

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

 

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this