Комментарии 33
В разработке электронных плат часто надо подписывать электронные платы каким-то серийным номером. Это нужно для идентификации платы при серийном производстве.
Такое ощущение, что попало в начало текста случайным копипастом...
Вероятно очень случайным не последовательным копипастом. Потому что дальше идет
Внешние чипы памяти особенно важны так как прошивку могут полностью стереть, поэтому хранить серийный номер на микроконтроллере внутри on-chip NOR-Flash самого микроконтроллера ненадежно.
Словно EEPROM стереть нельзя. В общем бред сивой кобылы. Если бы автор как-то хотел раскрыть эту тему, то к примеру там было бы упоминание о том, что те же stm32 имеют зашитый на производстве uid, или внешняя микросхема с зашитым uid и каким-нибудь aes протектором (у exDallaSemiconductor их навалом)
Наверное, автор имел в виду именно "серийный номер изделия", а не какой-то случайный предустановленный UID. Чтобы само устройство могло сообщить "я - № 437-ое изделие данного модельного ряда".
Для этого у многих МК есть OTP flash, которую тоже нельзя стереть после записи. Так что пример реально из пальца высосан.
Кому сообщить? Пользователю? Для чего? В чем смысл вот этого human like сообщения? Модель обычно на корпусе указана. Его достаточно и в прошивке захардкодить вместе с контрольной суммой. Это не сложно. Но зачем когда есть заранее прожитый uid (а производитель микроконтроллера редко меняется), который можно записать в базу во время автоматического тестирования.
Словно EEPROM стереть нельзя.
Можно из релизной прошивки исключить функции записи и стирания из драйвера EEPROM. Оставить только чтение.
Правильный ответ не "можно убрать функцию стирания", а "можно ножку WP подтянуть к земле".
Чтобы найти в базе данных отчет модульных тестов для этой конкретной платы.
Интересная и информативная база данных получится - "PASS, PASS, PASS, PASS, PASS, PASS, PASS, PASS, ...". Те платы, где был другой вердикт, улетели в мусорку (или на доработку).
Микроконтроллер могут и перекинуть
EEPROM тоже могут перекинуть. Могут вообще одну плату из двух собрать, если производитель особо бедный и каждый резистор на счету. Более того, помимо серийника может еще потребоваться сохранить какие-то секреты, доступность которых через I2C шину является крайне нежелательной.
А не проще для записи логов было использовать обычную SD-CARD подключенную по SPI?
Тут и масштабируемость лучше. И читать можно на любом компьютере, в случае чего.
А не проще для записи логов было использовать обычную SD-CARD подключенную по SPI?
Надо чтобы память была неразрывно связана с электронной платой. А SD карту можно вытащить и потерять.
А не проще для записи логов было использовать обычную SD-CARD подключенную по SPI?
Большинство SD карт не проходят по температурному диапазону
1--Дорогая память для масштабирования.
4--Мало памяти. Всего 256 байт.
Нормальная память. Для каждых задач свой тип памяти. Конкретно эта предназначена для частой записи мелких данных, т.к. выдерживает около 1млн. циклов перезаписи.
Если нужно еще чаще записывать, то стоит посмотреть в сторону FRAM, она совмещает достоинства EEPROM и имеет практически неограниченное кол-во циклов перезаписи, к тому же ее можно использовать без изменения кода.
FRAM просто прелесть, вместо использования батареек сейчас предпочитаю использовать FRAM. О ресурсе перезаписи не думаю, в моих кейсах использования, достаточно и того что есть. А вот то что не надо ставить батарейку и мониторить ее - это прям реально радует.
У FRAM есть такой нюанс, как разрушающее чтение. Полностью игнорировать вопрос питания не стоит.
А можно в двух словах? При чтении расходуется ресурс? И сколько это (хотя бы порядок)?
Не, про ресурс можно не задумываться. Есть небольшой шанс, что при выключении питания в момент чтения из FRAM будут потеряны записанные данные. Там какие-то крохотные времена на регенерацию, поэтому я просто держу информацию об этом в голове, чтобы знать, куда копать в первую очередь, если с этим столкнусь.
Этим микросхемам EEPROM уже сто лет в обед. По ним всё 1000 раз жёвано-пережёвано. Имеются даже готовые библиотеки под любой МК. В чём был смысл делать про это статью в 2023 году?
Человек открыл для себя EEPROM.
Лучше такие топики, чем очередное "почему OpenAI уволило Альтмана".
Поддерживаю. И все-таки статья достаточно полная.
Имеются даже готовые библиотеки под любой МК.
Хороший драйвер для I2C-EEPROM должен быть единообразным для всех микроконтроллеров и собираться без изменения кода на всех ToolChain(aх).
Обычно у драйвера чипа AT24Cxx вот такие зависимости .
Чтобы заработал драйвер AT24Cxx нужно чтобы у вас уже был реализован определенный MCAL. Это драйвер I2C, драйвер GPIO, драйвер аппаратного таймера или SysTick. Функции установки миллисекундных пауз. И желательно программный компонент расчета контрольных сумм. Без этого джентельменского набора говорить о разработке драйвера AT24Cxx не приходится.
По ним всё 1000 раз жёвано-пережёвано. Имеются даже готовые библиотеки под любой МК. В чём был смысл делать про это статью в 2023 году?
GIT Hub наполнен низкопробными драйверами от embedded школоты и Junior разработчиков.
Про то как писать добротный драйвер для ASIC есть вот эта методичка.
Архитектура Хорошо Поддерживаемого драйвера для I2C/SPI/MDIO Чипа
https://habr.com/ru/articles/683762/
+надо чтобы код драйвера проходил по ISO 26262-6
И вероятность найти такой код в интернете крайне мала.
Круто! Огромное спасибо за статью.
Также вам может быть интересно База по SPI NOR FLASH
Если бы вы поинтересовались у любого ремонтника бытовой техники, он бы вам сказал, что I2C микросхемы памяти приходится менять или перешивать в 1000 раз чаще, чем микроконтроллер.
Чего напали то на человека? Нормальная статья с нормальным, доступным, описанием полезного чипа, который практически все программисты и схемотехники щупали в своей жизни.
Да, верно сказано, бывают случаи, когда надо что-то записать на плату, и это не должно быть в контроллере. Таких кейсов тьма тьмущая.
Обзор Чипа Внешней I2C Памяти AT24Cхх