Arduino программатор PIC-ов.

Иногда встречаются очень интересные проекты выполненные на микросхемах PIC. Это микроконтроллеры с RISC архитектурой,
производимые фирмой Microchip Technology. Программаторы для PIC сложные и дорогие. Чтобы сделать программатор для PIC, нужен программатор для PIC, замкнутый круг для самодельщина. Но у нас есть Arduina! Сделаем из ардуины очень дешевый, очень простой, но работающий как очень дорогие HVSP программаторы микроконтроллеров от Microchip Technology.

HVSP - это High Voltage Serial Programming, высоковольтное последовательное программирование. Высоковольтное программирование позволяет сделать рабочим окирпиченный PIC контроллер из за неправильно выставленных фьюзов или заблокированных ног используемых при низковольтном программировании. В общем без разницы в каком состоянии Вам пришлют хитрые китайцы микроконтроллер, главное, чтобы он был аппаратно живой. А разлочить можно и ардуиной. Запрограммировать можно и ардуиной.

Схема.



Сборка на макетной плате.



Настройка Step-UP DC-DC



Пример работы программатора сделанного из ардуино нано в макете с парой дополнительных деталей которые можно выдрать из старой техники. Единственное для удобства я использовал повышающий преобразователь для получения 13V нужных для высоковольтного программирования. Удобство заключается в том, что просто вставляете программатор в USB и работаете не заморачиваясь на необходимости подачи внешнего питания. Иначе просто можно подать это напряжение от внешнего блока питания и схема станет еще проще.

 

[nobilia7]

Eig
Вы меня не совсем поняли. Проделайте пожалуйста вышеописанные процедуры со СВОИМ файлом. Мой - заведомо битый, нигде он работать не будет. У него уже ошибка при сохранении. Можете попробовать. Например возьмите WinPic800 и откройте в нем хекс. Да и масса других программ...

 

[Eig]

@nobilia7, повторил ту же процедуру со своим файлом rfid_pic16f628a_intrc.hex. Пересохраненная версия 628.hex весит в два раза больше и не открывается ни в формате intel, ни в формате motorola. Программа ArdPicProgHost читает записанную программу из памяти правильно, в формате intel, но отображает его почему-то с инвертированными битами. Можете убедиться сами (сравниваем левый-верхний и правый):

То есть программатор всё правильно пишет и читает, а ArdPicProgHost просто не умеет экспортировать правильно считанные файлы. Если были б исходники ArdPicProgHost, то я б поковырялся.

 

[nobilia7]

Eig
Вот о этом я Вам и толкую. На самом деле хекс, записанный в чип рабочий. В этом наверняка можно убедиться, впаяв его в соответствующее железо. Но!! если Вы сохраняете СЧИТАННЫЙ хекс для последующей работы (архив и пр.) , то здесь Вас ждет Засада. Файл считан и сохранен неправильно!
В принципе, если в редакторе Вы удалите первые 3 символа и пересохранитесь, то получите рабочую прошивку. Но это садомазохизм. И известен только Вам.... Это - то, что сохранила программа. А это Ваш Оригинал:.

На это "безобразие" Автор ответил следующее:
"...Es sieht so aus, als ob die Datei eine UTF-8-Byte-Ordnungsmarke enthält. Ich weiß nicht, wie das passiert ist, es sei denn, es wurde von der C ++ - Bibliothek ausgeführt, als Sie das Host-Programm erstellt haben. Sie können versuchen, das zweite Argument in die fopen () -Aufrufe von "w" in "wb" zu ändern, damit der Textmodus nicht verwendet wird..."
В принципе,... вот только у меня нет компилятора...
Да, должно сохраняться в Интел...

 

[Eig]

@nobilia7, Вот тут
разработчик утверждает, что этот баг пофиксил. "Last change: 01/11/2014 : fixed bugs in Intel hex file export (checksum calculation, format for EEPROM data)".
Вот тут скомпилированная версия файла от 2016 года.

@nobilia7, ну понятно. Видимо, он недофиксил.
В принципе, у меня на работе Win10, 15-ая студия и 17-ая студии стоят. Попробую через какое-то время сделать то, что он рекомендует. Дома искать образ старой студии и устанавливать запаришься. Я только не уверен, что у меня компонент VB там установлен.

 

[nobilia7]

Eig
Я писал письмо, а потом разговаривал с Автором на днях. Пофиксил не все, признает ошибки. Но проектом больше не занимается..
Насчет VB я Вам не помошник. Хотя очень хотелось бы иметь "допиленный" софт. Если получится - пишите.

А в чем у Вас проявляется некорректная работа, ели не перегрузить программу 2 раза?.

 

[Eig]

@nobilia7, программа просто не работает с первого раза. Включается зеленая лампочка, и дальше вообще ничего не происходит.

 

[nobilia7]

Просто чудеса какие-то. А у меня работает все с первого подключения. Пробовал специально и так и этак.

 

[Eig]

@nobilia7, поскажите пожалуйста, какую программу вы использовали для просмотра hex-файлов. Я не могу найти такую, чтобы показывала мне инвертированные биты.
В общем, я начал разбираться со всем этим. Автор софта в общении с Вами написал о какой-то другой программе, написанной на C++. Его рекомендация нам не поможет. Исходники ArdPicProgHost написаны на VB.NET. Идея моя заключалась в следующем. Я нашел пару проектов на C#, которые, по идее, правильно производят сериализацию массива Char, в котором считывает прошивку программа. Я скомпилировал первый из проектов и получил dll, вызов метода из которого добавил в программу. Проблема заключается в том, что у нас: 1) есть еще EEPROM. Это довольно просто решается удалением 00000001FF из конца области DATA, добавлением символа перевода каретки vbCrLf и сшиванием со строкой EEPROM, полученной вторым таким же вызовом. 2) У нас есть еще т.н. configuration word, которое находится в конце области DATA и начинается с 02400E00, и затем к нему добавляется еще некое значение lConfigWord.Text(i), полученное из памяти микроконтроллера, причем в инвертированном виде (i = 2,3,0,1). Но после этого добавляется еще и Checksum. То есть это полный вынос мозга, причем нигде толком не задокументированный. И, если честно, я уже не уверен, что автор все это правильно реализовал. По идее нужна отладка его кода, чтобы в прямом эфире смотреть, где он накосячил, где появляются эти лишние символы.

p.s. Всё, разобрался. Файл просто открывается в Notepad++ как надо. Итого видно различия, что в начале исходного файла есть расширение формата HEX386, которого нет в битом. Затем в нем куча нулей (3FFF) после значащих данных, которые, видимо, никак не влияют, но добавляют весу. И ближе к концу, перед configuration word, отсутствует строка ":084000000F00000000000700A2". Нужно разбираться что это, и почему она не добавляется.

p.p.s. В общем, прошу прощения, но я не нашел каких-либо проблем в сгенерированном программой файле кроме отсутствия расширения до PIC24 (HEX386 в самом начале + эта непонятная восьмибитная строка с какой-то инструкцией перед configuration word и расчетом контрольной суммы). Я внес правки, и попробую завтра снова получить преобразованные файлы.

 

[nobilia7]

PICDisasm

PICprog7

Посмотреть и скачать с Яндекс.Диска

disk.yandex.ru

 

[Eig]

@nobilia7, спасибо!

 

[nobilia7]

Eig

Host-Software for ArdPicProg
For programming a pic controller a host software would be required. You can select between two options: the terminal program “Ardpicprog” or the “Arduino Pic Programmer” (ArdPicProgHost) with a Windows based graphical user interface. The source code for both programs is Open Source and would be available for download on github.

Arduino Pic Programmer (ArdPicProgHost)
This windows application offers a modern and intuitive way of programming a pic controller.



Controllers which are supported by the Arduino Pic programmer can be read, erased, and written. The user interface and the program options are also described in the User’s Guide.

ArdPicProgHost was programmed with Microsoft VB2010 Express and is released under a GNU General Public License Version 3. The source code is provided through a github repository. The executable (Release 0.2.7) can be downloaded here:

Download ArdPicProg.Exe (.zip Datei)
The software does not require any installation. After downloading and unzipping the program can be executed right away.

 

[Eig]

@nobilia7, да, именно эту репу я и правлю. Но там нет и не может быть никаких fopen(), потому что это из совсем другой оперы - сишной.

 

[nobilia7]

Eig
Я наверное понял. Рекомендация была дана для версии командной строки.

Для этого видимо должно быть так:

 

[Eig]

@nobilia7, тогда давайте отделим мух от котлет, и согласимся, что мы сейчас боремся с двумя разными ветряными мельницами. У Вас консольная версия создает дополнительные символы, а у меня версия с окошком делает все правильно, но не поддерживает мои "суперсовременные, навороченные" пики, у которых .hex сохраняется в расширенном формате, как выяснилось.

upd: поправил в hexfile.cpp два вызова fopen() с w на wb. Какая сложность была скачать бесплатный CodeBlocks и бесплатный же компилятор Mingw64-GCC, я, если честно, не понял. Из всего мне только версию ARDPICPROG_VERSION пришлось добавить, иначе не компилировалось (вру, еще нужно скачать avr-gcc-10.1.0-x64-windows). Экзешник host.exe искать в папке bin.

 

[nobilia7]

Вы правы. Я просто высказал предположение. Буду рад, если у Вас получится поправить графическую версию.
Просто я этими делами не занимаюсь совсем. И у меня наверняка ничего не получится.

 

[Eig]

@nobilia7, попробуйте экспортировать с помощью исправленной консольной версии. У меня нет таких пиков, как у вас.

 

[nobilia7]

я пробовал на 628А. все сохранялось правильно. Сейчас в наличии есть только 16ф54.
но интересна не консольная, а графическая оболочка...
вот думаю, мне на днях надо прошить 16F1507. ее в списке вроде нет. надо добавлять библиотеку. но пока не до этого. разбираться некогда, возможно ли эту мсх добавить...

 

[Eig]

@nobilia7, хорошо, а с какими микроконтроллерами были проблемы в консольной программе?

 

[nobilia7]

я не пробовал изначально совсем. только в графике. 628а и 629

 

[Eig]

@nobilia7, ок. Значит с консольной версией в первом приближении всё в порядке, и ее можно использовать в качестве основы для понимания особенностей PIC24.

 

[nobilia7]

похоже, что так. что касается пик24 - не знаю.
архив консольной - уже измененный по совету.

 

[Eig]

На данный момент я убрал мусор (пустые ячейки 3FFF), который программа считывает в дамп памяти на компьютер. Но только в области памяти программы, а не в EEPROM. Это сильно сокращает размер формируемого файла, но ничем нам не помогает.
Прописал в начало экспортируемого файла инструкцию HEX386 ":020000040000FA" (подчеркнута красным). Эта инструкция одинакова для PIC16F628A и PIC16F648A. Тем не менее, для других микроконтроллеров она может отличаться, что весьма печально, поскольку из самого микроконтроллера программа ее не считывает.
Разобрался как работает программа: просто считывает дамп памяти построчно и вложенным циклом побайтно. Каждые 4 байта (4, 8, 12, 16, 20, 24, 28) и почему-то 31 (там еще считается контрольная сумма) считает некую сумму и добавляет ее в формируемую строку для hex-файла.
Основная проблема оказалась не в том, чтобы записать, а в том, чтобы считать. Точнее, в адресации данных.
Program range (0000-07FF) считывается непосредственно из микроконтроллера, а строчка ":084000...", также подчеркнутая у меня красным, отсутствует в дампе памяти по той причине, что находится вне этого диапазона (она начинается с 0x4000). Вероятно, HEX386 как раз указывает на расширение диапазона, или на то, что просто нужно "перепрыгнуть". Боюсь, что "в лоб" ":084000..." считать не получится, и в реальности она находится где-то в другом месте.
То, что подчеркнуто оранжевым и зеленым, добавляется автором вручную, одинаково для всех пиков и каких-либо проблем не представляет.
Так что пока вот так: буду думать, как считать первый конфиг и строку эту...

По-хорошему нужно было просто сделать из сишной программы (она довольно заумна, не содержит абсолютно никаких комментариев и точно воспроизводит инструкции Intel Hex) библиотеку и вызывать из нее функции. Но автор программы на VB почему-то поступил иначе...
Получается, что по уму надо все заново писать.

 

[nobilia7]

----для меня это темный лес... но, интересно... рад помочь, но нечем.

 

[Eig]

@nobilia7, папку host перезалил. Сегодня утром проверил: программа не запускалась из-за того, что я ARDPICPROG_VERSION объявил как int в попыхах. Сейчас исправил. Основное отличие консольной программы: в ней считывается диапазон _reservedStart(0x0800) - _reservedEnd(0x07FF). Никакой половой разницы между w и wb нет в данном случае. В конце каждой строки отличаются контрольные суммы из-за 3FFF. Но, похоже, это тоже никак не влияет. Попробую понять, что происходит в консольной программе (там какая-то принудительная калибровка и еще много всего интересного).

Всё, победа. Проблема была в том, что исчезающая строчка 2000: находится в скрытой области памяти. Чтобы получить к ней доступ, нужно обратиться к двум байтам по адресу 0000:, и сразу после этого считывать 8 байт по адресу 2000:. Автор программы на VB.NET этого не делал, а авторы консольной программы делали.

Выкладываю работоспособную версию программы на VB.NET и экспортированные прошивки. Исходный код выкладывать не буду – вам от него все равно что от козла молока. Надо делать форк на гитхабе и лить туда, но сейчас не до этого. Всё, всем спасибо.

upd: залил код на гитхаб. Поправил файл, чтобы не рушилась поддержка более простых микроконтроллеров.

 

[Lazy-R]

Собрал сей девайс, всё работает, но...
Прошивал 12ф675 , при считывании контроллера в пункте osccal показывает, как я понимаю константу.
Если выбрать файл и прошивать , то константа сохраняется, но если программа попросит сначала стереть контроллер, то при стирании константа затирается, и при следущей прошивке она не прописываеся.
Пришлось открыть файл прошивки в winpic800 вручную прописать в прогу константу, и сохранить, а потом прошивать через ArdPicProgHost