Микроконтроллеры

исходники я читаю еще с прошлой недели и основную идею понял с самого начала. теперь пытаюсь понять "нюансы" и "детали". эта "аж шелуха" (как вы ее называете) не такая уж и бесполезная, по крайней мере передавать указатель на контекст -- это очень и очень правильно. От того, как это сделано в coroutines -- меня просто передергивает. Здесь хотя бы все понятно и читаемо. Однако мне местами не хватает примеров использования, а в официальном релизе не все макросы охвачены. Как раз в protothreads все намного удобнее (и мое ИМХО -- правильнее) с точки зрения "снаружи поуправлять" и "напрямую сброс состояния дочернего потока". Поскольку контекст потока у вас в руках, а не где-то спрятан внутри в виде статической переменной. Поэтому вашу фразу

Но, используя эти макросы, напрямую сброс состояния дочернего трида недоступен - спрашивается, зачем оно тогда - модное слово в поток статей?

я как ни пытаюсь, но раскодировать не могу. Теперь моя ремарка насчет структуры контекста. Вы написали:

нужно иметь статическую структуру pt для него (а в pt лежит аж одна переменная состояний).

Есть такой древний сишный способ "наследования" структур: берем структуру, которую надо расширить своими полями, объявляем новую структуру, копируем в начало переменные из оригинальной структуры и добавляем в конец свои переменные. Теперь во все функции/макросы, работающие с оригинальной структурой можно передавать указатель на свою "расширенную" структуру и все будет работать на ура. typedef struct MyPt { lc_t lc; // из стандартной struct pt int i; // моя переменная для организации цикла например int result; // через эту переменную я могу вернуть результат наружу } MyPt; Конечно в плюсах все намного красивее, кто же спорит. Итого: спасибо за ваши ответы, но я ждал ответы именно про protothreads с живыми примерами, ваши ответы мне не сильно помогают, увы. ЗЫ: гласная в слове thread читается как Э, а не И, поэтому лучше не писать "трид", а еще лучше использовать русское слово "поток".