KnightIgor

Привет коллегам. Так случилось в карьере, что Линух вообще и "Малина" в частности прошли мимо меня: я обладаю общими представлениями, могу установить, запустить, но подточить под железо или сделать приложение под Qt не доводилось. Для заказчика разработано устройство на STM32F, которое выполняет свои функции как предусмотрено. Для конфигурирования устройства пока используется программа на PC под Win, которая общается с устройством через USB. Теперь заказчик решил развить устройство, дополнив его touch экраном, сетью, и т.п. Было решено использовать платформу RPI (так я назову Raspberry Pi) на основе модуля CM3 от Raspberry.org. Была тема Wandboard, но заказчик от этого предложения отказался. Я сделал новую версию платы, на которую устанавливается CM3. На плате я склонировал (в какой-то степени) периферию RPI 3B: за LAN|USB отвечает LAN9512, для WiFi используется модуль WSDB-104GNI, на котором стоит BCM43438, что и на Pi Zero. Raspberian взлетел. Правда, WiFi пока не распознается, т.к. возможно нужно доустановить/доконфигурировать. Задачей RPI будет конфигурирование устройства на STM32F вместо PC и отображение состояния устройства (через USB), коммуникация через LAN и WiFi с внешним миром (удаленная диагностика, управление режимом устройства, и т.п.). Я ищу специалиста-подрядчика, который возьмется за проект в части RPI. За оплату, конечно. Обо всем будем договариваться. Единственное условие: по орг. причинам подрядчик не должен проживать в РФ.

На сегодняшний день за последние 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.

Мне всегда интересно, как в небольшой системе с, как правило, отсутствием интерфейса к пользователю типа "keyboard not found, press any key to continue", можно разумно восстановться после такой ошибки как ошибка записи во флэш? Вот обнаружил человек не тот бит, что ожидался. Делать что? Ставить ноги в какое-то безопасное состояние и уходить в бесконечный цикл в надежде, что дядя придёт и увидит, что всё умерло? Я не о том, что нужно "забить" на всё, но реально возможности сделать "recovery" после ошибки записи во флэш, да и любых других подобных, в таких системах очень ограничены. Напишите, кто как выкручивается?

Вообще, у меня исторически "навороченный" собственный HAL, который сводит все к функции вроде flash(source*, const *destination, size), которая мне пишет данные любого (разумного) размера, вплоть до побайтно, во флэш, причем я могу писать через границы страниц. Безусловно, я копирую всю страницу флэш в ОЗУ, модифицирую данные в ОЗУ и переписываю страницу флэш целиком назад. Такой подход позволяет мне объявлять в коде константы (настроек) в виде скалярных переменных или массивов и структур, которые используются в коде ну как обычно. Например, const float ADC_Coeff ATS(_SECTION_PARAMS_) = 1.0; ... { return 2.0 * ADC_Coeff * ADC_ValueToVoltageRef(ADC_Values[ADC_ACCU_INDEX], ADC_VDDA()); } Во всем этом присутствуют неизбежные трюки: 1. мое макро ATS() собирает все такие константы в одну секцию (_SECTION_PARAMS_ это строка вроде "MySetting") 2. скаттерный файл компоновщика в проекте размещает такую секцию в требуемую мне страницу флэш, исключая пересечение данных с кодом. Вы можете сказать, я тут рекомендую не заморачиваться с размещением функций в ОЗУ, а сам замутил хардкор? Ну, сначала единовременная инвестиция, а потом удобство использования в любом проекте как copy&paste. Мне нужна структура сложных настроек, которая иногда должна модифицироваться извне? Я объявляю константную структуру как обычно, юзаю ее в коде как обычно. И иногда пишу в нее с помощью flash(source*, const *destination, size). В этом мое удобство и общность решения.

Совет: не заморачивайтесь с размещением в ОЗУ. В этом нет жесткой необходимости, ОЗУ и вправду мало, требует массу телодвижений, и т.д. Я уверен, что получится из флэша, иначе у меня бы не работало бы эти последние годы. Просто нужно подсуетиться разместить перезаписываемые данные в отдельной странице флэш, которая ни для чего более не используется.

В мануале (правды ради - для моих F051 и F103, влом скачивать для F3xx, но вроде у всех одинаково ) действительно сказано: "The Flash memory can be programmed 16 bits (half words) at a time.". Не помню, откуда ходит "байка" о 32-битах. Возможно, для других типов процессоров (NXP?). Ага, для EFM32 писать именно по 32 бита выровненно.

Я имел ввиду, что коллега прав по поводу сука. Далее он предложил НЕСКОЛЬКО вариантов, два из них: размещение функций в ОЗУ или в другом банке флэш. Я уточнил, что размещение в ОЗУ для STM32 (в отличие от EFM32) не является обязательным, можно оставить во флэш, просто в другой странице (даже не банке, если стирать постранично, что Вы и делаете, вроде). В желании Вам помочь и разобраться, я просматриваю мой нынешний рабочий код, которому уже много лет, и слабо вспоминаю, что вначале я тоже сталкивался с похожей проблемой. P.S. Вот у меня нашел такое: FLASH_Unlock(); FLASH_ClearFlag (FLASH_FLAG_BSY | FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPERR); // Clear All pending flags Возможно, нужно сбросить флаги с предыдущей операции. Может это объясняет, почему первая запись после сброса у Вас работает, а последующие нет, хотя сам факт записи имел место.

Я бы посмотрел для начала на карту памяти. Коллега Forger прав. Заморочки с размещением функций работы с флэш именно в ОЗУ для STM32 не обязательны (EFM32 - другое дело). До сих пор мои проекты работали с функциями во флэше, сами находясь, конечно же, не в странице, которая перезаписывается.

Я уже думал в этом направлении, правда, передача только от датчика наверх: см. картинку. Одним транзистором не отделаешься, хотя приведенная схема в 0402 и всяких SC-70 будет маленькой. Указаный LDO - только для примера и симуляции.

memcpy копирует в общем случае побайтно. Вроде есть реализации, где она копирует сначала в максимальной разрядности процессора, а потом, при нечетном количестве байт, докопирует побайтно. Очевидно, что реализация для M0|M0+ будет побайтная. Приведение к упакованной структуре просто порождает код, который работает побайтно. Потому компилятору и сообщают ключи типа -CortexM0, вроде того.

Как насчет 1-wire? Вообще, я не понимаю смысл: если мало места, то всякая схемотехника для передачи по питанию как раз место и займет! Другое дело, если есть только два свободных провода для питания, и нет для данных, то да...