Программное разделение, GSM и GPS Опции

[rat]

День добрый. В устройстве (трекер) есть несколько программных единиц: работа с GSM, GPS, опросы IO и т.д. Как правильно разделять работу с GSM и GPS в контроллере? Приоритетами прерываний, по времени? Кто как решает эту задачу?

[Frolov Kirill]

День добрый. В устройстве (трекер) есть несколько программных единиц: работа с GSM, GPS, опросы IO и т.д. Как правильно разделять работу с GSM и GPS в контроллере? Приоритетами прерываний, по времени? Кто как решает эту задачу?

Не понял вопроса. Звучит он скорей "какова архитектура программ выполняющих параллельно множество задач". Вообще ответ есть в статье "Embedded system" в Wikipedia. Подходов несколько, суть одна. Последовательно исполняются разные программные модули обслуживающие разные задачи. Вопрос, чем эта последовательность определяется. От программиста (super/big loop), до RTOS. Не обязательно RTOS с вытеснением, можно и кооперативная. Впрочем и RTOS не обязательна. Если RTOS (с отдельными стеками для каждой задачи) нет, то отдельные модули строятся так, что в какой-то переменной хранят своё состояние (google://Шалыто), например. Может быть событийно-управляемая архитектура, когда возникновение каких-либо событий приводит к запуску их обработчиков (в которых могут быть те же автоматы): это лучше чем big loop, потому, что если последний достаточно big, то слишком много процессорного времени тратится на ненужные проверки условий и, кроме того, с big loop трудно перевести процессор в спящий режим когда не нужно. Вообще если параллельных задач очень много, то подход с RTOS не реализуем без костыпей и подпорок -- не хватит памяти (стек и т.п.) на каждую. Всё сведётся скорей к событийно-ориентированному программированию (именно такая модель применяется в GUI, где тоже есть множество относительно независимых "задач" работающих параллельно). А RTOS скорей полезна для создания небольшого количества изолированных задач, причём именно вытесняющая RTOS. В основном ввиду возможности вытеснения. Т.к. рано или позвно в событийно-ориентированной архитектуре найдутся задачи требующие малого времени реакции и другие, обрабатываемые слишком медленно.

Видел железки с 128/256/512 КБ флеша, но что можно на 32КБ сделать? Только printf туда и поместится и ничего больше...

Вы новичёк и недоучка, вам сейчас объяснят. Профессионалы пишут на ассемблере, а C для ламиров.

Есть такая замечательная рекламная картинка, которая показывает как кортексы уделывают 8-битники

Этот ваш кортекс для ламиров и недоучек ниасиливших ассемблер из 35 простых инструкций, которые легко выучить ©

[AlexandrY]

Вообще если параллельных задач очень много, то подход с RTOS не реализуем без костыпей и подпорок -- не хватит памяти (стек и т.п.) на каждую. Всё сведётся скорей к событийно-ориентированному программированию (именно такая модель применяется в GUI, где тоже есть множество относительно независимых "задач" работающих параллельно). А RTOS скорей полезна для создания небольшого количества изолированных задач, причём именно вытесняющая RTOS.

Интересное мнение. На каком опыте основано?
Какую RTOS применяли и для каких задач?
И сколько это "небольшое количество изолированных задач"?

50 задач, например, это много или мало?

Потом с трудом представляю себе большое количество одновременно выполняемых задач которым бы не требовался свой стек.
Можете хоть умозрительный пример привести?