ATtiny26 (ATtiny2313 кроме fuse!!!)

а что с фузами ?

Fuse bits у tiny26 и tiny2313 не совпадают побитно, за исключением самого младшего байта. Однако AVRProg не пишет fuse побайтно, а скидывает все в МК после нажатия кнопки Write, соответсвтенно я бы не рисковал менять fuse bits. Между тем размер страницы памяти программ у tiny26 и tiny2313 совпадает, поэтому производить запись/чтение FLASH&EEPROM можно безболезненно, так как AVRProg НЕ АВТОДЕТЕКТИРУЕТ ЧИП!!! Ребята из ATMEL придумывают хорошие кремниевые штучки, но вот бригаду программистов, которая отвечает за soft support я бы послал к той самой матери...

Да забудьте вы про AVRProg - возьмите AVROSP (AVR911). Там нет этих проблем, все читается и пишется, описания чипов берутся из XML от самой свежей AVRStudio.


Если говорить о соответствии стандартам, то со стороны хоста не должно быть напряжения выше напряжения стабилизации диодов Зенера. Потому проблема есть только со стороны МК, и она действительно решается.

С другой стороны, USB устройство (как хост, так и device) обязаны выдерживать замыкание любых ног разъема в любых сочетаниях произвольное время. Как плюс на минус, так и сигнальных ног на любую из ног питания. Этому соответствуют очень далеко не все хосты (хабы и особенно материнки), которые горят по перегрузке по току.

Так что всё очень относительно, и если оно работает - можно не париться особо сильно, тем более, если устройство питается от самого USB.

Вы сами себе противоречите по поводу диодов, раз говорите что "... Этому соответствуют очень далеко не все хосты (хабы и особенно материнки), которые горят по перегрузке по току ...", К тому же ИМХО диоды Зенера, или попросту стабилитроны, все-таки имеют емкость, и ставить их параллельно линиям данных я бы не стал, тем паче что в AVRProg нет никакого контроля данных, а если к этому прибавить то, что в драйвере USB нет контроля достоверности данных (CRC), так вообще поле чудес может получиться, хотя у меня вся девайс уже скоро месяц, как нормально работает, при том что рядом куча заводов, фабрик и пароходов)))



По поводу AVRProg, как морально устарелого продукта, я с Вами согласен, но это был просто небольшой эксперимент c драйвером от Obdev, к тому же это мой первый (и скорее всего последний) опыт работы с AVR910... Переделать же все это в STK500ISP нет проблем ни каких, и я, со временем, переделаю, конечно, свое детище под STK500. Все же, ИМХО, изначально, что AVRProg, что STK500, принципиально "не правильные" продукты с точки зрения пользователя. Команды обоих изначально ориентированны только на использование с AVR. А мне видилосьчто то похожее на PONIPROG, который ориентирован на работу со всеми девайсами, имеющими хоть что то похожее на SPI. По идее так и должно быть - Чапай должен знать, как одолеть противника, а Петька просто пулеметчик. Сдесь же немного другая картина - и хост НЕМНОГО интелектуальный, и программатор тоже что то там свое соображает, хотя думать должна только программа, и она же должна знать и диктовать алгоритм программирования, а программатор только выполнять примитивные команды.

В ломы, конечно, писать универсальную программу схожую с PONIPROG, но можно попробовать...Хотя опять кто нибудь скажет, что этого [email="го@на"]го@на[/email] полным полно в сети...

Я не противоречу, а утверждаю, что у нас уже более чем достаточно несоответствий стандартам как программной, так и аппаратной части. Одним больше или меньше... Поэтому пытаться сделать максимально корректно любительскую конструкцию не слишком частого применения, как минимум, не всегда имеет смысл. Я предпочитаю зашить один раз boot loader, а потом работать через него. Это удобно во всех отношениях, в том числе, не нужен больше программатор. А в качестве интерфейса использую либо USB (если оный есть на устройстве), либо UART, для которого имею USB-to-UART конвертор, собранный в USB разъеме на CP2101.


Опять же, мы работаем на уровне "должно вроде бы работать". Устройство low speed, потому сильно мешать не должно.


В том и вопрос, что это - цена дешевой программной реализации. И, "как правило", должна (но не обязана) работать. А насчет поля чудес - для этого нормальный программатор умеет выполнять верификацию записанного. Не идеальный выход, но лучше, чем ничего.


Мне почему-то кажется, что тем, кому нужна максимальная универсальность, могут купить готовый программатор. Или собрать PonyProg. Потому лично меня этот топик больше интересует с точки зрения boot loader'ов и их интерфейсов, а в этом смысле универсальность программатора не имеет смысла.

Кстати, по поводу бутлоадера. Так и не смог я втиснуть в одно килослово USB драйвер и хотя бы малую толику программатора. В связи с этим есть идея - если, допустим, загрузчик держать в верхних адресах, но его код будет, к примеру, два килослова. Смогу ли я таким кодом прошивать нижние два килослова памяти программ МК? Конечно, функции записи-чтения памяти программ будут находится в области boot памяти программ МК.

По поводу бутлоадера... идею кину... установить на плате программатора еепром 24ХХ и заливать новую прошивку через USB в эту еепром, а затем каким либо способом запустить бутлоадер, который зашъет контроллер из еепром - таким образом не надо будет делать бутлоадер на USB который не помещается в 1к памяти, а надо сделать бутлоадер для I2C который поместится и в 512, я думаю. И еще одно преимущество при таком способе прошивки - можно менять код самого драйвера USB от obdev

Идея понятна, но дело в том, что USB постоянно должен обслуживать прерывания. На время записи их нужно запрещать, но на минимальное время. Не запрещать их нельзя, так как во время записи область приложения блокирована даже на чтение. Возможно, реально-таки так скомпоновать все, чтобы вынести интерфейс программатора в apps область, и не пользовать его во время записи (а USB драйвер пусть себе прерывается, лишь бы не попасть на интерфейсный запрос).

Но тут есть существенный минус: мы не сможем защитить при этом область загрузчика от непреднамеренного стирания фьюзом. Потому смысла в такой реализации я уже не вижу, увы. А если извращаться с EEPROM, то, возможно, будет проще поставить простейший аппаратный USB. Ведь по USB надо ту прошивку даже в EEPROM еще залить, а загрузчик должен быть защищен от стирания (иначе это не загрузчик). Значит.... весь код USB должен помещаться в том же boot-блоке. А пишет он в EEPROM или прямо в область приложения - вопрос уже второй.

Проще тогда уж использовать реализацию загрузчика через usblib, и написать интерфейс между ним и программатором в виде драйвера виртуального COM-порта. Или писать свой лоадер со стороны PC. Криво все это.

Ага, а во время заливки драйвера дадим РС отмашку релюшкой - обождите дяденька - я писаю...

Если бы все было так просто... После чтения по USB кода в EEPROM элементарно или запретить прерывания по USB (устройство потеряется), или, что куда лучше, использовать usbDeviceDisconnect() для такой цели (цена вопроса - один пин ввода-вывода). Последний использую я (с моей подачи он и появился в драйвере), отключая устройство, а потом вновь включая. В этом случае можно и код USB переписать.

Но проблема-то в другом: даже если исключить проблемы с RWW/NRWW областями, загрузчик обязан вмещаться в защищенную область памяти. Иначе это не загрузчик, и совершенно случайно будет стерта та часть, без которой реанимировать девайс можно будет только программатором. Это не серьезно.

Имеется ввиду область страницы в которую производится запись, или вся область ниже бутблока?

По поводу перепрошивки... сперва заливаем новую прошивку во внешнюю еепром, затем надо сделать ребут контроллера, бутлоадер I2C перехватывает управление и шьет контроллер, при этом USB работать не будет и и на прерывание int0 ему будет плевать, после завершения прошивки контроллера, снова ребутим его и управление передается новой прошивке, которая восстанавливает соединение по USB, а для переключения на бутлоадер и обратно можно использовать какой то признак, например во внутреннем еепром выделить байт под это. Но это просто идея представленная мною на всеобщее обозрение. Ж

Это понятно, я иронизировал)

для решения проблемы с неверной прошивкой можно еще сделать бэкап текущей прошивки в ту же еепром, просто надо будет использовать еепром не на 8к, а на 16к и выбор загружаемой прошивки сделать тоже по кикому-нибудь признаку, тот же байт в еепром или джампер

А на хосте в это время революция, и драйвер CDC слетает так, что без нажатия на волшебную кнопку устройство больше не видится...

Имеется в виду, что при записи вся NRWW область блокируется на запись и чтение. То есть, какую бы страницу памяти приложения мы не писали, вся область RWW блокируется на чтение, и исполнять в ней код нельзя. После операций записи обязательно нужно выполнить разблокировку этой области посредством RWWSRE: Read-While-Write Section Read Enable.

Дополнительная особенность в том, что границы области boot и RWW/NRWW секций в общем случае не совпадают (похоже, границы совпадают при выборе максимального размера бут-блока).

Мдя...Об этом я читал в даташитах, но была надежда, что я непонял чуждый мне язык, оказывается понял...

Это - решение проблемы средствами, куда более серьезными, чем сама проблема. Если речь идет об устройстве, где это столько важно - начиная с меги32 все решается прозрачно - там размера бут-блока хватает вполне.



А я еще и практически проверил, когда после записи блока верификация у меня не считалась правильно CRC. Ибо, с той области читается не то, что там есть на самом деле (что - не выяснял).

Я кстати никак не пойму из доки на Mega48/88/168 как дела обстоят с собственно 48. RWW у нее по доке нет, т.е. получается что мы можем писать любую страницу, продолжая дальше выполнять код ?
Хотя в другом месте пишется что MCU Halted.

2 osnwt

Олег, вопрос про АES. А его нельзя вынести из бут блока ? Мы же шьем страницами ? Почему тогда нельзя получит криптованую страницу, раскриптовать ее в память и потом шить. ? После раскриптовки движок дешифрования же уже нам не нужен ?

Так в том и дело, что нет RWW. Есть NRWW - она же и бут. То есть, в ней запись возможна исключительно с остановкой CPU на время операции записи. Области RWW (из которой можно читать во время записи - то есть, исполнять программу или читать вектор прерывания) как раз и не хватает. Так что в доке всё правильно - и малоприемлемо для нас.


Можно без проблем. А смысл? Как я уже писал, по моему мнению, boot блок должен быть способен после любого затирания application area обеспечить возможность ее зашивки. То есть, не должно быть никаких кусков кода в application area, на которые мы полагаемся при перешивке. Всякие методы записи того же самого блока, или просто незатрагивания куска application, где что-то находится, не годятся, так как рано или поздно ошибка случится, и этот кусок погибнет -> программатор потребуется. Если речь о серийном изделии - это неприемлемо. Если о штучном для внутреннего потребления - приемлемо, но проще тогда просто сделать бут, работающий по serial, и к нему UART-to-USB шнурок, один на все свои игрушки. И им пользоваться.

Был бы смысл, если бы можно было загрузчиком загрузить нечто в RAM, откуда и исполнять. Тогда да - можно было бы вынести код декриптора в RAM (сохранив ключи во FLASH). Но в контроллере гарвардской архитектуры это не сработает, в отличие от того же MSP430. И, кроме того, AES - это один килобайт, а кроме него - все равно еще 3. Даже в моем буте можно определить количество ключей в 0 и получить загрузчик без шифрования. Но все равно при сложном протоколе загрузки в 2 кило оно не влезет. А если не пугаться драйвера libusb и собственного загрузчика на PC - так такой бут уже есть, и он влезает в мегу8.

Да...За загрузчиком не получается - факт. Однако, для программатора это не слишком страшно, если контроллер в DIP корпусе))) Это ж программатор!!! Правда, есть необходимость иметь под рукой запасного игрока в виде Меги8) Выход не совсем удачный за то практичный.)))

Сдесь могу поспорить - не сработает ТОЛЬКО в AVR, потому как, во первых, память программ и память данных (SRAM) разной разрядности, и , во вторых, нет возможности подвесить внешнюю память программ, в следствии первой причины. От этого недостатка свободны контроллеры mcs51, у которых есть возможность расширять память программ путем навески внешней микросхемы ROM. Никто же не мешает вместо ROM подцепить RAM, и путем некоторой манипуляции с линиями управления исполнить код в этой самой RAM. Но это так, теоретически, хотя практически я так еще в универе делал, а подсмотрел все это на стенде с ADuCххх.



Кстати, хочу попробовать ввести CRC для приема данных от хоста - все таки не нравится мне, что целостность данных не контролируется. Проверить CRC можно и после приема, когда драйвер передаст управление прикладному ПО МК, но ведь он уже послал ACK! Я посмотрел, как формируется CRC для пакетов к хосту - довольно медленный классический алгоритм. А что, если проверять CRC входящих пакетов табличным методом? Это на порядок, ИМХО, быстрее бы проходило. 2 osnwt возможно ли это?

Скорее, перед оным...


Ну, вообще говоря, как я уже сказал, меня больше всего интересует загрузчик для произвольных разработок. А программатору самому по себе ну зачем бут вообще? Раз зашил - если нет аппаратной завязки на кристаллы, то едва ли понадобится его перешивать.


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


У адуков есть есть одна интересная фича: в режиме отладки софта есть аппаратная подмена содержимого адреса памяти команд на команду остановки. В результате не приходится переписывать flash для пошаговой отладки, как в AVR и debugWire. Ну чего там стоило сделать то же самое - нет, проще сказать, что "не используйте кристаллы после отладки в серийной продукции" :-) Но это так, к слову...


Таблица довольно большая, видимо, потому это и не было сделано. Хотя я не помню уже, где именно, но я читал, что с времянками есть проблемы, и там достаточно мало тактов на своевременный ответ хосту. То ли на сайте, то ли в личной переписке с автором. Так что не уверен, что можно - уже бы сделали.

Да, что то было про CRC, по моему, даже на этом форуме. Буду пробовать, таблица не такая уж и большая, 256 килослов всего...Флэша еще море) . Кстати, не подскажете, как таблицу сгенерить?

Не подскажу, но автору драйвера вопрос задал :-) Будет ответ - поделюсь.

Неплохое руководство по CRC. Описана реализация как прямого так и табличного алгоритма wasm.ru/docs/5/crc.zip.

Сенька вери-вери мачч))) Прям в десятку)

Но радоваться рано.

По информации от автора драйвера, реализация алгоритма однобитовым способом была выбрана из соображений минимального размера кода. Табличный метод с 16-байтной таблицей едва ли будет существенно быстрее по причине не слишком простой адресации flash в AVR. Вариант с 256-байтной таблицей может быть и лучше, но вот (дословно):


Так что, полагаю, вопрос закрыт.

ладно, глянем, что получится... Меня CRC интересует теперь по следующим соображениям: Так как вариант с бутом зарезан окончательно, есть море памяти. Табличный способ формирования CRC явно выгоднее по скоростным характеристикам, для меня это существенный плюс. Я и так повысил скорость программатора, об этом говорят те, кто его уже успел собрать. Все же хочется найти способ проверки CRC входящих пакетов, т.к. это повысит надежность, и откроет двери для применения драйвера не только в радиолюбительких поделках...

С точки зрения Профессионалов (а не китайских инженеров) это все равно не вариант для серийной продукции. А с точки зрения моей - лично я никогда бы не полагался на то, что любой канал данных, будь то обычный UART или USB, будет error-free. Я бы все равно проверял достоверность того, что мы получаем. В применении программатора со стандартной оболочкой такое средство - верификация прошивки. В применении со своим собственным протоколом обмена - это верификация на уровне приложения с перезапросом пакетов, пришедших со сбоем.

Так что очень серьезных проблем в оговоренных рамках не вижу.

Но всё равно - удачи! Чем чёрт не шутит...

По поводу Професcионалов и Кытайцев: Приходится иногда сталкиваться с такими чудами, рыжими да конопатыми, да толстомордыми, да вумными во всем, о чем мы говорим, но - выпускающими серийные изделия - что кытайцы отдыхают... Если прошитый контроллер внешне будет полностью соответствовать спецификации USB для хоста, и достоверно переваривать данные в обе стороны (USB - функция), чем он будет отличаться от аналогичных по функциональности специализированных МС?

Спасибо! А то я сам уже свою тему потерял)

2 prottos вопрос может не по существу но всеже спрошу, Если замкнуть перемычкой сразу все три контакта, програмотор будет шиться? имеется виду перемычка для переключения ресета.

Шиться программатор будет, а работать как программатор нет. В принципе, перемычку J2 можно исключить, замкнув ее накоротко, оставив только J1 для аппаратного сброса по RESET.

Кстати, как работается на программаторе, если Вы его собрали, какие кристаллы пробовали программировать?

Вот и я подума что если вообще исключить J2 а котда надо сменить прошиву замыкать J1, кстати по той схеме какую я приводил раньше не заработало вот теперь переделываю. (поспешил и сам посмеялся).

и еще вопрос а можноли еще и транслятор USB в RS 232 туда добавить, вообще класнобы получилось чтоб отладку по принтф можно было делать.

Я не понял, схема которая со стабилитронами?



Если использовать полностью совместимый интерфейс с AVRProg b совместимых с ней программ, то нет. Если же ввести команды для перевода девайса в режим COM-порта, то да. Но для этого надо будет написать отдельную программку-арбитр , которая будет переводить программатор в режим последовательного порта...Геморно все это, лучше уж иметь отдельный переходник USB-RS232...

Да именно эта схема. Да имеено так как с арбитром. А там она по месту поместиться ????

А кто то спорил, что со стабилитронами все отлично будет работать)

Легко

не не я не спорил просто спросил знающих людей. и кстати шиться при питалове 3.5 он отказывался, а вот когда 4 и выше все ок, может из за того что мега не L.

а может не загоняться с арбитром, может юзануть PD 5 для выбора програмер или транслятор.

Следующий текст может звучать нагловато: может поделитесь сурцом ? может я что накропаю в эту сторону я думаю этой функции все обрадуються а особенно я, так как айс соберать неохота. потомучто нечем большим пока незанимался.

Вот еще вопрос, сейчас глянул, к буку подключен USB видео ввод потребление 350 мА. что натолкнуло на мысль юзать питалово от USB для таргета, в следствие чего было решено всеже поставить предохранитель но не простой а самовостонавливающийся, знающие люди подскажите какой доставабельный С.В. предохранитель туда можно поставить.

Насколько я понял, в программаторе от ObDev сделана эмуляция со стороны PC двух независимых COM-портов. Одни управляет программатором, который далее шьет target через SPI. Второй независимо от первого поддерживает отладочный вывод, который target может выводить через свой UART, подключенный к UART'у кристалла программатора, трансилируемый на второй виртуальный (CDC) COM порт. Только там поддержан только вывод (по схеме, по софту не смотрел), а надо поддержать и ввод. И получится именно то, что нужно.

Странно, я несколько штук попробовал, все шьются. Конечно, все они из одной партии...Шил PoniProg + STK200...Может быть дело в программаторе, которым Вы зашивали МК? При программировании при пониженном напряжении задержки при записи во FLASH увеличиваются... Я тоже об этом подумал, когда ответил... Сырцы я, пока, раздавать не намерен...

Получается, что на одном физическом устройстве можно эмулировать несколько последовательных портов, я правильно Вас понял? Я, признаться, как то об этом не думал) Хотя сейчас подумал - у моего модема (в диспетчере устройств) аж четыре COM-порта, а USB шнурок то один...Это интересно...



Кстати, по поводу AVROSP, о котором говорилось выше. Программатор мой он видит (в новой версии прошивки, которую еще не выложил), но ни как немогу считать или записать в/из МК - пишет "Error opening HEX file for output!". А так все нормально - читает сигнатуру, фьюзы и в, общем, выполняет все операции не связанные с файловым вводом-выводом.



Еще один трабл с AVRDUDE. При работе с ним, программатор зависал. При мониторинге порта оказалось, что после команды SetLED AVRDUDE не посылает данные (какие биты включать), а программатор эти биты ждет. Когда же я переписал функцию SetLED, так, что бы она игнорировала вслед идущий байт, все заработало. Но у AVRDUDE по сравнению с AVRProg явный минус, он не посылает/принимает данные блочно, тем самым программирование МК с 8к флэша с верификацией проходит более чем за 2 минуты(

RXE, TR

Ага :-)


Хех, этот трабл лично проходил при попытке им работать с AT90PWM3. Была та же беда, но причина оказалась прозрачной.

Объясняю: AVROSP для работы с любым типом кристалла хочет открыть найденный по PATH XML файл с описанием. После этого он выкидывает из него всё, для него несущественное, и записывает новый файл в собственный кэш в текущий каталог - под тем же именем, что и оригинальный файл. Если положить большой оригинальный XML прямо к нему, то он попытается его открыть на чтение, и его же открыть отдельно на запись - что ему и не удается. А если файл уже урезанный (кешированный), то его перезаписи не происходит.

Итого, решение в моем случае такое:

@echo off
set PATH=%PATH%;.\xml
avrosp.exe -cCOM1 -dAT90PWM3 %*

В ./xml лежат оригиналы, а в текущий каталог идет кешированная копия.

Спасибо, заработало, но - опять то же эффект, что и с AVRDUDE - девайс программируется в обычном режиме, т.е программа посылает адрес слова, ждет ответа ACK(0x0D), посылает слово, ждет ответа и т.д. Нет блочного режима, что есть в AVRProg, которая при старте запрашивает, есть ли блочный режим и размер блока. Мой программатор посылает ей в ответ размер блока 32768 байт (на большее число программа реагирует, как нет блочного режима). При программировании AVRProg посылает в СОМ-порт весь дамп памяти. И ждет подтверждения записи. Т.е. все проходит очень быстро. Вот такие дела

Ну это типо можно надеяться, на то что в дальнейшем, такая функция появиться ? и если я правильно понемаю то вывод будет через родной RX TX ?

Не знаю, если и будет, то не в этой конструкции и не в ближайшее время, т.к. в данный момент занимаюсь совершенно другим делом, наверное до следующего моего отпуска...)))

Вообщем, жизнь заставила обратить внимание на сей девайс (шил все время байтбластер+авреал, да только почему-то на испытаниях стал шить только в 20% случаев, толи ноутбук новый гонит, толи биополя в центре сертификации такие ).

Собрал, М128 шьет. Ну уже радость, попробую его на выезде (дай бог чтобы не пришлось )

Хотелось бы пару просьб.

1. Организовать на каком нибудь Output Compare меандр с частотой Fspi/4...8 для прошивки процов со слетевшими фузами, определяющими Clock Source.
2. Более глобальная вещь - доделать его чуток, чтобы он умел 8-милапые кристаллы шить с High Voltage, т.к. именно на 8pin вечная борьба за выводы, в результате - нужен HV.




Может есть смысл подумать над переведением проекта в категорию OpenSource?

Спасибо, что обратили внимание на мой девайс))) Кстати, добавлю про М128 на страницу, а то многие пишут - типа "...сенькс, круто, спасибо, с меня пиво...", но мало кто говорит, на каких камнях он все это обкатывал...Кстати у одного парня были проблемы с резисторм R10 (по схеме на странице), номиналом 1 кОм, после замены оного на 330 Ом проблемы исчезли...Хотя схему я обкатывал на разных машинах, у меня проблем не наблюдалось...Может быть поможет. Один писал про проблемы из под Win2000 - плохая связь (искажение данных) - у меня пока нет времени испытывать устройство под другими ОС, пока на всех машинах, к коим у меня есть доступ, стоит WinXP разных сервиспаков. Вообще, по моим подсчетам, девайс собрало около трех сотен народу (это по количеству тех, кто мне написал) Из них у троих были траблы о которых я написал выше...Вот такие пока дела...


Я об этом сам думал, наверное заведу такой сигнал на контакт LED ISP разъема...
Мне, честно говоря, ни разу не приходилось работать не то что с HV, даже с просто с 8-пиновыми контроллерами. И, скорее всего, это уже будет не ISP программатор... Может быть вам обратить свой взор на AVRDoper c http://obdev.at ?

Кстати, там как раз OpenSource)

Если вас не затруднит то добавьте генератор меандра побыстрей. Хочу сделать ваш программтор. У меня на ноуте win2000 - заодно и потестирую.