Комментарии 16
НЛО прилетело и опубликовало эту надпись здесь
Ну, спинлок реализовать — здесь много ума не надо. Достаточно просто SVC вызывать в цикле.
С семафорами сложнее, но концептуально для них тоже всё готово.
С семафорами сложнее, но концептуально для них тоже всё готово.
При кооперативной многозадачности можно и без них.
Задача и так знает, в какой момент времени она отдает управление.
Задача и так знает, в какой момент времени она отдает управление.
На самом деле нет. Например, при доступе к ресурсам. Два кооперативных потока могут неподелить доступ к шине i2c, например.
Да, если требуемое время доступа к ресурсу превышает «квант».
Но можно спроектировать так, что или задача не отдает управление, пока не закончит возиться с ресурсом, то есть увеличить «квант» (если вносимая этим задержка выполнения других задач некритична), или так, чтобы непосредственно с ресурсом работала одна выделенная низкоуровневая задача — «драйвер», разгребающая запросы от разных задач уровнем выше — а постановка запроса в очередь может делаться быстро.
Некий аналог критических секции требуется для обеспечения атомарности доступа к данным из прерываний.
Но можно спроектировать так, что или задача не отдает управление, пока не закончит возиться с ресурсом, то есть увеличить «квант» (если вносимая этим задержка выполнения других задач некритична), или так, чтобы непосредственно с ресурсом работала одна выделенная низкоуровневая задача — «драйвер», разгребающая запросы от разных задач уровнем выше — а постановка запроса в очередь может делаться быстро.
Некий аналог критических секции требуется для обеспечения атомарности доступа к данным из прерываний.
НЛО прилетело и опубликовало эту надпись здесь
Если пойти дальше, то можно сделать многозадачную систему бе стеков задач. Такая event driven тогда не надо использовать СистемТик периодический и бесцельно просыпаться для проверки есть задача или нет… Принцип примерно такой, таймер знает, что задача должна выполнится через 100мс, он настраивается на 100мс, и по его истечению вызывается функция задачи, правда она не должна быть сделана в бесконечной петле, т. е. Это просто периодический вызов функции на том же стеке. Преимущества: меньше ОЗУ, меньше потребление, проще архитектура ПО.
Теорию можно почитать тут:
www.state-machine.com/qpc/arm-cm_qk.html
Теорию можно почитать тут:
www.state-machine.com/qpc/arm-cm_qk.html
Хрень полная. Минус. Я б еще один влепил, за пропаганду "не хочу учить ОС", но не получится.
Суть всех ОС в том, что они предлагают язык абстракций, т.е. другой разаботчик зная этот язык гораздо быстрее поймет ваш код, нежели в случае использования такого велосипеда.
Так и не понял, зачем вместо бесплатной кроссплатформенной FreeRTOS (к примеру) изобретать велосипед…
"не хочу использовать проверенную и понятную ртось, потомучто мне лень, а вот свой велосипед написать не лень"
В качестве академического интереса похвально, но на практике все куда сложнее и на этапе разработки и на этапе сопровождения и внедрения новых фич.
Это все понятно, а исходниками «совесть» поделиться мешает?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного о многозадачности в микроконтроллерах