jcxz

Дикий лес какой-то развели... Всё просто. В .icf задать регион памяти и послать туда нужную секцию (.iapMem): define memory mem with size = 4G; define region FLASH_regionA = mem:[from 0x08000000 to 0x08001FFF]; place in FLASH_regionA {section .iapMem}; В .cpp: struct KalibrData { ... } const kalibrData @ ".iapMem" = {...}; Всё! И обращаться к kalibrData.

Привычка, оставшаяся с моих проектов с батарейным питанием

Ну в STM32F4 этой проблемы нет. Это было в других МК. LPC17xx например. Там не было прерывания завершения передачи символа по UART. И например для RS-485, где нужно переключать направление передачи в линии, приходилось делать поллинг регистра статуса на прерываниях таймера.

У меня этот драйвер работает примерно 1.5 года - проблем вроде не замечал особых. На этой шине висят: FRAM+RTC+тач_пад+тюнер. Всё работает стабильно. Правда я не совсем честно сделал SCLK - он у меня push-pull. Если сделать его OK - очень редко происходят сбои (видимо проводов и их ёмкости слишком много). Никаких таймаутов не отслеживаю - по любой ошибке (или не-ACK) у меня должно сразу падать в ловушку критической ошибки и защёлкиваться в этом состоянии. Но этого не происходит - проверено за это время многими днями непрерывной работы. Работаю по прерываниям + DMA. Планировщик транзакций автоматически определяет необходимость DMA (по размеру пересылаемых данных). Единственное место которое вызывает недовольство - это указанное в заголовке темы. Похоже потрачу один таймер и сделаю поллинг в этом месте по его прерываниям. PS: Хотя конечно I2C в STM32F4 не выдерживает никакого сравнения с I2C в XMC47xx. Вот там сделано действительно отлично! Умеют немцы Там не нужно всех этих прерываний, и возни с битами-флагами в них. Можно сразу всю транзакцию записать в виде единой посылки, кодирующей все старты-стопы-рестарты-данные. И зарядить её через DMA в I2C. И получить одно прерывание в конце всей работы Разницы нет никакой в том плане, что всё равно нужно ждать. Хоть где. Понятно что можно на хромой козе объехать. Но блин - умеют же другие вендоры делать без коз! И ожидание у меня в конце, потому что я стараюсь так строить драйверы периферии: включил периферию, поработал с ней, если нет другой работы для неё - выключил.

Получается - так и не смогли STM-щики сделать нормальный I2C? А вроде кто-то говорил, что в старших STM он уже нормальный.... Прям какая-то засада с ним! Купили бы что-ли у других производителей. Другие с первого раза нормальный делают как-то.... Старт-стоп работает. По-крайней мере если ставить оба бита СТАРТ и СТОП одновременно. Иначе бы вообще нельзя было работать с некоторыми слэйвами, которые переключаются на приём именно такой последовательностью. Но если что делать если следующая транзакция должна быть с другим слэйвом? Писать новый адрес пока на закончилась предыдущая транзакция думаю нельзя. У меня на шине много разных устройства. И что делать если не нужно делать повторный старт? А нужно просто узнать что транзакция закончилась. Например - чтобы отключить после этого периферию. Ну или ещё что-то сделать. PS: Похоже - если полностью корректно делать, то нужно задействовать дополнительный таймер. Ситуация блин прям как с нахождением стоп-бита UART.

Ну а какая разница - поллинг в начале или в конце? Желательно вообще без поллинга.

Просматривая один свой проектик на STM32F4, обратил внимание, что при завершении I2C-транзакции (I2C-мастер) выставляю СТОП-условие на шину и после этого жду полного завершения активности на шине поллингом бита MSL в I2C_SR2. Хотя все остальные действия работают по прерываниям. Проверил и точно: после выставления СТОП-условия (I2C_CR1.бит9) я уже больше не получаю никаких прерываний от I2C-периферии. В то время как сам бит MSL обнуляется естественно не сразу после подачи СТОП. Получается, что без поллинга тут не обойтись? Или я где-то чего-то проглядел и как-то можно заставить I2C-периферию сгенерить прерывание при окончательном освобождении шины?

Шумят в основном те, которые имеют встроенный DC-DC. Это вроде ADUM6xxx которые. ADUM2xxx - без DC-DC и шумят незначительно.

Это только ТС знает где и что у него стоит. Опять-же: насколько далеко у ТС моторы - знает только он. И в любом случае: если уж так боимся - помещаем его в стальной стакан экранирующий поля. Да и про точность ТС ничего не писал.

Может выкинуть энкодер и поставить такой?: https://ru.aliexpress.com/item/Full-Circle-No-Dead-Angle-12-Bit-Holzer-Angle-Sensor-0-360-Degree-0-5V-Output/32422949989.html?spm=a2g0v.10010108.1000023.6.4c2516c8T6E9K7

Решаема. И без концевика. У ТС вроде - шаговые двигатели? Тогда: добавляем FRAM, перед каждый шагом двигателя пишем во FRAM текущее положение, после шага - опять пишем текущее. Таким образом, при сбросе по питанию будем знать текущее положение двигателя с точностью +/-1шаг. После чего выдвигаемся в одно из крайних положений (по запомненным показаниям позиции). Получается что при таком выдвижении на двигатели будет подан максимум 1 лишний шаг. Думаю, что это не смертельно для системы ТС-а. Это конечно если с момента первого отключения питания и до момента выхода в крайнюю позицию было только одно отключение питания, а не гроздь отключений. В любом случае: факт выхода в крайнее положение можно определять по тому, что перестали меняться показания энкодера при подаче шагов на двигатель. Как уже заметил ув. AlexandrY.

Возможно там не настоящий резистор (контакт бегающий по проволоке или чему там), а эмуляция резистора. Определяет угловое положение по какому-то другому бесконтактному принципу: например датчиками Холла или ещё как. А потом эти микрухи по выходу девайса эмулируют работу наподобие цифрового потенциометра. Либо меняя напряжение на выходе в соответствии с угловым положением, либо даже - меняя сопротивление на выходе в соответствии с угловым положением. Если там реально настоящий резистор, то каков у него будет ресурс? На сколько оборотов его хватит при непрерывном вращении ротора? Это же всё-таки трение, а значит - износ. А если например ещё начать довольно быстро крутить? Тогда из-за трения он начнёт греться. И сопротивление его поплывёт -> поплывут показания. Поэтому и думаю что там - эмуляция. Так как для бесконтактных датчиков таких проблем нет.

Из-за того что для записи новых данных может не требоваться стирание сектора. См. выше - я же описал алгоритм. Я же уже посоветовал! Вы читаете? Не надо ничего склеивать. Надо весь hex-файл обрабатывать как поток символов.

Тут надо не номера стёртых хранить, а адреса принятых сегментов. Например: пришёл кадр-X1 который пишется внутрь сектора-Y. Вы проверили: всё ОК - он нормально может быть записан в этот сектор, так как любой бит может быть запрограммирован или оставлен без изменения (т.е. - нет битов, которые нужно перевести из '0' в '1' (что можно сделать только стиранием)). Записываете этот сектор. Но в других адресах этого сектора есть места содержащие '0' (так как сектор не стирался). А затем приходит следующий кадр-X2, который как раз требует записи в те грязные '0' битов со значением =='1'. А значит - нужно стереть сектор-Y, и только потом писать туда этот новый кадр-X2. Но чтобы не потерять ранее записанные данные из кадра-X1, нужно сперва считать всё ранее записанное содержимое сектора, стереть его, записать старое содержимое (но только полезную его часть, ранее переданную), а потом записать содержимое кадра-X2. Так что: 1) Или хранить карту ранее записанных данных. Карту байт. Так как адрес и размер hex-строки может иметь произвольное байтовое смещение (в общем случае). 2) Или хранить карту стираний секторов. И стирать сектор не в тот момент, когда невозможно в него записать данные из нового кадра, а в тот момент когда принят первый кадр попадающий в этот сектор. Вне зависимости от содержимого сектора. Т.е. - при первом попадании - стирать, при последующих - не стирать. Первый вариант требует больше памяти, но можно получить меньше стираний секторов. Ну если каждый такой блок передаётся одним UDP-кадром (а не режется на несколько UDP-кадров) - тогда нет проблем.

Прочитать это место - разве трудно? И проверить что все биты могут быть запрограммированы. Если Вы работаете через UDP, то кроме этого надо ещё проанализировать, что UDP-кадр не был дублем какого-то предыдущего. И что не перепутан порядок следования UDP-кадров. Так как UDP не даёт гарантии целостности и порядка следования кадров данных.