Добрый день всем!
Возникло желание - точнее, необходимось использовать многозадачность в своем проекте - вернее, или надо писать свой диспетчер (в котором я уже успел запутаться), или пользоваться чем-то готовым.
Увидел scmRtos - попытался запустить демку. Пример под IAR на MSP430F2617 - у меня на плате MSP430F2410, IAR версия 5.30

Немножко подправил демку под свою плату, чтобы нужный светодиодик моргал, указал иару на MSP430F2410 - и ничего. WDT прерывание случается раза 4 (вроде как это системный таймер?), после чего программа улетает неведомо куда.

Кто-нибудь может на путь истинный наставить - что можно трогать, что нельзя. Может ли на работоспособности версия компилятора сказаться? Или, лучше всего, может у кого готовая рыба завалялась для моргания именно на этом кристалле или похожем?

Ok, кажется загрузка новой версии (4.0) немного помогла.
Но моргалка здесь сигнал выдает какой-то совсем не похожий на периодический

context_switcher_isr:
save_regs
mov.w SP,r12
XOR.B #0x2, &0x21 // blinking led
xcall #os_context_switch_hook
mov.w r12,SP
l_restore_context:
restore_regs
reti

А зачем вы в самые недра ядра-то полезли? Это не место для пользовательского кода. И с чего взяли, что тут должен быть периодический сигнал? Вы документацию-то читали? Используйте для формирования таких сигналов пользовательские процессы и функцию sleep().

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

И примеры из комплекта тоже не работали?

Я с примеров и начинал - с моей версией ИАРа и 3.10 версией scmRtos программа улетала непонятно куда - по крайней мере кода в той области, где я ее останавливал, не было. 4-ая версия работает - по крайней мере, и демки, и мои попытки их модификаций. Самое время начать читать документацию. Кстати, у тексаса не увидел никаких упоминаний о Вашей операционной системе. Они не знают о ней или игнорируют? Или я плохо искал?

3.10 делалась довольно давно и тестировалась на вверсии IAR 4.2х. В IAR 5.xx поменяли поведение компилятора в части размещения обработчиков прерываний, и получалось, что некоторые обработчики прерываний не линковались. В 4-ке этот момент был пофиксен. Использовать 3.10 в новых проектах нет вообще никакого смысла.


К TI это вообще не имеет никакого отношения. И этих осей как собак бездомных, чего такому монстру, как TI, обращать на это внимание. Он микрухи делает и поддержку для некоторых из них (TMS) в виде тулчейна и своей собственной операционки.

Попытаюсь воспользоваться еще раз добротой и отзывчивостью авторов, уже чуть более конкретно.
Одна из моих задач отправляет радиопакет по таймеру (прерывание номер раз). Для управления используется аппаратный SPI - прерывание номер два. Когда данные отправлены - передатчик генерирует прерывание три. После чего он переключается на прием в и течении определенного времени ждет прерывания от приемника. Дождался - считывает данные. Нет - выключается приемник и все начинается с начала.
Какими средствами scmRTOS кошерно воспользоваться здесь? Сделать одну задачу с семафорами или две - одна обслуживает SPI, а вторая трансмиттер?

И второй вопрос - пусть это будет UART только на передачу по прерываниям и у него есть буфер. Как поступить при заполнении буфера, чтобы приостановить программу? Можно ли как-то семафоры разместить не в задаче, а в вызываемых подпрограммах? или вообще все как-то иначе лучше сделать?
Заготовка кода на чистом С выглядит примерно так (без всяческого контроля, только опустошение буфера):


Контроль переполнения можно как-то сделать в putchar остановив задачу или все-таки где-то в самой задаче это делать?

Если вопросы слишком наивные - как медный чайник, обещаю обзавестись свистком

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

P.S.

по второму вопросу - видимо, нужны channel и я плохо смотрел приметы?

Почитай статьи по потокам. Это фактически тоже самое.

Также статьи по использованию scmRTOS существуют. И там и рассказано, что и как инициализировать/использовать.

1. В процессе ждать флаг события от таймера, когда флаг просигнален, отправить в SPI. Тут если скорость SPI высокая, а МК не очень быстрый, то, возможно, имеет смысл не заморачиваться с прерываниями, а просто поллить флаг окончания передачи - с переходами в другие процессы может получиться тормознее и накладнее. Если скорость SPI медленная по сравнению с темпом выполнения инструкций процессора, то просто после инициирования отправки в этом же процессе ждать другого флага событий, который просигналит уже обработчик прерывания передатчика SPI. Дождались, пошли дальше - теперь ждём, как я понял, данных от приёмника, но ждём не вечно, а в течении какого-то времени и ждём не просто события, а данных. Поэтому тут логично было бы использовать OS::message<> - создать объект-сообщение для ожидаемого типа и ждать его с таймаутом. Пришли данные до истечения таймаута - одни действия, таймаут истёк - другие. Весь код получается простой и линейный в одном процессе.

2. Да, OS::channel<> вполне нормально подходит. Но, возможно, пойдёт и просто кольцевой буфер - зависит от приложения, от того, какие источники и как они обращаются к буферу передатчика. Возможно, проще будет использовать кольцевой буфер с критическими секциями. Но и канал тоже нормально подходит, единственное, надо следить, чтобы в ISR передатчика канал не пытался встать на ожидание, т.е. надо следить за тем, что обработчике прерываний перед извлечением из канала очередного элемента канал не пуст. Иначе он будет вставать в ожидание с попыткой отдать управление ядру, а это чревато негативными последствиями.

Здравствуйте. Чтобы не плодить лишних тем решил отписаться здесь.

Пытаюсь запустить scmRTOS 4.00 на LPC1766.

CodeSourcery + Eclipse. За основу взял GCC пример для STM EventFlag.
Проблема в том, что работает только процесс Proc1.
Управление процессам Proc2 и Proc3 не передается.
Соответственно светодиод led2 не
работает.
Флаг TimerEvent в system_timer_user_hook взводится и обрабатывается
процессом Proc1. Светодиод led1 моргает как и положено.
Код запускаю из RAM. Возможно в этом и грабли. Но хотелось бы понять в чем дело.

Недавно запускал такой пример для LPC1766 и IAR для scmRTOS 3 версии. Проблем не было.

Буду благодарен за любые замечания. Проект прикрепил.
Нажмите для просмотра прикрепленного файла

У меня всё уже работает (1-EventFlag и 4-Debug и начинаю писать рабочий проект), именно на LPC1766+GCC
Но из флеша, в RAM меня пока не тянет.
Сейчас нет сил, вечером как-то причешу и оформлю. Я бы уже и в репозиторий положил, но мне не нравится то, что я написал по аналогии с pin.h из примеров для Cortex-M3, а решить, как переделать — нет времени.

Если забуду — постучите завтра в личку, мне на почту уведомление придёт.

Ага. И первым делом вписал свой копирайт в мой мейкфайл
Вообще-то так не делается.

Виноват, Обидеть не хотел.

Я его сначала начал сам писать и конкретно запарился, а потом взял за основу Ваш.

Но пока разбирался, было не до копирайта.

Только переползаю на GCC.

Исправил.

Сам вспомнил :-)
Но все равно откладывается. Там хоть и примеры, но много завязано на конкретную мою плату и уже почикано под пробу конкретных моих заморочек.

На работе есть плата SK_MLPC1768, я на ней подниму примеры, вычищу лишнее, тогда можно будет показать.
Для начала 1-EventFlag, он по сравнению с STM32-шным уже изменён. Приведён в соответствие с avr-gcc-шным.

Спасибо, буду разбираться дальше.

Прошу прощения за задержку. 23-го первый пример был доведён до удобоваримого состояния.
Но я понял, что если я вброшу архив сюда, то в репозитории он появится нескоро ввиду отсутствия хоть какого-то «гвоздика».
AHTOXA подвигал каталоги и я забросил пример на его законное место pre-v400/Samples/CortexM3/GCC/LPC17XX/
4-Debug добавлю на днях. Он рабочий, просто тоже вычистить немного нужно.
Остальные буду писать по мере поступления на склад очередных партий минут свободного времени, аккуратно упакованных в пачки по 30-40 штук.

p.s. Просто пример 1-EventFlag мне интересен как источник данных для сравнения

Вот, к примеру, в пересчётне на ту же тактовую у STM8 общее время переключения процессов на «дулі відсотка» меньше, чем у AVR, но при этом собственно время переключателя контекстов ощутимо меньше, а поиск готового процесса — немного больше. Просто любопытно.

А 4-Debug хорош как база для начала отладки реальной работы.
Потому с них и начал.

Спасибо за оперативность. Разбираюсь....

4-Debug уже там же.

Товарищи гуру и приближенные к ним!
Помогите решить еще одну чайниковскую проблему - процесс крутится в своем бесконечном цикле, и хотелось бы, чтобы он крутился каждые N циклов системного таймера. Сейчас он делает все задачи и ложится спать на определенное время, но, в связи с тем, что задачи выполняются не каждый раз за одно и то же время - период процесса тоже меняется. Конечно, можно запустить еще один таймер и пусть он генерирует событие, которого процесс и будет ждать, но хотелось бы обойтись системным таймером. Еще один тупой путь - запустить еще один процесс, который только спит, и просыпаясь, генерирует событие для другого процесса. Но как-то это выглядит не кошерно.

Как-то так.


Обработка ситуаций, когда спать уже некогда (ждать следующей метки или не ждать вообще) — по требованиям к задаче.
Также надо учесть, что tick_count_t и timeout_t имеют (могут иметь) разные размеры, тогда надо бы брать разность и «досыпать» порциями, влазящими в timeout_t.

Спасибо, когда пояснили, все стало так очевидно! Даже как-то стыдно за вопрос.

доброго времени днутра или ночера...

есть комплект stm32f0diskovery - требуется откомпилить и запустить какой нибудь из примеров под scmRTOS ..
как я понял примеров пока под cortex-m0 не существует... и ос тоже непонятно работает или нет

ТАК???

помогите пжста чайнику...

Примеров нет, но порт есть: порт для Cortex-M0

да да ... я порт нашел...
не могу понять как переделать пример для себя...
чтоб перекомпилить и чтоб заработало...

нет некоторых файлов типа стартап.си... и прочих

стартап.си - обычный, только таблица векторов должна быть соответствующей.

Update: вспомнил ещё ссылку - там стартап и тп

там для LPC11xx
а stm32f0 нет ...

Большая разница?
Там и там Cortex-M0.

мэй би ес, мэй би ноу....

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

может быть различное количество переферии, разные векторы прерываний и прочее...

проект переделал из stm32f2xx отключил кой чего и кой где...

отключил макросы для работы с пинами (pin.h) с шаблонами я пока не очень то разбимрался и не совсем понимаю чего там понаворочали...

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

Регистры ядра одни и те же?
Какие ещё системные переменные? О чём вы?


Стартап нужен соответствующий.

Разработчики все здесь, так что, считайте, связались

Антон, хотелось бы с вашей помощью "допилить" порт cortex-m0 для stm32f0xx до рабочего состояния...
ну и опубликовать естественно...

сейчас нахожусь на этапе...
sturtup, ld-script, sysinit переписаны... остольное взято с сайта...
с этими файлами перекомпилил и запустил демку для дискавери... (дефолтная)
т.е. файлы вроде как рабочие...

проблема такая...
при запуске системы работает только одна задача - первая...
и не работает функция sleep();

похоже контекст не переключается...
платформо зависимую часть брал из "ветки"
демку и настройки системы взял от stm32f2xx...

как с вами Антон связаться...??? кроме как в форуме ??? думаю работа пошла бы оперативнее..

У вас, похоже, не работает прерывание от системного таймера. Возможно, не совпадает имя обработчика с именем в таблице векторов. Выложите проект сюда, посмотрим, в чём может быть дело.

Скорее прерывание переключения контекста.

выкладываю исходники

Странно, не собирается:

сори...
надо src и мэйк в папку проекта бросить как у примеров РТОС
ну или мэйк надо немного поправить

На очередные грабли наступил. В ИАРе для 430 стОит в Library Option для Printf поставить вместо Tiny Large - и та же программа, которая благополучно работала раньше, виснет. Похоже, что-то со стеком. Понятно дело, что float и тем более printf - это не спортивно, но все же... Как бы с этих грабель уйти?

Если подозрение на стек -- увеличить стек для процесса, использующего printf

Действительно, очевидное решение. И ведь даже увеличивал - но не думал, что надо так сильно увеличить. 500 байт хватило.
Спасибо!

Помогите пожалуйста определиться со структурой процессов, потоков данных и приоритетами для процессов.

Есть следующий дизайн:
Удалённый терминал сбора данных.
Состав:
- Процессор MSP430F210
- Связь с хостом по RS485-slave (используется ModBus, но это непринципиально). (UART)
- Связь головкой сбора данных по RS485-master (UART)
- Пользовательский интерфейс: 4 кнопки и 3-4 строчный графический дисплей. Связь с ним по SPI через расширитель. При нажатии на кнопки вырабатываются прерывания.
- Управление 3мя реле через GPIO
- Внешний RTC с интерфейсом I2C. RTC может вырабатывать прерывания. Скажем, раз в секунду.
- Внутренняя используемая периферия: 3 канала PWM для медленно меняющихся сигналов, ADC для отслеживания уровня питания, внтуренний EEPROM

По первой прикидке представляется следующее (в порядке приоритета)

1. RS485_Slave_Proc - включает в себя обработку прерываний от UART, чтение команды/данных от хоста и соответствующее реагирование на них. Использует channel для передачи и приёма данных в/из DataProcessing_Proc. Длина канала TBD.
2. DataProcessing_Proc - фактически коммутатор данных между процессами с декодером команд. Формирует необходимые данные для периферии в нужных форматах.
3. UI_Proc - Обслуживание пользовательского интерфейса. Включает в себя обработку прерываний от SPI. Использует message для передачи кода нажатой кнопки в DataProcessing и channel для передачи отображаемой информации на дисплей. Отображаемая информация пока только текстовая, т.е. этот процесс содержит в себе декодер ASCII в графику.
4. RS485_Master_Proc - Включает в себя обработку прерываний от UART. Но не для скорости ответа, а для того, чтобы можно было послать запрос и заниматься остальными делами пока не появится ответ. Как вариант, можно и без прерываний, т.е. в одном цикле запросил данные, в следующем - проверил и если есть, то забрал. Использует, скорее всего, message.
5. LowSpeed_Proc - включает в себя обработку прерываний от RTC (раз в секунду или минуту) и считает время до следующего обслуживания , по данным от DataProcessing включает и выключает реле, по данным от него же выставляет новые значения на PWM, работает с EEPROM, читает АЦП, измеряющее напряжение питания. Передача данных через структурированные мессаджи, т.е. message представляет из себя структуру необходимых данных.

Сразу возникают несколько вопросов:
- Не имеет ли смысла UI_Proc разделить на отдельные процессы работы с кнопками и дисплеем даже при том, что они используют один физический интерфейс?
- Имеет ли смысл вынести в отдельные процессы работу с RTC (редко) и с EEPROM (долго - надо ждать флага). Или просто внутри одного процесса пройти по всей этой периферии, благо всё это медленно? А может и RS485_Master вставить в LowSpeed?
-

Никто, кроме вас, не знает, как лучше распределить ресурсы в программе под вашу задачу. Общее правило такое: всё, что не может ждать, помещать в более приоритетные процессы, чем срочнее, тем приоритетнее. Какие там конкретно требования по времянкам, это вам известно, от этого и отталкивайтесь.

По поводу пользовательского интерфейса - тоже вам виднее, но я бы не разделял, кнопки не по прерываниям обрабатывал, а по опросу, синхронизированному с основным циклом UI.

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

Но вот вопрос совмещения или разделения кнопок и дисплея в олдном процессе остался. Основное в нём то, что используется один SPI. Стоит на этом базироваться или просто иметь в виду, что это единый ресурс для двух процессов, которые всегда вызываются в разное время?

Я пока сделал следующее объявление:


Ага, сейчас понял, что для случая, который я сейчас показал, для SPI должен использоваться Mutex. Я прав?

Ну да. Через mutex обычно и делается.

Спасибо.
Насколько я понимаю, у тебя есть опыт работы с этой системой. Пока уважаемые авторы системы заняты, может подскажешь по поводу моей структуры. Нормально или что-то изменил бы?

Не нашёл в документации других членов класса process кроме так exec. Это так и должно быть?

Да, где-то так:


Но так как process насладник TBaseProcess,
то есть ещё методы, перешедшие по наследству от TBaseProcess:

Ага, спасибо, нашёл в доке.

Возможно глупый вопрос: может ли mutex быть членом класса или он всегда является внешним по отношению к любым другим объектам?