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

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

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

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

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

Не большую. Есть прибор на 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, то лучше и не пробовать ("ничего не работает" несмотря на малый размер).




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



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



Это как раз проще простого. Если там что-то вроде конечных автоматов по технологии Шалыто или 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

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

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

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

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

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

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

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

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

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

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


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

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

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

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



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

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



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

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



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



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

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

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

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

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

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

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