-
- Мне для понимания в свое время помог сайт pic24.ru + исходники +
консультации Александра. - Nikolaev_Aleksey(04.12.2020 18:21)
- Спасибо. Скачал, посмотрел. Огромный плюс - читаемый исходник! Dingo(1705 знак., 04.12.2020 19:07, ссылка)
- С автором давно не общаюсь, но раньше после его семинаров хотелось менять половину кода в проекте) - Nikolaev_Aleksey(04.12.2020 20:08, ссылка)
- Спасибо. Скачал, посмотрел. Огромный плюс - читаемый исходник! Dingo(1705 знак., 04.12.2020 19:07, ссылка)
- сколько трудов для создания нового велосипеда, а есть ведь
настоящая проблема требующая решения. Это отсутствие кооперативки
для пика под XC8. Либо нужна "новая" OC либо порт OSA на XC8. - abivan(03.12.2020 10:31)
- Эти смотрели? CoOS и прототреды Дункелса. Dingo(519 знак., 04.12.2020 19:34, ссылка, ссылка)
- Полно их - Ruslan(06.12.2020 21:02, ссылка)
- Очевидно, что без механизма ожидания -- получается полная ерунда, которая ничем не лучше биглупа. Когда
событий станет много (типов событий, происходить им не обязательно)
-- всё время только и будет уходить на такие циклы проверки, как и
в биглупе. Зачем тогда сущность с громким названием "операционка"? fk0(7411 знак., 06.12.2020 14:41, ссылка, ссылка)
- Если вы про мой планировщик, то это скорее способ организации исходного текста (потому и sheduler), нежели претензия на кооперативную ОС. Dingo(1342 знак., 06.12.2020 21:29, ссылка, ссылка)
- Заглянул в причесанное Vit(149 знак., 06.12.2020 10:00)
- а напомните пожалуйста порядок вычисления аргументов для функции Zoro(58 знак., 06.12.2020 17:35)
- ЕМНИП, порядок любой. По чётным дням один, по нечётным другой. - SciFi(06.12.2020 17:41)
- Для конструкторов при этом -- строго слева-направо. - fk0(06.12.2020 18:46)
- ЕМНИП, порядок любой. По чётным дням один, по нечётным другой. - SciFi(06.12.2020 17:41)
- Во-первых p_tsk = &tasks[++i]. Во-вторых надоели идиоты:
оператор "запятая" ничем не плох, даже хорош по сравнению с
вариантами вроде ++*i-- так как порядок очевиден -- слева направо.
Оператор "запятая" от "точки с запятой" отличается только временем
жизни временных переменных (до "точки с запятой") и возможностью
использования в контексте выражения (а не оператора). В языке C
полезные применения: как раз избавление от ++*i--, возможность
записать последовательность fk0(247 знак., 06.12.2020 14:33)
- От идиота слышу. Твоё "во-первых" при выполняемой перед этим
проверке if ( i>=TAB_SZ ) break; вызывает обращение за границу
массива и это нужно вылечить, а не тут говном исходить. По логике
действительно нужен преинкремент. По тексту правильнее инкремент
делать до проверки на маскимальный индекс, а присваивание указателя
после. Работа с задачами не из списка, а из массива, в этой
интерпретации делается пробежкой по всему массиву, до первой
"задачи-пустышки". Обычно это Vit(601 знак., 06.12.2020 15:16)
- Спасибо за найденную ошибку. Начинал как вариант со списками,
сейчас склоняюсь к мысли вообще выкинуть этот изврат, ибо там, где
уместно применить "это-вот-всё", там списки лишние. Тогда будет
возможность дёргать задачу по номеру (из прерываний удобней,
например), а не по функции. - Dingo(06.12.2020 18:33)
- Считаю списки более удобным решением. Как минимум для отладки.
Невключение модуля - просто коммент строки, а не застирывание
массива, правка каких-то конфигов... Vit(936 знак., 06.12.2020 19:37)
- Если в реализации на списках из прерывания что-то делать, то мы
пошли обходить список, а с таблицей - номер N, обработай!( в свой
приоритет). Dingo(174 знак., 06.12.2020 20:35)
- Насчет "из прерывания что-то делать" - если говорим о добавлении задачи в список, то если не бояться дидлоков, для собственно быстрой операции добавления хранится указатель на хвост. Насчет дидлоков тоже можно решать быстрее, чем пробежать по списку, но это отдельный вопрос. Насчет соотношения приоритетов не понял. Наверно речь об идее с вытеснением. - Vit(06.12.2020 22:08)
- Списки хотят выделения/освобождения памяти, Dingo(959 знак., 06.12.2020 20:29)
- Что-то намешалось Vit(1765 знак., 06.12.2020 21:51, ссылка)
- Блин, не отпускает... Я ещё и о существовании XMACRO вспомнил. Dingo(1155 знак., 10.12.2020 08:31)
- ХЗ. Но в TASKLIST не видно запятых. Дальше не смотрел - Vit(10.12.2020 09:38)
- Вы правы, списки можно хранить и в таблице, например. Dingo(704 знак., 07.12.2020 07:59)
- Блин, не отпускает... Я ещё и о существовании XMACRO вспомнил. Dingo(1155 знак., 10.12.2020 08:31)
- Что-то намешалось Vit(1765 знак., 06.12.2020 21:51, ссылка)
- Если в реализации на списках из прерывания что-то делать, то мы
пошли обходить список, а с таблицей - номер N, обработай!( в свой
приоритет). Dingo(174 знак., 06.12.2020 20:35)
- Считаю списки более удобным решением. Как минимум для отладки.
Невключение модуля - просто коммент строки, а не застирывание
массива, правка каких-то конфигов... Vit(936 знак., 06.12.2020 19:37)
- Вот я и говорю про идиотов, ы которых набор каких-то догматических правил, мол "оператор запятая использовать нельзя" ("goto использовать нельзя") и т.п. Обосновывать свои догматы, конечно, они не могут, нечем. Мы о профессиональном программировании или о кружке пионеров? - fk0(06.12.2020 16:01)
- Приоритет во всех языках примерно одинаковый. Козырять несклерозом
не надо, но основные приоритеты знать надо. Иначе из-за количества
скобок код будет нечитаемый глазами. Надо знать про то, что
операторы взятия адреса и дереференса указателя выше по приоритету
арифметики (а ++ и -- ещё выше), и что логические операторы ниже
арифметики, и ниже оператора сравнения (который ниже арифметики). И
оператор присваивания -- ниже всех (кроме запятой). А тернарный
оператор выше fk0(66 знак., 06.12.2020 15:57)
- Представь, что знать-то знаю, а вот доверять не могу:) - Vit(06.12.2020 16:03)
- Спасибо за найденную ошибку. Начинал как вариант со списками,
сейчас склоняюсь к мысли вообще выкинуть этот изврат, ибо там, где
уместно применить "это-вот-всё", там списки лишние. Тогда будет
возможность дёргать задачу по номеру (из прерываний удобней,
например), а не по функции. - Dingo(06.12.2020 18:33)
- От идиота слышу. Твоё "во-первых" при выполняемой перед этим
проверке if ( i>=TAB_SZ ) break; вызывает обращение за границу
массива и это нужно вылечить, а не тут говном исходить. По логике
действительно нужен преинкремент. По тексту правильнее инкремент
делать до проверки на маскимальный индекс, а присваивание указателя
после. Работа с задачами не из списка, а из массива, в этой
интерпретации делается пробежкой по всему массиву, до первой
"задачи-пустышки". Обычно это Vit(601 знак., 06.12.2020 15:16)
- а напомните пожалуйста порядок вычисления аргументов для функции Zoro(58 знак., 06.12.2020 17:35)
- Кому нужна? С компилятором такого качества уже никакая ОС не нужна,
на мой взгляд. Да и вообще компилируемый стек и ОС --
малосовместимые понятия: как спрашивается в двух задачах исполнять
один и тот же код? (вытесняющая ОС или кооперативная не важно) Это
будет недоос с массой идиотских ограничений. Такая на мой взгляд не
нужна. Программируй автоматы. - fk0(03.12.2020 13:05)
- автоматы ну их нахер. У меня проект на осе на пик 18 прекрасно
работает с HT-PICC std abivan(345 знак., 03.12.2020 17:24)
- См. ниже. Суть не в том, что "для меня блаблбла..." что переводится
как "мне нравится...", а в том, что компилятор накладывает
СУЩЕСТВЕННЫЕ И ПРИНЦИПИАЛЬНЫЕ ОГРАНИЧЕНИЯ НА АРХИТЕКТУРУ ПО,
настолько серьёзные, что практически не может идти и речи о том,
чтобы переключить задачу в какой-то какой попало функции. Только
биглуп. Где у каждой задачи своя функция и она может переключать
задачи, в ней цикл. А всё что вызывается ничего уже переключать не
может. Без вариантов. Ты fk0(170 знак., 03.12.2020 17:32)
- да как хочешь назови хоть 10 задач, хоть 10 биглупов. Мы все понимаем о чем речь Приоритеты задач есть, сервисы имеются (задержки очереди таймеры). Код в приделах задачи линейный, поддерживать легко. Задачи временные создаются и удаляются. Мне не требуется вытеснение. "ОСИ" для новых пик16 и pic18Q нет поэтому я не рассматриваю их применение в моей реальности. - abivan(03.12.2020 17:51)
- См. ниже. Суть не в том, что "для меня блаблбла..." что переводится
как "мне нравится...", а в том, что компилятор накладывает
СУЩЕСТВЕННЫЕ И ПРИНЦИПИАЛЬНЫЕ ОГРАНИЧЕНИЯ НА АРХИТЕКТУРУ ПО,
настолько серьёзные, что практически не может идти и речи о том,
чтобы переключить задачу в какой-то какой попало функции. Только
биглуп. Где у каждой задачи своя функция и она может переключать
задачи, в ней цикл. А всё что вызывается ничего уже переключать не
может. Без вариантов. Ты fk0(170 знак., 03.12.2020 17:32)
- а в чём проблема исполнения одного кода в двух задачах? - Mahagam(03.12.2020 13:57)
- В компилированном стеке. Когда каждая переменная каждой функции по
сути -- static. - fk0(03.12.2020 14:05)
- а, это из-за особенностей архитектуры? - Mahagam(03.12.2020 14:14)
- Для PIC18 и i8051 -- да. Можно было бы их пытаться обойти, но
эффективность кода была бы очень низкая, а объём кода -- огромный. - fk0(03.12.2020 14:27)
- Ну для 8051 есть микроос от кейла. Вроде не сильно тяжелая. - LightElf(03.12.2020 15:16)
- Ты не можешь заблокироваться в функции, передать управление другому
потоку и вызвать эту же функцию. Т.е. деревья вызовов разных задач
должны быть полностью непересекающимися. Т.е. библиотечных функций
не должно быть по сути. Это нормальное программирование? И здесь
нужна теперь операционка? Чем это лучше автоматов? (хуже). - fk0(03.12.2020 17:28)
- 1) совсем не все библиотечные функции Кейла требуют стека. LightElf(199 знак., 04.12.2020 14:41)
- Ты не можешь заблокироваться в функции, передать управление другому
потоку и вызвать эту же функцию. Т.е. деревья вызовов разных задач
должны быть полностью непересекающимися. Т.е. библиотечных функций
не должно быть по сути. Это нормальное программирование? И здесь
нужна теперь операционка? Чем это лучше автоматов? (хуже). - fk0(03.12.2020 17:28)
- Ну для 8051 есть микроос от кейла. Вроде не сильно тяжелая. - LightElf(03.12.2020 15:16)
- Для PIC18 и i8051 -- да. Можно было бы их пытаться обойти, но
эффективность кода была бы очень низкая, а объём кода -- огромный. - fk0(03.12.2020 14:27)
- а, это из-за особенностей архитектуры? - Mahagam(03.12.2020 14:14)
- В компилированном стеке. Когда каждая переменная каждой функции по
сути -- static. - fk0(03.12.2020 14:05)
- автоматы ну их нахер. У меня проект на осе на пик 18 прекрасно
работает с HT-PICC std abivan(345 знак., 03.12.2020 17:24)
- Зачем в микроконтролллерной кооперативке ассемблерный код?... Я в
вытесняющей его избегать стараюсь. - Dingo(03.12.2020 11:53)
- Для функций сохранения и восстановления контекста в основном. В принципе можно использовать setjmp/longjmp но у многих эти функции либо вовсе не работают, либо сделаны абы как. Может потребоваться их переписать. Кроме того, структура jmp_buf не прозрачна и непонятно как запустить новую задачу. Можно через alloca() конечно... Но если C++ и исключения, то возникают проблемы с размоткой стека. Нужно нормально инициализировать стек, без трюков. - fk0(03.12.2020 13:14)
- Спасибо, посмотрю при случае. Но пока это интересней ковырять. - Dingo(03.12.2020 10:42)
- Эти смотрели? CoOS и прототреды Дункелса. Dingo(519 знак., 04.12.2020 19:34, ссылка, ссылка)
- Первое, что задышало. Dingo(1208 знак., 02.12.2020 08:46, ссылка)
- Основной примитив -- ожидание множественных событий. У многих нет и
это проблема. Но по крайней мере у многих есть event flags из TRON.
У кого нет (есть и такие) -- невозможно же программировать, всё
упирается в очередь и работает только по очереди... Второй больной
момент -- реализация условной переменной (conditional variable).
Нужна возможность побудки одновременно всего множества процессов её
ожидающих. Последнее -- что-то вроде futex в линуксе и зачатки
видны в моём fk0(1124 знак., 02.12.2020 13:28)
- Вопросы, идеи по следующим шагам. Dingo(3115 знак., 02.12.2020 18:37, картинка)
- Основной примитив -- ожидание множественных событий. У многих нет и
это проблема. Но по крайней мере у многих есть event flags из TRON.
У кого нет (есть и такие) -- невозможно же программировать, всё
упирается в очередь и работает только по очереди... Второй больной
момент -- реализация условной переменной (conditional variable).
Нужна возможность побудки одновременно всего множества процессов её
ожидающих. Последнее -- что-то вроде futex в линуксе и зачатки
видны в моём fk0(1124 знак., 02.12.2020 13:28)
- Во-первых я предлагаю абстрагироваться от используемой процессорной
архитектуры для начала. Можно сделать модель на ПК, в виде
компьютерной программы, а потом переносить на МК. Так будет и
проще, и быстрей, и исключит какие-либо архитектурно-зависимые
решения. Во-вторых игнорировать примитивы синхронизации никак
нельзя, это -- краеугольный камень, без них собственно планировщик
построить не удастся. fk0(20298 знак., 30.11.2020 00:09, ссылка)
- Спасибо.
Ну вот как так? Р-р-р-р-раз - и 20 килознаков?Буду разбираться. Dingo(877 знак., 30.11.2020 05:48)
- Спасибо.
- возможность принудительно остановить одну задачу и передать управление другой - если это из самой задачи это не вытеснение, это кооперативность - PTOC(29.11.2020 18:35, , ссылка)
- возможность принудительно остановить одну задачу и передать
управление другой - это не вытеснение, это кооперативность - PTOC(29.11.2020 18:33, , ссылка)
- Habr :-) что за бред? - OlegPowerC(29.11.2020 18:37)
- как мне показалось, этот именно то, что хочет автор топика - PTOC(29.11.2020 18:40, )
- Короче, кооперативная - задача запустилась, выполнилась, САМА завершилась или отдала управление и начала выполняться следующая из очереди, вытесняющая - в квант времени N, перешло управление планировщику (в нашем случае обычно прерывание от какого нибудь таймера), посмотрели список готовых задач, если есть готовая с большим приоритетом, текущую приостановили предварительно сохранив ее контекст, отдали управление той которая с болтшим приоритетом и готова. OlegPowerC(27 знак., 29.11.2020 22:18)
- Нет. Хочу вытеснения. - Dingo(29.11.2020 19:16)
- как мне показалось, этот именно то, что хочет автор топика - PTOC(29.11.2020 18:40, )
- Habr :-) что за бред? - OlegPowerC(29.11.2020 18:37)
- хороши исходники CTL. и документация вменяемая. написать свой
велосипед - это полезно и похвально. но вот потом лучше
использовать что-либо стороннее. ибо Mahagam(198 знак., 29.11.2020 18:07)
- Спасибо! очень близко к тем идеям, что у меня в голове. Вы уже не однократно о ней тепло отзывались. Например Dingo(5 знак., 05.12.2020 11:27, ссылка)
- Советую почитать мануал от scmRTOS AlexG(43 знак., 29.11.2020 18:03, ссылка)
- Для разных процессоров будут отличия. Проще всего изучать на Cortex-M - у него много удобных хардверных заточек под такие действия. Т.е. думать надо будет про логику, а не про то, как извернуться на конкретном процессоре. - LightElf(29.11.2020 14:06)
- Хорошее дело, сразу подумайте как будут работать драйвера переферии , так как будут прерывания от планировщика и в той же FreeRTOS не все так однозначно. Я пока отказался от вытесняющей в пользу one shot execution механизма - OlegPowerC(29.11.2020 13:06)
- А почему у Вас планировщик в главном цикле? Так он никогда не
получит контроль над стеком. - my504(29.11.2020 12:40)
- можно так:
sheduler();enable_systick_irq(); while(1) { ; } Dingo(417 знак., 29.11.2020 13:00)
- можно так:
- IMHO, неплохое чтиво - мануал на embOS и Миро Самек, Роберт Вард
"Построение наипростейшего диспетчера задач" Vit(718 знак., 29.11.2020 12:37, ссылка, ссылка)
- Ознакомился с переводом Миро Самек (Quantum Leaps). Любопытная идея. Впрочем, Dingo(565 знак., 29.11.2020 16:29, ссылка, ссылка)
- Спасибо! Вы тоже много написали, надо хотя бы обзорно
познакомиться. fk0 крут, но это как-то "из пушки по воробьям". Хотя, буду рад, если
он подскажет. опасаюсь, что сильно разными категориями оперируем.
Никлауса обязательно почитаю(даже если не всю книгу). Dingo(347 знак., 29.11.2020 13:10)
- обязательно доберитесь до списков - Vit(29.11.2020 13:11)
- Мне для понимания в свое время помог сайт pic24.ru + исходники +
консультации Александра. - Nikolaev_Aleksey(04.12.2020 18:21)