Arduino.ru

на дуне - слишком большие накладные расходы на сохранение контекста потоков.  Было бы ОЗУ хотя бы 16К, было бы полезно, наерна.

Тут таймеров то 16 штук заведешь, дак они замучают своими коллизиями.  

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

Там использован механизм setjump.h, который сам требует буфера для сохранения контекста около 23 байт + тут функция квантования процессов отжирает стек задачи на сохранение регистров R18-R31 плюс ещё кучка (около 20 байт) .. как понял контекст следующей задачи создается на стеке текущей .. и что там будет происходит в режиме квантования нескольких задач .. пока не разобрался, но пока не вижу ничего хорошего.

Как достоинство - все крутится на стеке и не требует malloc(), которого там нет. Количество оторжанной памяти - динамически по числу задач.

Как недостаток пока вижу что все .. крутится на стеке, а он "един". Ну и пока вижу двойное сохранение контекста местным диспетчером на таймере и функциями из setjump.h, но возможно они "не пересекаются".. не уверен как будет вести себя задача, если её активизировал диспетчер по таймеру, а она взяла да и переключилась "по завершению" или через yield() самостоятельно.

Ну и конечно, напрягает несохранение младшей половины регистров .. компилятор конечно их сохраняет сам где надо, но вот достаточно ли этого при межзадачных переходах .. не анализировал пока.

То, что на стеке крутится - явный плюс. И то, что без malloc() обходится тоже. Помоему двойного сохранения контекста нет, там два механизма переключения - через yield() и по таймеру. Приоритет процессов кольцевой - жирный минус. Нет попыток управления ресурсами, тот же сириал два потока могут неподелить и даже не подозревать что поперек друг друга стали. Даже если симафор влепить, то по освобождению ждущий получит квант на общем основании. Но этот минус не так важен т.к. оба потока наши и разраб сам должен о этом думать. Я понимаю, что многие видят что многопоточность - скачал два скетча из инета, запустил каждый своим потоком и все работает. Ага, конечно ;) Ну и под стек надо держать много ОЗУ, его максимальный размер ведь будет как сумма максимальных стеков каждого потока + накладные. А средний типичный в разы менше максимума. Но изредка наложатся вызовы при максимальных размерах и можна завалится. Вобщем я пасс, вытесняющую многозадачность без меня, я за кооперативную.

Ну вот тоже .. в плане отжираемых ресурсов имхо "дорого" и не надежно, ибо стек - един. Такое можно себе позволить в расширенной SRAM, где у меня есть 32 кила общей памяти и 2 группы страниц по 16 килов - "листаемых". Выделение 16 кб под задачу позволяет разместить в них как данные самой задачи и её глобалы, так и стек задачи. Межзадачный диспетчер меняя контекст, заодно перелистывает страничку локальных данных и усё .. запись в чужую задачку невозможна чисто физически. А для обмена есть 32кб единой памяти задач. Вполне.

Да давно это видел. Но губит людей не пиво, губит людей вода. Если автор предложил это, то где он это применяет. Где мануалы по применению. А так идея есть, а смысла нет. Мой менеждер задач по легче, но да же ему я применения не нашел.

Ну то наверно другую поделку типа RTOS видели. Это новая.  

//я применения не нашел.

А умеющему писать для МК оно и не надо. Проблема у не умеющих, которые хотят RTOS чтоб "скачал два скетча из инета, запустил каждый своим потоком и все работает". А фиг!