AHTOXA 15 20 апреля, 2015 Опубликовано 20 апреля, 2015 · Жалоба Сделал, залил в репозиторий. rev. 587. Для того, чтобы получить приоритет прерывания системного таймера чуть выше, чем приоритет прерывания планировщика, необходимо в scmRTOS_TARGET_CFG.h объявить макрос #define CORE_PRIORITY_BITS 2 Если этот макрос не объявлен, то считается, что приоритет имеет 8 значащих бит. Так как на всех знакомых мне камнях приоритет имеет менее 8 бит, то в этом случае всё будет работать как раньше, приоритет прерывания системного таймера будет самым низким. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 23 апреля, 2015 Опубликовано 23 апреля, 2015 · Жалоба Для того, чтобы получить приоритет прерывания системного таймера чуть выше, чем приоритет прерывания планировщика, необходимо в 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 15 23 апреля, 2015 Опубликовано 23 апреля, 2015 · Жалоба Ещё б документировать его не только на форуме... Я ещё в список рассылки отписался. Надо будет ещё добавить про новый порт новость на сайт. И обновить документацию... Но это уж к следующему релизу, наверное :) И вообще, мне кажется, стоит добавить табличку с комментариями в 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 18 29 сентября, 2016 Опубликовано 29 сентября, 2016 · Жалоба Разбирался с переключением контекста, появился вопрос: можно ли в обработчике прерывания 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 15 29 сентября, 2016 Опубликовано 29 сентября, 2016 · Жалоба Второй вариант короче, быстрее, но не может прыгать так далеко, как первый. Это относительный переход, и есть ограничение на длину прыжка. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aaron 1 12 октября, 2016 Опубликовано 12 октября, 2016 · Жалоба а что мешает в таком случае объявление функции os_context_switch_hook сделать в одной секции с PendSV_Handler? Надо полагать, и остальные хуки можно попробовать сделать так же? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 12 октября, 2016 Опубликовано 12 октября, 2016 · Жалоба В общем, довольно долго у меня там был как раз ближний переход. Потом обнаружилось, что при разнице адресов больше допустимого для ближнего перехода GCC никак не ругается, а молча генерирует нерабочий код. Обсудили это с коллегами. Обсуждали вариант сделать макрос, чтобы пользователь мог сам переключать. Но потом посчитали, что на фоне всего обработчика (включая код os_context_switch_hook) дополнительные 2 такта настолько ничтожны, что проще, надёжнее и вернее сделать безусловно дальний переход. Остальные хуки вызываются из сишного кода, поэтому там выбора нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alex6441161 0 20 декабря, 2016 Опубликовано 20 декабря, 2016 · Жалоба Всем привет. Добрался до 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 56 20 декабря, 2016 Опубликовано 20 декабря, 2016 · Жалоба Здравствуйте, извиняюсь что не по совсем по теме но... не могу найти порт для Cortex-A8. Может у кого есть? Эк вы замахнулись! :) Нет, такого порта, увы, нет. В перспективе может появиться под SoC c FPGA, но там A9. А у вас какой процессор конкретно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
darkling07 0 12 апреля, 2017 Опубликовано 12 апреля, 2017 · Жалоба Подскажите, на что обратить внимание при переходе с версии 4.00 на 5 (5.10 аналогично)? Есть проект на lpc1768 и gcc, который пережил еще scmRTOS 3. На версии 4.00 все замечательно работает. С версией 5 после изменения CortexM3 на СоrtexMx все скомпилилось, но не работет. Инициализация проходит точно, но после OS::run() процессы не идут. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 12 апреля, 2017 Опубликовано 12 апреля, 2017 · Жалоба Проверьте имена обработчиков прерываний SysTick и PendSv. Там что-то менялось, вроде. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
darkling07 0 12 апреля, 2017 Опубликовано 12 апреля, 2017 · Жалоба Да, точно они. Спасибо! Было PendSVC_ISR и SystemTimer_ISR , стало PendSV_Handler и SysTick_Handler Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 12 апреля, 2017 Опубликовано 12 апреля, 2017 · Жалоба Это чтобы соответствовать нынешним именам в CMSIS. Для PendSV_Handler я оставил weak-алиас: #pragma weak PendSVC_ISR = PendSV_Handler А вот с SysTick так не получилось, потому что там ещё нужна возможность использования другого таймера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 24 апреля, 2017 Опубликовано 24 апреля, 2017 · Жалоба Балуюсь свежим 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 15 24 апреля, 2017 Опубликовано 24 апреля, 2017 · Жалоба С LTO у меня не получилось собрать ни разу с тех пор, как я перенёс ассемблерные функции в *.cpp. Похоже, компилятор не понимает вызовов из инлайн-ассемблера. Вот всё думаю, что раньше случится - авторы gcc допилят gcc, или я переделаю обратно на *.S файл :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться