Подскажите однако как лучше запустить многозадачность на авр-ах

Жуть :-)

На тредах это было бы просто


Но речь не столько об этом, сколько о том, что написание и отладка более-менее сложной логики превращается в ад - представьте что у вас там пара десятков состояний, причем переключаемых не по "switch ( g_state )", а по битовым флажкам, условиям нулевости некоторых указателей и так далее. Нет, адекватно перенумеровать их все можно далеко не всегда, да и что толку с того, что если мне надо будет постоянно помнить, что в state1 у меня p_queue должен быть NULL, а в state2 взведен флаг F_NEW_MESSAGE и сброшен F_RESYNC - не проще ли сразу их и проверять? Это раз.

Второе, даже если я успешно построил свою машину с двумя десятками состояний, я не смогу написать код в виде:

как это позволила бы сделать система с передачей управления через сохранение контекста (неважно, с вытеснением или без оного - я же могу просто в ключевых местах yield() расставить).

Я буду вынужден _весь_ код, с самого нижнего до самого верхнего уровня порезать кровавыми ножницами на мелкие кусочки в асинхронном стиле и переключать их по тем же флагам, т.е. что-то вроде:


Теперь попробуйте вообразить в таком стиле не "Hello, Vasya!", а что-то вроде SMTP, или, скажем, веб-панель управления... а светодиодами помигать - это не показатель.

Да, есть такое...
Но тут, как говорится, за всё надо платить.
И за удобство, и за свободные ресурсы.
Сомневаюсь я что-то, что кому-нибудь придёт в голову поднимать SMTP или WEB на меге с 1к ОЗУ

Вот тут и начинается "кровосмешение" - у мну в коде именно yield() и ставится. Примерно так

Метки в TICK_YIELD() создаются из макроса __LINE__.
Но где надо я могу себе позволить тупо перерисовать из документации машину состояний с теми же именами состояний (например машина состояний ModBus).

Если это реализация на основе duff's device, то вы не сможете сделать yield изнутри функции. В результате stdio отдыхает, библиотеки, если они не специально спроектированы под async, отдыхают...

Простите, я неясно написал? TICK_YIELD() это реализация yield(). Вываливаемся в шедулер или вызывающую функцию - если второе, то организация вываливания в шедулер просто чуть-чуть дольше, чем в первом случае. Как ни странно, но последовательный набор действий с ожиданиями (ввод-вывод разной природы) используется довольно часто и второй случай без срочного вываливания в шедулер вполне востребован. Насчёт stdio частично правы - одним ретаргетингом ожидающий ввод-вывод на неожидающий не поправишь, но как и с библиотеками проблема полноценного использования stdio более теоретического плана, чем практического. Асинхронный ввод-вывод же (да, его нужно делать самому - в ANSI он не есть таковой) организовывается как неожидающий и при этом легко превращается в ожидающий, но не наоборот. Оборачивание же стандартных sprintf и sscanf вполне несложная работенка.

Насколько дольше? Как по мне - придется в каждую функцию во всей цепочке вызовов вставить индикатор, показывающий, просто так мы возвращаемся или с отдачей управления.


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

Повторюсь - подобные подходы плохи не тем, что они "усложняют" код, они плохи тем, что требуют асинхронности по _всему_ коду, снизу доверху.

Булевый код возврата (или NULL/!NULL) практически ничего не стОит. А анализ кода возврата при небольшой вложенности вполне сравним по времени с сохранением/загрузкой контекста (тут нужно цифры рассматривать, но, ИМХО, при глубине вложенности до 3 чаще вытеснение проиграет, а если глубина больше 4, то это уже скорее будет говнокод).
Ну не знаю - мне удобно для всякой логики (может то, что Вы называете сложной, не попадалось) - важно только понимать, где могут быть ощутимо долгоиграющие участки кода и там отдавать управление вручную. Последнее скорее может показаться непривычно (я бы сказал, что оно просто несколько не похоже на примеры из учебников), чем неудобно.
опять Имею другое мнение. Считаю, что оперирование асинхронно изменяющимися данных и наличие буферов для них есть само по себе основным источником асинхронности в системах на МК. А если семь бед - один ресет(С), то зачем быть святее Папы Римского?

Это процессору он ничего не стоит. А вот возвращать осмысленный результат придется через глобальное состояние - код возврата-то уже занят. Конечно, все можно завернуть в макросы, но в один прекрасный момент мы обнаружим, что пишем не на C, а черт-те на чём :-)



Если уж на то пошло, то весь мир вокруг асинхронный ;-)

И, опять же, если абстрагироваться по максимуму - само наличие разницы между синхронным и асинхронным кодом есть следствие линейной модели стека и отсутствия поддержки coroutines. Такшта спор о том, какие костыли неудобнее :-) Хотя и практически важный в некоторых частных случаях :-)

Contiki...


Верно... но 4-х уже с головой.

Пишу это скорее как прикол. Сам никогда не использовал эту чудо-ось, если есть у кого реальный опыт - рассказывайте.

... даже такое там есть...

P.S.: Гы... Сервак на 64k. - CPU: MOS-Technology 8bit 6510 - Clock Speed: 1Mhz. Однако... Зажрались мы. Может Хейц и прав был чо 512 k RAM должно хватать всем?

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

Сообщение отредактировал Dimmix - Sep 9 2010, 14:01

Ось и мышь - понятия абсолютно перпендикулярные, никак друг от друга не зависят
Равно как USB, Ethernet и прочее другое.
Вам просто привели в пример разные подходы.
Самый простой - каруселька из стэйт-машин. Простой поначалу, до определённого уровня сложности проекта.
С определённого этапа проще становится встроенная ось.
Так что, всё зависит от задачи.