[AHTOXA 18]

Сделал, залил в репозиторий. rev. 587.

 

Для того, чтобы получить приоритет прерывания системного таймера чуть выше, чем приоритет прерывания планировщика, необходимо в scmRTOS_TARGET_CFG.h объявить макрос

#define CORE_PRIORITY_BITS  2

Если этот макрос не объявлен, то считается, что приоритет имеет 8 значащих бит. Так как на всех знакомых мне камнях приоритет имеет менее 8 бит, то в этом случае всё будет работать как раньше, приоритет прерывания системного таймера будет самым низким.

[esaulenka 7]

Для того, чтобы получить приоритет прерывания системного таймера чуть выше, чем приоритет прерывания планировщика, необходимо в scmRTOS_TARGET_CFG.h объявить макрос

#define CORE_PRIORITY_BITS  2

Если этот макрос не объявлен, то считается, что приоритет имеет 8 значащих бит. Так как на всех знакомых мне камнях приоритет имеет менее 8 бит, то в этом случае всё будет работать как раньше, приоритет прерывания системного таймера будет самым низким.

 

Ещё б документировать его не только на форуме...

 

И вообще, мне кажется, стоит добавить табличку с комментариями в target_cfg.h:

CORE_PRIORITY_BITS = 4 для STM32F1xx, F2xx, (F3xx ?), F4xx, LPC17xx, LPC18xx

CORE_PRIORITY_BITS = 3 для LPC13xx, LM3S

CORE_PRIORITY_BITS = 2 для STM32L0xx, LPC11xx

 

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

 

 

И да, принудительно привести тип будет аккуратнее:

enum { SYS_TIMER_PRIORITY = (uint8_t)(0xFEUL << (8-(CORE_PRIORITY_BITS))) };

 

[AHTOXA 18]

Ещё б документировать его не только на форуме...

Я ещё в список рассылки отписался.

Надо будет ещё добавить про новый порт новость на сайт. И обновить документацию... Но это уж к следующему релизу, наверное :)

 

И вообще, мне кажется, стоит добавить табличку с комментариями в target_cfg.h:

Дело в том, что scmRTOS_TARGET_CFG.h - это файл уровня проекта, то есть, он изначально не рассчитан для применения на разных контроллерах.

Хотя, можно и добавить, не помешает.

И да, принудительно привести тип будет аккуратнее:

enum { SYS_TIMER_PRIORITY = (uint8_t)(0xFEUL << (8-(CORE_PRIORITY_BITS))) };

Да, верное замечание, спасибо. Только я лучше маску добавлю, потому что доступ к словам оптимальнее:

enum { SYS_TIMER_PRIORITY = ((0xFEUL << (8-(CORE_PRIORITY_BITS))) & 0xFF) };

[arhiv6 20]

Разбирался с переключением контекста, появился вопрос: можно ли в обработчике прерывания PendSV_Handler() вместо

" LDR R1, =os_context_switch_hook \n" // call os_context_switch_hook();
" BLX R1                          \n"

использовать

" BL =os_context_switch_hook \n" // call os_context_switch_hook();

вроде же команды равнозначны, но получается на одну инструкцию меньше. Или есть причины делать переход по адресу, а не по метке?

[AHTOXA 18]

Второй вариант короче, быстрее, но не может прыгать так далеко, как первый. Это относительный переход, и есть ограничение на длину прыжка.

[Aaron 1]

а что мешает в таком случае объявление функции os_context_switch_hook сделать в одной секции с PendSV_Handler?

Надо полагать, и остальные хуки можно попробовать сделать так же?

[AHTOXA 18]

В общем, довольно долго у меня там был как раз ближний переход. Потом обнаружилось, что при разнице адресов больше допустимого для ближнего перехода GCC никак не ругается, а молча генерирует нерабочий код. Обсудили это с коллегами. Обсуждали вариант сделать макрос, чтобы пользователь мог сам переключать. Но потом посчитали, что на фоне всего обработчика (включая код os_context_switch_hook) дополнительные 2 такта настолько ничтожны, что проще, надёжнее и вернее сделать безусловно дальний переход.

 

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

[alex6441161 0]

Всем привет.

 

Добрался до Cortex-M0+ (STM32L0xx). Подумал, что отличий от порта для Cortex-M4(F) немного, и поэтому взял порт Cortex-M0 от Сергея Борща и влил его в M4(F).

А так как порт Cortex-M4(F) уже поддерживал Cortex-M3, то порт получился универсальный.

Назвал порт CortexMx, чтоб не трогать имеющиеся. Поддерживаются Cortex-M3, Cortex-M4(F), Cortex-M0, Cortex-M0+, Cortex-M1.

Добавил также пример для STM32L0xx (плата STM32 NUCLEO-L053R8).

 

Планирую после тестирования перевести на этот порт все примеры для M3/M4.

 

Замечания и предложения приветствуются:)

 

 

Здравствуйте, извиняюсь что не по совсем по теме но...

не могу найти порт для Cortex-A8. Может у кого есть?

[dxp 65]

Здравствуйте, извиняюсь что не по совсем по теме но...

не могу найти порт для Cortex-A8. Может у кого есть?

Эк вы замахнулись! :) Нет, такого порта, увы, нет. В перспективе может появиться под SoC c FPGA, но там A9. А у вас какой процессор конкретно?

[darkling07 0]

Подскажите, на что обратить внимание при переходе с версии 4.00 на 5 (5.10 аналогично)? Есть проект на lpc1768 и gcc, который пережил еще scmRTOS 3. На версии 4.00 все замечательно работает. С версией 5 после изменения CortexM3 на СоrtexMx все скомпилилось, но не работет. Инициализация проходит точно, но после OS::run() процессы не идут.

[AHTOXA 18]

Проверьте имена обработчиков прерываний SysTick и PendSv. Там что-то менялось, вроде.

[darkling07 0]

Да, точно они. Спасибо!

Было PendSVC_ISR и SystemTimer_ISR , стало PendSV_Handler и SysTick_Handler

 

[AHTOXA 18]

Это чтобы соответствовать нынешним именам в CMSIS. Для PendSV_Handler я оставил weak-алиас:

#pragma weak PendSVC_ISR = PendSV_Handler

А вот с SysTick так не получилось, потому что там ещё нужна возможность использования другого таймера.

 

[esaulenka 7]

Балуюсь свежим gcc с link time optimization.

В двух проектах он как-то хитро оптимизировал os_context_switch_hook() и __init_system_timer() - почему-то решил, что символ не определён.

Причём в одном выкинул одну функцию, в другом - другую.

Помогло приписывание этим функциям атрибута used.

 

Сейчас попробовал тестовый пример - там выкинуло обе :-)

Invoking: Cross ARM GNU C++ Linker
arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding 
-flto -Wunused -Wuninitialized -Wall -Wextra -Wmissing-declarations -Wconversion -Wpointer-arith -Wpadded -Wshadow -Wlogical-op 
-Waggregate-return -Wfloat-equal  -g -T mem.ld -T libs.ld -T sections.ld -nostartfiles -Xlinker --gc-sections -L"../ldscripts" 
-Wl,-Map,"scmRTOS.map" --specs=nano.specs -o "scmRTOS.elf"  
./src/src/_cxx.o ./src/src/_exit.o ./src/src/_sbrk.o ./src/src/_syscalls.o ./src/src/assert.o  ./src/_write.o ./src/main.o ./src/os_kernel.o 
./src/os_services.o ./src/os_target.o ./src/recursive_mutex.o ./src/startup.o ./src/sysinit.o ./src/usrlib.o   

C:\Users\ESAULE~1\AppData\Local\Temp\ccEIkvE6.ltrans0.ltrans.o: In function `PendSV_Handler':
<artificial>:(.text.PendSV_Handler+0x1c): undefined reference to `os_context_switch_hook'
C:\Users\ESAULE~1\AppData\Local\Temp\ccEIkvE6.ltrans0.ltrans.o: In function `Reset_Handler':
<artificial>:(.text.Reset_Handler+0x190): undefined reference to `__init_system_timer'

[AHTOXA 18]

С LTO у меня не получилось собрать ни разу с тех пор, как я перенёс ассемблерные функции в *.cpp.

Похоже, компилятор не понимает вызовов из инлайн-ассемблера.

Вот всё думаю, что раньше случится - авторы gcc допилят gcc, или я переделаю обратно на *.S файл :)