[Артём__ 0]

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

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

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

 

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

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

[AHTOXA 14]

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

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

[kopalovvp 0]

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

 

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

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

 

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

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

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

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

 

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

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

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

 

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

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

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

 

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

[AHTOXA 14]

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

[Сергей Борщ 119]

У вас, похоже, не работает прерывание от системного таймера.

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

 

[kopalovvp 0]

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

Test_2012_08_21_08_26_10.7z

[Артём__ 0]

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

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

./src/main.cpp:47:23: fatal error: stm32f0xx.h: No such file or directory

[kopalovvp 0]

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

 

сори...

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

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

[varvar 0]

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

[ReAl 0]

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

[varvar 0]

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

 

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

Спасибо!

[Chudik 0]

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

 

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

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

Состав:

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

-

 

[dxp 32]

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

 

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

[Chudik 0]

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

[Артём__ 0]

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

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