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

[rat]

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

[CADiLO]

Хм.... Это что ж туда запихивать то собрались ? Операционку ???

Народ по сей день на PIC18 да PIC24 с 32К флеша нормальные железки делает....

[_Артём_]

Хм.... Это что ж туда запихивать то собрались ? Операционку ???

Народ запихивает.

Народ по сей день на PIC18 да PIC24 с 32К флеша нормальные железки делает....

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

[alexdos]

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

Много можно.
Если у Вас "printf туда и поместится и ничего больше..." вовсе не означает что у других та же ситуация. Согласен с CADiLO Народ по сей день на PIC18 да PIC24 с 32К флеша нормальные железки делает, добавлю что и на STM32.

[_Артём_]

Народ по сей день на PIC18 да PIC24 с 32К флеша нормальные железки делает

И какой функционал у таких железок?

Если нужно GSM/SMS/CSD/GPRS/...GPS + ещё чего-нибудь, то 32К запросто может не хватить. Только если очень простые функции нужны тогда хватит.

[sobr]

И какой функционал у таких железок?

Если нужно GSM/SMS/CSD/GPRS/...GPS + ещё чего-нибудь, то 32К запросто может не хватить. Только если очень простые функции нужны тогда хватит.

Все, что вы перечислили, плюс работа с сетью различных устройств через юарт по своему протоколу, впритык влезло в 32К. Я считаю, что это очень не мало. В вашем случае (влезает только printf) надо просто взять printf поменьше.

[AlexandrY]

Все, что вы перечислили, плюс работа с сетью различных устройств через юарт по своему протоколу, впритык влезло в 32К. Я считаю, что это очень не мало. В вашем случае (влезает только printf) надо просто взять printf поменьше.

Работа ссетью в 32 кБ?
Это будет что угодно но не сеть.

Мне удалось реализовать анемометр на PIC16F1827 c его 4Kслов Flash.

Описание Анемометра с передачей данных по каналу GSM...

Получить данные с АЦП и послать по AT командам в модуль это и 1 Kбайт не займет.
А чем заполнены остальные 3 кБ?
Почти уверен, что тем самым printf.

[firew0rker]

Получить данные с АЦП и послать по AT командам в модуль это и 1 Kбайт не займет.
А чем заполнены остальные 3 кБ?
Почти уверен, что тем самым printf.

Много занимают строковые константы АТ-команд в виде retlw. Компилятор генерит громоздкий код для арифметики с типом long и, что странно, функции _delay.
Не использую printf, он не влез. Пришлось писать функции типа таких:

Код

//converts val to string of width digits.
//returns pointer to 0-terminating of buf
//if width is less than neccessary, string will be truncated at left!
char *
utoaa(char * buf, unsigned val, unsigned char width)
{
    char        c;
    char *    cp;

    buf += width;
    cp = buf;
    *buf-- = 0;
    do {
        c = val % 10;
        val /= 10;
        if(c >= 10)
            c += 'A'-'0'-10;
        c += '0';
        *buf-- = c;
        width--;
    } while(val && width);
    while(width--) *buf-- = '0';
    return cp;
}

char *
itoaa(char * buf, int val, unsigned char width)
{
    if(val < 0) {
        *buf++ = '-';
        val = -val;
    }
    return utoaa(buf, val, width);
}

[AlexandrY]

Много занимают строковые константы АТ-команд в виде retlw. Компилятор генерит громоздкий код для арифметики с типом long и, что странно, функции _delay.
Не использую printf, он не влез. Пришлось писать функции...

Дела не меняет. Весь ли printf использовался или по кускам, факт что стандартные библиотеки С-и и другие либы промежуточного слоя занимают большую часть кода.
И вот для действительно развитых M2M и IoT приложений легко прикинуть сколько надо памяти программ не вникая особенно в функциональность дивайса.
Так вот для работы с облачными сервисами только парсер JSON или или уж подавно XML может съесть до 100 кБ.

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

И функционал GPS, GSM, IO разделять нужно исключительно средствами RTOS.
Кстати не меньше пары десятков килобайт тоже займет.

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

Кортексы тоже друг другу не равны.
Скажем серия Kinetis умеет делать аппаратное усреднение отсчетов АЦП.
Т.е. еще сжать и последующий код той самой фильтрации.

[Frolov Kirill]

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

Не большую. Есть прибор на PIC18, 128кБайт. Из них C-библиотека:

printf (sprintf, snprintf, vsnprintf...): 4875 байт.
scanf (и всё относящееся): 1445 байт
qsort: 584 байта
malloc: 3437 байт
strdup: 82
strsep: 180
поддержка unicode: 1650
всякой мелочи на: 3414 байт
---------------------------------
Итого: 15667 байт или 1/8 часть прошивки.

Раскладка на PIC24 по-серьёзнее будет. C-библиотека с float и всем таким под 40кБайт. Библиотека там, правда, далека от идеала, если -legacy-c (dinkumware судя по внутренностям). А если без -legacy-c, то лучше и не пробовать ("ничего не работает" несмотря на малый размер).

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

Никаких в embedded. Из разумных считаю что-то вроде eCOS, например. Но в типичный МК оно не очень-то лезет. Остальное -- ещё те поделки, почему -- см. ниже. Интересна nuttx, но не дошло пока.

И сколько это "небольшое количество изолированных задач"?
50 задач, например, это много или мало?

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

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

Это как раз проще простого. Если там что-то вроде конечных автоматов по технологии Шалыто или Protothreads -- таких задач может быть очень много. И в таком стиле можно написать любой код, на самом-то деле. Стек, разумеется, у них есть. Во временном владении и общий на всех.

Здесь есть одна закавыка, правда, на которую я указал: при достаточно большом количестве таких задач CPU будет очень много времени тратить на проверки условий переходов (если по технологии Шалыто) или проверки выполнения условий блокировки (Protothreads). И жизненно необходим становится планировщик, хотя в виде той же RTOS. Не чтобы вытеснение, или стек раздельный. Ни то, ни другое жизненно не необходимо. Чтобы знать когда какие задачи требуют запуска и не вычислять условия переходов вхолостую. И второй аспект, я на него тоже указал. Что в большом количестве задач найдутся и такие, которые занимают CPU на большое время, и такие, которые требуют быстрой реакции. И здесь уже нужно вытеснение и, как следствие, раздельные стеки.

Соответственно, как можно поступить. Большое количество задач (автоматов, protothreads, без стека) размещается в меньшем количестве "процессов" обладающих стеком. Размещение по принципу разной максимально допустимой задержки в обработке сообщения и по функциональному различию. И в каждом "процессе", со своим стеком, нужен механизм обработки очереди событий. Общий для всех "процессов" и задач. Вот это мне кажется хорошим вариантом. Но, к сожалению, доступные RTOS для МК не предполагают "событийно-ориентированного программирования". В частности почти все из них обладают заметной проблемой: невозможно ожидать наступления более одного события. Некоторые (TNKernel, например) имеют такую возможность -- флаги событий, их количество весьма ограничено и требует много ручной работы. Скорей следовало бы для RTOS оставить вытесняющую многозадачность и в дополнении к RTOS нужна библиотека обработки очереди событий...

Потом ещё один вопрос, обычно оставляемый без внимания. Для полноценной многозадачности библиотека C должна это поддерживать. Если мы используем newlib, например, это возможно (библиотека явно имеет поддержку многопоточности). А если библиотеку dinkumware, то скорей нет. Проблемы начинаются с errno, который не должен быть переменной в таком случае. С функциями вроде strtok. Это из очевидного. Из не очевидного: нет гарантий, что какие-либо функции не хранят в себе статических переменных. Для ряда функций (strtok) это очевидно, для остальных -- без гарантий.

И, наконец, ещё момент. RTOS должна давать что-то вроде Thread Local Storage, дабы иметь возможность различать данные конкретного потока (процесса, задачи). Либо полностью изолировать процессы (как это делает nuttx). Но многие популярные RTOS для МК не изолируют процессы (скорей, это аналог использования потоков при программировании для ПК) и при этом не имеют TLS. Как следствие -- невозможна параллельная работа C-библиотеки (нельзя различить errno в разных потоках). Как следстие этого -- вообще нельзя использовать математические функции (из math.h), которые могут возращать ошибки в errno. Это лишь один пример из многих.

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

Не с сетью, а с сетью устройств. Их может быть до двух десятков. Если вам не нравится слово "сеть" в данном контексте, назовите стайкой.

Если изделия "Вега-Абсолют" ваши -- то вызывает уважение. Хотя, честно говоря, не понятно как можно всё упихнуть в такой маленький контроллер (PIC18F65J15: 48КБайт ПЗУ, 2КБайт ОЗУ) без жёсткого ассемблера, вряд ли оправданного экономически (за спиной спрашивают когда будет проект готов, а я им про ассемблер, ага). С другой стороны там модем Sierra Wireless WMP100 и всё может быть (в его прошивке).

Сообщение отредактировал Frolov Kirill - Jul 12 2013, 15:12

[AlexandrY]

... Никаких в embedded.
... Интересна nuttx, но не дошло пока. ...

Т.е. опыта нет, но есть твердые убеждения.

Тогда рекомендую посмотреть RTOS MQX и применить в следующей разработке.
Сильно поможет повысить квалификацию в многозадачных приложениях.
В MQX помимо других планировщиков есть интересный механизм конвееризации задач.
В конвеере задачи как раз могут использовать один стек, поскольку никогда друг друга асинхронно не вытесняют.


А библиотеки C-и без внимания никто не оставляет.
Есть такой процесс при написании софта под RTOS - называется retargeting. Описывается в компиляторах. Это адаптация стандартных библиотек под среду исполнения, в частности под RTOS.
Там все специфицировано. Волноваться не стоит.

[Frolov Kirill]

Т.е. опыта нет, но есть твердые убеждения.

Тогда рекомендую посмотреть RTOS MQX и применить в следующей разработке.

"Дураки учатся на своих ошибках". Невозможно иметь опыт во всём. Но хорошо бы представлять, раз уж я "пришедший из мира PC", как в этой параллельной вселенной делаются аналогичные вещи. Так вот в мире PC не пытаются строить программы с безумным количеством потоков непонятно ради чего, а приходят к event driven архитектуре ПО. Даже там есть для того причины, несмотря на то, что приложение с тысячей потоков в целом не представляет проблемы, например.

Сильно поможет повысить квалификацию в многозадачных приложениях.

Для построения "многозадачных приложений" не нужна "многозадачная" (в кавычках, именно так) ОС. Тут некоторые товарищи пяткой в грудь бьют, мол 640кБ хватит всем. История нас учит... не хватит.

Я не отрицаю полезность вытесняющей многозадачности, очевидно, она даёт меньшее время отклика и это серьёзное преимущество. Но не стоит бросаться в крайности. Ни в 640к, ни в RTOS во все места. Повторю своё мнение: достаточно ограниченного количества изолированных задач (а-ля процессы в unix).

В MQX помимо других планировщиков есть интересный механизм конвееризации задач.
В конвеере задачи как раз могут использовать один стек, поскольку никогда друг друга асинхронно не вытесняют.

Здорово. Но одно жирное НО. Такой механизм должен существовать вне рамок ОС, как библиотека, например. И не должен быть привязан к конкретной ОС, конкретной фирмы для конкретного множества микроконтроллеров.

Крайне не рационально привязывать ПО к исключительно одной аппаратной платформе. У меня, например, обязательно есть компиляция на PC, с симуляцией аппаратуры. Это принципиально важно, т.к. упрощает отладку. Чего-то вроде valgrind, например, для МК ожидать не приходится.

А библиотеки C-и без внимания никто не оставляет.

"Мы не используем библиотечных функций, пишем свой кривой самодельный printf". Об этом тут раз 10 уже.

Есть такой процесс при написании софта под RTOS - называется retargeting. Описывается в компиляторах. Это адаптация стандартных библиотек под среду исполнения, в частности под RTOS.
Там все специфицировано. Волноваться не стоит.

Ещё раз. Если RTOS не предоставляет Thread Local Storage, то уже ничего не поможет, всё мёртвому припарки. Я вот об чём. И популярная FreeRTOS, например, не предоставляет. Фанаты об этом часто не догадываются (т.к. "библиотечных функций не используем", или суют её в такие задачи, где оно и не нужно и принципиальные недостатки RTOS просто не могут проявиться). Или если библиотека C в виде бинарника, исходников нет. Да и при наличии исходников -- это значит попросту переписать часть кода. К вопросу об опыте. Я хотя бы представляю возможные проблемы, чтобы сразу сказать -- здесь не то, что вытесняющая, здесь кооперативная ОС работать не всегда будет. RTOS хорошо, но попросту нет возможности во-первых, во-вторых нет на то крайней нужды.

[AlexandrY]

Так вот в мире PC не пытаются строить программы с безумным количеством потоков непонятно ради чего, а приходят к event driven архитектуре ПО.

Ещё раз. Если RTOS не предоставляет Thread Local Storage, то уже ничего не поможет, всё мёртвому припарки. Я вот об чём. И популярная FreeRTOS, например, не предоставляет.

Сейчас посмотрел Windows Task Manager увидел там 1540 потоков!
Мне с RTOS за этим никогда не угнаться.

Под PC и я пишу. Там все определяется средой разработки и компонентами.
В Delphi или Builder-е тяжковато было с потоками поскольку их VCL модель компонентов была довольно мутной и недокументированной в части взаимодействия потоков с GUI. Каждый шаг нужно было тестировать.
Но даже там были скажем компоненты стека TCP/IP которые для каждого соединения создавали свой поток. Сделать случайно 1000 потоков там было как раз плюнуть.

Так называемая "событийная" модель встречается в известной либе uC/GUI. В результате эта библиотека в микроконтроллере пожирает большую часть процессорного времени. Уровень вложенности рекурсивных вызовов достигает многих десятков, стека не напасешься.
Но про это я тут уже не буду ... Это все уже пройдено.
Такие модели трудоемки и годны для использования в серьезных академических научных долгоиграющих дотируемых проектах. Не наш профиль.

Честно говоря хотя библиотеки С-и и могут быть настроены под RTOS (и их бинарный вид не проблема для этого) но я предпочитаю просто не использовать небезопасных для многозадачности функций. Этих функций на C-и по пальцам можно пересчитать.

[Frolov Kirill]

Сейчас посмотрел Windows Task Manager увидел там 1540 потоков!
Мне с RTOS за этим никогда не угнаться.

Из частного не следует общего. Большая часть потоков порождена парочкой безумных программ, остальные однопоточные или имеют весьма ограниченное число потоков. Даже службы windows попытались компактно разместить в рамках одного svchosts.exe, а не размазывать по безумному числу процессов или потоков.

Но даже там были скажем компоненты стека TCP/IP которые для каждого соединения создавали свой поток. Сделать случайно 1000 потоков там было как раз плюнуть.

Это специфика конкретных библиотек. Вообще для работы с TCP/IP не нужно over9000 потоков, более того, крайне вредно для массового обслуживания: google://C2K problem.
"Тяжёлые" сервера, например, могут создавать множество потоков, но уже не fork под каждое соединение (самое простое и плохое решение), а для последовательной обработки запросов одним потоком из пула свободных. А совсем тяжёлые обходятся одним потоком (процессом) и таки event driven моделью программирования.

Так называемая "событийная" модель встречается в известной либе uC/GUI.

Она встречается в любом GUI, кроме самых примитивных может быть. Она встроена в windows, она в X-window тоже (и там вся графика отрабатывается одним потоком, одним процессом). Без событийной модели (сигналы-слоты -- по сути тоже событийная модель) я не представляю как вообще GUI построить. Из GUI toolkits без событий мне вспоминаются только поделки для текстового режима 90-х годов. Но там все окна, элементы -- модальные. Невелика хитрость.

Ещё важный момент событийно-ориентированного программирования -- отсутствие жёсткой связности компонентов на момент компиляции. Компоненты A и B могут работать вместе, но они не знают друг о друге. Т.е., например, функция A() не может напрямую вызвать функцию B(), и наоборот. Это принципиальное свойство и сколько-нибудь большие программы без него сложно построить (иначе невозможно изолировать модули, каждый должен знать о каждом). В примитивной форме такая (не)связность может обеспечиваться callback функциями и установкой в процессе исполнения (не компиляции).

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

А это говорит, что там нет очереди событий или чего-то в этом роде. А очередь событий здесь -- принципиальна необходима. Или какой-то механизм её замещающий. И тогда ни рекурсий, ни вложенности. Обработка строго последовательная. См. state-machine.com. Но мне у них что не нравится: все задают этот вопрос, а что если очередь переполнится. Такой же механизм, кстати, описан в wikipedia в статье "Embedded system", он же описывается в книгах (обработчики прерываний кладут адреса функций в очередь). Я думаю, ответ здесь должен быть такой, что некоторые события должны обрабатываться непосредственно, без очереди.

Честно говоря хотя библиотеки С-и и могут быть настроены под RTOS (и их бинарный вид не проблема для этого)

Как это не проблема, я же явно указал на принципиальную невозможность использования _переменной_ errno. А после компиляции в бинарный вид оно уже заняло место в конкретных машинных кодах и тут ничего не изменить. Библиотеки расчитывающие на многопоточность (не многозадачность, т.к. к многозадачности с полной изоляцией процессов, а-ля unix, готова любая C-библиотека) изначально имеют что-то вроде #define errno (TLS->errno) и/или даже #define errno (*errno_location()), где функция errno_location() возвращает действительный адрес errno для данного потока.

Если библиотека не предполагает вытеснение -- здесь ничего не сделать. Только использовать её в кооперативной ОС. В таком случае тоже... есть проблемы с рядом функций вроде strtok(), но таких функций действительно по пальцам пересчитать и можно их переписать самому.

А malloc()? Тут очевидно. Не reentrant и не thread-safe.

А printf? Невозможен одновременный доступ к структуре FILE. А ведь на PC из разных потоков всё работает... Не reentrant и не thread-safe.

И самое главное -- для ускорения вычислений некоторые, особенно математические, функции могут использовать статические переменные. Не reentrant и не thread-safe.

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

Не надо путать thread-safe и reentrant-safe функции. Это разные понятия, хотя и похожие. Функции для вытесняющей многозадачности должны быть thread-safe.

Этих функций на C-и по пальцам можно пересчитать.

Это "безопасные" можно по пальцам сосчитать.

И вы туда же: "мы не используем функций C-библиотеки". Вы сами не знаете чего не используете. Потому, что одни функции могут вызываться из других или из функций сторонних библиотек. И вы не знаете какие проблемы связывают C-библиотеку и многозадачность -- вот я о чём. А всё туда же. Не имею ничего против многозадачности, но она возможна только в рамках соответствующей библиотеки и ОС. Я пример привёл: и eCOS и newlib, например, подразумевают многопотчность. А библиотека фирмы dinkumware -- нет, и здесь возможна, максимум, кооперативная ОС, или вообще не возможна. Или можно "не использовать библиотечных функций", но это очень порочный путь.

[AlexandrY]

А это говорит, что там нет очереди событий или чего-то в этом роде. А очередь событий здесь -- принципиальна необходима.

Как это не проблема, я же явно указал на принципиальную невозможность использования _переменной_ errno.

Библиотеки расчитывающие на многопоточность (не многозадачность, т.к. к многозадачности с полной изоляцией процессов, а-ля unix, готова любая C-библиотека)

Какая может быть очередь в однозадачной библиотеке?

Как правильно сами сказали есть как минимум механизм Thread-local storage (TLS) в GCC. Вот там и помещаете errno если используете GCC.

Но я не использую GCC.
В RVCT все гораздо проще. Просто переопределяете функцию __aeabi_errno_addr(). Она вызывается библиотеками C-и на низком уровне для получения адреса errno.
Наверно вы не забываете при создании задач выделять память для переменных задачи с помещением указателя на нее в управляющую структуру задачи.
В любой RTOS эта память из любого места задачи доступна по идентификатору задачи. Вот там и храните errno, пулы памяти для malloc и все прочее что надо.

И вот такими переопределениями низкоуровневых функций весь retargeting и производится. Сами библиотеки при этом остаются в бинарном виде .

Насчет терминологии. Говорю только о RTOS без виртуализации памяти. Поэтому применяю термин многозадачность .