Вышла очередная версия AVR-USB драйвера от Objective Development, Исправлена пара серьезных багов, рекомендуется обновиться Опции

[osnwt]

Вышла версия программного USB драйвера для большинства AVR контроллеров.
См сайт автора.

Самая последняя версия всегда находится в составе reference-проекта PowerSwitch.

Изменения в текущей версии:

* Release 2006-03-14

- Added IAR compiler compatibility to USB driver (not the PowerSwitch project).
Thanks to Oleg Semyonov for contributing this port!
- Major Bugfixes in the low level parts of the USB driver. See the driver's
Changelog for details.

Changelog:

- Give a compiler warning when compiling with debugging turned on.
- Added Oleg Semyonov's changes for IAR-cc compatibility.
- Added new (optional) functions usbDeviceConnect() and usbDeviceDisconnect()
(also thanks to Oleg!).
- Rearranged tests in usbPoll() to save a couple of instructions in the most
likely case that no actions are pending.
- We need a delay between the SET ADDRESS request until the new address
becomes active. This delay was handled in usbPoll() until now. Since the
spec says that the delay must not exceed 2ms, previous versions required
aggressive polling during the enumeration phase. We have now moved the
handling of the delay into the interrupt routine.
- We must not reply with NAK to a SETUP transaction. We can only achieve this
by making sure that the rx buffer is empty when SETUP tokens are expected.
We therefore don't pass zero sized data packets from the status phase of
a transfer to usbPoll(). This change MAY cause troubles if you rely on
receiving a less than 8 bytes long packet in usbFunctionWrite() to
identify the end of a transfer. usbFunctionWrite() will NEVER be called
with a zero length.

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

[EWAVR]

Спасибо, все заработало( все так просто, сам мог бы догадаться!).
Далее я попробовам перенести в IAR свой прект на tiny26. В нем использутся прерывание от АЦП, и линкер выдал следующее:

Error[e16]: Segment INTVEC (size: 0x18 align: 0x1) is too long for segment definition. At least
0x4 more bytes needed. The problem occurred while processing the segment placement
command "-Z(CODE)INTVEC=0-(_..X_INTVEC_SIZE-1)", where at the moment of placement
the available memory ranges were "CODE:0-1,CODE:4-17"
Reserved ranges relevant to this placement:
CODE:0-1 ?FILL1
CODE:2-3 Absolute code from usbdrvasm
CODE:4-17 ?FILL2

Ассемблерный код нагло залез в сегмент INTVEC.
Разборки с директивами ассемблера показали, что в файле usbdrvasm.S в месте

ASEG
ORG INT0_vect + IVT_BASE_ADDRESS
rjmp SIG_INTERRUPT0

нужно поменять ASEG на COMMON INTVEC, тогда линкуется без проблем.

P.S. При переходе с gcc на IAR в проекте на tiny26 я выиграл аж 10 байт, так что овчинка выделки не стоила. Но все равно спасибо за помошь:-}

Сообщение отредактировал EWAVR - Mar 20 2006, 22:56

[osnwt]

нужно поменять ASEG на COMMON INTVEC, тогда линкуется без проблем.

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

IVT_BASE_ADDRESS появилась ради размещения драйвера в boot area для создания загрузчиков. В варианте с INTVEC эта часть снова уходит в небытие.

P.S. При переходе с gcc на IAR в проекте на tiny26 я выиграл аж 10 байт, так что овчинка выделки не стоила. Но все равно спасибо за помошь:-}

Но если замыкаться на IAR, то смысл в этом есть - появляется возможность разместить определенный код в мЕньшем устройстве. Остается лишь проблема, как красиво с минимумом правок решить проблему с передачей указателя. Ну что стоило поддержать __near для всех CPU...

[Rst7]

P.S. При переходе с gcc на IAR в проекте на tiny26 я выиграл аж 10 байт, так что овчинка выделки не стоила. Но все равно спасибо за помошь:-}

Но если замыкаться на IAR, то смысл в этом есть - появляется возможность разместить определенный код в мЕньшем устройстве. Остается лишь проблема, как красиво с минимумом правок решить проблему с передачей указателя. Ну что стоило поддержать __near для всех CPU...

Ох, господа, не надеялся я бы так на T26. Недавно писал про глюки со старшим байтом X, так вот действительно:

If you use

LD r16,X

then you can use XH (r27) to something else, if you use

LD r16, X+

XL is incremented and XH is reset. I can see that the description in the instruction set is a bit unclear, but you have to
believe me in that this is how it is desgined to work ( I double checked with the IC-designers) and that it is not a bug.

Это я от Atmel'а ответ получил...

Особенно убивает последняя фраза про то, что так задумано, а в описании комманд - немного ошибочно

Мне пришлось из-за этого ПРИНУДИТЕЛЬНО включить для T26 режим near, точнее выбрать в опциях проекта не конкретно проц, а модель -v1.