Комментарии 33
С прибытием :)
Но тут в отличии "другого сайта" в комментах нам не погутарить :)
Немного странная статья для 2022 г, но красивая и кто я такой бесстатейный тут что-бы об этом рассуждать :)
это именно тот случай когда коту делать нех..., счатливые вы люди , у вас столько времени жизни на такие бестолковые вещи, прогер на али стоит дешевле ардуины и работает с тысячами микр, купил и пользуешься
Тут же суть не в прогере, а в алгоритме и в принципе работы. Заместо этой микросхемы может быть любая другая, суть именно в способе связи, работе с терминалом. Изучении устройства и принципа работы программатора, а не просто "купил, сунул, вынул".
прослойка в виде ардуины с терминалом для этого совсем лишняя,
есть ft[2]232h с mpsse, ну или копеечные китайские же клоны альтеровских усббластеров (которые внутри на 8051 тот же ftdi из себя изображают c самопальной и упрощённой версией "mpsse") для получения usb -> spi + gpio.
да и CH341 - для месье знающих толк в китайской документации.
беда этих чипов в нестабильности функционирования. По сути программный ногодрыг на костылях. Который в связи с закручиванием гаек в виндовс всё сложнее и геморнее использовать. В какой-то момент эти решения внезапно с точки зрения безопасности станут "вне закона" и что делать? Не обновляться? ну, кое кто 98-ю винду использует для программаторов, т.к. софт требует прямого доступа к портам.... на ХР был драйвер, который по сути делает огромную брешь в бехопасости системы.... а люди хавали, ибо не понимают чем это чревато. работа на костылях. Поэтому ардуинка, как бы ни казалось странным, это более правильный путь - на ней у нас все аппаратные возможности под полным контролем, а поддержку uart в том или ином виде с операционной системы врятли выпилят. Но если нужны будут скорости, есть вектор развития - USB... и USer-mode драйвера на свои поделки.
Это не так, костыли тут ардуина, и учитывая что usb->serial в них иногда лепят из чего попало (особенно в клонах), вероятность потенциальных граблей с драйверами в будущем у них имхо чуть ли не больше чем с ftdi.
в ft232h mpsse - конечный автомат который на скорости, вроде бы, 6МГц исполняет отправленные ему простые команды,
то есть им можно аккуратно, с точностью до такта этих 6МГц дрыгать ногами, отправив разом последовательность команд, и исполняться они будут не зависимо от ОС и милисекундных циклов усб.
Для синхронизации этого автомата правда только один единственный вход, то есть присутсвуют команды "ждать положительного/отрицательного перепада на входе", но только на одном. Но можно прицепить какой-нибудь spi АЦП, который по готовности данных дергает drdy, который ждёт mpsse, после чего начинает пересылку байтов по spi, опять же сам, независимо от ОС, и без поллинга статусных байтов.
Помимо этого сам spi там "аппаратный" то есть команды "отправь следующие N байт с в нужном cha/pol режиме ногами/головой вперёд, с заданной скоростью" также как дрыгание io исполнятся независимо от ОС.
И альтервоский usb blaster - то же самое, только там, до появления mpsse, изначально был колхоз из usb->fifo ft245 и мелкой cpld которая разбирала приходящие байты и на заданной скорости отправляла их в spi и дергала ногами, снова не зависимо от того что там наверху у ОС происходит.
Протокол там проще mpsse и давно доступен, как-то делал программатор для какого-то еепрома как раз альтеровским бластером, лет 10, наверное, назад, если не больше.
Ардуина может это же делать на 20Мгц тактах, а в соседстве с ПЛИС и на 100МГц... а FTDI как была специализированным чипом так и останется - развития нет, расширения функционала тоже. В то время как ардуина в качестве USB-интерфейса имеет тот же МК с USB на борту, прошивку которого можно поменять и получить более гибкое устройство. Кроме того непонятно ещё как тот самый FTDI чип программировать и использовать, не очень открытая документация.
не может, хотя бы потому что для того чтобы какие-то осмысленные данные из какого-то буфера достать и положить в порт, надо несколько больше одного такта, во-вторых full speed usb, а до самого контроллера вообще уарт, который больше мегабита не разогнать.
ардуина и тут-то не нужна, а в соседстве с ПЛИС тем более.
какое может быть развитие у usb->spi интерфейса?
mpsse и так любой последовательный, да и не только, интерфейс может изобразить.
и я так понимаю что тот же человек, что парой сообщений выше опасался закручивания гаек виндой на предмет подключения непонятных устройств со всяким подписыванием драйверов, теперь предлагает запилить кастомное usb устройство, потому что это более гибко?
вся документация на ftdi открыта, доступна и понятна.
там единственная dll c функциями FT_Read, write, open, close, и AN_108 с описанием байтовых команд mpsse.
Устройство не кастомное, кастомное оно уже после USB интерфейса, а для виндовс оно представляется одним из классов устройство драйвера для которых уже есть в системе. В варианте FTDI нет гибкости, для оперативного решения всеравно нужна связь с хостом и соответствующая задержка передачи по USB. Выдать заданную последовательность будет можно, а вот первичная условная обработка уже затруднена, чтобы что-то решить(отреагировать на сигнал) нужна связь с хостом. Раньше уже такое практиковалось - так называемые софт-модемы, где часть аппаратной обработки была заменена на софтовую, аппаратными там остались разве что ЦАП/АЦП и небольшие буфферы и работали они ненадёжно из-за того что софтовая часть не успевала вовремя. Просто плюнуть в SPI - Ок, а если в момент передачи приходит сигнал, который должен поменять/отменить передачу? а софт целую милисекунду ещё не в курсе этого... в этом ограничение применения таких чипов.
а мы точно всё ещё программатор spi-еепрома обсуждаем?
да, не очень гибко, тем не менее со своей задачей преобразования usb->spi справляются на отлично, гораздо лучше чем корявый велосипед из ардуины.
есть тут пара тестовых стендов где ft232h непрерывно забирает данные с ads1278, или с 8 штук ads1263, гибкой ардуине силенок не хватит просто прочитать столько данных, не говоря о том чтобы куда-нибудь передать дальше.
где-то попадались usb пзс камеры состоящие внутри исключительно из ft2232h и ацп ad9826, без каких-либо мозгов, всё остальное -"программное" ногодрыгание с ПК, нормально работает.
Бывает фактор времени, вынуждающий делать всякую ересь на ардуино. Бывает технологический - когда нужно запрограммировать допотопную параллельную ромку еще и высоковольтную. А там уже другие программаторы...
Вот только.... разбираешь прогер, ба.... а там та же самая ардуина стоит по сути. Но не в этом фишка... в том что на ардуине можно сделать любой программатор, даже тех экзотических чипов которые не поддерживаются китаем, ибо программистам лень было внести их параметры в прогу. А потом столкнешься с чипами вроде ПЗУ для хранения БИОСа на материнках, с защищёнными от чтения/записи областями и таже TPM областью под хранение ключей шифрования, и прошить такую можно только зная ключ, а считать нельзя будет - данные будут ЗАШИФРОВАНЫ хранящимся внутри ключом, так что даже на работающей системе сдампить содержимое путем анализа обмена будет нельзя. Казалось бы, простой чип памяти...
Ну не знаю, как на других ресурсах, а тут некоторыми принято читать посты...
Итак, приступим:
Язык программирования - си.
не бьется с
откроем редактор скетчей Arduino
поскольку здесь С++.
сколько чисел содержится в маске
и сколько именно чисел в маске?
void ERAL() { // ERASE CHIP
а назвать функцию, к примеру, Erase_Chip, нельзя?
void READ(word startAddress, int endAddress) { //read fashion HEX by Ben Eater
параметры функции формально разного типа ( на самом деле одинакового) а что так можно было? Ну и про комментарий - если это перевод, то где тэг?
дальше просто лень стало, извините.
Адресация при записи в режиме x16 осуществляется с шагом 2, т.е. не 0,1,2...f, а 0,1,2..7,
Аналогично (. Где тут шаг 2?
Название функции ERAL, вероятно, взято из документации на ИМС.
Имеется в виду по два байта на адрес, вместо 16 адресов используется 8 адресов которые указывают на двухбайтные ячейки, короче путаница небольшая. По смыслу - чип сам умножает адреса на два, поэтому реальный шаг адресации - 2, но внутри чипа.
В данном случае, это скорее ближе к чистому си, хотя язык для скетчей Arduino и C++ (к тому же, в редакторе кода нет кнопки "C", а есть только C++), здесь функции ООП не задействованы, всё укладывается в рамки именно процедурного программирования
Про числа - верная оговорка, я имел ввиду разрядность применяемой маски (13/14 бит), но неверно написал, и не скорректировал.
ERAL, WRAL и т.п., функции, взятые из даташита. Конечно, по naming convention это некрасиво, но сделано для более понятного текста.
Здесь тоже верно, возникло из-за того, что startAddress я задавал словом, а второй параметр у меня был - длина (размер читаемой области), которую прибавлял к адресу. А при отладке уже в какой-то момент заменил длину на конкретное значение конечного адреса, и не заметил несоответствия типов.
Тэга перевод нет, потому, что это не перевод, а моя собственная статья, в которой просто напросто имеются заимствования (к тому же, не из печатного материала, а из видео со ссылкой на автора)
То, что лень стало - тоже нормально, так как Вам данная статья просто не интересна, судя по количеству публикаций Вы уже и так неплохо разбираетесь в теме. Для Вас, думаю, это бесполезный материал, потому что через всё это прошли.
Вы не правы, материал все равно полезный, интересно же посмотреть, как теперь через грабли перепрыгивают.
А по теме и без шуток - есть такой классный прибор Black Magic Probe, который реализовывает с одной стороны интерфейс GDB, с другой цепляется по JTAG к ARM контроллерам. Не думали в данном направлении - тогда Вам не потребуются программки на стороне хоста -любая IDE (почти любая) умеет работать с GBD, да и отдельных утилит должно быть богато, было бы интересно сделать такую вещь.
Эти EEPROM очень часто встречаются в автомобильных блоках SRS, и часто используются в блоках ЭБУ как накопитель для данных иммобилайзера. Всегда не хватает устройства для отладки, а именно в идеале нужна железка, которая пошагово разберет, в какой момент времени и на какой адрес идет обращение. Есть мысли как собрать такую приблуду из говна и палок на Arduino?
Для автомобилистов отчасти и писал статью.
Мысли есть - навесить Arduino на шину SPI (так как она разрешает подключение многих устройств), и, отследив сигналы CS и CLK, записать последовательность данных, переданную по шинам, а потом расшифровать данные. Есть промышленные логические анализаторы, которые стоят сотни нефти, но сами способны на ходу читать SPI. А из палок придётся повозиться. Сигнал CS включается, когда идёт работа именно с данным чипом, чтобы другие чипы на шине не принимали команды. Включение CS на нужной микросхеме можно отследить как момент для начала чтения данных.
зачем ардуино.... есть же лог. анализаторы. Цепляете его на CLK DI DO и один вывод на нужное событие, чтобы потом сориентироваться с моментом. Во многих программах анализаторов есть даже SPI I2C декодеры, просто поставил на запись, сделал что нужно, смотришь результат и делаешь выводы. На ардуино сделать это будет проблематично, нужеен аппаратный адаптер в виде регистров - дело в том что ардуине может не хватить скорости чтобы отрабатывать корректно сигнал CLK, но это прекрасно делает регистр, и на каждый 16 такт внешнего сигнала CLK после активного CS вызывать прерывание ардуины и в нем считывать этот регистр - с этим она справится. Ну а дальше понятно, разбираешь команду, адрес результат.... надо только забыть про реал-тайм передачу в терминал, скорей всего не будет успевать. Поэтому приняли блок данных целиком, и только тогда слать в терминал.
Какие такие 7 вольт? Это же абсолютный предел. Максимальное напряжение питание для долгой беспорочной службы — 5,5 В.
Кстати в коде вижу что сигнал выбора кристалла предполагается активный уровень - лог.1, но по опыту в схемотехнике, у этих чипов активный уровень - лог.0 тоесть "0" - кристалл активен, принимает команды, "1" - игнорирует. Это не ошибка?
Делалось согласно фигуры 3-2, а так верно подмечено, для SPI же шина должна быть занулена, если чип выбран. Но тогда на чипе пишется SS (CS) с черточкой наверху (active low), здесь же чёрточки нету, значит, данный чип - active high.
P.S. я так думаю, в схемах на данную линию ставится одинарный логический инвертор
Программирование EEPROM 93C76. Пишем программатор. Часть 1