Перейти к содержанию

    

KnightIgor

Участник
  • Публикаций

    667
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о KnightIgor

  • Звание
    Знающий

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Германия
  1. Rasbberry CM3 + WiFi/BT как у RPI Zero W - какие порты?

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

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

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

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

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

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

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

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

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

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

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

    Я придерживаюсь противоположного мнения: именно флэш ультимативно удобна и надежна для хранения настроек. Аргументы: - внешние устройства хранения есть дополнительные компоненты, для них нужно место, к ним требуются шины коммуникации, которые занимают пины и могут сбоить; подвешивание автоматов 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.
  13. В EFM32 нет boot пинов. Там в первых 2KB есть встроенный загрузчик (во всяком случае, в процессоре топик стартера, я тоже с таким работал), поддерживающий XMODEM. Свою программу надо изначально размещать, начиная с 2К (с перемещением векторов), если хочется сохранить этот самый родной загрузчик, который весьма полезен для производства, например: можно прошивать процессоры через последовательный порт с помощью макро для TERATERM.
  14. Запись во FLASH.

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

    Вообще, у меня исторически "навороченный" собственный 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). В этом мое удобство и общность решения.