Картошка

Переставил на 5.24. Заработали загрузки паков и программатор ресет начал делать после загрузки в камень, а не только в дебаг режиме, так что не в обновлении программатора дело было.

Да. Особенно если где-то стоит неприметный прагма пак. Вообще то стоит обязательно, да и по умолчанию включенно вроде 4.

с double были проблеммы с выравниванием, места хранения параноидально сделал static и поставил на них прагма пак 8

Та же самая проблема. Плюс еще одна - ST/link перестал сбрасывать (генерировать RESET) когда загружаешь прошивку в контроллер. Установлен на двух разных компьютерах аналогичная проблема. Reset работает только при старте DEBUG режима, а когда загружаю прошивку без дебага - он не сбрасывает контроллер, сброс работает только по питанию и по кнопке.

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

Это то да. Но разжечь огонь как раз с Вами сложнее, то костыли не дрова, то кремний не спички :). Всем спасибо. Особое спасибо AVI-crak. Искал готовое решение, чтоб не изобретать велосипед. В принципе все понятно.

А о размере can фрейма не наслышаны случаем :) ?! ------------------------ Будет помощь в написании функции принудительного вытеснения задачи по времени с сохранением текущего состояния задачи ?

Не понимаю любителей тратить время и угадывать стековую память на пару десятков задач, чужого кода например. Сидеть философствовать и проверять кучу критериев по возможным скачкам памяти, зная что рано или поздно эти грабли настанут. Тогда просто выделяешь размер с ЗАПАСОМ. Ну и в какие это ворота идет, память в контроллере не мегабайты, а выбирать другой камень - это как плохому танцору... Другое дело когда задач с чужим кодом немного и на две задачи можно определить оптимальный размер памяти под задачу. Знаю пару больших проектов от куда из-за тормознутости шедулера - его просто выкидывали, не хватало реакции при интенсивном обмене по can шине, нужно было обрабатывать около 5000-7000 тыс can фреймов в секунду. Его просто выкидывали, писали дружественные задачи. Никто не менял и не влазил в дебри шедулера, просто выкидывали операционку, "Чибис" Chibios например. Задачу хочется решить кардинально. Не хочется ждать всякие порты под контроллер когда добрые люди напишут, а потом сидеть снова еще грабли эти ковырять. Вот и поднял темку, вроде бы зрелая потребность в независимости :) же-ж ...

Да. С самым шо ни на есть лимитированным устанавливаемым временем выполнения :). И без всякого излишества планирования. Короче урезаная и упиленная ОС с ручным планировщиком :)

Мужжик ! Спасибо :) . Код уже понравился . Надеюсь что-то выковырять получится. Спасибо. Достаточно нормально рассказали. ... пока не надоест пойду набивать шишки куда AVI-crak указал :).

спасибо. Там много обращений к I2C короткими посылками и SPI микросхемам, которые я не могу перевести в прерывания, так как нет больших потоков данных, а только мишура с единичными регистрами. Перенес все на SYSTICKer что нужно запускать с прогнозируемым периодом и не занимает много времени. Остальное кинул в main цикл, но туда же кинул и формирование изображения и работу с диском. Спасибо. Что объясняете. Есть в RTOS управление временем вытеснения ? Или оно косвенно только с приоритетом связано ?

А есть что-то очень деревянное и простое по проектам переключения задач ? БЕЗ СТАНДАРТНЫХ ДЕБРЕЙ реализации каш из топоров.

Это я делаю со своим кодом в каждой задаче. Лопатить fatfs - то проще вытеснить контекст его выполнения на потом. Он отбирает 0.1 секунду на поиск файла - неприемлимо. В идеале бы вытеснить его выполнение на следующий цикл loop. Пусть он с 100-го цикла сделает свое медленное дело, а за это время выполнится то что нужно.

while (true) { SYSBIOS::EXECUTE_PERIODIC_SYS (); MeasADC.Task (); Leds.Task (); Motor.Task (); Tenso.Task (); Led_Task (); BusI2CDsptch.Task (); Pages.Task (); Ethernet.Task (); TimeLimitCallTask (Handle_SD_Task, 10 ms); TimeLimitCallTask (Handle_Display_Task, 12 ms); } Вот примерно по такой архитектуре построена программа. Где TimeLimitCallTask - периодически запускает зарегистрированную задачу с лимитированным временем, выполняя ее установленное время и сохраняя ее контекст выходит с ее выполнения в основной цикл от куда была вызвана.

Часть кода в прерываниях там где нужно, несрочные вычисления и обращения к внешней периферии в основном цикле main, но туда же пихнул fatfs - чтоб любые прерывания его вытесняли , как и остальные задачи. Но он медленный по файловым операциям открытия и закрытия, так как происходит поиск и изменения таблиц фат. Код большой и сложный, его просто надо ограничить по времени работы, так как в основном его тормоза заключаются в коде с SD картой. Я расказал какая есть цель. Она по ходу постов не поменялась и рождена она не за мгновение. Нужно запустить на некоторое время задачу и вытеснить ее, чтоб после ее завершения продолжил выполнялся тот контекст от куда функция CallTaskTimeLimit (Handle h_task, unsigned long time_ms); была запущена. Побочный продукт ОС как вытеснение - у меня как цель реализации. Нужен функционал - переключить задачу и завершить ее работу по времени, с сохранением ее текущего состояния от вызова к вызову. То есть одна функция :) Есть какая-нибудь - очень очень маленькая ОС, кроме RTOS и тд, где можно это выковырять ?