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

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

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

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

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

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



Да, еще кое что против м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-ной версии).

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

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

Нет.

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



Например,

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

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

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

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

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

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

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

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

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



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



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

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

и


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

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


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

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

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

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



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

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


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

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

License.txt:



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