Всем привет!

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

Что касаемо скорости. Тестировал на stm32f4discovery, проц STM32F407 Rev A (То есть, не работает ART prefetch), частота 168 МГц.
Итак.

• Если два процесса не использовали FPU, то передача управления осуществляется за 900ns.
• Если один из двух процессов использовал FPU, то передача управления осуществляется за 1.1us.
• Если оба процесса использовали FPU, то передача управления осуществляется за 1.34us.

Красивая картинка:
Нажмите для просмотра прикрепленного файла
К порту залиты примеры для STM32F4xx. Кроме стандартных четырёх примеров добавлен пятый - "5-FPU".
Он тестирует неизменность контекстов задач при выполнении действий с плавающей точкой.

Да, кстати. Этот порт подходит без изменений для M4F, M4 и M3. Так что, скорее всего, в дальнейшем развиваться будет именно он.


Забыл написать.
Краткая инструкция по скачиванию.

• Забираемся в папку, в которую мы хотим скачать примеры.
• Даём команду
  svn co https://scmrtos.svn.sourceforge.net/svnroot...F/GCC/STM32F4XX STM32F4XX
• Появляется папка STM32F4XX
• Заходим в неё, даём команду switch.bat (в линуксе - sh switch.sh)
• Всё.

Антон, Спасибо огромное.

«Кричат эмбеддеры „Ура!“ и в воздух чипчики бросают».

Схемы доступа претерпели изменения, в текущий момент:

• svn checkout svn://svn.code.sf.net/p/scmrtos/code/ и т.д.

Смотреть на странице http://sourceforge.net/p/scmrtos/code/

Добавлю сюда, пожалуй. Вот что я раскопал по поводу смены схемы доступа к svn.
Итак:

1. Сменился путь svn, был: http://scmrtos.svn.sourceforge.net/svnroot/scmrtos/ , стал: http://svn.code.sf.net/p/scmrtos/code/)
2. Доступ по https теперь требует авторизации.
3. Анонимный read-only доступ остался только по http (http://svn.code.sf.net/p/scmrtos/code/trunk) и svn (svn://svn.code.sf.net/p/scmrtos/code/trunk).
4. Новый адрес веб-интерфейса к svn: http://sourceforge.net/p/scmrtos/code/
   К сожалению, если забраться там поглубже, то в ссылке появляется номер ревизии: http://sourceforge.net/p/scmrtos/code/563/tree/trunk/ .
   Путём невероятного напряжения умственных сил я догадался, как получить ссылку на HEAD. Надо заменить номер ревизии на слово HEAD: http://sourceforge.net/p/scmrtos/code/HEAD/tree/trunk/

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

Вопрос: как в новой версии получить архив какой-либо части (trunk и др.) или всего дерева, включая старые версии?
Раньше были значки для формирования нужного архива.

Эта ссылка http://svn.code.sf.net/p/scmrtos/code/ у меня не работает (404 Not Found). Остальные дают результат.

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

Хм. У меня работает. Может быть это были временные трудности?
(В любом случае, эта ссылка не для браузера, а для svn-клиента, браузером там практически нечего делать)

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

Конечно делали
Пример 5-FPU как раз этим и занимается.
Там две задачи постоянно проверяют неизменность своего контекста (контексты изначально различаются), а третья - вычисляет число Пи.

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

а где можно почитать как проекты на с без оси адаптировать под csmrtos?

обязательно ли все делать на с++ или можно подключать старые модули на с?

и существуют ли где либо ссылки по прикручиванию к этой оси какой либо виртуальной машины пи-кода?

Там сначала обычные регистры заполняются разными значениями, потом эти значения копируются в плавучие регистры, а потом в цикле производится сравнение их значений. Если выявляется несовпадение - начинает моргать светодиод.
А почему у вас возникли сомнения в неизменности контекста?

Почитайте для начала Руководство пользователя. Это поможет понять, как вообще устроены программы с использованием scmRTOS.
Модули на си подключать можно.
Насчёт пи-кода - не припоминаю. Знаю только, что к ардуине прикручивали.

сомнений конкретно относительно scmrtos как таковых нет, но изучая разные сайты нашел обсуждения относительно pawn, что в некотоых случаях он работает некорректно, соответственно если буду использовать scmRTOS то хотелось бы быть уверенным в ней на все 100%

спасибо за ответы, посмотрю ваши ссылки

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

Может быть. Хотя я довольно интенсивно использую порт в нескольких проектах, и ни разу с таким не сталкивался.
Какой у вас был размер стека, и какой стал? Может быть всё равно не хватает?
И убедитесь, что у вас самая свежая версия оси, я там что-то исправлял вроде.

за основу взят ваш пример

typedef OS::process<OS::pr0, 4000> TProc0;
typedef OS::process<OS::pr1, 1000> TProc1;
typedef OS::process<OS::pr2, 4000> TProc2;
typedef OS::process<OS::pr3, 306> TProc3;--- так не работает

typedef OS::process<OS::pr0, 4000> TProc0;
typedef OS::process<OS::pr1, 1000> TProc1;
typedef OS::process<OS::pr2, 4000> TProc2;
typedef OS::process<OS::pr3, 303> TProc3;--- так работает

при величине стека третьей задачи больше 303 начинает моргать светодиод

TProc3 Proc3;

template <>
OS_PROCESS void TProc3::exec()
{
test_context(0x87654321);--- ваша функция на ассембл
}


обнаружил случайно - стал в ваш пример свое нутро пихать сохранив эту задачку с проверкой сохранения контекста, пока везде стек был 300байт все работало нормально, на определенном этапе разростания задачи загорелся и не выключался светодиод - решил сначала что плата накрылась поменял отладочную плату поведение не изменилось, подумал, что ошибка возникла изза переполнения стека, везде увеличил до 1000 светодиод стал моргать, тогда стал искать как влиятет размер стека в разных задачах, обнаружил что при размере стека в третьей задаче больше 303 байт светодиод в ней моргает, при меньших значениях не горит, такое поведение меня очень удивило,логичнее было бы еслиб было наоборот, видимо ошибка где то в ядре системы?

Увеличивать стек конкретно этой задачи нет смысла, 300 байт ей за глаза (200 байт на контекст, плюс сама задача кладёт максимум 4 регистра на стек).
На всякий случай задавайте размер стека кратно 4, а лучше - кратно 8.
Посмотрите на общее потребление памяти, попробуйте на время сократить какой-нибудь большой массив.
Возможно, на стек этой задачи наползает куча.
Поэкспериментировать сам смогу нескоро, я сейчас в отпуске, не до этого совсем

это понятно что ей 300 байт хватает, как раз не понятно отчего при увеличении стека она заваливается, стек делал разным с шагом единица в пределах 300-310, ни 304, ни 306 ни 308 ни 310 не улучшают ситуацию

по памяти:

--- building 5-FPU. defines: -DSTM32F4XX -DVER_MAJOR=0 -DVER_MINOR=1 -DHSE_VALUE=8000000
text data bss dec hex filename
38408 2164 51304 91876 166e4 ./exe/5-FPU.elf
Errors: none

видно что потребление гораздо меньше 112к но попробую поменять задачки местами, возможно что то изменится и куча не будет мешать локальным стекам задач (если дело в этом)

жаль что не сможете попробовать повторить в ближайшее время - очень сильно на это надеялся

хорошего отдыха

зы проверил про кучу дело явно не в ней - изменил одну задачку на

template <>
OS_PROCESS void TProc1::exec()
{
test_context(0x87654312);
}

поведение в двух этих задачах совершенно одинаковое ломаются контексты при увеличении стека свыше 303 байт

Я имел в виду, что не смогу добраться до своих серъёзных рабочих проектов, чтоб посмотреть там. (Хотя думаю, что я бы заметил порчу контекста )
А тестовый пример на F4discovery - я прогнал, с разными стеками, всё работает нормально, контекст не портится.
Вы как-то проигнорировали мою реплику про самую свежую версию оси. У вас точно она? Потому что в каком-то (пред-)предпоследнем варианте было такое, там было неверно сделано выравнивание стека. Вроде бы я это исправил до создания этого топика, но всё же проверьте на всякий случай.
Ну и с кучей - попробуйте временно отключить динамическое распределение памяти, чтоб уж точно знать, что это не она.
То есть, попробуйте постепенно возвращаться к примеру 5-FPU, пока всё снова не заработает. Или наоборот, потихоньку добавляйте к примеру свой функционал, пока не сломается.

версия os 4.0

динамически память вообще не выделяется

сейчас попробую на чистом вашем примере сделать то же самое увеличение стека

сделал: вырезал весь свой функционал все равно светодиодик моргает... а где можно скачать самую последнюю вашу версию порта и ос?

Вот тут: ссылка. Там можно нажать на "Download Snapshot".

вот распределение памяти в чистой вашей задаче

text data bss dec hex filename
2576 0 2644 5220 1464 ./exe/5-FPU.elf


размер стека

//
typedef OS::process<OS::pr0, 300> TProc1;
typedef OS::process<OS::pr1, 300> TProc2;
typedef OS::process<OS::pr2, 1000> TProc3;
typedef OS::process<OS::pr3, 300> TProc4;

моргает оранжевый светодиод

Что с осью, у вас была свежая версия?
У меня с такими размерами стека мигает зелёный!
Распределение памяти чуть другое (я компилировал сборкой от klen-а):

Что у вас за компилятор?

копмилятор gcc-arm-none-eabi-4_6-2012q2

*************************************************
GNU Tools for ARM Embedded Processors
- June 2012
*************************************************

This release includes the following items:
* Bare metal EABI pre-built binaries for running on a Windows host
* Bare metal EABI pre-built binaries for running on a Linux host
* Source code package (together with build scripts and instructions to setup
build environment), composed of:
* gcc : ARM/embedded-4_6-branch revision 188521
http://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_6-branch/

* binutils : 2.21 with mainline backports
git://sourceware.org/git/binutils.git

* newlib : 1.19 with mainline backports
ftp://sources.redhat.com/pub/newlib/newlib-1.19.0.tar.gz

* gdb : 7.3.1 with mainline backports, without target sim support
git://sourceware.org/git/gdb.git

* cloog-ppl 0.15.11 :
ftp://gcc.gnu.org/pub/gcc/infrastructure/...-0.15.11.tar.gz

* expat 2.0.1 :
http://space.dl.sourceforge.net/project/ex...at-2.0.1.tar.gz

* gmp 4.3.2 : ftp://gcc.gnu.org/pub/gcc/infrastructure/gmp-4.3.2.tar.bz2

* libelf 0.8.13 : http://www.mr511.de/software/libelf-0.8.13.tar.gz

* libiconv 1.11.1 :
http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.11.1.tar.gz

* mpc 0.8.1 : ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-0.8.1.tar.gz

* mpfr 2.4.2 : ftp://gcc.gnu.org/pub/gcc/infrastructure/mpfr-2.4.2.tar.bz2

* ppl 0.11 : ftp://gcc.gnu.org/pub/gcc/infrastructure/ppl-0.11.tar.gz

* zlib 1.2.5 with makefile patch :
http://sourceforge.net/projects/libpng/fil...ar.bz2/download

* ncurses 5.9 :
http://ftp.gnu.org/pub/gnu/ncurses/ncurses-5.9.tar.gz

а что за сборка от klen-а?

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

может все дело в .ld файле? он из примера для евентфлаг

и да зеленый тоже моргает но с ним и моргает оранжевый... может в тестовой задаче test_context(0x87654321); у меня что то другое?

//
typedef OS::process<OS::pr0, 300> TProc1;
typedef OS::process<OS::pr1, 300> TProc2;
typedef OS::process<OS::pr2, 300> TProc3;
typedef OS::process<OS::pr3, 300> TProc4;

text data bss dec hex filename
2576 0 1944 4520 11a8 ./exe/5-FPU.elf
Errors: none

а при таком стеке что с памятью?

величина стека влияет только на bss он уменьшился ровно на 700 байт... вроде как и положено.. может оптимизация на что то влияет? у меня остался старый маке файл сменю его сейчас и еще раз попробую

в общем с новым мейк файлом перестало собираться, буду разбираться что не так

в итоге работает с нормальным сохранением контекста только со значением оптимизации

# compile options
OPTIMIZE = -O1(s)

Творится что-то невероятное
Давайте сделаем чистый эксперимент, по шагам. Я проделаю, опишу шаги, а вы повторите. Итак...

• Идём на https://launchpad.net/gcc-arm-embedded, качаем компилятор. Я скачал gcc-arm-none-eabi-4_7-2013q2-20130614-linux.tar.bz2.
• Устанавливаем его, убеждаемся, что он доступен:
  
  Код
  $ arm-none-eabi-gcc --version
  arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.7.4 20130613 (release) [ARM/embedded-4_7-branch revision 200083]
  Copyright (C) 2012 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
• Создаём папку test, заходим в неё.
• Качаем примеры:
  
  Код
  svn checkout http://svn.code.sf.net/p/scmrtos/code/trunk/Samples/CortexM4F/GCC/STM32F4XX STM32F4XX
• заходим в папку STM32F4XX;
• запускаем switch.bat (под линуксом - switch.sh)
  Всё, теперь у нас есть самые свежие примеры с самой свежей осью.
• Теперь компилируем пример №5. Заходим в папку 5-FPU и командуем make.
• И наконец, заливаем пример в плату. Я для этого набираю make program, но это не суть.
  Моргает зелёный светодиод.
• Меняем стек процесса TProc3 на 1000, компилируем, заливаем. Моргает зелёный светодиод! Красный не подаёт признаков жизни.

сейчас установил как раз этот тулчейн, устанавливаю эклипс новый - старый с этим тулчейном не работает а без эклипса заливать в платку не умею

результат сборки со стеком 300

text data bss dec hex filename
2616 0 1944 4560 11d0 ./exe/5-FPU.elf
Errors: none

стек 1000

text data bss dec hex filename
2616 0 2644 5260 148c ./exe/5-FPU.elf
Errors: none

скоро научусь заливать в платку посмотрю на результаты

интересно... тулчейн версии 4.6 оптимизировал по размеру сильнее чем 4.7...

залил на платку все заработало, спасибо за помощь, заодно спасибо и за драйвер в нокии дисплейчику - давно в инете находил по моему за вашим авторством для AVRок

Уф-ф
Я думаю, что причина всё-таки в том, что в заглавном посте топика ссылка устарела. Она указывает на старый репозиторий, который перестал обновляться уже давно.
Поэтому просьба к модераторам: исправьте пожалуйста в заглавном посте топика строчку
"svn co https://scmrtos.svn.sourceforge.net/svnroot...F/GCC/STM32F4XX STM32F4XX"
на

(желательно в теге "code", чтобы движок форума не сделал ссылку).

А ещё, на мой взгляд, лучше - создать отдельную тему по репозиторию и закрепить её в заголовке подфорума.
В каждой теме, где есть указание на репозиторий хорошо бы давать не конкретный адрес, а ссылку на тему о репозитории.

а как грамотно подключить в .ld использование 16к рам под езернет? и в примерах под chibi os есть вариант .ld файла для использования дополнительных 64к под стек ( вкачестве информации - вдруг кому пригодится)

и еще в порядке пожелания: в том старом примере файл определений регистров содержал меньшее количество перифирии чем есть у процессора (я про файлик stm32f4xx.h) подскажите что надо изменить в стандартном stm-овском файле чтобы можно было бы пользоваться им совместно с scmrtos? (в прошлый раз я просто добавил в ваш вариант несколько определений регистров для usart но хочется использовать родной stm-овский файл)

ну и малоли кому пригодится тоже: связка
gcc-arm-none-eabi-4_7-2013q2
eclipse 4.3 kepler
openocd 0.6.1
вместе чудно уживаются и приемлемо работают

Мне кажется, это лишнее. Репозиторий полностью переехал, все новые ссылки будут на новый репозитоорий, адрес которого, я надеюсь, больше меняться не будет. Исправить для полноты картины ссылку в начале этого топика, и будет практически полный порядок.

Ну вот как пример (для батарейной памяти). Объявляем новую область памяти (BATTRAM):

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


и затем в коде помещаем нужные переменные в секцию .battram:

Теперь буфер nvBuffer будет расположен в батареечной памяти.

Во-первых, файл stm32f4xx.h не используется собственно осью, только примерами.
А во-вторых, это и есть стандартный stm-овский файл (он у меня был расположен в "Libraries/CMSIS/ST/STM32F4xx/Include").
В общем, если есть другой, более полный файл, просто используйте его, и всё.

огромное спасибо!!



все заработало

в версии stm32f4xx.h 2013 года учитываются разные контр и соотв существует два разных дефайна
STM32F427X и STM32F40XX, соотв чтобы с этим файлом корректно работала ось необходимо
- в майк файле добавить SUBCHIP = STM32F40XX, изменить DEFS = -D$(CHIP) на DEFS = -D$(SUBCHIP)
- в pin.h #if (defined STM32F2XX) || (defined STM32F4XX) заменить на
#if (defined STM32F2XX) || (defined STM32F4XX) || (defined STM32F40XX) || (defined STM32F427X)

больше в файлах оси я не нашел вхождений константы STM32F4XX, вопрос: их действительно бальше нет или я просто не нашел?

Я не видел этого вашего ответа, и поэтому решил-таки сделать пример с использованием ST-lib.
Сейчас собрался его запостить, а у вас уже всё решилось
Но. В только что мной скачанной версии stm32f4xx.h (11-January-2013) уже есть три дефайна:

Поэтому мне не пришлось править makefile, прокатил имеющийся дефайн STM32F4XX.
Хотя может быть, я просто что-то не так понял в организации библиотеки

Действительно нет. Ось использует для определения архитектуры M3-M4/M4F дефайн __SOFTFP__, остальное ей неважно.
Ладно, всё равно выложу пример, раз уж сделал. Может кому-ннибудь пригодится
Вот: Нажмите для просмотра прикрепленного файла

они пошутили на самом деле если использовать STM32F4XX то не будет определено перывание FPU, поэтому надо использовать либо STM32F40XX либо STM32F427X (на сколько я разобрался в stm32f4xx.h)

кстати как интересно то в сисинит...

#if (!defined __SOFTFP__)
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); // set CP10 and CP11 to all ones.
#endif

по логике должно включаться если не эмулируется плавающая точка и есть вычисления с ней - то есть аппаратная плавающая арифметика, НО она может не эмулироваться и в CM3 - скажем, когда в задачке только целочисленная арифметика, думаю все же правильнее было бы сделать как в оригинале

#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
#endif

да.. и видимо так же правильнее было бы откорректировать ос_таргет_сипипи - для CM3 если не определена эмуляция плавающей точки порт будет работать как для процессоров с аппаратной плавающей арифметикой

как понимаю __VFP_FP__ и __SOFTFP__ устанавливаются компилятором в зависимости от вот этой строчки майк файла FPU= -mfpu=fpv4-sp-d16 -mfloat-abi=hard, правильно? а далее __FPU_PRESENT и __FPU_USED устанавливаются соотв в stm32xx.h и core_cm4.h и далее ими уже пользуются все остальные модули программы, так?

Наверное да, STM32F4XX - это общий дефайн для семейства, а STM32F40XX и STM32F427X - это варианты исполнения.
Прерывание FPU есть в обоих вариантах, так что можно просто перенести его в общую часть:


sysinit.cpp - это просто пример, это не часть порта/оси. Поэтому он не претендует на универсальность. Он сделан просто для примера. К тому же, __SOFTFP__ - это дефайн компилятора, а __FPU_PRESENT и __FPU_USED - это дефайны из ST-шной библиотеки, а она в примерах не использовалась.

Не, там всё нормально. Вот тут я выяснял самый подходящий дефайн. Получилось, что это __SOFTFP__. (__VFP_FP__ определён во всех четырёх случаях, так что его проверять нет смысла.)

Я не особо разбираюсь в ST-шных либах. По-моему, там жёстко задаётся __FPU_PRESENT = 1, а __FPU_USED устанавливается в зависимости от __VFP_FP__ и __SOFTFP__.
Кстати, поэтому варианты

и

идентичны

короче сломал себе голову и сделал проще, вот так в мейкфайле


CHIP = STM32F4XX
HSE_VALUE = 8000000

ifeq ($(CHIP),STM32F4XX)
MCU = cortex-m4
FPU = -mfpu=fpv4-sp-d16 -mfloat-abi=hard
#FPU = -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
DEFS = -DSTM32F40XX
else
MCU = cortex-m3
DEFS = -D$(CHIP)
DEFS += -DST_M___3__2_C__M_3__SOFTFP__
endif

# compiler defines
DEFS += -DVER_MAJOR=$(VER_MAJOR)

ну и в порте заменил __SOFTFP__ на ST_M___3__2_C__M_3__SOFTFP__

А зачем?

чтобы от меня зависело а не от компилятора(поставит он нужный дефайн или нет) как сохранять контекст как см3 или см4, этот дефайн в мейкфайле просто признак того что контроллер см3

Компилятор ставит дефайн __SOFTFP__ в двух случаях:

• -mcpu=cortex-m3
• -mcpu=cortex-m4

То есть, в случае M3 и M4 без сопроцессора. В этих случаях порт использует контекст M3.
В случае наличия сопроцессора (два варинта):

• -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard
• -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp

используется контекст с плавучкой.
То есть, мы полностью управляем поведением порта: хотим M3 - определяем -mcpu=cortex-m3, хотим M4 без плавучки - определяем -mcpu=cortex-m4. Нужна плавучка - -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi={hard|softfp}.
Ну а если всё же хочется определить именно M3, то для этого у компилятора есть специальный дефайн: __ARM_ARCH_7M__
(для M4: __ARM_ARCH_7EM__).

а как кстати определить адрес функции во флеше?

Что вы подразумеваете под "определить"? Если узнать адрес - в программе достаточно присвоить имя функции соответствующему указателю, а человеку нужно найти эту функцию в .map или дизассемблированном листинге. Если же вы имели ввиду "задать конкретный адрес для функции" - то надо в скрипте линкера описать секцию по нужному адресу и разместить фукцию в эту секцию при помощи __attribute__((section("имя секции"))

я имею ввиду написание загрузчика-биоса отдельно от прикладной программы, биос во флеше, прикладная программа во внешней ram(памяти оперативной все же не хватает)

то есть надо вначале компилировать биос и смотреть его мап файл потом прикладную программу и ее мап файл смотреть?

Все расно не понял, что же вам нужно - узнать адрес функции или разместить ее по заранее определенному адресу.

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

восстановил задачку, все работает

очень приятное впечатление и от оси и от порта, спасибо разработчикам

В этом случае вам надо либо размещать эти функции по фиксированным адресам, что неудобно - либо будут оставаться дырки между ними, либо после очередного улучшения какая-то из функций не влезет в выделенную ей область и начнутся пляски по ее утаптыванию. Простое и надежное решение - разместите в приложении по фиксированному адресу таблицу указателей на функции и обращайтесь из загрузчика к функциям приложения через эту таблицу. Аналогичную таблицу указателей на функции загрузчика расместите по фиксированному адресу в загрузчике и обращайтесь через нее из приложения. Будет некий аналог таблицы векторов прерываний. Эти таблицы можно оформить в виде структур с осмысленными именами членов и даже добавить в эти структуры какие-то служебные данные, как, например, номер версии софта в приложении или номер версии железа в загрузчике:

еще раз спасибо, буду осмысливать

Добрый день.

Пользуюсь SCM под LPC17xx продолжительное время, но сама операционка для меня как черный ящик.
Подскажите, насколько реально сделать порт под LPC43xx ?
Степень сложности ?

Как вижу, там внутри Cortex-M4 и Cortex-M0. Степень сложности равна нулю - под оба эти ядра существуют порты операционки, от конкретной периферии кристалла в самой операционке ничего не зависит, зависят лишь инициализация, махание ногами и сброс флагов в прерывании таймера в примерах. То есть просто берете порт для M4 (для M0 лежит в репозитории), выкидываете все лишнее (собственно сам пример) и пишете инициализацию периферии под свой пример.

Спасибо, подбодрили. Будем пробовать.

добрый день, подскажите а ТMutex.lock() запрещает прерывания или только блокирует переключение задач и запрет прерываний нужно делать отдельно?