anpaza

Описание протокола здесь: https://docs.google.com/document/d/1oHtMBnZ...dit?usp=sharing Если в двух словах, пакеты переменной длины, заголовок 3 байта, данные до 16 байт, 1 байт контрольная сумма (CRC8). Дерево исходников здесь: https://code.google.com/p/iwattnick/source/...se/#svn%2Ftrunk Коментарии местами на русском, местами на инглиш, в зависимости от ожидаемой ширины аудитории :). Несколько коментариев по поводу организации дерева исходников: библиотеки в каталоге libs/, приложения в каталоге apps/, тестовые проги в каталоге tests/, публичный интерфейс библиотек в каталоге include/, система сборки (использует GNU Make и arm-none-eabi-gcc) в каталоге tibs/, утилиты, использующиеся во время сборки в каталоге tools/. В каждом перечисленном подкаталоге создаётся подкаталог по имени модуля (например, библиотека gears в libs/gears/, приложение iwacon в подкаталоге apps/iwacon, публичный интерфейс библиотеки yagl в каталоге include/yagl и так далее). Для каждой целевой аппаратной платформы создаётся отдельный файл include/hardware-xxxx.h, в котором описано на каких ногах чего висит. У меня пока всё отрабатывается на STM32VLdiscovery. Название этого файла надо присвоить макросу HARDWARE_H (в командной строке компилятора), в коде стоит просто #include HARDWARE_H. Библиотека с реализацией протокола (режим single-master, режим multi-master пока теоретический): https://code.google.com/p/iwattnick/source/...2Flibs%2Fmudbus Публичный интерфейс библиотеки: https://code.google.com/p/iwattnick/source/...nclude%2Fmudbus Библиотеку старался писать аппаратно-независимо, поэтому всё что касается STM32 находится в подкаталоге stm32/. Основная логика по приёму и посылке - в файлах send.c и recv.c соответственно. Основная жесть в файле include/mudbus/stm32/drvgen.h. Этот файл включается из основного кода, предварительно макросами задаются номер USART'а, плюс из hardware*.h используются доп. макросы типа какой канал DMA прикреплён к этому USART и т.п. Тестовое приложение для библиотеки в каталоге tests/tmudbus/. Приложение на Питоне для общения с устройством через USB-UART в подкаталоге apps/iwacon/. Низкоуровневая работа с DMA и отчасти USART реализована в библиотеке gears: https://code.google.com/p/iwattnick/source/...2Fgears%2Fstm32 (в некотором смысле аналог Standard Peripherials Library, от неё меня тошнит). Ещё из интересного можно посмотреть библиотеку YAGL (Yet Another Graphics Library). Она поддерживает работу с графическими LCD дисплеями, на текущий момент только одного типа - на контроллере ST7567, но достаточно легко добавить поддержку других типов (к тому же они все похожи друг на друга вплоть до кодов команд). Вся работа ведётся с фреймбуффером (1 килобайт для Ч/Б 128x64), периодически буффер выкидывается на экран через SPI/DMA. Трансфер охренительно быстрый, можно обновлять экран более 500 раз в секунду почти не напрягая ЦП, и это при том что я постеснялся выставлять делитель SPI /2, поставил пока /4 - конкретно мой дисплей тянет /2, но мало ли что...

Отгадка простая - терминалка (или какая там программа принимает байты на второй стороне) сжирает нуль. Тоже на это нарывался, писал в лог с терминалки а устройство толкало бинарные дампы. Приезжало всё нетронутое, кроме нулей :) Большинство C программ, которые трактуют поток из COM порта как строки, пропускают нуль. Проще всего дампить через что-то типа cat /dev/ttyUSBx >file.bin

Ну так UART+DMA ничем по сути от фифы не отличается, но гораздо гибче. Я тоже такую шнягу писал, для обмена с компом с минимальным участиям собственно процессора МК (протокол запрос-ответ). Если интересно, могу дать ссылку на репозиторий (проект опенсорсный, хоть пока в начальной стадии реализации).

SD карточки до 4Гб используют один протокол, свыше 4Гб - другой. Возможно, с этим как-то связано. Почему у Вас граница на 8ми - не знаю.

Я новичок на форуме, и личные сообщения у меня отключены. Буду рад если смогу помочь, хотя я и сам только-только начал пользоваться этим программатором. Я заполнил в профиле скайп, jabber и icq и включил доступ к электронной почте, выбирайте что Вам удобнее.

Продолжение сериала "Самые умные плачут первыми" :) Простите если кого достал, но кому-то может помочь. В общем, последовательность, которая железно активирует SAM-BA следующая: Подключаем к плате питание. Даже если там всё убито, неважно. Замыкаем (при включённом питании! ЭТО КЛЮЧЕВОЙ МОМЕНТ!) ERASE на +3.3V и держим так 3-5 секунды. Китайцы говорят 10 - перестраховываются. Размыкаем ERASE (до или после выключения питания - это неважно). Выключаем питание Включаем питание снова Замыкаем TST на +3.3V. Держим так 10 секунд (китайцы говорят 20 - перестраховываются). Выключаем питание, убираем перемычку. После повторной подачи питания устройство распознаётся как USB CDC Serial, можно ставить драйвер SAM-BA и прошивать! Подтяжка на USB D+ -> +3.3V не нужна! (не знаю почему :-) но работает и без неё). Лочить прошивку не надо, у меня с включённой блокировкой не работали программы! Вылетали по тайм-ауту при старте. Это железно проверено несколько раз. Теперь о правильной прошивке. Почему-то на моём устройстве ЛЮБАЯ попытка апгрейда прошивки через программы от SEGGERS приводит к убийству устройства. Не знаю, как у других работает на клонах - для меня это загадка. Огромное спасибо AleksD за выложенную здесь прошивку от июля 2014 года!!! Прошил относительно свежую прошивку, после чего подобрал относительно свежий софт, который не желает обновлять прошивку. Идём на сайт SEGGERS в раздел архивов и качаем последнюю версию программы, которая работает с прошивкой по ссылке выше - 4.90e. Вот в такой комбинации - а именно, прошивка FW_JLinkARM_V488b_17072014.rar и программа 4.90e - всё у меня и заработало. Такие дела, надеюсь кому-то помог.

Ндааа..... Короче, хрень какая-то. Видимо, дело было не в моих телодвижениях, когда оно вдруг начало прошиваться, а в фазе Луны. Долго пытался сбросить биты блокирования записи, все мои замыкания ERASE и TST ни к чему не приводили. Как ВДРУГ! оно взяло и сбросилось, и вошло в режим USB CDC Serial... и я прошился заново с серийным номером 480003177 (вроде не забанен), но уже не стал блокировать запись. Устройство заработало, но.... При первом же запуске JLinkExe оно пошло апгрейдить прошивку, и аллес капут... Теперь опять замыкаю ERASE и TST в разных комбинациях :) замерил напряжение на ногах PA0, PA1, PA2, там 2.8В что, в общем-то, соответствует логической единице, как и написано в документации... но при этом замыкание TST ничего не даёт. Я весь в непонятках, ну что это за микроконтроллер такой, который в режим программирования входит только раз в неделю... Кстати, процедура стирания прошивки вообще не нужна (замыкание ERASE). Вот, например, здесь подробно расписана процедура активации загрузчика SAM-BA: https://www.olimex.com/Products/ARM/Atmel/_...s/SAM-BA-Notes/ Я во второй раз просто TST замкнул безо всякой перепрошивки, и оно сработало. А теперь срабатывать не хочет :01:.

Отбой воздушной тревоги, всё заработало :) Просто я думал, что SAM-BA загрузчик должен активироваться после шага ERASE, а оказывается ERASE просто затирает флэш-память (сюрприз, да :-)). Потом закоротил TEST на 10 секунд и устройство определилось как USB CDC Serial, запустил SAM-BA софт от атмелей и всё загрузилось. Теперь вылезла другая проблема. Когда прошил микроконтроллер, по окончанию операции защитил флэш-память от перезаписи от греха подальше. Теперь при запуске софта (JLinkExe) он пытается обновить прошивку, J-Link зависает напрочь до перевтыкания (но по крайней мере не запарывается). То есть, по сути, пользоваться софтом невозможно т.к. он принудительно пытается обновить прошивку без спроса. Все прошивки 8й версии, которые я скачал, абсолютно идентичны за исключением копирайта, серийного номера и списка включённых опций. Есть ли прошивки для v8 более свежие, чем 2009 года? И ещё, есть ли возможность обратно активировать загрузчик SAM-BA? Он теперь опять напрочь отказывается реагировать на ERASE, подозреваю, это оттого что я заблокировал флэш-память?

Вопрос такой. Купил в Китай один из вариантов J-Link v8 на AT91SAM7S64AU. Ровно такой же, какой описан в этой статье. Скачал SEGGER'овский софт под Линукс и запустил. Он, зараза, сразу ничего не спросив, первым делом проапгрейдил прошивку до декабрьской прошлого года. После этого адаптер издох, не успев принести никакой пользы :crying:. Курил всю ночь эту тему, нашёл даже видео где чувак на чисто китайском языке показывает как восстанавливается прошивка на таком программаторе. Увы и ах, ничего не помогает. Закорачиваю пинцетом ERASE на VCC (там рядышком два специальных отверстия в плате, подозреваю там изначально должен был быть 2-pin header, но китайцы сэкономили). Держал целую минуту, ничего не помогает. При подключении устройства к USB порту в журнале ядра идут ошибки, устройство никак не отзывается. Посмотрел осциллографом на конденсаторах рядом с кварцем - никаких следов жизни. Ну не верю я, что микроконтроллер сгорел вот так вот на ровном месте, после программного обновления прошивки. К сожалению, с такими микроконтроллерами никогда не имел дела, поэтому понятия не имею что может быть не так. У STM32, например, пока кварц программно не запустишь он так и стоит мёртвый. Изначально запуск идёт на встроенном RC генераторе. Может и здесь то же самое, но прошивка криво встала и не запускает кварц. Есть у кого-нибудь опыт восстановления подобных адаптеров? Есть ещё в наличии JTAG программатор, который встроен в отладочную плату STM32Discovery. Хочу им попробовать, но в китайском мануале по восстановлению прошивки через JTAG всё равно сказано, что первым делом надо сбросить загрузчик закорачиванием ERASE на VCC, а у меня данная операция не проходит. Это китайцы врут, надеюсь?

Всем привет! Набрёл на таобао на схему китайского клона J-Link v9 на STM32F2, прочитал тему довольно внимательно но такой не видел. Может кому сгодится. Большой разницы относительно v8 не вижу, только вместо одного большого конвертера уровней используется куча мелких.