Jump to content
    

scmRtos для медных чайников

описание регистров и системных переменных совершенно разное ...

Регистры ядра одни и те же?

Какие ещё системные переменные? О чём вы?

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

ну и опубликовать естественно...

 

сейчас нахожусь на этапе...

sturtup, ld-script, sysinit переписаны... остольное взято с сайта...

с этими файлами перекомпилил и запустил демку для дискавери... (дефолтная)

т.е. файлы вроде как рабочие...

 

проблема такая...

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

и не работает функция sleep();

 

похоже контекст не переключается...

платформо зависимую часть брал из "ветки"

демку и настройки системы взял от stm32f2xx...

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

сори...

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

ну или мэйк надо немного поправить

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Спасибо!

Share this post


Link to post
Share on other sites

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

 

Есть следующий дизайн:

Удалённый терминал сбора данных.

Состав:

- Процессор 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?

-

 

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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. Я прав?

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...