I think that there are still problems, consider this:
msg_t usbTransmit(USBDriver *usbp, usbep_t ep, const usbbufptr_t buf, size_t n);
The "buf" parameter could point to either ROM or RAM data, aren't those different types on AVR?
If this is right then you would need two functions, for example:
msg_t usbTransmit(USBDriver *usbp, usbep_t ep, const uint8_t buf, size_t n);
msg_t usbTransmitROM(USBDriver *usbp, usbep_t ep, const romuint8_t buf, size_t n);
A possible solution could be to add "ROM" variants of the high level functions to the low level driver, of course that would be AVR-specific.
Giovanni
[PATCH] AVR USB device driver
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: [PATCH] AVR USB device driver
Giovanni wrote:I think that there are still problems, consider this:
msg_t usbTransmit(USBDriver *usbp, usbep_t ep, const usbbufptr_t buf, size_t n);
The "buf" parameter could point to either ROM or RAM data, aren't those different types on AVR?
In the AVR port, usbbufptr_t is optionally defined using a special __memx attribute:
typedef const volatile __memx uint8_t *usbbufptr_t;
The __memx part is a gcc 4.7+ feature called "named address spaces" (https://gcc.gnu.org/onlinedocs/gcc/Name ... paces.html) that allows a single pointer in AVR to point to either flash space or RAM space.
(it basically turns a normally 16-bit pointer into a 24-bit "fat" pointer with the top bits being used to indicate flash/RAM/EEPROM space)
When the compiler see accesses to the __memx pointer it inserts runtime code to check the type of the pointer (flash or RAM) and then use the appropriate load/store instructions for that address space.
The __memx attribute on the pointer must be maintained throughout the entire callstack or the compiler will "slice" the 24-bit pointer into a 16-bit pointer and lose the information about which address space it is in. That is why the patch is necessary to change the pointer type of the high-level transmit functions...
-
- Posts: 359
- Joined: Sat Jan 07, 2012 6:22 pm
- Location: Brazil
- Has thanked: 1 time
- Been thanked: 20 times
- Contact:
Re: [PATCH] AVR USB device driver
devlware wrote:Can you check this patch with Leonardo support files?
LGTM! Applied, thanks!
Cheers,
Fabio Utzig
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: [PATCH] AVR USB device driver
Hi,
Thanks for explaining, it is clear now. The problem is that also the other drivers could require similar changes, there are a lot of API functions that take pointers to buffers.
Rather than just fixing the USB driver an abstraction should be defined and implemented in the whole HAL.
In order to not block development on the AVR platform I suggest to proceed as follow: Duplicate hal_usb.c/.h in the AVR drivers directory and name them hal_usb_avr.c/.h, from the makefile refer the modified versions. From the application perspective the API would be the same. Same could be done for other drivers
Giovanni
Thanks for explaining, it is clear now. The problem is that also the other drivers could require similar changes, there are a lot of API functions that take pointers to buffers.
Rather than just fixing the USB driver an abstraction should be defined and implemented in the whole HAL.
In order to not block development on the AVR platform I suggest to proceed as follow: Duplicate hal_usb.c/.h in the AVR drivers directory and name them hal_usb_avr.c/.h, from the makefile refer the modified versions. From the application perspective the API would be the same. Same could be done for other drivers
Giovanni
Who is online
Users browsing this forum: No registered users and 10 guests