Здравствуйте, уважаемые форумчане.

Здравствуйте, уважаемые форумчане.

Уже неделю ковыряюсь в гугле по вопросу применения ОС для PIC 18.
Вопрос наверно даже не в том, как заюзать какую нить RTOS для PIC18 (я так понимаю, что это не те МК которые заточены под реалтайминговые ОСы),
а скорее какие архитектуры можно использовать для громоздких проектов...

До сих пор я все подпрограммы запускал при помощи флагов (которые устанавливались в процедурах прерываний от таймеров и др. источников),
в мейне у меня был цикл опроса флагов. Причем пришел я к этому просто тыканьем, но как оказывается до меня все давно придумано, и называется такая организация
проекта флаговым автоматом...
Теперь ломаю голову и не могу придумать как организовать вызов подпрограмм с учетом их приоритетности. Есть задачи которые необходимо обработать после выхода из
прерывания в течении 1 мс, а есть которые подождут и поболее - значит нужна очередь задач, а цикл по которому все крутится - вообще сильно мешает.

Наверняка есть готовые решения и возможно не очень сложные.
Крайний вариант это конечно RTOS, хоть я еще не совсем понял что это.
Есть Rtos for Pic24, Pic30 and Pic33 на сайте майкрочипа, но полагаю что на XC8 она не запустится, да и нужно ли?

Поделитесь кому не лень, кто как организует структуру своих программ для пик до 18ой линейки включительно...

Сейчас пишу код на XC8 в МПлаб. Конкретный камень - PIC18F6520
Спасибо...

Хороший ресурс.
Там же есть примеры для PIC18.

Если любая другая задача в каком-то месте выполняется более 1 мс (т.е. отдаст управление планировщику не раньше, чем через 1 мс), то без вытесняющего планировщика не обойтись.

А так, как уже предложили выше, "OSA" - неплохой вариант. Сам лично ей пользуюсь уже давно, нареканий никаких нет. Но она кооперативная. Все времена планируются программистом на этапе написания программы. Т.е. нужно чётко понимать, что происходит в программе, когда отдаётся управление планировщику, где и на какое время может задержаться передача, ...

Добавлено after 10 minutes 11 seconds:
Тю... Проморгал в Вашем сообщении слово "XC8". OSA, к сожалению, не поддерживает этот компилятор. Для 18-ых ПИКов - "MPLAB C18".

если условие для необходимости быстро решить эту задачу появляется в самом обработчике, то разве нельзя её именно там и выполнить? Ведь по сути то или иное местоположение куска кода под выполнение этой задачи никакого значения не имеет, главное как я понял, его незамедлительно выполнить. То есть, как сформировались условия, так и выполняй, в этом случае даже флаг не нужен.
Либо можно просто манипулировать стеком, то есть подменить адрес возврата, но это не лучше и не хуже, а в принципе тоже самое.
Я думаю, можно и усложнить саму структуру основного цикла, разбить его на подциклы, и разделить частоту обращений в соответствии с приоритетами, то есть то, что важнее, крутишь чаще.

Открыт интернет-магазин MEAN WELL.Market – весь ассортимент MEAN WELL, выгодные цены

Открыта удобная площадка с выгодными ценами, поставляющая весь ассортимент продукции, производимой компанией MEAN WELL – от завоевавших популярность и известных на рынке изделий до новинок. MEAN WELL.Market предоставляет гарантийную и сервисную поддержку, удобный подбор продукции, оперативную доставку по России. На сайте интернет-магазина посетители смогут найти обзоры, интересные статьи о применении, максимальный объем технических сведений.

Подробнее>>

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

Сейчас получается, что основной цикл слишком громоздок, даже если сделать в прерывании что то быстрое, все-равно потом это нужно обработать в основном коде.
А если случилось много событий? Цикл просто может не завершится до конца, и тогда, при новом прерывании мы рискуем потерять старые данные, а при возврате попадем в середину цикла и
не обработаем новые данные, а будем заниматься бесполезным выводом информации на ЖК например .

Да бегло почитал введение в OSA, приятно что на русском и много инфы.
Подумываю над С18...

LED-драйверы MOSO - надежные решения для индустриальных приложений

Продукция MOSO предназначена в основном для индустриальных приложений, использует инновационные решения на основе более 200 собственных патентов для силовой электроники и соответствует международным стандартам. LED-драйверы MOSO применяются в системах наружного освещения разных отраслей, включая промышленность, сельское хозяйство, транспорт и железную дорогу. В ряде серий реализована возможность дистанционного контроля и программирования работы по заданному сценарию. Разберем решения MOSO подробнее>>

А никто не сталкивался с MPLAB Harmony?
Там есть возможность подключения разных RTOS (freeRTOS openRTOS например).
Насколько понимаю поддерживает компиляторы XC.

Добавлено after 44 minutes 5 seconds:
А все, он для PIC32...

Остановился на OSA по ссылке выше...
Пытаюсь запустить тестовый проект из первого примера.

Компилятор С18 (3.47) + MPLab X IDE 3.4

И никак не могу подключить инклуды нормально.
Сначала проект не видел osa.h в папке с osa - после танцев с бубном вроде подключил.
Но теперь не подключается OSAcfg.h - строчка #include osa.h выделена желтым в расшифровке (не может найти OSAcfg.h хотя она в папке проекта).


Вообще в настройках проекта есть sourse folders ПРОЕКТА и include directories компилятора. И там, и там указываются подключаемые директории, но
какие куда директории подключать так и не понял...

1. В папку с проектом кидаем папку "osa".
2. В настройках компилятора, в подключаемых путях, добавляем текущую папку (".") и папку с ОСой ("osa").
3. Файл OSAcfg.h кладём в папку с проектом.

Это стандартные шаги для запуска OSA в MPLAB 8.xx . Для MPLAB X, думаю, всё должно быть идентичным...

Добавлено after 15 minutes 46 seconds:
Попробовал в Х-е. Всё без проблем.
Тут должны быть прописаны пути :

Спойлер

Вложение:

2016-11-03_23-39-07.png [170.48 KiB]
Скачиваний: 293

Проект :

Спасибо за емкий ответ, Alex!
Все стало на свои места...
Запустил проект из учебника с задержками с небольшими поправками...

В частности, почему то компилятору не нравится строчка обработчика прерывания void interrupt isr (void) {}
Заменил на

#pragma interrupt isr
void isr (void) {}

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

Это синтаксис хайтека. В С18 обработчики немного по другому реализуются.

Добавлено after 10 minutes 5 seconds:
Ещё не забывайте, что в 18-ых PIC'ах 2 вектора прерываний - высокого и низкого приоритета.
Вот, что гласит мануал по поводу их прагм :

Потихоньку вникаю.
Простые примеры все отработал. Потихоньку думаю как применить к своему проекту...

Возникают вопросы, пытаюсь найти ответы:

1. Я так понимаю OS_Delay используется только в задачах, но в подпрограммах (например чтение отправка SPI) мы вольны использовать обычный Delay?
2. Ну вот в проекте у меня есть критическое событие - по таймеру раз в 20мс нужно прочитать с постоянным интервалом по 3 байта от 3-х устройств. Обработать можно потом...
Если у меня во время прерывания по таймеру УЖЕ выполняется длинная задача LCD Write, после прерывания мы вынуждены ее закончить до вызова сервиса OS,
прежде чем попадем в следующую задачу SPI Read. Варианты -
- SPI Read делать в прерывании (до 100 мкс)
- Длинные задачи типа LCD Write разбивать на более мелкие LCD Write Table(обновление таблицы), LCD Write Text (список), LCD Write Variables (обновление значений). Но
это полностью не решает проблему и добавит много новых задач - как то не функционально.