KnightIgor

На сегодняшний день за последние 10 лет ничего не изменилось, и на вопрос нельзя дать однозначный ответ: в разных stm32f* - разные I2C. Все начиналось с F1xx, где I2C такой, словно французы его запилили на пикнике, нажравшись бордо и закусив самым заплесневелым сыром. Вроде и F4xx унаследовали этот пьяный бред. Протрезвев лишь через несколько лет, на последующих моделях M0 и M0+ ребята радикально сменили спецификацию, и стало возможным работать, но и этот I2C все еще требует достаточно ручных усилий в отличие, например, от I2C на Кортексах от Atmel (ныне - часть Microchip), где I2C называлась TWI и обеспечивала полные транзакции почти полностью аппаратно. Если под "stm32f*" имеется ввиду действительно F1xx (и, возможно, F4xx), то по нему я высказывался и предлагал решения здесь неоднократно. Основные заморочки: не любит I2C, когда его прерывают, поэтому обработчик прерываний I2C должен иметь наивысший приоритет в системе. транзакции чтения с 1 или 2 байтами (или поведение обработчика, когда осталось принять 1 или 2 байта) требуют особого алгоритма обработки. замечено, что можно влететь в прерывание с набором флагов, не описанных в документации, и если не прореагировать на такую смесь, транзакция рушится. На F0xx все выглядит иначе, гораздо стабильней и проще.

Вопрос, а нужно ли бороть. DWT показывает абсолютное время, ибо щелкает четко с тактом процессора. Разве не это нужно? - измерить время от и до. Делать задержки, исходя из предположения, что NOPы однозначно отражают такт процессора, - путь явно ошибочный ввиду строения процессоров (кэши, prefetch, предсказательное ветвление, хотя это уже не NOP). А еще есть прерывания. Они могут прервать линейку NOP, и все будет насмарку. Хотите точное время - используйте таймеры. Не получается и так? Используйте внешнюю времязадающую периферию.

В сети я не могу найти полную схему RPI Zero W, чтобы подсмотреть. Моя задача: разрабатываемому устройству, которое должно использовать Raspberry CM3 (такой DRAM-подобный модуль), добавить Wifi/BT как у RPI Zero W. У последней в качестве WiFi/BT используется BCM43438, подключенный к процессору по SDIO и UART, а также к еще некоторым GPIO. Вопрос: к каким именно линиям порта? Из-за возможностей ремаппинга в процессоре в качестве кандидатов выступают различные выводы, а мне бы хотелось сделать полный аналог подключения в Zero W, чтобы прошивка взлетала без допиливания. TIA.

0x00200652 - это же RAM? Похоже, проблемы в алгоритме записи во флэш: JLINK грузит сервисную программу (алгоритм) в RAM, с которой общается и заставляет писать во флэш.

Может, пока flash доступна по записи (флаг FLASH_CR_PG установлен), сравнение не срабатывает? Даже если, как пишет Сергей Борщ, у Вашего процессора нет кэш, есть таки какой-то регистровый кэш для операций записи во флэш? Идеи: 1. Изменить алгоритм и вынести верификацию "за скобки" флага. 2. Попробовать __DMB() и иже с ними перед верификацией.

Я не спец в протоколе. Вот нашел https://github.com/fetisov/lrndis

Я как раз об этом и говорю: на мой взгляд, последняя фраза просто блестяще характеризует стиль - она крайне нетактична по отношению к коллеге-автору топика. Вы не находите? Я нахожу, и очень часто, и именно из Ваших уст. Именно Вы отказываете другим в праве прийти на форум, спросить и получить достойный ответ, а не нарываться на упрёки, якобы что-то с чем-то часто путать. Нет дурных вопросов, есть тупые или нетактичные ответы. Мои извинения остальным за OT.

Это да! Я мечтаю о маленькой IC - watchdog, которая бы следила за непотребным поведением I2C EEPROM. Как-то (было место на плате) я применил таймерок на одном транзисторе для питания EEPROM: как только она "залипала" SCL на землю надолго, транзистор снимал ей питание, пока SCL не возвращалось в стойло.

С такими монстрами не работал. Я ж говорю: мне внутренняя память ближе, чем что снаружи. И речь о EEPROM внешней была, а не о какой quad spi flash в десятки мегов. EEPROM не отображается даже Вашими горячо любимыми LPC. P.S. И, кстати, я никаких "приёмов" в этой дискуссии не применяю: я же не пытаюсь кого-то тут унизить или обманом вовлечь в ряды последователей моих решений. Вы же, коллега, мной замечены в очень бурных реакциях на мнение постеров.

Можно постранично стирать. Размер страниц зависит от общего объема, как правило, и лежит от 512 байт до 2К, может до 4-х для каких-нибудь мегабайтников - не знаю, не работал.

Не пугайте так! Я слова такого не знаю, а если, то только у не до конца прибитой мухи.

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

Если невозможно остановить, применяйте другие решения. Я ж не заставляю. Для моих разнообразных систем остановка для записи параметров некритична: это настройки, как правило, имеют место быть при вводе в экплуатацию. Потом во флэш в процессе работы никто не пишет: ресурс же ограничен, никаких логов и подобного туда не сливают. Код записи в ОЗУ не обязателен, по крайней мере для STM. Для EFM32 - да, но размер кода, что пишет, мал (там буквально пара операций). Размер конфига может быть разный. Например, таблицы подстроек могут быть большими. Если у какого-то процессора проблемы с размером страниц - это его проблемы, и надо применять другие решения. Я ж не спорю. Для STM|EFM таких проблем нет. Если ПО работает 20 лет, багов там нет. Точнее, по закону Мерфи, они там есть ("безошибочное ПО неработоспособно"), но прячутся по углам. Когда EEPROM потеряла содержимое, а модуль перегрузился и не смог загрузить настройки, он встал. PC обнаружило и сообщило. В чем проблема? И не надо начинать Холивары. Я ж никому ничего не навязываю. Не знаю, как на России, но я привык к плюрализму.

Я придерживаюсь противоположного мнения: именно флэш ультимативно удобна и надежна для хранения настроек. Аргументы: - внешние устройства хранения есть дополнительные компоненты, для них нужно место, к ним требуются шины коммуникации, которые занимают пины и могут сбоить; подвешивание автоматов I2C EEPROM общеизвестно. - требуется ощутимое время на считывание из внешних хранителей. - настройки извне надо копировать в ОЗУ, а в микроконтроллерах его, как правило, ощутимо меньше, чем флэш; - размещение параметров во флэш позволяет использовать их непосредственно как константы в выражениях кода. - флэш надежнее; если это опровергать, нужно смириться и с тем, что и сама прошитая программа ненадежна, к чему ей тогда настройки вообще, когда она рухнет? P.S. У нас есть объекты, на которых работают контроллеры 8051, первые с флэш (до этого были с EPROM, стираемые UV), c... 1997! Там все на свете гарантии прошли, мы несколько раз сменяли PC (речь о распределенном управлении отоплением в коммунальных зданиях с центральным PC), а модулики работают! Мы сами в позитивном шоке. Так вот, там настройки хранятся в I2C EEPROM, т.к. тогда самопрограммирования флэша еще не было. И вот было несколько сбоев недавно. Мы проверили, и оказалось, что именно содержимое EEPROM потерялось. Мы перезалили EEPROM, и модули поскакали дальше. Заменить/обновить их не можем, т.к. их нет у нас больше на складе, да и сами процессоры такие не купишь. А старые процессоры еще могут! Спасибо, TEMIC и ATMEL! P.P.S. Ностальгия пробила, порылся в коробках, нашел такой модуль (см. фото). Вверху на плате дата разработки стоит: 18.09.96. Под кварцем видна EEPROM в SO8.

В EFM32 нет boot пинов. Там в первых 2KB есть встроенный загрузчик (во всяком случае, в процессоре топик стартера, я тоже с таким работал), поддерживающий XMODEM. Свою программу надо изначально размещать, начиная с 2К (с перемещением векторов), если хочется сохранить этот самый родной загрузчик, который весьма полезен для производства, например: можно прошивать процессоры через последовательный порт с помощью макро для TERATERM.