Программное разделение, 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.
Там все специфицировано. Волноваться не стоит.