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

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

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

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

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

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

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




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

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

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

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

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

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





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

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

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

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

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

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

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

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




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





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

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


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

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

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

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