ALCOR plast

Полистал каталог всяких полимеров от фирмы ALCOR Plast, весьма интересно, в том числе и для косплея — такой грим можно навертеть и наросты всякие, что огого .з. Впрочем цены могут быть такими же огогошными >>

Вот страничка с вариантами пластиков для творчества. из эпоксидок можно всяких "драг. камней налепить", из силикона формы для отливки деталей, силикон для всяких нашлёпок на тело (рожи, рога, лапы, морды, и т.д.), силиконовые пены для всяких имитаций мягких деталей тела, пигменты, полиуретановые литьевые пластики и пенополиуретан для всякого рода крафта Оо

Правда, на сайте нифига не понятно и не факт, что можно купить в розницу...

@темы: мии, няшодки

---

Семинар по светодиодному освещению

От Компела 20 сентября семинар: Компоненты светодиодного освещения и управления светом.

Очень интересно, интересно, отпустят ли?.з.

@темы: семинар, электроника, няшодки

---

Сегодня ехали на машине с дачи на Гашека, подумалось: "Чувствуешь себя незначительным? Устрой ДТП на единственной дороге у въезда на КАД с утра..."

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

@темы: мии

---

Фигурка Конаты

Хотеть себе такую фигурку:


И такую:

@темы: няшодки

---

Новый десятик

Как написано с новости центробанка, на третье сентября анонсирована юбилейная монета номиналом десять рублей «Великие Луки».


Тираж, как и обычно, 10 миллионов.

Кстати, и «Туапсе», и «Полярный» мне уже попадались.

@темы: монетики

---

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

@темы: мии

---

Прошивание AVR устройства "одним движением руки"

Установив AVR Studio 5.1 неожиданно обнаружил ряд интересных и полезных вещей.

Например, появился командный интерфейс (CLI), позволяющий прошивать контроллеры из командной строки =)
Находится сия программа в папочке \AVR Studio 5.1\avrdbg и называется atprogram.exe. Конечно, оно поддерживает только канонные устройства, но такая ли сложность их достать? =)

Интерфейс у неё простой и достаточно свободный. Например, для прошивки устройства я сделал следующий алгоритм:
atprogram -t jtagice3 -d atmega1280 -i isp -cl 250khz write -fs --values FFC9FC
atprogram -t jtagice3 -d atmega1280 -i isp -cl 1500khz chiperase
atprogram -t jtagice3 -d atmega1280 -i isp -cl 1500khz program -fl -f %1
atprogram -t jtagice3 -d atmega1280 -i isp -cl 1500khz verify -fl -f %1

-t — прибор, которым пользуемся.
-d — контроллер.
-i — интерфейс программирования (isp, jtag, debugwire, hvpp, hvsp).
-cl — скорость интерфейса. В данном коде фьюзы ставятся на частоте 250 кГц (так как новый контроллер работает на частоте 1 МГц), а потом прошивка и проверка идёт на частоте 1.5 МГц.

Команды говорят сами за себя. Есть и иные, но это в справку.

-f указывает файл с прошивкой (hex, elf).
-fl — записываем и проверяем флеш.
-fs — пишем фьюзы. --values указывет, что пишем не из файла, а вот прям то, что написано: FFC9FC. порядок фьюзов такой: Low, High, Extended.

Данный код сидит в файлике program.bat в той же папочке и вызывается по мановению ярлыка, где в качестве аргумента передаётся путь до файла прошивки. Примерно так:
"C:\Program Files\Atmel\AVR Studio 5.1\avrdbg\program.bat" C:\Production\NyashaPomigasha.hex

В общем, удобно.

Поддержка подобных алгоритмов появилась и в самой студии. Так называемые ELF Production file. То есть в исходном коде программы можно указать фьюзы и содержимое EEPROM. И оно запишется в elf-файл.
И в окошке AVR Programming появилась вкладочка Production, где этот файл можно зашить:

скриншот

Правда, тут всё шьётся с одной скоростью, а значит, с минимальной (250 кГц для меня). Не круто, но где-то таких проблем нет и прекрасно можно пользоваться.

И как бонус, пример файлика, объявляющего необходимые фьюзы: fuse.c
Он ничего не требует, достаточно его подключить к проекту. Однако ж для каждого контроллера надо иметь свой файлик =) Или же сделать комбо с помощью макросов...

И, применяя фьюзы подобным образом, не залочьте контроллер и не удивляйтесь невозможности отладки, если во фьюзах выключен JTAG или OCD. Фьюзы перед каждой отладкой зашиваются ж.

@темы: avr, электроника, няшодки

---

Сегодня на платформе слышал обсуждение чего-то у девочек-мальчиков абитуриентского возраста:
...
— А я смотрю многосерийный фильм. Ну, сериал. То есть мультик. Почти что аниме.
— «Наруто»?
— Мне нравится ^^
...

Эх...

@темы: мии

---

STM32F4. Режимы работы.

Как вам должно быть уже известно, Cortex-M4 имеет два режима работы, в отличие от старых версий архитектуры, где оных режимов штук семь:
Thread Mode, то есть режим для обычного кода. Уровень привелегий может быть урезан для исключения доступа к особо важным регистрам.
Handler Mode, который включается в прерываниях и исключениях. Этот режим привелегированный по умолчанию. То есть имеет доступ ко всему, чему угодно.

Для контроля таких вещей есть системный регистр CONTROL. Он содержит три управляющих бита, но бита важных:
Бит 0: nPRIV, уровень привелегий у Thread Mode. 1 - непривелигерованный, 0 - привелигерованный.
Бит 1: SPSEL, выбор указателя стека для Thread Mode. 0 - MSP (Main SP), 1 - PSP (Process SP). В Handler Mode регистр ВСЕГДА будет переключаться на MSP, вне зависимости от настройки данного бита. В том и фишка.
Бит 2: FPCA, включение контекста FPU. То есть будет ли он сохраняться в стеке при исключениях.

Для надёжности, что будет использоваться прям вот новый стек, лучше всего сразу после изменения указателя стека выполнить инструкцию ISB, которая сбросит линию выполнения процессора и все выборки там начнутся заново, с заведомо верным SP. Хотя, если там будет много операций без использования стека, то это не потребуется.

Инструкция MSR (MRS) даёт доступ к системным регистрам. Регистров этих достаточно много: APSR, IPSR, EPSR, IEPSR, IAPSR, EAPSR, PSR, MSP, PSP, PRIMASK, BASEPRI, BASEPRI_MAX, FAULTMASK и CONTROL.

Нам пока понадобятся только два из них:
CONTROL для настройки;
PSP для смены указателя стека при переключении процессов.

Замечу интересный неочевидный момент. Возвращайтесь из прерываний всегда по тому коду, который даёт вам LR. А не по какому вы высмотрели в таблице. Это логично - если процессор сохранит, например, состояние FPU-регистров, но не загрузит их по выходу, потеряется дофига места на стеке. Несколько таких операций и указатель неизвестно куда улетит!

С этим, в общем, всё.

EnterNonPrivelegedMode PROC
	; Запишем в PSP пока что значение MSP. 
	; Всё равно оно перезапишется потом при переключении процессов.
	MRS  R0, MSP
	MSR  PSP, R0

	; Установим в регистре CONTROL разделение стеков:
	MRS  R0, CONTROL
	ORR  R0, #CONTROL_nPRIV ; Непривелегированный режим
	ORR  R0, #CONTROL_SPSEL ; Раздельный SP для TM и HM
	MSR  CONTROL, R0

	BX   LR
ENDP

Теперь загрузка указателя стека, например, будет выглядеть так:

LDR   R2,  [R1, #CONT_SP]
MSR   PSP, R2

Ну и типа того.

Интересное:
nyaos_core.s
system.s

Проект.

<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, ассемблер, stm32f4discovery, stm32

---

XB24-WFSIT (WFPIT) firmware update

В используемых модулях Wi-Fi было ПО версии 101E, которое не давало возможности (ввиду какой-то внутренней ошибки) определить разрыв сондинения с точкой доступа. Модуль просто переставал принимать и передавать данные, даже не зная об этом.

Я спрашивал в техподдержке, что делать, несколько дней назад, но пока отвечал только робот со статусами вопроса. Изучение сайта показало, что для этих модулей есть новая версия ПО 102D, где уже это исправлено. Кроме того, добавлена поддержка шифрования WEP. Так что пока у них я не вижу особо критичных недостатков.

Единственное, что не нравится - программа X-CTU, вроде, которая эти модули позволяет настраивать и обновлять ПО.
Только обновлятор до чего капризный и мнительный - аж жуть. Стоит модулю чуть-чуть задуматься с ответом, так он закатыват истерики: "Ты не хочешь со мной общаться! Я обиделся и иди нафиг". То есть два модуля удалось обновить хорошо псли с пятнадцатой попытки. Потому протокол снял логическим анализатором (благо он прост) и испытываю желание запихать в отдельный микроконтроллер, чтоб автономно без всяких капризов их обновлять.

@темы: мии, электроника, xbee

---

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

---

Десятики

Общий итог:

собственно, итог

.
Обычные: 429 (тяжёлые уже)

65 лет Победы: 1 (ещё хотя бы одну тт)
50 лет полёта в космос: 16
100500 лет Государственности: 3 (c 20 марта 2012)

Белгород: 6
Курск: 6
Орёл: 4
Владикавказ: 2
Малгобек: 2
Елец: 15
Ржев: 4
Ельня: 8
Воронеж: 3
Луга: 2 (c 2 мая 2012)
Полярный: 0 (c 30 мая 2012)

Всего: 68
Осталось 2 уникальных монеты!><

Биметалл:
"Никто не забыт, ничто не забыто": 2
"Министерство иностранных дел Российской Федерации": 1
"Республика Бурятия": 2
"Воронежская область": 2

Двушки:
200 лет 1812: 0


Ждём: Полярный, Ростов-на-Дону, Туапсе, Великие Луки, Великий Новгород, Дмитров, 200-летие победы России в Отечественной войне 1812 года.

Кстати, никто не в курсе, где можно сделать латунное покрытие металлического изделия?Оо

Log. Last 11.06.2012

23.12.2011: 5 обычных, Владикавказ;
25.12.2011: 5 обычных;
28.12.2011: 5 обычных;
02.01.2012: 10 обычных;
02.01.2012: 1 Курск, 3 Ельни (1 увёз домой), 1 обычный;
10.01.2012: 1 Ржев, 1 Елец, 22 обычных, 1 "Кировская область".
14.01.2012: 1 Ельня (отдал Ане), 3 обычных.
15.01.2012: 1 Елец, 1 Ельня (отдал Даше), 3 обычных.
31.01.2012: 3 Елец, 3 обычных, 1 "Воронежская область".
08.02.2012: 12 обычных.
09.02.2012: 4 обычных.
15.02.2012: 4 обычных.
16.02.2012: 2 Елец, 7 обычных (спасибо Вале =D).
17.02.2012: 4 Елец.
21.02.2012: 1 Космос, 1 Белгород, 6 обычных.
22.02.2012: 2 Космос.
23.02.2012: 4 обычных.
24.02.2012: 8 обычных, 1 "Республика Бурятия".
27.02.2012: 5 обычных.
01.03.2012: 1 Ельня, 5 обычных.
04.03.2012: 1 Космос, 10 обычных.
05.03.2012: 3 обычных, 2 "Никто не забыт...", 1 "МИД РФ"
07.03.2012: 1 Белгород, 2 Космос, 5 обычных.
08.03.2012: 7 обычных, 2 Орёл, 1 Елец, 1 Ельня, 1 Космос.
13.03.2012: 1 Космос, 9 обычных.
15.03.2012: 1 Малгобек, 4 обычных.
29.03.2012: 1 Космос, 14 обычных
09.04.2012: 1 Елец, 1 Белгород, 2 Курск, 4 Космос, 20 обычных.
20:04.2012: 1 Ржев, 15 обычных, 1 "Республика Бурятия".
22.04.2012: 2 обычных.
02.05.2012: 17 обычных, 2 Космос, 1 Белгород, 1 "Воронежская область".
10.05.2012: 17 обычных, 2 100500, 1 Ельня.
19.05.2012: 16 обычных, 1 Космос, 1 Ельня, 3 Воронеж.
23.05.2012: 9 обычных, 1 100500, 1 Ржев, 1 Орёл;
11.06.2012: 18 обычных, 2 Ельня, 2 Луга.

запись создана: 21.12.2011 в 15:33

@темы: просто ня, монетики

---

STM32F4. Критические секции.

ОС работает. Создание и завершение процессов в любой момент возможно.

Но есть ещё одна очень нужная штука в ОС: критические секции.

Бывают такие места в коде, которые ну никак прерывать нельзя. Ну или нежелательно.
Пока у меня таких мест нет, но всё бывает. Для поддержки такой функциональности введены две процедуры:

uint32_t EnterCriticalSection(void); // Начать критическую секцию
uint32_t LeaveCriticalSection(void); // Закончить критическую секцию

Принцип их прост: при начале секции отключается системный таймер, а при конце включается. При этом не должно происходить смены контекста, что даёт уверенность, что обработка критичных данных (которые используются и конкурирующими процессами) пройдёт нормально. И никто никому не помешает и не затрёт результат его деятельности.
А то как бывает... Есть код:
читать содержимое переменной X в регистр А.
изменить содержимое регистра А (например, выставить бит)
записать значение регистра А в переменную Х.

При этом, если процессов с подобным два или больше, возникает опасность гонки:
ПРОЦ1: ляляля
ПРОЦ1: читать содержимое переменной Х (0x10, например)
ПРОЦ1: выставить флаг (0x12)
ЯДРО: смена контекста на ПРОЦ2
ПРОЦ2: ляляля
ПРОЦ2: читать содержимое переменной Х (всё те же 0x10, не успели записать изменённое)
ПРОЦ2: выставить флаг (0x14)
ПРОЦ2: записать содержимое переменной Х (теперь там 0x14)
ПРОЦ2: ляляля
ЯДРО: смена контекста на ПРОЦ1
ПРОЦ1: записать содержимое переменной Х (теперь там 0x12), а флаг 0x04 потерялся. Затёрли его.
ПРОЦ1: ляляля
...

Использование критических секций предотвращает подобное поведение.

Из железного... Отключение прерываний (TICKINT) не предотвращает появления ещё одного, последнего прерывания, когда таймер досчитает до нуля. Не знаю почему так, пока что я не разобрался.
ПРЕДУПРЕЖДЕНИЕ! В данной версии проекта есть ещё возможность залипнуть из-за критической секции: системный таймер может успеть досчитать к моменту его выключения, выставить флаг и отправить прерывание на обработку. Ну нет такой штуки в контроллере, которая прерывание таймера бы намертво заглушила сразу и навсегда .з. Потому я в следующих версиях добавил проверку на выключенность системного таймера прямо в процедуре переключения контекстов!

Для этого сделана простенькая процедура SysTickInterruptEnable. Пока что так.
Конечно, если секция длиннющая, то все тайминги процессов и задержек поползут. Но секции такие в принципе должны быть как можно короче.

Что ещё поменялось? При входе в прерывание остальные прерывания запрещаются.
Есть такая полезная инструкция CPS (Change Processor State). Раньше флаг глобального разрешения прерываний хранился в регистре CPSR и требовалось его считать, установить и записать (Команды MSR, MRS). Теперь всё делается за одну команду.

CPSIE i ; Разрешить прерывания (Interrupt Enable)
CPSID i ; Запретить прерывания (Interrupt Disable)

Аналоги оных функций на АВР: sei и cli.

Проект тот же самый. Только доавился ещё один процесс и код события. Новый процесс опрашивает акселерометр (в критической секции) и считает вектор ускорения. Если он превышает заданный предел, то генерируется событие "Перегрузка": INPUT_ACCEL_ONSHOCK.
И процесс моргательный моргает сразу почти всеми светодиодами. За исключением второго, который моргает с разной частотой в зависимости от показаний акселерометра по оси Z. Чем больше намеряно, тем реже моргает.

Функции LedOn и LedOff тоже поменялись в угоду скорости: теперь передаётся в них маска. То есть младшие 4 бита определяют, какие светодиоды гасим или зажигаем.

Ещё поменянна файловая структура проекта для удобства. Все файлы исходного кода помещены в папку source, а компиляция осуществляется в папку build. Внутри проекта тоже файлы разделены по категориям:
1. NyaOS. Файлы, относящиеся к ОС;
2. Main. Файлы запуска контроллера и файл main.c;
3. Drivers. Файлы для работы с периферией: светодиоды, SPI и акселерометр.

Файлы не прикладываю, там особых изменений нет.
Проект целиком.

<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, ассемблер, stm32f4discovery, stm32

---

STM32F4. Динамические процессы.

ОС уже имеет миниальную поддержку событий и задержек. То есть, с задержками уже всё хорошо, а вот с событиями не очень.

Например, одно событие слушает несколько процессов. Тогда успеет тот, который первый поймает. Остальные уже и не узнают, пока и им не повезёт.

Для предотвращения сего система событий немного изменена! Теперь структура TProcess в поле Event хранит не указатель, а идентификатор.
И процедура FireEvent просматривает таблицу и самостоятельно делает всё, что надо, если найдёт, что событие слушается кем-то. И только если не найдёт слушателей, то посмотрит таблицу зарегистрированных событий и запишет код события туда.
Процедура WaitForEvent сначала смотрит зарегистрированные события и реагирует на код, записанный в соответствующую переменную. Если там ноль или событие не зарегистрировано, то она записывает в таблицу процессов флаг F_EVENT и соответствующий код.

То есть теперь не обязательно регистрировать событие, чтоб его сигнализировать или ждать.

Ещё важное изменение: добавилась функция ExitProcess, которая обнуляет PID и сигнализирует о завершении процесса всем, кому это интересно. Ну и забирает управление от процесса. При этом идентификатором события является номер слота, а кодом его является код завершения.
То есть для завершения процесса можно вызвать ExitProcess(код завершения).

Наконец-то пригодилась функция nyaos_Stub, адрес которой писался в LR процесса. В ней я добавил svc-вызов функции ExitProcess. При этом, как понятно, в R0 окажется то, что вернул процесс с помощью return =) По-моему, это шикарно.
И завершать процесс можно с помощью return <код_завершения>. Прям как в винде.

int SlaveProcess(uint32_t Argument)
{
	LedOn(Argument);
	Delay(100);
	LedOff(Argument);
	Delay(300);

	// Завершение процесса с кодом ошибки 0
	return 0;
}

Для создания процессов из процессов у функции nyaos_AddProcess я сделал svc-псевдоним CreateProcess.
То есть теперь можно спокойно создавать процессы.

И флагам в аргументе тоже нашлось применение: первый флаг, CP_F_WAIT_FOR_EXIT, позволяет ждать завершения созданного процесса. Как раз с помощью того, что ExitProcess извещает о завершении процесса.
И тоже очень просто: записываем в запись о текущем процессе, в Flags бит F_EVENT и в Event номер процесса. И передаём управление дальше. А там уже всё сделается само.

Теперь по событию нажатия/отпускания кнопки создаётся дочерний процесс SlaveProcess (с ожиданием его завершения), в котором моргает на 100 мс светодиод и процесс завершается. После чего ожидается следующее событие.

while(1){
	uint32_t Led = WaitForEvent(BUTTON_EVENT);
        
	uint32_t ExitCode = CreateProcess("SlaveProcess", &SlaveProcess, Led, CP_F_WAIT_FOR_EXIT);
}

Конечно, такая ОС не из сверхбыстрых или оптимальных. Но работает, как я хочу, чем меня очень радует =)
Использовать я буду что-то типа FreeRTOS, а это так, для изучения принципов.

Интересные файлы:
main.c
nyaos_api.c
nyaos_core.s

Проект.

<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, stm32f4discovery, stm32

---

STM32F4. Задержки и события в ОС.

Пока ОС предоставляет только услугу переключения процессов. Однако в любой человеческой ОС нужны две важных вещи: программная задержка и ожидание события. Пока не истекло время или не наступило ожидаемое событие, процесс не получает управления. Таким образом можно ожидать, например, прихода символа по UART сколь угодно долго, никак не напрягая ядро.

Для таких случаев у меня выделен регистр флагов. И понадобится ещё один служебный 32-битный регистр, например Event.
1. Один флаг (F_DELAY) будет обозначать, что сейчас выполняется программная задержка. На каждый вызов прерывания таймера число, сохранённое в регистре Event будет уменьшаться на единицу. По достижении нуля флаг F_DELAY снимается, процесс продолжает выполнение в обычном режиме.
2. Другой флаг (F_EVENT) будет означать, что выполняется ожидание событие. Событие представлено сохранённой в регистре Event ссылкой на переменную. Как только в переменной читается ненулевое значение, оно заносится в R0 процесса (код результата) и флаг F_EVENT снимается. Процесс продолжает выполнение.

Чем это здорово, что легко генерировать программные события. Заводи переменную, меняй её значение...
В принципе, можно немного модифицировать систему событий и ввести третий параметр: маска, которая применяется к переменной перед проверкой. Тогда можно будет ссылаться напрямую на регистры периферии с флагами прерываний.

Но тут не так. ОС проверяет значение переменной и, если оно ненулевое, записывает значение в R0 процесса (стек) и ноль в переменную как знак того, что событие обработано.

И добавить следует несколько API-функций:
1. Задержка.

void Delay(uint32_t Milliseconds);

2. Ожидание события.

uint32_t WaitForEvent(TEvent Event);

3. Добавление события.

uint32_t RegisterEvent(EVENT Event, volatile uint32_t * Value);

4. Активация события

uint32_t FireEvent(EVENT Event, uint32_t Value);

Все API идут через программные прерывания. Кстати, в Си их определение объявляют c помощью ключевого слова __svc(номер):

__svc(3) uint32_t FireEvent(EVENT Event, uint32_t Value);

Реализация функций написана тоже на Си. Только обработчик прерывания на ассемблере. Начало в нём точно такое же, как и раньше, только в конец добавлено переключение процессов, если надо.
Надобность определяется тоже просто: имеется константа SWI_ChCount, с которой сравнивается номер программного прерывания. Если больше или равно - переключения нет, если меньше, то переключение форсируется.
То есть в данном проекте будет форсироваться переключение после вызова функций Delay и WaitForEvent.

Можно поморгать светодиодами с помощью них... Этим занимается третий процесс.
А первые два работают с кнопкой по следующей логике:
Первый регистрирует событие и потом в цикле опрашивает кнопку с периодичностью порядка 10 мс и по детектированию фронта на линии кнопки генерирует событие. Ну и светодиодом 0 показывает состояние линии кнопки. В зависимости от фронта он генерирует событие с кодом 1 (нажали) или 3 (отпустили).

Второй ждёт события и моргает светодиодом (номер берёт из кода события) длительностью примерно 100 мс.
Третий просто моргает светодиодом, номер которого передаётся через аргумент (2).

Таким образом, по нажатию кнопки моргнёт светодиод 1 (оранжевый), а по отпускнию - светодиод 3 (синий).

Ну и я добавил в проект файл system_stm32f4xx.c из CMSIS, который имеет реализацию функции SystemInit, где тактовая частота настраивается равной 168 МГц.

Файлы только самые интересные, остальные в проекте:
main.c
nyaos.c
nyaos.h
nyaos_api.c
nyaos.core.s
swi_table.s

<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, ассемблер, stm32f4discovery, stm32

---

STM32F4. Базовая ОС.

Ладно. Наплюём пока на акселерометр (он нам понадобится потом). Сейчас главная задача — сделать примитивную вытесняющую ОС. Памяти дофига, можно не жадничать.
ОС я ни разу не писал, но надо ж с чего-то начинать. А для изучения асма и контроллера это самое то. Пока читать литературу не буду, попробую сообразить сам.

Что для самого-самого базового нам понадобится?
1. Системный таймер.
В прерывании должно происходить переключение контекста. То есть сохраняться все регистры (R0-R15 и CPSR) для текущей задачи и загружаться для следующей. Самое классное то, что часть работы сделает сам процессор. Как я уже говорил — основные регистры (R0-R3,R12,LR,PC,CPSR) при появлении прерывания кладутся в стек, откуда их можно преспокойно скопипастить. И заменить на иные. И процессор их благополучно вернёт, как будто ничего и не случалось.
2. Память под контекст задачи и для каждой свой стек. Плюс структура для идентификации процессов и их переключения.

Возьмём самый первый пустой проект, настроим стандартную библиотеку и системный таймер.
Единственное замечание: ОС — это средство, потому оно должно быть в побочных файлах. А главным файлом будет main.c, откуда ОС будет запускаться и где будут добавлены сами процессы.
В принципе, никто не запрещает сделать то же самое с асмовскими функциями, но так более наглядно, как мне кажется. С прикладной точки зрения.

И да, ОС у нас будет называться NyaOS. Что, в общем-то, было очевидно с самого начала. Название эмулятора-дизассемблера NyARM я тоже застолблю за себя =D

Запись в таблице процессов будет содержать идентификатор процесса, указатель на имя процесса и поле флагов. Таблица будет состоять из наперёд заданного количества элементов. Процесс с нулевым PID не участвует в работе и пропускается. При инициализации все записи имеют PID = 0.

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

// Контекст процесса
typedef struct
{
    uint32_t     SP; // Указатель стека процесса. Там автоматически сохранятся 
                     // R0-R3, R12, LR, PC, CPSR (и перед запуском их настроим вручную)
        
    uint32_t     Rother[8]; // Остальные регистры: R4-R11
} TProcessContext;

В принципе, можно ещё для удобства создать структуру, описывающую состояние вершины стека после попадания в прерывание:

// Описание регистров в стеке после входа в прерывание
typedef struct
{
    uint32_t  R0;  // Регистры общего назначения
    uint32_t  R1;
    uint32_t  R2;
    uint32_t  R3;
        
    uint32_t  R12;
        
    uint32_t  LR;   // Регистр с адресом возврата
    uint32_t  PC;   // Регистр-указатель команды
        
    uint32_t  CPSR; // Регистр статуса
} TInterruptStackFrame;

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

При добавлении процесса:
1. Ищем свободный слот в таблице;
2. Назначаем PID;
3. Запоминание название;
4. Назначаем вершину стека (из имеющейся кучи, хотя в приципе компилятор позволяет динамически выделять её);
5. Записываем в регистры общего назначения нули (в таблицу в стеке, конечно же);
6. В регистр R0 записываем аргумент к задаче (там же);
7. В LR пишем адрес заглушки (Там инструкция "B ."), чтоб если вышло из процесса, так хоть не куда попало, а вполне контролируемо. В будущем можно добавить возврат на функцию аварийного завершения процесса.
8. Инициализируем CPSR в таблице числом 0x01000000, то есть установлен только T-бит, ответственный за режим. Иначе будет плохо.
9. В область памяти, ответственную за PC, запишем точку входа в процесс.

Вот и всё. Все остальные дела сделает диспетчер при наступлении очередного прерывания =)

Что должен делать диспетчер?
1. Посмотреть номер текущего слота (или можно хранить прям указатель на него) и записать туда регистры R4-R11 и сохранить SP, используя только регистры R0-R3 и R12. Напомню, что их ядро автоматически сохраняет в стек. После чего появляется свобода использования остальных регистров;
2. Найти следующий процесс. Пока они не имеют никаких флагов ожидания, так что это будет просто первый попавшийся следующий в таблице процесс с ненулевым PID. Если таковых после полного обхода таблицы не обнаружилось, выбираем заранее созданный процесс в слоте ноль (Idle);
3. Меняем номер активного процесса в переменной;
4. Загружаем адрес записи контекста;
5. Загружаем оттуда новый указатель стека;
6. Загружаем старшие регистры копипастом из таблицы (используя R0-R3, R12);
7. Выходим из прерывания.

При этом выполнение перейдёт в выбранный процесс.

Сделав два процесса, моргающих светодиодами, можно понаблюдать их синхронную работу. Диспетчер работает.

Вот файлы:
main.c
nyaos.h - объявления таблиц;
nyaos.c - инициализация таблиц, добавление процесса;
nyaos_core.s - диспетчер;

Проект целиком.

<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, ассемблер, stm32f4discovery, stm32

---

STM32F4. Системный таймер.

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

Для начала можно рассмотреть SysTickTimer. Это такой специальный 24-битный таймер, который есть во всех ARMах и который умеет циклически считать с определённого заданного значения до нуля на частоте порядка тактовой. Ну и, конечно, имеет своё прерывание.
Основная его задача обычно — инициировать переключение процессов в ОС, ну и отсчитывать временные интервалы для разных событий внутри неё.

Регистров у него много: аж целых четыре штуки.
STK_CTRL (0xE000E010) - регистр настройки и статуса;
STK_LOAD (0xE000E014) - с какого числа он будет считать вниз;
STK_VAL (0xE000E018) - текущее значение; Любая запись сбрасывает его в ноль.
STK_CALIB (0xE000E01С) - число калибровки (только чтение).

В регистре настройки аж 4 значащих бита. Из которых три бита настройки и один статуса. Не знаю, есть ли проще периферия на AVR?
Бит 0 (ENABLE). Флаг включения таймера.
Бит 1 (TICKINT). Флаг разрешения прерывания (которое SysTick_Handler).
Бит 2 (CLKSOURCE). Флаг выбора частоты тактирования. Если бит равен нулю, то тактовая делится на 8 (CKDIV8 прям =DDD), если единице, то не делится.
Бит 16 (COUNTFLAG). Флаг, говорящий о том, что счётчик досчитал до нуля.

Не стоит удивляться такому расположению бит - так удобнее читать статус (LDRH старшего слова будет давать 1 или 0) и настраивать таймер (STRH).

Как уже понятно, настройка проста:

; Базовый адрес системного таймера
<b>MOV32 </b>R0, STK_BASE
            
; Значение для перезагрузки
; Частота таймера: 1000000 Гц
; Тик 1 раз в миллисекунду
MOV32 R1, F_SYSTICKRELOAD
STR   R1, [R0, #STK_LOAD_OFFSET]

; Запуск и разрешение прерывания
MOV   R1, #0
ORR   R1, #STK_CTRL_ENABLE  ; Разрешить тактирование
ORR   R1, #STK_CTRL_TICKINT ; Разрешить прерывание
STRH  R1, [R0, #STK_CTRL_OFFSET]

Число F_SYSTICKRELOAD объявлено как тактовая частота, делённая на 1000. Так как пока камень работает от внутреннего RC-генератора (8 МГц), и ещё предделителем таймера делится частота на 8, то итоговая частота падает до 2000 Гц. Ещё где-то делится частота пополам (но я пока не понял где). Но где-то раз в 1 мс прерывание дёргается (я подсчитывал секунды и сравнивал).
Потом с системой тактированя разберусь, как приспичит.

Обработчик я для примера взял примитивнейший: ведётся подсчёт вызовов в переменную SysTickCount.

; Обработчик прерывания системного таймера
SysTick_Handler PROC
	PUSH {LR}
                
	; Прибавим единицу
	MOV32 R0, SysTickCount
	LDR   R1, [R0]
	ADD   R1, #1
	STR   R1, [R0]
                
	POP  {PC}
ENDP

Собственно, ОС уже можно реализовать, используя эти два механизма. ARM очень хорошо заточен под работу с ОС.

Файлы:
main.s
stm32f4xx.inc
system.inc
system.s
systick.s
Ну и проект. Уже за номером восемь.

Кому не интересны возможности ядра по поддержке ОС и ассемблер, может перейти сразу на работу с периферией: Базовый таймер. Правда, там идёт уже в основном Си. Но переписать логику на ассемблер уже должно быть несложно и самостоятельно.

<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, ассемблер, stm32f4discovery, stm32

---

Тадайма

А я приехал уже в Питер обратно =)

Повезло с датой билета — уже на следующий день, как мы проехали, размыло ЖД под Сегежей Оо И поезда фиг знает сколько стояли.

@темы: мии

---

STM32F4. Программное прерывание.

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

Кстати, я узнал, что в новых архитектурах ARM есть смециальная последовательность команд для загрузки 32-битного числа в регистр.
MOVW Rn,<младшие 2 байта>
MOVT Rn,<старшие 2 байта>

Но в ассемблере есть честный макрос: MOV32.
То есть все предыдущие инструкции LDR Rn, =<32-битное число> можно спокойно поменять на MOV32 Rn, <32-битное число>, что я и сделал. Правда, эти правки я не стал выкладывать в виде отдельных файлов, ибо не суть.

Код станет менее переносимым (на старые платформы), но кто собирается это делать, раз пишет на ассемблере?=D
UPD (от 12.11.2012): Кстати, ядро Cortex-M0 такое комбо тоже не умеет, так что если хотите код использовать и на нём, то лучше эту команду не трогайте, остановившись на старом добром LDR Rn, =Value.

И ещё одна необычная инструкция, устанавливающая правила условного выполнения до четырёх последующих команд: IT (If-Then), — которая появилась только на ядрах новой архитектуры.
Запись её такова: IT{X{X{X}}} <условие>

Работает это дело так: проверяется условие и, если оно верное, то следующая за этой команда выполнится.
Если хотим, чтоб две команды подряд подчинялись условию, то добавляем ещё один суффикс T: ITT. И так до четырёх штук.
Но это ещё не всё! Оно ещё умеет проверять обратное условие, то есть реализовывать поведение else. Для этого вместо суффикса T нужно применить суффикс E: ITTE. В этой команде две команды выполнятся, если условие истинно и пропустится третья, и наоборот, если условие ложно.
Очень интересная операция. Пример:
ITE EQ ; Если равно...
MOVEQ R0, #1 ; T: В регистр запишем 1
MOVNE R0, #0 ; E: В регистр запишем 0

На си это же:

if(a==b)
{
    R0 = 1;
}
else
{
    R0 = 0;
}

Или:

R0 = (a == b) ? 1 : 0;

Суффиксы условного выполнения к командам при этом писать обязательно. При этом нельзя помещать внутрь блока вызовы подпрограмм — это влечёт за собой непредсказуемое поведение.

Что насчёт прерываний... Обработчик прерывания объявляется очень просто. Таблица наименований прерываний есть в файле запуска startup_stm32f4xx.s. Для примера возьмём не самое простое (но и не сложное) прерывание: программное. Запишем его обработчик:

; Обработчик прерывания
SVC_Handler PROC
	PUSH {LR}
	; Полезный код
	POP  {PC}
ENDP

Ничем оно от подпрограммы пока не отличается. И это хорошо =)
Вызвать его можно командой SVC с каким-нибудь номером, который обозначает функцию. Прям как в DOS. В принципе, желающие могут написать что-то типа доса для практики на тех же принципах =D
Например: SVC 1
Разрешённые номера: от 0 до 255.

И всё! Программа прекрасно будет попадать в это прерывание.
Теперь необходимо, как минимум, добавить таблицу функций, а то толку с прерывания такого.
Сначала нужно узнать номер вызванного прерывания. Для этого придётся заглянуть в код, откуда вызывали, и вытащить номер из опкода инструкции SVC. Он сидит в младшем байте.
Заметьте! В старых версиях ядра регистр LR содержал в прерывании, как и в подпрограмме, адрес возврата. Теперь адрес возврата со всеми остальными регистрами лежит в стеке, а LR содержит специальный код для возвращения в обычный режим. Есть и другие коды, их можно посмотреть в PM0214 (Cortex-M4 Programming Manual).
В стек кладутся регистры: R0-R3, R12, LR, PC, xPSR. (Остальные надо сохранять вручную, если они будут использоваться). На R0 будет как раз указывать SP. До PC смещение 0x18. Ну и плюс сохранённый LR. Получится что-то вроде:
LDR R0, [SP, #0x1C] ; PC
LDRB R0, [R0, #-2] ; Младший байт инструкции (номер)

Ну а дальше получить адрес функции из специальной таблицы и перейти по нему. Лучше бы для всего этого запользовать регистр R12. В R0-R3 сидят аргументы всё ж. Большее количество аргументо использовать неразумно. Ищи-свищи потом в стеке остальное. Там же при включённом FPU ещё десяток с лишним регистров сохраняется (учтите при расчёте быстродействия).
Ещё одна тонкость - результат через регистры нет смысла передавать. По выходу из прерывания всё затрётся сохранённым содержимым стека. В принципе, можно копировать содержимое R0 куда надо и всё будет ок.

Пример таблицы:

; Количество элементов в таблице
SWI_Count        EQU 5

; Таблица функций
SWI_Table        DCD swi_LedOn  ; 0
                 DCD swi_LedOff ; 1
                 DCD swi_AccelX ; 2
                 DCD swi_AccelY ; 3
                 DCD swi_AccelZ ; 4

Функции типа swi_LedOff - самые что ни на есть обычные. Я их даже не менял.

Вызовы функций я поменял на вызов SVC:

; Вызов через SVC
LedOff      PROC
PUSH {LR}
	SVC   1
	POP  {PC}
ENDP

Для конечного кода ничего не поменялось. Но теперь можно делать API для RTOS. Ещё б RTOS эта была =D
Вызов, конечно, стал длиннее, но за всё надо платить.

Вот основные изменённые файлы:
main.s
swi.s
swi_table.inc
led.s
accel.s

И проект.

<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, ассемблер, stm32f4discovery, stm32

---

STM32F4. Низопоказометр.

На повороты проект предыдущий реагирует - это круто. Но чисто внешне реагирует невнятно, да и все переменные хранит в регистрах. Это не круто - регистров мало.

Для этого надо бы использовать память, наконец-таки. Объявим секцию переменных:

AREA    RAM, NOINIT, READWRITE, ALIGN=3

Название можно любое в пределах допустимого ассемблером. Оно создаёт секцию в объектном файле, но на результат не влияет. Все секции, объявленные с атрибутом READWRITE получают адреса начиная с 0x20000000 (выставляется в настройках проекта).

Переменные объявляются примерно так:

rAccelX     DCD 0
rAccelY     DCD 0
rAccelZ     DCD 0

rButton     DCD 0

Ключевое слово DCD означает, что переменная занимает 4 байта. DCW - 2 байта. DCB - 1 байт.
Если бы эти объявления были в секции READONLY, то это были бы константы заданного размера и содержания.
В NOINIT секции в качестве инициализирующего числа не может быть иного, чем ноль. Инициализируется секция всё той же библиотекой, так что если вы не успели её вернуть, а инициализация нужна - самое время это сделать.

Доступ к переменным осуществляется точно так же, как и к регистрам, с помощью команд LDR, STR. Пример:
LDR R0, =rAccelX ; Загрузить в R0 адрес rAccelX

LDR R1, [R0] ; Загрузить в R1 содержимое памяти по адресу R0 размером в 4 байта.
LDRH R1, [R0] ; Загрузить в R1 содержимое памяти по адресу R0 размером в 2 байта.
LDRB R1, [R0] ; Загрузить в R1 содержимое памяти по адресу R0 размером в 1 байт.

Запись осуществляется аналогичными командами. Причём, модификаторов к командам чтения/записи куда как больше, чем H и B. Есть модификаторы загрузки знаковых данных (SH, SB), где при чтении осуществляется знаковое расширение числа до 32 бит. По сути, если там выставлен знаковый бит в исходных данных (7 для SB и 15 для SH), то все старшие разряды заполнятся единицами.

Сам проект претерпел некоторые структурные изменения в главном файле: весь нечитабельный код из главного цикла был удалён и заменён на вызов более понятных процедур WriteAccel и PWMAccel.
Таким образом, теперь на светодиодах можно контролировать наклон относительно поверхности земли: светодиоды светятся с той стороны, которая ниже. И чем ниже больше наклон, тем больше светится. Аналогичный код уже можно пихать в игрушки: шарик, светящийся с одной стороны всегда, как его ни клади. Ну и могущий моргать при перегрузках =D

Ещё одно замечание относительно оформления кода по сохранению регистров в процедурах. Желательно очень, чтоб единовременно сохранялось чётное число регистров, так как ядро любит, чтоб адрес указателя стека всегда был кратен 8 байтам (три нулевых бита в конце указателя). И при наличии вызовов функций, которым это требуется, из ассемблерного кода, где это дело не выполняется, приведёт к ошибке:
Error: L6238E: <модуль>(<секция>) contains invalid call from '~PRES8 (The user did not require code to preserve 8-byte aligment of 8-byte data objects)' function to 'REQ8 (Code was permitted to depend on the 8-byte aligment of 8-byte data items)' function <функция>
Требование на такой режим выравнивания по умолчанию есть у всех функций, написанных на Си. У Ассемблера это можно затребовать директивой PRESERVE8 в начале файла. То есть требование относится ко всем функциям модуля и к их вызовам.

Причём, даже наличие одной функции в модуле, где нечётное количество регистров пихается в стек, приведёт к этой ошибке.
PUSH {R4-R5,LR} ; Может быть причиной ошибки L6238E
PUSH {R4-R6,LR} ; Это ошибки вызвать не может.

И последнее замечание на этот раз про локальные метки.
Сначала необходимо объявить область действия локальных меток с помощью ключевого слова ROUT (routine).
nameofscope ROUT ; Область действия меток с названием nameofscope

Область действует до следующего объявления области. Внутри этой области можно объявлять метки вида <номер от 1 до 99><название области>. Например:
3nameofscope

Переход по таким меткам записывается: B %3nameofscope
Более просто можно записывать только числа:
3 ;Локальная метка 3
B %3 ; Переход на локальную метку 3

Но с названием области более надёжно. Почему метки сделаны так странно - я не знаю, лично мне не нравится.
Хотелось бы пользоваться локальными метками осмысленными и полезными в каждой почти функции: exit, skip и т.д. Но нельзя. Либо добавлять префиксы или по-другому модифицировать название метки, делая её глобальной для модуля, либо использовать числа.

В этот раз изменился только один файл: main.s.
Проект целиком.

<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, ассемблер, stm32f4discovery, stm32