Seb, please keep us informed if you know how to find what part of memory USB is using.
It looks like I am making some small amount of progress on USB MSD class. The HID generic sample was a good starting point, and I seem to understand USB more now. The HID generic sample should be made into a template for users to easily create new usb files of different classes. Hmmm... maybe there's a networking class :) Matt. On Apr 1, 6:18 pm, Sebastien Lelong <[email protected]> wrote: > Ah, ah, that was a bait... > > While trying to understand why it didn't work, I compared USB ram on > 18F4550, 18F14K50 and 18F27J53. USB ram can span onto specific banks > (18F4550, 18F14K50) or all ram (18F27J53). Within USB ram, some is reserved > for buffer descriptor tables (BDT), which actually defines some sort of > registers with variable size within USB ram. Those locations vary from PIC > to PIC. usb_defs.jal currently takes care of 14K50 and 4550, I'll update it > for 27J53. But I was wondering if there was a way to make this more generic, > maybe enriching these special locations in device files. I had a very quick > look at 18f27j53.inc file in MAPSM, I can't find anything related to this, > but you know this far better than me, so maybe you'll have an idea. > > For 18F27J53, all ram can be used as USB ram, this means you can put buffer > anywhere. But current jalv2 USB implementation assumes USB data is following > BDT. For this PIC, memory is oragnized as (IIRC): USB data from bank 0 to > 13, BDT and USB data on bank 14, USB data on bank 15. this means, with > current implementation, only bank 15 can be used, as it's following BDT/bank > 14. If we have information about this, maybe we could build a better, more > generic USB lib set. > > So, to sum up: > 1. is it possible to enrich device file with BDT memory location ? > 2. is it possible to enrich device file with USB data memory location ? > > 1. would help setting USB_BASE_ADDRESS in usb_defs.jal in a more generic > way. > > 2. really is an extra, using this type of information would require huge > modifications in libraries. But also would allow to build heavy USB device. > I'm not sure it's useful right now though... > > Cheers, > Seb > > 2011/4/1 Rob Hamerling <[email protected]> > > > > > > > > > Hi Seb, > > > On 2011/04/01 20:59, Sebastien Lelong wrote: > > > During my USB "travel", I mentioned several issue regarding debug > >> statement (see also issue 153). With the help of newfound from Microchip > >> forums, I pointed another issue about USB base address (Rob, maybe we > >> can work on this ?). I'll try to address both of these. > > > I would be glad to help, but you'll have to tell me more how! > > > Regards, Rob. > > > -- > > R. Hamerling, Netherlands ---http://www.robh.nl > > > -- > > You received this message because you are subscribed to the Google Groups > > "jallib" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/jallib?hl=en. > > -- > Sébastien Lelonghttp://www.sirloon.nethttp://sirbot.org- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
