USB programmer AVR910, с драйвером от obdev Опции

[prottoss]

Наваял тут программатор USB, совместимый по командам с AVR910 ISP Programmer. Довольно шустро работает и не надо драйверов, т.к CDC-класс... Если кто повторит, интересно почитать мнение

[m16]

Наваял тут программатор USB, совместимый по командам с AVR910 ISP Programmer. Довольно шустро работает и не надо драйверов, т.к CDC-класс... Если кто повторит, интересно почитать мнение

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

[prottoss]

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

Будет время, сделаю и STK500 на той же основе. Это мое первое знакомство с AVR910. Все время, пока я знаком с микроконтроллерами AVR, прошивал их с помощью самодельного STK200 на 555АП5, так как все (2) СОМ-заняты. Тут, в отпуске, решил повозиться с ПЛИС, а ей нужен байтбластер через ЛПТ, вот и решил сваять AVR910 ака USB - для дома пойдет. Правда, пришлось повозится с ассемблерным исходником AVR910 и перевести немного на Си, да полопатить даташиты на старые контроллеры , кстати 90S1200 пока мой программатор не поддерживает.На днях доделаю. Кстати, у STK500 схожий набор команд?

[Petka]

Тут, в отпуске, решил повозиться с ПЛИС, а ей нужен байтбластер через ЛПТ, вот и решил сваять AVR910 ака USB - для дома пойдет.

Если Вы собрали байтбластер, то зачем тогда какой-либо другой программатор АВРок? =) AVReal прекрасно шьёт AVR как через STK200 так и через ByteBluster'ы. Надеюсь труд будет ненапрасным =)

[prottoss]

Тут, в отпуске, решил повозиться с ПЛИС, а ей нужен байтбластер через ЛПТ, вот и решил сваять AVR910 ака USB - для дома пойдет.

Если Вы собрали байтбластер, то зачем тогда какой-либо другой программатор АВРок? =) AVReal прекрасно шьёт AVR как через STK200 так и через ByteBluster'ы. Надеюсь труд будет ненапрасным =)

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

ЛПТ у мя один, вот и решил STK200 переделать в байтбластер, а вместо оного применить собственный вышеупомянутый девайс на USB. Хотя теперь уже возникла идея и байтбластер на USB перекинуть...

[Petka]

Тут, в отпуске, решил повозиться с ПЛИС, а ей нужен байтбластер через ЛПТ, вот и решил сваять AVR910 ака USB - для дома пойдет.

Если Вы собрали байтбластер, то зачем тогда какой-либо другой программатор АВРок? =) AVReal прекрасно шьёт AVR как через STK200 так и через ByteBluster'ы. Надеюсь труд будет ненапрасным =)

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

ЛПТ у мя один, вот и решил STK200 переделать в байтбластер, а вместо оного применить собственный вышеупомянутый девайс на USB. Хотя теперь уже возникла идея и байтбластер на USB перекинуть...

Таки Вы и не поняли мою мысль. Если переделаете stk200 в bytebluster, переделанный девайс не потеряет возможность программировать AVR!

[shevek]

Вот вам и USB программатор на протоколе stk500.
http://www.tuxgraphics.org/electronics/200...icle05101.shtml

НА мой взгляд программторов сейчас разных как грязи, почти столько же как операционных систем.

[prottoss]

Таки Вы и не поняли мою мысль. Если переделаете stk200 в bytebluster, переделанный девайс не потеряет возможность программировать AVR!

Да все я понял....Ну не нравится мне командная строка AVReal...Это одно. Я в отпуске, и захотелось посмотреть, что такое программный USB на AVR, это другое.

Сейчас появилась идея извратится и с LPT по тому же принципу

[prottoss]

Вот вам и USB программатор на протоколе stk500.
http://www.tuxgraphics.org/electronics/200...icle05101.shtml НА мой взгляд программторов сейчас разных как грязи, почти столько же как операционных систем.

Он сделан на чипе от FTDI. Ничего не имею против данной конторы, но меня более интересует программный USB на AVR. К тому же, ИМХО, производительность оного чипа сомнительна (только давайте не будем опять разжигать в этом топике межнациональный спор, что лучше), и дрова под него ставить надо...Сдесь же все прозрачно и просто.

По поводу программаторов как грязи - согласен....Я же не предлагаю Вам его купить. Я просто показал то, что сделал, всего лишь.

Я ожидал, конечно, что будут более интересные вопросы, но, похоже я ошибся...

[Petka]

Таки Вы и не поняли мою мысль. Если переделаете stk200 в bytebluster, переделанный девайс не потеряет возможность программировать AVR!

Да все я понял....Ну не нравится мне командная строка AVReal...Это одно. Я в отпуске, и захотелось посмотреть, что такое программный USB на AVR, это другое.

Сейчас появилась идея извратится и с LPT по тому же принципу

а вот это здраво! ибо ЛПТ потихоньку отмирает, а с ЛПТ эмбеддерам прощаться очень уж не хочется... может действительно сделать USB->LPT, и соответствующий драйвер dlportio для этой приблуды...

[prottoss]

а вот это здраво! ибо ЛПТ потихоньку отмирает, а с ЛПТ эмбеддерам прощаться очень уж не хочется... может действительно сделать USB->LPT, и соответствующий драйвер dlportio для этой приблуды...

А зачем драйвер? Я, правда, еще не вдавался в подробности CDC USB, но, по идее, он должен поддерживать и LPT через Win32 API

[aaarrr]

Я, правда, еще не вдавался в подробности CDC USB, но, по идее, он должен поддерживать и LPT через Win32 API

Нет, не будет. Он и COM поддерживает почти случайно.

[prottoss]

Я, правда, еще не вдавался в подробности CDC USB, но, по идее, он должен поддерживать и LPT через Win32 API

Нет, не будет. Он и COM поддерживает почти случайно.

ЖАль, еще есть Printer Class, может с ним что сварганить можно?

[aaarrr]

И с ним нельзя. Слишком далек он от "железа".

[prottoss]

И с ним нельзя. Слишком далек он от "железа".

А всевозможные переходники USB-LPT получается со своими дровами идут?

[aaarrr]

А всевозможные переходники USB-LPT получается со своими дровами идут?

Угу. И всякий программаторный софт с ними не очень дружит.

ИМХО, LPT, в отличие от COM'а умрет достаточно быстро и безболезненно, и
создавать такие переходники нецелесообразно.

[oll]

Я бы хотел выразить благодарность автору. Использую 910 на ком порт - на ноутбуке один ком порт и постоянно приходится перетыкать шнурок. С USB будет удобно. И вопрос работает ли Ваш USB AVR910 с Codevision программой для программатора и с программой avrdude.

[prottoss]

Я бы хотел выразить благодарность автору. Использую 910 на ком порт - на ноутбуке один ком порт и постоянно приходится перетыкать шнурок. С USB будет удобно. И вопрос работает ли Ваш USB AVR910 с Codevision программой для программатора и с программой avrdude.

Спасибо за благодарность!))) Моя девайсина работает со всеми программами, которые видят AVR910 ISP, так как протокол один в один. Единственно - AVRProg, когда я его мониторил, обращался только к портам COM1 и COM2, а так как в моем компе оба СОМ-а заняты, и под модемы и всякие другие шелезяки зарезервированно СОМ портов аж до 9, естественно AVRProg его не увидел. Пришлось в ручную одному физическому порту присвоить имя СОМ10, а моему программатору соответсвенно СОМ2, после этого все пошло как по маслу

[invertor79]

Я бы хотел выразить благодарность автору. Использую 910 на ком порт - на ноутбуке один ком порт и постоянно приходится перетыкать шнурок. С USB будет удобно. И вопрос работает ли Ваш USB AVR910 с Codevision программой для программатора и с программой avrdude.

Полностью присоединяюсь по той-же причине - наиполезнейшая весчь! Спасибо автору!

[osnwt]

имхо если что-то и ваять для авров то лучше клона STK500 на сегодняшний день нет

Возможно, не совсем в тему, но меня интересует вариант USB boot loader'а (а не программатора). Есть несколько вариантов, но вариант STK500 и CDC поверх USB был бы очень приятен. Свой USB boot я сделал, но он - HID со своим протоколом, что выглядит неинтересным. Я выложил тот проект в свободный доступ на сайте AVR-USB, но развивать его бросил, так как нужда писать нестандартный софт со стороны PC меня напрягает (я не люблю писать под PC).

Вопрос же такой: а что со стороны Windows поддерживает этот протокол (STK500)? Хотелось бы иметь ПО, позволяющее как красиво ставить галочки на фьюзы и пр., так и использовать полностью пакетный режим. Я просто с STK500 не сталкивался, потому не в курсе дела, какой софт поддерживает этот протокол.

Нельзя ли тут ткнуть пальцем в минимальный список (AVR Studio, думаю, будет первым, но я его не исталлировал даже, так как пользую IAR). Есть еще что-то?

[aaarrr]

Возможно, не совсем в тему, но меня интересует вариант USB boot loader'а (а не программатора). Есть несколько вариантов, но вариант STK500 и CDC поверх USB был бы очень приятен.

А какая связь между STK500 и bootloader'ом?

Делал я в свое время клон STK500 + PICSTART+ на ATmega16 и PDIUSBD12. Прошивка обновлялась как раз при помощи своего USB CDC bootloader'а. К сожалению, проект пришлось забросить по причине острого недостатка времени...

[prottoss]

Возможно, не совсем в тему, но меня интересует вариант USB boot loader'а (а не программатора). Есть несколько вариантов, но вариант STK500 и CDC поверх USB был бы очень приятен. Свой USB boot я сделал, но он - HID со своим протоколом, что выглядит неинтересным. Я выложил тот проект в свободный доступ на сайте AVR-USB, но развивать его бросил, так как нужда писать нестандартный софт со стороны PC меня напрягает (я не люблю писать под PC).

Я сейчас мучаю бутлоадер именно в таком плане, но пока напряг с размером бутблока в меге8, а хочется именно на ней сделать свой программатор, так как мега 32 уже дорого выходит. Можно и на ХИД-классе сделать, а под девайс написать свой драйвер, благо опыт небольшой есть, но хочется, чтоб без разных дров все работало. Так что пока безутешно занимаюсь запихиванием в 1 килослово AVR910 и USB obdev

[osnwt]

А какая связь между STK500 и bootloader'ом?

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

В принципе, AVR910 протокол тоже имеет право на существование. К нему есть (для старых девайсов) оболочка AVRPROG (не поддерживающая ни командной строки, ни новых устройств), а также AVRISP, поддерживающий все, что угодно, но не имеющий GUI. И на этом всё. Предполагается, что более популярные протоколы дают больший выбор.

Можно и на ХИД-классе сделать, а под девайс написать свой драйвер, благо опыт небольшой есть, но хочется, чтоб без разных дров все работало. Так что пока безутешно занимаюсь запихиванием в 1 килослово AVR910 и USB obdev

Были такие идеи и у меня, но до реализации ход не дошел. Вероятно, можно попробовать просто переписать кусок драйвера на ассемблере, и на нем же - все остальное. Тогда должно поместиться. Работа, правда, будет серьезная, хотя и в значительной степени механическая. А бут в меге8 - это ведь не только в меге8 - это, например, в AT90PWM3, где такой интерфейс был бы очень полезен для определенных применений. Потому мне тоже интересна эта тема, но кроме асма я пока не вижу альтернативы. Есть, конечно, готовый бут для всех мег (в т.ч. 8-й) на том же сайте, но он требует установки драйвера. Это существенный минус. Так что удачи!

[prottoss]

Были такие идеи и у меня, но до реализации ход не дошел. Вероятно, можно попробовать просто переписать кусок драйвера на ассемблере, и на нем же - все остальное. Тогда должно поместиться. Работа, правда, будет серьезная, хотя и в значительной степени механическая. А бут в меге8 - это ведь не только в меге8 - это, например, в AT90PWM3, где такой интерфейс был бы очень полезен для определенных применений. Потому мне тоже интересна эта тема, но кроме асма я пока не вижу альтернативы. Есть, конечно, готовый бут для всех мег (в т.ч. 8-й) на том же сайте, но он требует установки драйвера. Это существенный минус. Так что удачи!

В том то и дело, что хочется именно на Си реализовать, так как (и я в этом не раз убеждался), на Си проект получается совсем-совсем на чуть-чуть больше, а то и меньше чем оный же на ассемблере, за то выйгрыш в скорости написания проекта неоспоримый. Да и встроить такой код в другой проект плевое дело. Даже взять пример с моим проектом программатора. Сначала я взял код от Igor Cesko где ВСЕ регистры заняты под сам USB драйвер + код AVR910 где ВСЕ регистры заняты под программатор... ужас...подумал я и взял драйвер от Objective Developvent - благое дело, проект задышал на макетке спустя пару часов (час на разборку USB джойстика, дабы поиметь с него шнурок, и на паяние схемы)

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

[osnwt]

ужас...подумал я и взял драйвер от Objective Developvent - благое дело

Это точно что благое дело. Самое удивительное, что автор продолжает активно развивать сей проект. Скажу по секрету, что уже готова версия драйвера с полностью конфигурируемыми USB дескрипторами, каждый из которых может быть во FLASH, в RAM или запрашиваться в run-time вызовом функции. Это дает возможность делать комбинированные устройства, чего мне очень не хватало бы в одном из потенциальных применений. Сам я этот код еще не пробовал (руки не доходят), но по утверждению автора, использованы дополнительные возможности оптимизации компилятора (путем соответствующего написания кода), что эта версия может получаться еще более компактной, чем предыдущие, несмотря на расширение функций. Как только версия пройдет stress testing, я полагаю, она появится и на сайте автора.

[osnwt]

вариант STK500 и CDC поверх USB был бы очень приятен

Ну что за расстройство - стоит только что-то захотеть, а кто-то это уже сделал
Завтра на сайте obdev появится новый проект - программатор для AVR с поддержкой STK500. Поддержан высоковольтный режим программирования, питание от USB, встроенный USB-to-serial конвертор...

Громозека: "Опять я опоздал..."

[prottoss]

вариант STK500 и CDC поверх USB был бы очень приятен

Ну что за расстройство - стоит только что-то захотеть, а кто-то это уже сделал
Завтра на сайте obdev появится новый проект - программатор для AVR с поддержкой STK500. Поддержан высоковольтный режим программирования, питание от USB, встроенный USB-to-serial конвертор...Громозека: "Опять я опоздал..."

Да не расстраивайтесь, всегда можно сделать лучше, чем есть...

[Old1]

...
Завтра на сайте obdev появится новый проект - программатор для AVR с поддержкой STK500. Поддержан высоковольтный режим программирования, питание от USB, встроенный USB-to-serial конвертор...

Громозека: "Опять я опоздал..."

Что-то не видать его...

[prottoss]

Что-то не видать его...

http://www.obdev.at/products/avrusb/avrdoper.html

Однако немного схитрили ребята, я еще пока разбираюсь, но что то там с HIDом завязано, а это похоже, что дрова надо ставить, или я не прав?

[osnwt]

Однако немного схитрили ребята, я еще пока разбираюсь, но что то там с HIDом завязано, а это похоже, что дрова надо ставить, или я не прав?

1) HID хорош как раз тем, что это стандартный класс, для которого свои драйверы не нужны.

Можно и на ХИД-классе сделать, а под девайс написать свой драйвер, благо опыт небольшой есть, но хочется, чтоб без разных дров все работало.

Думал, что это опечатка (и имелся в виду не драйвер, а свой софт уровня приложения), но похоже, что это другое.

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

Альтернативно можно сделать устройство CDC, представленное как стандартный COM порт, например. Для него тоже существует системный стандартный драйвер (к нему необходим уже .inf файл, хотя сам драйвер от Microsoft), но потом с ним может работать любая утилита, например, программатор, понимающая COM порт API.

А свой драйвер надо писать, если устройство не относится ни к какому стандартному классу.

2) Говоря про конкретно AVR-Doper. Стандартным для него является CDC интерфейс, и программатор представлен COM-портом, с которым непосредственно работает весь софт, понимающий STK500 протокол. Драйвер порта при этом используется стандартный.

Альтернативно можно скомпилировать прошивку, поддерживающую собственный протокол через HID. При этом никаких .inf не надо, но пока нет утилиты управления программатором, работающей через HID. Поэтому смысл этого больше теоретический, что понятно, так как проект является образцом (reference) для написания подобных приложений.

[TamTam]

Если не затруднит просветите в чем разница между 910 и STK 500

2 prottoss а когдаже будут светодиоды, уже так хочется собрать в корпус.

[Old1]

Наваял тут программатор USB, совместимый по командам с AVR910 ISP Programmer. Довольно шустро работает и не надо драйверов, т.к CDC-класс... Если кто повторит, интересно почитать мнение

Посмотрел на схему и вижу: Mega8-16, напряжение питания 3,5 В, частота 12 МГц... Как я понял, при таком питании максимальная гарантированная частота 8 Мгц, или я не прав?

[prottoss]

2 prottoss а когдаже будут светодиоды, уже так хочется собрать в корпус.

До конца недели будут точно. Блочный режим уже написан, что подняло скорость программирования примерно раза в 1,5 - 2 (оценивал визуально). SPI работает на четырех фиксированных частотах, в зависимости от тактовой частоты МК - clock/8 ../16.. /32.. /64 в - это для AVR. Для 89S частота будет clock/128

Наваял тут программатор USB, совместимый по командам с AVR910 ISP Programmer. Довольно шустро работает и не надо драйверов, т.к CDC-класс... Если кто повторит, интересно почитать мнение

Посмотрел на схему и вижу: Mega8-16, напряжение питания 3,5 В, частота 12 МГц... Как я понял, при таком питании максимальная гарантированная частота 8 Мгц, или я не прав?

даташит ATmega8 Complete, Раздел ATMega8 Typical Characteristics ->Active Supply Current (Page 247 Figure 119 Active Supply Current vs Frequency (1 - 20 MHz))

[prottoss]

Однако немного схитрили ребята, я еще пока разбираюсь, но что то там с HIDом завязано, а это похоже, что дрова надо ставить, или я не прав?

1) HID хорош как раз тем, что это стандартный класс, для которого свои драйверы не нужны.

Можно и на ХИД-классе сделать, а под девайс написать свой драйвер, благо опыт небольшой есть, но хочется, чтоб без разных дров все работало.

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

Имелось в виду драйвер, который бы выступал в качестве виртуального СОМ-порта, и передавал данные на HID-устройство. Дело в том, что изначально устройство задумывалось, как совместимое со стандартным атмеловским софтом, который и ведать то не ведает про HID, да и из СОМ-портов то только всего два видит...

[osnwt]

Имелось в виду драйвер, который бы выступал в качестве виртуального СОМ-порта, и передавал данные на HID-устройство. Дело в том, что изначально устройство задумывалось, как совместимое со стандартным атмеловским софтом, который и ведать то не ведает про HID, да и из СОМ-портов то только всего два видит...

Значит, в тот раз я понял правильно.
А в этот раз вопрос про драйвер для HID меня сбил с толку. Впрочем, CDC в данном случае выглядит интереснее. Беда лишь одна - он жрет процессорное время AVR (см. описание драйвера). Так что для простых вещей, завязанных на USB, это приемлемо. А вот как побочный интерфейс наряду с основной сложной функциональностью - увы...

[TamTam]

2 prottoss а когдаже будут светодиоды, уже так хочется собрать в корпус.

До конца недели будут точно. Блочный режим уже написан, что подняло скорость программирования примерно раза в 1,5 - 2 (оценивал визуально). SPI работает на четырех фиксированных частотах, в зависимости от тактовой частоты МК - clock/8 ../16.. /32.. /64 в - это для AVR. Для 89S частота будет clock/128

А может есть уже прикидки на каких ножках они будут стоять, а то я уже плату развел.

[prottoss]

Значит, в тот раз я понял правильно.
А в этот раз вопрос про драйвер для HID меня сбил с толку. Впрочем, CDC в данном случае выглядит интереснее. Беда лишь одна - он жрет процессорное время AVR (см. описание драйвера). Так что для простых вещей, завязанных на USB, это приемлемо. А вот как побочный интерфейс наряду с основной сложной функциональностью - увы...

Наверное, немного энтузиастов возьмутся делать на подобном драйвере виртуальный жесткий диск или еще что, требующее большой перекачки данных, но для малых устройств, ИМХО, отличное решение, тем паче на Си. Решающее значение имеет то, что в одном флаконе (корпусе) можно объединить USB и собственно функцию

[TamTam]

Мне вот интересно, насколько реально транслировать, этот драйвер под CODEVISIONAVR ?

[prottoss]

А может есть уже прикидки на каких ножках они будут стоять, а то я уже плату развел.

Спэшл фо ю: т.к. порт В безнадежно занят под ИСП, и как раз на нем два свободных ВВ, то РВ0(запись) и РВ1(чтение)

[osnwt]

Наверное, немного энтузиастов возьмутся делать на подобном драйвере виртуальный жесткий диск или еще что, требующее большой перекачки данных, но для малых устройств, ИМХО, отличное решение, тем паче на Си. Решающее значение имеет то, что в одном флаконе (корпусе) можно объединить USB и собственно функцию

Решение-то отличное, но я же не об этом. А о том (см. документацию на драйвер), что при реализации CDC (и вообще bulk transfer) драйвер будет проводить внутри USB прерываний 90% процессорного времени AVR независимо от того, что он делает, так как хост будет поллить его до посинения. В итоге на собственно функцию останется только 10% времени CPU.

Имея требование обеспечить приоритет USB int0, мы ничего не сможем с этим сделать. Так что про time-critical функции можно легко забыть. Программатору это не критично, как и boot-loader'у, а вот другим применениям - даже очень. Единственным вариантом я вижу или отключать USB устройство, когда оно не нужно (использовать только для конфигурирования или сливания данных, а в остальном - работать автономно). Или не использовать такие интерфейсы, что обидно.

Workaround'а автор пока найти не смог, если это вообще возможно.

Дословно из переписки:

BTW: Bulk endpoints (as they are required for the CDC class) are not as useful as it seemed at first glance. The host polls them at the highest possible rate if there is nothing else to do. This consumes
90% of the AVR's CPU time in the USB interrupt. I have found no workaround for this.

[prottoss]

...при реализации CDC (и вообще bulk transfer) драйвер будет проводить внутри USB прерываний 90% процессорного времени AVR независимо от того, что он делает, так как хост будет поллить его до посинения. В итоге на собственно функцию останется только 10% времени CPU.

И, что ни каких путей управления управляющим потоком (извините за каламбур) нет?

И еще вопрос: bulk transfers могут быть 8, 16, 32, 64 байта..., для низкоскоростных устройств, и для драйвера, в частности, это тоже имеет место?

[osnwt]

И, что ни каких путей управления управляющим потоком (извините за каламбур) нет?

Я не смотрел новый драйвер в этом плане. Но если автор пока путей не видит, то боюсь, что действительно есть проблема. Можно, конечно, просто отвечать на все NAK, но работать при этом мы с USB не сможем.

И еще вопрос: bulk transfers могут быть 8, 16, 32, 64 байта..., для низкоскоростных устройств, и для драйвера, в частности, это тоже имеет место?

Не смотрел, надо смотреть код. Или спросить автора драйвера. Я спрашивать пока не готов, так как не "въезжал" в эту тему пока. Времени нет.

[TamTam]

А может есть уже прикидки на каких ножках они будут стоять, а то я уже плату развел.

Спэшл фо ю: т.к. порт В безнадежно занят под ИСП, и как раз на нем два свободных ВВ, то РВ0(запись) и РВ1(чтение)

Как они должны быть подключены, анодом к мк через резюк или иначе.
Планируется индецировать соединение девайса с USB ?
И как заиметь свежую прошиву, насайте от 15.07.2006

[µµC]

Как они должны быть подключены, анодом к мк через резюк или иначе.
Планируется индецировать соединение девайса с USB ?
И как заиметь свежую прошиву, насайте от 15.07.2006

IMHO, лучше не тратить время на AVR910 программатор когда уже есть STK500 совместимый на полностью аналогичной схеме. AVRProg (AVR910) практически не обновляется, между вер1.37 и вер1.40 несколько лет прошло и будет ли следующая версия не известно.

[prottoss]

Как они должны быть подключены, анодом к мк через резюк или иначе.
Планируется индецировать соединение девайса с USB ?
И как заиметь свежую прошиву, насайте от 15.07.2006

Светодиоды будут подключаться, скорее всего, анодом к МК, катодом через резистор 220 ... 330 Ом на "землю" . Кроме этого, планируется поставить опторазвязку, подключение оптронов по точно такому же принципу. Прошивка будет доступна так же на страничке.

[prottoss]

IMHO, лучше не тратить время на AVR910 программатор когда уже есть STK500 совместимый на полностью аналогичной схеме. AVRProg (AVR910) практически не обновляется, между вер1.37 и вер1.40 несколько лет прошло и будет ли следующая версия не известно.

Кроме AVRProg есть и другие программы, поддерживающие AVR910, кроме того, пока, в пакет AVRStudio программа AVRProg входит. Встроить же в AVR910 высоковольтное программирование плевое дело (но нужно оно, мне, ИМХО для программирования тех чипов, которые нельзя программировать обычным последовательным способом).

Дело каждого, собирать AVR910, STK500, или еще чего

[osnwt]

IMHO, лучше не тратить время на AVR910 программатор когда уже есть STK500 совместимый на полностью аналогичной схеме. AVRProg (AVR910) практически не обновляется, между вер1.37 и вер1.40 несколько лет прошло и будет ли следующая версия не известно.

Известно - не будет. Поскольку AVRProg давно уже заменен на AVROSP - Open-Source Programmer (AVR911). Последний выполнен с открытым исходным текстом и поддерживает работу только из командной строки. Зато он не содержит описания кристаллов, а использует вместо этого XML файлы из AVRStudio. В результате любой новый чип можно шить, скопировав указанные файлы или просто поместив их в PATH. Кстати, у него нет этого ограничения в COM1 или COM2. Можно указывать и другие порты.

Я нашел только одну беду: у него никак не задается скорость в порту. В результате на моих машинах он не видит железа, если перед этим порт не был настроен на требуемую скорость (например, из панели управления или путем запуска AVRProg или любой терминашки).

[prottoss]

Я нашел только одну беду: у него никак не задается скорость в порту. В результате на моих машинах он не видит железа, если перед этим порт не был настроен на требуемую скорость (например, из панели управления или путем запуска AVRProg или любой терминашки).

Если он OpenSource - это не беда, легко ведь добавить нужные ключи, а настройка последовательных портов из Win32 - 10 строк кода...

[TamTam]

2 prottoss ну когдаже будет новая прошива, чтоб светики моргали.

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

Эскизы прикрепленных изображений

 

[prottoss]

2 prottoss ну когдаже будет новая прошива, чтоб светики моргали.
Подскажите посмотрев на организацию схемы USB_STK500, переделал схемку проттоса, но вот вопрпос, будет так работать ?

Может быть в меня счас полетят тапки от матерых электронщиков, но мне не очень нравится схема со стабилитронами. Объясню, почему:

1. Я считаю, что стабилитроны включены правильно только по отношению к МК, т.к. только с его стороны стоят токоограничительные резисторы, это и понятно - для того, чтобы ограничить напряжение сос тороны МК. Со стороны же USB таких резисторов нет, так что, если на шине USB напряжение будет превышать напряжение стабилизации стабилитронов (3,6 вольт), через них может потечь относительно большой ток. Может быть, проблему можно решить включив и со стороны USB резисторы номиналом 22...47 Ом. (???)

2. Стабилитроны имеют емкость, хотя и относительно небольшую, и возможно искажение формы сигнала как со стороны USB, так и со стороны МК.



Хотя, конечно, решение простое, и, так сказать, в лоб, но, ИМХО, не факт что красивое. Опторазвязки в схеме AVRDOPERа тоже нет, что не есть хорошо. Сами понимаете, что в некоторых случаях вы рискуете потерять не только USB порт, но и мамку вашего кремниевого друга. Я же, все таки, остановлюсь, на своей схеме. Правда в место стабилизатора поставлю впослед два диода средней мощности, а разъема ISP развяжу с МК через четыре оптрона, подешевле и побыстрее. Прошива с блочным режимом уже протестированна, скорость, как и ожидалось, возрасла - при записи примерно раза в 1,5 -2, при чтении примерно раз в 5. Схема с диодами и прошива скорее всего (но не факт)будет сегодня. Напрягает больше всего то, что я уже вышел на работу((( и свободного времени резко поубавилось(((((((((( Но эксперименты с проектом я в ближайшее время забрасывать не собираюсьи есть еще кое какие задумки, но об этом пока говорить рано...

[TamTam]

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

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

[prottoss]

ATtiny26 (ATtiny2313 кроме fuse!!!)
а что с фузами ?

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

[osnwt]

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

1. Я считаю, что стабилитроны включены правильно только по отношению к МК, т.к. только с его стороны стоят токоограничительные резисторы, это и понятно - для того, чтобы ограничить напряжение сос тороны МК. Со стороны же USB таких резисторов нет, так что, если на шине USB напряжение будет превышать напряжение стабилизации стабилитронов (3,6 вольт), через них может потечь относительно большой ток. Может быть, проблему можно решить включив и со стороны USB резисторы номиналом 22...47 Ом. (???)

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

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

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

[prottoss]

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

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



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

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

[osnwt]

Вы сами себе противоречите по поводу диодов, раз говорите что "... Этому соответствуют очень далеко не все хосты (хабы и особенно материнки), которые горят по перегрузке по току ..."

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

К тому же ИМХО диоды Зенера, или попросту стабилитроны, все-таки имеют емкость, и ставить их параллельно линиям данных я бы не стал

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

тем паче что в AVRProg нет никакого контроля данных, а если к этому прибавить то, что в драйвере USB нет контроля достоверности данных (CRC), так вообще поле чудес может получиться, хотя у меня вся девайс уже скоро месяц, как нормально работает, при том что рядом куча заводов, фабрик и пароходов

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

В ломы, конечно, писать универсальную программу схожую с PONIPROG, но можно попробовать...

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

[prottoss]

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

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

[GDI]

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

[osnwt]

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

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

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

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

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

[prottoss]

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

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

[osnwt]

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

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

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

[prottoss]

Не запрещать их нельзя, так как во время записи область приложения блокирована даже на чтение.

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

[GDI]

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

[prottoss]

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

Если бы все было так просто...

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

[GDI]

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

[prottoss]

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

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

[osnwt]

Не запрещать их нельзя, так как во время записи область приложения блокирована даже на чтение.

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

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

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

[prottoss]

Не запрещать их нельзя, так как во время записи область приложения блокирована даже на чтение.

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

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

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

[osnwt]

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

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

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

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

[lazycamel]

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

2 osnwt

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

[osnwt]

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

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

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

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

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

[prottoss]

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

Но в контроллере гарвардской архитектуры это не сработает, в отличие от того же MSP430.

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



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

[osnwt]

Да...За загрузчиком не получается - факт.

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

Однако, для программатора это не слишком страшно, если контроллер в DIP корпусе

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

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

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

а подсмотрел все это на стенде с ADuCххх.

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

А что, если проверять CRC входящих пакетов табличным методом? Это на порядок, ИМХО, быстрее бы проходило. возможно ли это?

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

[prottoss]

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

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

[osnwt]

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

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

[VladimirZ]

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

[prottoss]

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

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

[osnwt]

Прям в десятку)

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

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

Real-time computation is out of question, at least at 12 MHz.

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

[prottoss]

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

Real-time computation is out of question, at least at 12 MHz.

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

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

[osnwt]

Все же хочется найти способ проверки CRC входящих пакетов, т.к. это повысит надежность, и откроет двери для применения драйвера не только в радиолюбительких поделках...

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

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

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

[prottoss]

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

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

[prottoss]

AVR

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

Сообщение отредактировал prottoss - Jul 30 2006, 17:39

[TamTam]

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

[prottoss]

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

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

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

[TamTam]

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

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

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

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

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

[prottoss]

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

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

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

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

[TamTam]

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

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

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

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

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

[prottoss]

Да именно эта схема.

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

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

Легко

[TamTam]

Да именно эта схема.

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

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

Легко

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

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

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

Сообщение отредактировал TamTam - Aug 2 2006, 22:03

[TamTam]

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

[osnwt]

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

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

[prottoss]

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

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

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

Я тоже об этом подумал, когда ответил...

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

Сырцы я, пока, раздавать не намерен...

[prottoss]

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

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



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



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

Сообщение отредактировал prottoss - Aug 3 2006, 10:26

[Petka]

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

RXE, TR

[osnwt]

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

Ага :-)

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

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

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

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

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

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

[prottoss]

Хех, этот трабл лично проходил ...

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

[TamTam]

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

Я тоже об этом подумал, когда ответил...

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

Сообщение отредактировал TamTam - Aug 3 2006, 16:05

[prottoss]

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

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

[Rst7]

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

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

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

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

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

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

[prottoss]

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

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

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

Я об этом сам думал, наверное заведу такой сигнал на контакт LED ISP разъема...

2. Более глобальная вещь - доделать его чуток, чтобы он умел 8-милапые кристаллы шить с High Voltage, т.к. именно на 8pin вечная борьба за выводы, в результате - нужен HV.

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

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

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

[Shurmas]

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