|
|
|
scmRtos для медных чайников |
|
|
|
Aug 16 2012, 11:39
|
Гуру
Группа: Свой
Сообщений: 2 128
Регистрация: 21-05-06
Пользователь №: 17 322
|
Цитата(Посторонним В... @ Aug 16 2012, 11:57) описание регистров и системных переменных совершенно разное ... Регистры ядра одни и те же? Какие ещё системные переменные? О чём вы? Цитата(Посторонним В... @ Aug 16 2012, 11:57) может быть различное количество переферии, разные векторы прерываний и прочее... Стартап нужен соответствующий.
|
|
|
|
|
Aug 21 2012, 03:43
|
Участник
Группа: Участник
Сообщений: 41
Регистрация: 2-08-12
Пользователь №: 72 984
|
Цитата(AHTOXA @ Aug 16 2012, 15:44) Разработчики все здесь, так что, считайте, связались Антон, хотелось бы с вашей помощью "допилить" порт cortex-m0 для stm32f0xx до рабочего состояния... ну и опубликовать естественно... сейчас нахожусь на этапе... sturtup, ld-script, sysinit переписаны... остольное взято с сайта... с этими файлами перекомпилил и запустил демку для дискавери... (дефолтная) т.е. файлы вроде как рабочие... проблема такая... при запуске системы работает только одна задача - первая... и не работает функция sleep(); похоже контекст не переключается... платформо зависимую часть брал из "ветки" демку и настройки системы взял от stm32f2xx... как с вами Антон связаться...??? кроме как в форуме ??? думаю работа пошла бы оперативнее..
|
|
|
|
|
Aug 22 2012, 04:26
|
Участник
Группа: Участник
Сообщений: 41
Регистрация: 2-08-12
Пользователь №: 72 984
|
Цитата(_Артём_ @ Aug 21 2012, 20:37) Странно, не собирается: сори... надо src и мэйк в папку проекта бросить как у примеров РТОС ну или мэйк надо немного поправить
|
|
|
|
|
Sep 8 2012, 16:17
|
Частый гость
Группа: Участник
Сообщений: 93
Регистрация: 5-01-05
Из: Оулу
Пользователь №: 1 811
|
Цитата(ReAl @ Sep 6 2012, 23:36) Если подозрение на стек -- увеличить стек для процесса, использующего printf Действительно, очевидное решение. И ведь даже увеличивал - но не думал, что надо так сильно увеличить. 500 байт хватило. Спасибо!
|
|
|
|
|
Oct 3 2012, 02:09
|
Частый гость
Группа: Свой
Сообщений: 197
Регистрация: 31-03-06
Пользователь №: 15 676
|
Помогите пожалуйста определиться со структурой процессов, потоков данных и приоритетами для процессов. Есть следующий дизайн: Удалённый терминал сбора данных. Состав: - Процессор MSP430F210 - Связь с хостом по RS485-slave (используется ModBus, но это непринципиально). (UART) - Связь головкой сбора данных по RS485-master (UART) - Пользовательский интерфейс: 4 кнопки и 3-4 строчный графический дисплей. Связь с ним по SPI через расширитель. При нажатии на кнопки вырабатываются прерывания. - Управление 3мя реле через GPIO - Внешний RTC с интерфейсом I2C. RTC может вырабатывать прерывания. Скажем, раз в секунду. - Внутренняя используемая периферия: 3 канала PWM для медленно меняющихся сигналов, ADC для отслеживания уровня питания, внтуренний EEPROM По первой прикидке представляется следующее (в порядке приоритета) - RS485_Slave_Proc - включает в себя обработку прерываний от UART, чтение команды/данных от хоста и соответствующее реагирование на них. Использует channel для передачи и приёма данных в/из DataProcessing_Proc. Длина канала TBD.
- DataProcessing_Proc - фактически коммутатор данных между процессами с декодером команд. Формирует необходимые данные для периферии в нужных форматах.
- UI_Proc - Обслуживание пользовательского интерфейса. Включает в себя обработку прерываний от SPI. Использует message для передачи кода нажатой кнопки в DataProcessing и channel для передачи отображаемой информации на дисплей. Отображаемая информация пока только текстовая, т.е. этот процесс содержит в себе декодер ASCII в графику.
- RS485_Master_Proc - Включает в себя обработку прерываний от UART. Но не для скорости ответа, а для того, чтобы можно было послать запрос и заниматься остальными делами пока не появится ответ. Как вариант, можно и без прерываний, т.е. в одном цикле запросил данные, в следующем - проверил и если есть, то забрал. Использует, скорее всего, message.
- LowSpeed_Proc - включает в себя обработку прерываний от RTC (раз в секунду или минуту) и считает время до следующего обслуживания , по данным от DataProcessing включает и выключает реле, по данным от него же выставляет новые значения на PWM, работает с EEPROM, читает АЦП, измеряющее напряжение питания. Передача данных через структурированные мессаджи, т.е. message представляет из себя структуру необходимых данных.
Сразу возникают несколько вопросов: - Не имеет ли смысла UI_Proc разделить на отдельные процессы работы с кнопками и дисплеем даже при том, что они используют один физический интерфейс? - Имеет ли смысл вынести в отдельные процессы работу с RTC (редко) и с EEPROM (долго - надо ждать флага). Или просто внутри одного процесса пройти по всей этой периферии, благо всё это медленно? А может и RS485_Master вставить в LowSpeed? -
|
|
|
|
|
Oct 4 2012, 04:35
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Никто, кроме вас, не знает, как лучше распределить ресурсы в программе под вашу задачу. Общее правило такое: всё, что не может ждать, помещать в более приоритетные процессы, чем срочнее, тем приоритетнее. Какие там конкретно требования по времянкам, это вам известно, от этого и отталкивайтесь.
По поводу пользовательского интерфейса - тоже вам виднее, но я бы не разделял, кнопки не по прерываниям обрабатывал, а по опросу, синхронизированному с основным циклом UI.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
Oct 4 2012, 19:31
|
Частый гость
Группа: Свой
Сообщений: 197
Регистрация: 31-03-06
Пользователь №: 15 676
|
dxpСпасибо за ответ. Про общее правило - это-то понятно. Не вчера за программирование микроконтроллеров сел Собственно я и прикинул структуру из общих соображений и понимания того, что мне надо. Да и вообще, изложенное на бумаге/в форуме позволяет лучше сформировать собственное понимание того, что надо Просто некоторые тонкости работы с вашей системой могут быть таковы, что варианты могут быть разными. Тем более, если эти тонкости могут быть указаны авторами системы. В частности, совет по поводу опроса кнопок по опросу учту. Сейчас у себя поменяю инициализацию. Но вот вопрос совмещения или разделения кнопок и дисплея в олдном процессе остался. Основное в нём то, что используется один SPI. Стоит на этом базироваться или просто иметь в виду, что это единый ресурс для двух процессов, которые всегда вызываются в разное время? Я пока сделал следующее объявление: Код //--------------------------------------------------------------------------- // // Process types // typedef OS::process<OS::pr0, 200> TProc1; typedef OS::process<OS::pr1, 200> TProc2; typedef OS::process<OS::pr2, 200> TProc3; typedef OS::process<OS::pr3, 200> TProc4; typedef OS::process<OS::pr4, 200> TProc5; //--------------------------------------------------------------------------- // // Process objects // TProc1 RS485Slave_Proc; // interface to a host TProc2 DataProcessing_Proc; TProc3 UI_Buttons_Proc; // reading buttons status TProc4 UI_TextDisplay_Proc; // display text information TProc5 LowSpeed_Proc; // Relay, RTC, PWM (4-20mA control), Power ADC, EEPROM, RS485 master Ага, сейчас понял, что для случая, который я сейчас показал, для SPI должен использоваться Mutex. Я прав?
|
|
|
|
|
|
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0
|
|
|