[prottoss 0]

Я вот глянул код примерно по обьему чуть больше 4 килобайт и мысль такая возникла может можно както это все ужать до ATmega48 ведь они с мегай8 пин ту пин совместимые :)

 

Да вот тут платку развел для этого программера в SMD корпусах может кому надо :a14:

 

Теоретически код можно попробовать ужать до 4096 байт, а смысл? Только чтоб в 48-ю запихать? Я сейчас думаю, как в программатор запихать полный СОМ-порт (со всеми сигналами, благо, USB CDC-класс допускает эмуляцию всех сигналов Communication Port) и AVR JTAG ICE. Вот, кстати, фото оригинала))) Собран на монтажке за 2 часа. На плате место как раз под это дело оставлено)))

[asen 0]

Просто у меня есть сейчас купленые две меги48 и не одной меги8 вот а насчет кома тоже полезно ! ща попробую сконвертить в 2002 или PDF формат

 

вот сделал экспорт в П-САД 2002 ASCII формат

usb_to_avr910.rar

[Rst7 5]

Замечена еще одна интересная вещь - после установки драйверов от шнура USB<>COM (который на PL2302 или как ее там) стал глючить обмен с программатором, т.е. программатор зажигает красный светодиод когда пускаешь AvrProg и тишина... Помогает убить драйвер USB910 и потом поставить его... А после того, как вытащишь и вставишь программатор обратно, все повторяется...

[prottoss 0]

Замечена еще одна интересная вещь - после установки драйверов от шнура USB<>COM (который на PL2302 или как ее там) стал глючить обмен с программатором, т.е. программатор зажигает красный светодиод когда пускаешь AvrProg и тишина... Помогает убить драйвер USB910 и потом поставить его... А после того, как вытащишь и вставишь программатор обратно, все повторяется...

ИМХО это глюк не программатора, а драйверов шнура. По идее, для переходника драйверов не надо, так как в USB CDC Class, и родном Win98/ME/2000/XP драйвере usbser.sys все есть для эмуляции Communication Port (в простонародье COM-порт). Все прописывается в установочном inf-файле, даже таблицу DCB порта записать там можно, еще много чего сделать. Подробнее в MSDN...

 

У меня вот тоже прикол был: после установки драйверов libusb для своего девайса у меня начал таким же макаром, что вы описали, отваливаться USB модем, с которым я в данный момент работаю аж на 5-и ОСях. Вывод - кривые дрова.Я считаю, что дрова должны быть написанны так, что бы ни какое тупое устройство извне не могло потревожить состояние хоста...

 

 

 

Я вот глянул код примерно по обьему чуть больше 4 килобайт и мысль такая возникла может можно както это все ужать до ATmega48 ведь они с мегай8 пин ту пин совместимые :)

Да, еще кое что против м48/88/168. Там память SRAM начинается с 0х0100, а для компиляции USB драйвера надо, чтобы один из сегментов был обязательно TINY... Это для RX буфера USB надо, для быстрого доступа. Возможно, есть пути модифицировать asm-код драйвера, но ИМХО, если бы такая возможность была, автор драйвера не стал бы заморачиваться с разными сегментами...

[osnwt 0]

Да, еще кое что против м48/88/168. Там память SRAM начинается с 0х0100, а для компиляции USB драйвера надо, чтобы один из сегментов был обязательно TINY... Это для RX буфера USB надо, для быстрого доступа. Возможно, есть пути модифицировать asm-код драйвера, но ИМХО, если бы такая возможность была, автор драйвера не стал бы заморачиваться с разными сегментами...

Как автор порта USB драйвера для IAR, проясню ситуацию.

 

На самом деле, требуется только одно: чтобы тот самый буфер не переходил границу в 256 байтов. То есть, можно было бегать по всему буферу, модифицируя только младший его байт. А старший должен быть константой, равна она 0x00, или 0x01, или что-то еще. И последний байт буфера не должен быть по адресу xxFF.

 

Сегменты задаются так, чтобы сегмент был в пределах 0x00-0xFE (или xx00-xxFE). В IAR проще всего использовать TINY (он уже подходит, кроме окончания на FF), а для переопределения его для, скажем, ATmega128, и появилась такая возможность по моей просьбе (исходно она была только для GCC-ной версии).

 

Так что это не проблема.

[prottoss 0]

На самом деле, требуется только одно: чтобы тот самый буфер не переходил границу в 256 байтов... Так что это не проблема.

 

Получается (для IAR) достаточно выкинуть объявления атрибутов за usbRxBuf а перед ним объявить, допустим, #pragma location 0x0100? Я правильно понял?

[osnwt 0]

Получается (для IAR) достаточно выкинуть объявления атрибутов за usbRxBuf а перед ним объявить, допустим, #pragma location 0x0100? Я правильно понял?

Нет.

 

Для IAR надо объявить специальный сегмент для размещения Rx буфера, например, USB_RX_BUFFER, в определении ниже (usbconfig.h), после чего соответственно прописать размещение этого буфера в опциях линкера (в командной строке, либо в IDE на последней вкладке Linker, Extra options, Use command line options). Формат задания сегментов см. документацию на линкер, либо примеры из стандартных конфиг-файлов.

 

/* #define USB_BUFFER_SECTION ".bss" */

/* The USB receive buffer (variable "usbRxBuf") with a length of 22 bytes

* MUST NOT cross a 256 byte boundary. We have introduced this configuration

* option to allow you to change the data segment where this buffer is

* allocated. If you have problems with the default segment (start of .bss),

* you may change this setting. See the comment in usbdrv.h for details.

* On IAR C, the default is the TINY_Z segment (first 256 bytes). You must

* change this default for devices which don't have RAM below 0x100.

*/

 

Например,

 

#define USB_BUFFER_SECTION "USB_RX_BUFFER"

 

-Z(CODE)USB_RX_BUFFER=0100-01FE

[prottoss 0]

Получается (для IAR) достаточно выкинуть объявления атрибутов за usbRxBuf а перед ним объявить, допустим, #pragma location 0x0100? Я правильно понял?

Нет.

Почему нет? Практически тоже самое...

[osnwt 0]

Почему нет? Практически тоже самое...

С точки зрения конечного результата - да.

С точки зрения правильного (грамотного) подхода - нет.

 

Я предпочитаю давать линкеру свободу в размещении сегментов. Например, я использую чужой код, и кто-то тоже решил нечто разместить с адреса 0x105. И что, я должен это все править? Определение сегментов для этого и сделано, чтобы не менять исходники при смене чего-либо.

 

А выбор конечного решения, безусловно, остается за автором исходного текста.

[asen 0]

так что можно на деется на перетаскивание сего дивайса на мегу 48 или можно сразу шагать в магазин за мегой8

[prottoss 0]

так что можно на деется на перетаскивание сего дивайса на мегу 48 или можно сразу шагать в магазин за мегой8

Да почему? Вы следите за ходом мыслей? Все возможно. Определилось два пути решения проблемы.

 

1. Через определение сегменов линкеру

 

2. Через указание аППсолютных адресов компилятору.

 

Какой Вы выберете Ваше право.

 

 

 

НО. Исходники своего программатора я не опубликовываю...Пока... Возможно, когда будет рабочяя прошива с three-in-one... Возможно скомпилирую для м88

 

 

 

Почему нет? Практически тоже самое...

С точки зрения конечного результата - да.

С точки зрения правильного (грамотного) подхода - нет.

Я предпочитаю давать линкеру свободу в размещении сегментов. Например, я использую чужой код, и кто-то тоже решил нечто разместить с адреса 0x105. И что, я должен это все править? Определение сегментов для этого и сделано, чтобы не менять исходники при смене чего-либо.

А выбор конечного решения, безусловно, остается за автором исходного текста.

Сразу предупреждаю, что не буду спорить, что слаще - хрен или редька. ИМХО грамотный подход для чела, который не дилентант в программировании, тот, который ему удобен

[Rst7 5]

Почему нет? Практически тоже самое...

С точки зрения конечного результата - да.

С точки зрения правильного (грамотного) подхода - нет.

 

Я предпочитаю давать линкеру свободу в размещении сегментов. Например, я использую чужой код, и кто-то тоже решил нечто разместить с адреса 0x105. И что, я должен это все править? Определение сегментов для этого и сделано, чтобы не менять исходники при смене чего-либо.

 

А выбор конечного решения, безусловно, остается за автором исходного текста.

 

Есть мнение, что оптимально будет вот так:

.с-файл:
#pragma location="MY_P_SEGMENT"
__root __no_init char buffer1[64]; //или сколько там надо

и

.xcl-файл:
-P(DATA)MY_P_SEGMENT=60-FE,100-1FE,200-2FE,300-3FE,400-45F

 

Я правильно понял, что последний элемент не должен быть с адресом xxxFF? Если нет, то еще проще

-P(DATA)MY_P_SEGMENT=[60-45F]/100

[osnwt 0]

Сразу предупреждаю, что не буду спорить, что слаще - хрен или редька. ИМХО грамотный подход для чела, который не дилентант в программировании, тот, который ему удобен

Спорить с товарищем Protoss-ом я тоже не буду, поскольку он - не дилетант в программировании, и сам знает, как ему удобнее :) (я, правда, тоже, ну да ладно).

 

Есть мнение, что оптимально будет вот так:

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

 

Драйвер USB исходно был рассчитан на компиляцию только под GCC/WinAVR. Поскольку мне ближе был IAR, я портировал его для себя, пытаясь сохранить всю ту гибкость настроек, которую предусмотрел автор. Найдя ряд проблем, я стал общаться с автором, и он предложил включить IAR порт в официальный состав, правда, оговаривая, что я не могу претендовать на прибыль от его продажи (он не только бесплатный при условии опубликования исходных текстов разработок, но и коммерческий, если исходные тексты не публикуются). Да мне это и не было нужно.

 

Так вот, этот драйвер исключительно грамотно написан, и я могу отметить, что многие вещи из того, что я прислал автору, были переписаны совершенно по другому, и многое - еще более красиво, чем пытался сделать я. Устранение серьезного бага, к примеру, привело к... сокращению объема кода. И так далее.

 

Определение того самого буфера в исходном тексте драйвера выглядит вот так:

 

/* usbRxBuf MUST be in 1 byte addressable range (because usbInputBuf is only 1 byte) */
__no_init uchar usbRxBuf[2][USB_BUFSIZE] __attribute__ ((section (USB_BUFFER_SECTION))) IAR_SECTION(USB_BUFFER_SECTION);/* raw RX buffer: PID, 8 bytes data, 2 bytes CRC */

 

Отсюда видно, что там предусмотрено и задание сегмента для GCC, и иной формат задания для IAR. Поэтому я лично не вижу никакого полезного смысла модифицировать авторский код, который в противном случае может быть проапгрейжен на более свежую версию простым копированием одной папки. Автор драйвера крайне серьезно относится к вопросам совместимости, и потому только в самом крайнем случае меняет интерфейсы, иногда даже жертвуя чем-то иным ради обратной совместимости.

 

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

 

НО. Исходники своего программатора я не опубликовываю...

Есть, правда, еще один нюанс: лицензия на драйвер AVR-USB предполагает, что при любом использовании данного драйвера разработанное устройство обязано быть опубликовано в Сети с его схемотехникой и полными исходными текстами. В противном случае драйвер следует купить. Я сделал две разработки с его использованием - обе они опубликованы на сайте AVR-USB. Но, безусловно, только дилетант в программировании (коим я, по видимости, являюсь) будет раздавать свои исходники бесплатно, выполняя требования лицензии - профессионалам это, увы, не к лицу Обычно я не затрагиваю таких тем на технических форумах, но в данном случае промолчать, извиняюсь, не смог. Больше не буду.

[prottoss 0]

НО. Исходники своего программатора я не опубликовываю...

Есть, правда, еще один нюанс: лицензия на драйвер AVR-USB предполагает, что при любом использовании данного драйвера разработанное устройство обязано быть опубликовано в Сети с его схемотехникой и полными исходными текстами. В противном случае драйвер следует купить. Я сделал две разработки с его использованием - обе они опубликованы на сайте AVR-USB. Но, безусловно, только дилетант в программировании (коим я, по видимости, являюсь) будет раздавать свои исходники бесплатно, выполняя требования лицензии - профессионалам это, увы, не к лицу Обычно я не затрагиваю таких тем на технических форумах, но в данном случае промолчать, извиняюсь, не смог. Больше не буду.

Я просто не хочу увидеть свое детище(хотя оно и не совсем мое, конечно) в рекламном проcпекте на каком нибудь сайте за $9.99...Наверное жаба душит... разве не достаточно прошивки и схемы?

[osnwt 0]

разве не достаточно прошивки и схемы?

 

License.txt:

 

III. Distribution of the Project

The distributed form of a Project must contain at least the following files:

(a) Software Source Code files for the USB Driver, the Function and the Host

Software.

(b ) Circuit diagrams for the hardware in PDF, PNG or GIF image file format.

(c ) A file with name "Readme.txt" in ASCII format with at least the following

content (in English language):

- An explanation what the Project does.

- What to do with the distributed files (installation procedure etc.).

- A reference to Objective Development's USB driver.

- Your (author's) name and contact information. E-mail and/or URL is

sufficient.

(d) Optionally a text file with a description of the circuit diagram, an

explanation of special (software) techniques used etc.

(e) A copy of this license in a file with the name "License.txt". This copy

can be in the "usbdrv" subdirectory which contains the driver.

 

IV. Requirement for Publication

All modifications and derived work (Projects using the USB Driver) MUST be

distributed (published) as described in section III above on a Web Site. The

main page must reproduce at least a description of the Project (e.g. as

contained in the "Readme.txt" file distributed) and a download link for the

entire Project. The URL of the main page must be submitted to OBDEV. OBDEV

will provide a mechanism for submitting Project URLs and for publishing

Projects on their Web Site. The Project must remain available for at least

twelve (12) months after the initial publication or at least six (6) months

after a subsequent version of that particular Project has been published.

 

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