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

[rat]

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

[megajohn]

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

[_Артём_]

Как правильно разделять работу с GSM и GPS в контроллере?

Обмен с GSM и GPS наверняка будет на разных UART-ах, поэтому уже раздельный.

Приоритетами прерываний, по времени?

Приоритетов не напасёшся. Хотя смотря какой МК. Но всё равно не то.

Кто как решает эту задачу?

С помощью ОСРВ (RTOS) наверное в в основном решают.

[molecul]

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

Некоторые GSM модули, например Telit, умеют принимать NMEA по дополнительному UART, парсить их и выдавать результат по запросу AT командой. Соответственно одна проблема снимается, да и UART освобождается один.

[CADiLO]

Не всегда удобно - GSM можно уложить спать или отключить, а с GPS работать дальше. Нет смысла дергать GSM модуль для приема координат. На сегодня достаточно много контроллеров с 3-мя UART и прочими фишками.
Так вот например. Банальные ARM-M0 начального уровня.

[_Артём_]

Так вот например. Банальные ARM-M0 начального уровня.

У этих АРМов flash-памяти маловато для GPS/GSM (если конечно не совсем примитивное устройство делать).

[CADiLO]

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

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

[Harbinger]

На MSP430 о 60К - тоже. С операционкой.
Для совсем примитивного устройства скорее пойдут LPC812M101.

[_Артём_]

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

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

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

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

[_Pasha]

Качества софта о 32кбайтах определяется архитектурой. В данном случае в выигрыше MSP и AVR. Pic18 - это ужасно, ARM - тесновато

[Harbinger]

В данном случае в выигрыше MSP и AVR. Pic18 - это ужасно, ARM - тесновато

C8051F... дороговато. Но не всегда.

[alexdos]

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

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

[_Артём_]

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

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

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

[Aner]

Используйте STM32F1xx, ...STM32F4xx и все проблемы легко решаться. Дешевые, и много много всего хорошего.

[ArtemKAD]

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

Страниц на 40-50 инструкции.

[sobr]

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

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

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

[firew0rker]

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

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

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

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

1. Замеры.
- скорость ветра
- направление ветра
- температура
- расстояние от датчиков до Анемометра до 50м.

2. Регулируемые параметры
2.1. локально, записываются на SIM КАРТУ
- Телефон админа (с которого могут производиться настройки)
- Параметры соединения с оператором GSM по каналу GPRS
- Параметры для доступа к WEB – серверу
2.2. дистанционно SMS-сообщениями
- Перезагрузка устройства (комманда)
- Интервал накопления оценки

3. Выводимые данные на сервер
3.1. Скорость ветра
- Максимальная за интервал
- Средняя за интервал
- Минимальная за интервал
3.2. Температура средняя за интервал

[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);
}

[megajohn]

Компилятор генерит громоздкий код для арифметики с типом long

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

Эскизы прикрепленных изображений

 

[AlexandrY]

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

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

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

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

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

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

[alexdos]

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

[rat]

Проект на STM32F105, иногда подвисает, судя по всему обработчики прерываний от обоих уартов чего-то делят, потому и спросил про приоритеты прерываний.

[Aner]

не наблюдал такое, разве что в коде недосмотрели ...ну или в прокладке.

[AlexandrY]

не наблюдал такое, разве что в коде недосмотрели ...ну или в прокладке.

Есть в STM32 такая беда. Вызвана отсутствием FIFO на UART.
При определенном построении ISR могут быть зависания.

[Aner]

Так это года как 3-4 назад было выявлено с первыми сотыми, и решений несколько было предложено.

[rat]

Так это года как 3-4 назад было выявлено с первыми сотыми, и решений несколько было предложено.

А можно поподробнее?

[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 простых инструкций, которые легко выучить ©

[vassabi]

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

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

О, пришел Frolov, ща начнется (уже началось)...
Kirill, у вас по ходу наклонности проповадника. Никогда не думали, что другие тоже умеют "программировать", а некоторые даже лучше вас и, самое главное, не так как вы?


Сообщение отредактировал vassabi - Jul 12 2013, 11:13

[AlexandrY]

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

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

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

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

[Aner]

А можно поподробнее?

Так гоним мимо ядра посредством DMA в память, даже на больших скоростях не находим никаких проблем.

[sobr]

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

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

[Aner]

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

[AlexandrY]

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

Да нет, я честно говоря подумал сразу о ZigBee. Где в 40 кБ надо с большим трудом утаптывать.
А сеть то по сути простенькая.

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

[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

[ArtemKAD]

, не понятно как можно всё упихнуть в такой маленький контроллер без жёсткого ассемблера

С жётстким ассемблером GSM-устройство типа GSM-шлюза влезает в объём меньше 8кБ.

[sobr]

Да нет, я честно говоря подумал сразу о ZigBee. Где в 40 кБ надо с большим трудом утаптывать.
А сеть то по сути простенькая.

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

если мне вдруг приспичит поднимать канопен или блюетутх иле чего еще в этом роде, я просто снова использую SL6087 с его 8 метрами флэш и 2 метрами рам. Тут реч зашла о принтф (ваще не пользую библиотечные функции) и 32К. 32К хватит под 90% задач, ИМХО.

[Frolov Kirill]

С жётстким ассемблером GSM-устройство типа GSM-шлюза влезает в объём меньше 8кБ.

DOS тоже умещался на одной дискете, максимум трёх со всеми основными программами.
Windows 95 помещалась на полтора десятка дискет.
Windows XP помещалась на компакт-диск (один).
Windows 8 занимает какой-то безумный объём памяти.

Программисты в Microsoft дураки? Не умеют ассемблера?
Или хотя бы функции даже двух соседних ОС из списка сильно различаются по количеству и качеству?
А казалось бы, то и другое "операционная система". Там и там может быть "Пасьянс", например.

Так же и здесь. Это первая часть ответа. Вторая: Windows NT чем-то весьма неиллюзорно отличается от Windows 95. И на полтора десятка дискет не умещается. И требования к компьютеру сильно выше. И уж вроде вообще всё то же самое. Не только "пасьянс" тот же, а в целом набор программ в комплекте, функций, примерно одинаков. В NT немного по-больше из-за "серверных" приложений. Кто разницу помнит, тот поймёт. Дьявол кроется в мелочах.

И с ассемблерами в 8кБайт дело обстоит так же. И уйдут они туда, куда ушли программы для DOS.

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

[sobr]

...И уйдут они туда, куда ушли программы для DOS.

А чё не ушли еще? Или создадели С компиляторов ощутимо тупее того, кто пишет, что асм рулит?

[AlexandrY]

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

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

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


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

[ArtemKAD]

И с ассемблерами в 8кБайт дело обстоит так же.

Ну с учетом того, что тому изделию в следующем году стукнет 10 лет - возможно. Тем более что на Асме я сейчас почти не пишу. Но тем не менее, даже на Си там более чем 10-ки мне не потребуется.

Как верно заметил sobr

32К хватит под 90% задач, ИМХО.

[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 хорошо, но попросту нет возможности во-первых, во-вторых нет на то крайней нужды.

[zöner]

есть несколько программных единиц: работа с GSM, GPS, опросы IO и т.д. Как правильно разделять работу с GSM и GPS в контроллере?

распараллелить задачи ессно.

[Aner]

распараллелить задачи ессно.

и расскажите как?

[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-и по пальцам можно пересчитать.

[sobr]

В Delphi или Builder-е тяжковато было с потоками поскольку их VCL модель компонентов была довольно мутной и недокументированной в части взаимодействия потоков с GUI. Каждый шаг нужно было тестировать.

А в чем возникали проблемы потоков и GUI? Я в Builder'е что то делал не очень много, но с подобными проблемами не сталкивался.

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

Нет, это писал не я. Но я прекрасно знаю людей, которые это делали несколько лет назад (сейчас там уже другие). Не скажу за последние модели, но в GSM 100, 110, 120, 130 WMP100 стоит не так давно, сначала сим 300 стоял, и вся программа в пике, максимум что перенесли в WMP это дтмф. Я этот подход не разделяю, и сделал подобную систему полностью на SL6087.

[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 -- нет, и здесь возможна, максимум, кооперативная ОС, или вообще не возможна. Или можно "не использовать библиотечных функций", но это очень порочный путь.

[ArtemKAD]

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

В мире РС над одним проектом работают десятки, сотни, а иногда и тысячи программистов. Когда у нас подобным запахнет, тогда возможно и задуматься над увеличением объёма памяти и архитектуры...

[AlexandrY]

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

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

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

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

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

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

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

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

[rat]

Вопрос в продолжение темы: прошу общих рекомендаций по работе с прерываниями в STM32F1. Особенности, специфика при работе с несколькими прерываниями, на что стоит обратить внимание, грабли, тонкости?

[Falkon_99]

Писали про UART, DMA - рулит, и забыть про прерывания.

[=F8=]

Вопрос в продолжение темы: прошу общих рекомендаций по работе с прерываниями в STM32F1. Особенности, специфика при работе с несколькими прерываниями, на что стоит обратить внимание, грабли, тонкости?

Честно говоря никакой особой специфики не заметил. Из общих рекомендаций... ну удобно читать данные из uart в циклический буфер, есть там такая настройка у dma контроллера.
PS в конфе по армам есть целая прикрепленная ветка по STM32

Писали про UART, DMA - рулит, и забыть про прерывания.

У dma тоже есть прерывания.