jcxz

Я говорил не о "передаче параметров через стек", а о "создании и инициализации временного const-объекта на входе в функцию". И глупости это или нет, но я наблюдал такое поведение у какого-то из компиляторов (скорее всего IAR для какой-то платформы (не помню какой)).

И об этом тоже. И о том, что даже если имеется только UPDATE-прерывание, но: или внутри DoSomething() выполняется какое-то длительное действие, что за его время может возникнуть новое UPDATE; или внутри DoSomething() перепрограммиуется таймер, изменяя период UPDATE; или есть другое, более приоритетное прерывание, которое может вклиниться во время выполнения этого ISR, замедлив его; ...etc то во всех этих случаях будет происходить потеря UPDATE-прерываний. Вы пишете программы, которые корректно выполняются только "если повезёт"? А когда пользователь обращается к вам с претензией по поводу глюков программы, отвечаете ему "вам просто не повезло"? Вы когда рельсы переходите - тоже по сторонам не смотрите? Ведь поезда тоже довольно редко ездят, и "это на сколько должно "не повезти"" чтобы под поезд попасть? Он не просто "не делает", он может даже наоборот - делать деоптимизации. Создавая на стеке const-объект нужного типа и инициализируя его на входе в функцию. Т.е. - производя кучу совершенно ненужных манипуляций и впустую расходуя стек.

При такой кривой обработке, возможна потеря прерываний. Зачем делать так криво, если можно сделать согласно мануала??? И на кой тут 'const'?

В выражении (delay_active && elapsed >= delay_target) чтение elapsed - неатомарно. И (судя по коду) в это же время могут срабатывать прерывания таймера. В которых происходит модификация elapsed. Если такое прерывание сработает во время побайтного чтения elapsed, то результат чтения может быть неверным (а значит - и результат выражения). А я говорил в целом о работе с переменной elapsed в коде. Код не работает по-частям. Он работает целиком. Т.е. - или работает или нет. В данном случае - нет.

Подумайте ещё раз. Первый раз у вас не получилось. Подсказка: Разрядность переменных в фоновом процессе = точно такая же как в ISR. to gretis: А зачем переменная delay_target объявлена как volatile? Или просто - за компанию с elapsed? Не вижу иной причины. Да и все другие, кроме elapsed - зачем с volatile?

Ваш код кривой. Видим в main(): и в то же время в ISR: При том, что elapsed - 32-битная переменная, а CPU насколько мне известно - 8-битный, то следовательно: не обеспечивается атомарность операций чтения-модификации-записи переменной elapsed. И операций её чтения в фоновом процессе. Да и манипуляции: выглядят сомнительными. Хотя я не разбираюсь в AVR. И за деревьями не заметили леса кучей лишних скобок не заметили явного бага в этом выражении.... Вот к чему ведёт скобкопоклонничество. Очевидно - не всё. см. выше. сорри.

Вы - не узнаете. Так как о разработке прошивок знаете только по-наслышке (судя по вашим постам). А человек, который реально разрабатывал прошивки - узнает запросто. Дилетанту объяснять бесполезно. Профессионал и без объяснений знает. В точку!

Ну если вы так хорошо умеете "складывать трёхзначные числа", то может также сможете ответить на простой вопрос: "Из чего следует, что именно значение на рисунке - верное? А не значения, указанные в других местах?" Может на вашем рисунке - неверное значение, а в реале ОЗУ всего = 32КБ? И второй вопрос: Если даже в таких базовых вещах, как объём ОЗУ, у них такой бардак, то чего стоит ожидать от остальной документации? Документации на периферию например? И как предлагаете угадывать - где там правда, а где баги (документации)? МК - новый, значит чтобы на нём что-то написать, нужна в первую очередь - нормальная документация. С вычищенными багами. Сляпать "на примерах из инетика" - не получится. А если ошибки даже в таких базовых вещах, которые сразу бросаются в глаза, значит нормальной документации нет. И первопроходцы скорее всего сильно пожалеют, что вообще связались с таким сырым продуктом. Как тут ранее уже справедливо заметили: "Забег по граблям гарантирован". С непредсказуемым результатом. Вы как будто первый день в этой стране живёте. В ней никогда не было дела до проблем физиков. Вне зависимости от наличия "войнушек".

Из сообщения ТС никак не следует, что мастер что-то отправляет. Из него только следует, что он подключает датчик к плате и уже ожидает на его ногах какой-то активности. И прочитайте полностью то моё сообщение, на которое отвечали. Может стоит остудить голову, выпить немного для храбрости, и наконец-то набраться смелости открыть даташит/RM? Чтобы начать использовать аппаратные интерфейсы.

Откуда почерпнута сия цифра? Вроде в заглавном посте говорится только о 192КБ... А если открыть предоставленную ссылку BE-U1000 , то там и вовсе: Всего 32КБ??? По ~11КБ на ядро??? Откуда тогда ТС взял 192КБ? Или там очепятка? Ну да - на заборе тоже написано.... Но как все давно знают: Оптимизм по поводу богатства обещанной периферии, очень часто быстро заканчивается после прочтения errata. ...а потом эти "ценители" внезапно обнаружат, что это самое ПЗУ - очень тормозное. И чтение из него занимает аж целых N тактов! И питон еле ползает. Плавно превращаясь из микропитона, в нанопитона. 😉 Плавали, знаем! И тут - не факт. Вы ими (э/двигателями) управляли? И какими? Или только по-наслышке? 😉 PS: Снимите розовые очки.

192КБ на 3 ядра? По 64КБ на ядро? Всего-то??? По нынешним временам, это вообще = с гулькин нос. А если ещё и бОльшая её часть - TCM, то сколько памяти останется для работы с DMA? Или там нет DMA? Какие серьёзные задачи можно решать на таких крохах ОЗУ? Вы даже текст собственного поста прочитать не осилили....

И I2C и SPI и UART и прочее - и всё ногодрыгом??? вот уж.... нет слов... "и эти люди ещё запрещают мне ковырять в носу..."

Что такое "нормальный ритм на SCL, данные на SDA"? Что вы там видите? По идее, без подключения датчика, вы не должны там видеть ничего (должны быть фиксированные потенциалы). И что такое "зависает чтение/запись"? Узнать - кто писал ваш код и попробовать в нём разобраться. На этой плате судя (по схеме) ноги PB6/PB7 используются для подключения nRF. У вас на них ничего чужеродного не подключено, надеюсь? Не понятно - что в вашем понимании "нормальный сигнал I2C"? Без датчика вы должны видеть адресную фазу I2C без ACK. Но только при попытке обращения к датчику. Без обращения там должны быть фиксированные высокие уровни на обеих ногах.

Тут видимо как с гербалайфом - его адепты всюду его пытались пропихивать в своё время. И к месту и ни к месту - главное прорекламировать. Будем знать: rust == гербалайф.

как именно испортить? Про MPU в вашем "некаменном веке" слыхали?