USB RAM locations (BDT & Data)

[GoogleCodeExporter]

USB RAM is divided into 2 main areas:
  - BDT (Buffer Descriptor table)
  - USB data (actual buffers)

Current USB implementation uses USB_BASE_ADDRESS variable as the beginning of 
USB RAM, assuming it's the first area, BDT. For instance, 18F14K50 USB RAM 
starts at 0x200h, 18F4550 at 0x400h. From this reference point are declared 
buffers and other USB specific variables. This highly important variable is 
declared in usb_defs.jal.

For now, "if then else" logic is implemented to set this variable according to 
target chip. There's no information about how USB RAM is structured in device 
file. If we had this information, we could enrich this "if then else" logic to 
support, possibly, all USB PIC.

Is it possible to include, in device files:
  1. the start of BDT address ? (0x200h to 0x27Fh for 18F14K50, 0xD00h to 0xDFFh for 18F27J53)
  2. USB data locations ? (0x280h to 0x300h for 18F14K50, 0x060h to 0xCFFh and 0xE00h to 0xEBFh for 18F27J53)

See page 258 for 14K50 and page 387 for 27J53 for memomy space.

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...

Seb

Original issue reported on code.google.com by sebastie...@gmail.com on 2 Apr 2011 at 9:11

[GoogleCodeExporter]

Jim Robertson (newfound) from Microchip forums suggest the following: 

"""
The only thing that I have that may save a little time is a  complete PIC18F 
USB list that defines the buffer descriptor locations. 

if (target_chip ==PIC_18F2450) | (target_chip == PIC_18F2455) | 
(target_chip == PIC_18F2458) | (target_chip == PIC_18F2550) | 
(target_chip == PIC_18F2553)| (target_chip == PIC_18F4450) | 
(target_chip == PIC_18F4455) | (target_chip == PIC_18F4458) | 
(target_chip == PIC_18F4550) | (target_chip == PIC_18F4553) then 
const  USB_BASE_ADDRESS = 0x400 
end if 

if (target_chip == PIC_18F13K50) | (target_chip == PIC_18F14K50) then 
const  USB_BASE_ADDRESS = 0x200 
end if 

if (target_chip == PIC_18F24J50) | (target_chip == PIC_18F25J50) | 
(target_chip == PIC_18F26J50) |  (target_chip == PIC_18F44J50) | 
(target_chip == PIC_18F45J50) | (target_chip == PIC_18F46J50) then 
const  USB_BASE_ADDRESS = 0x400 
//#define PLLEN_REQD 
end if 

if (target_chip == PIC_18F26J53) | (target_chip == PIC_18F27J53) | 
(target_chip == PIC_18F46J53)  | (target_chip == PIC_18F47J53) then 
const  USB_BASE_ADDRESS = 0xd00 
//#define PLLEN_REQD 
end if 

if (target_chip == PIC_18F65J50) | (target_chip == PIC_18F66J50) | 
(target_chip == PIC_18F66J55) | (target_chip == PIC_18F67J50) | 
(target_chip == PIC_18F85J50) | (target_chip == PIC_18F86J50) | 
(target_chip == PIC_18F66J55) | (target_chip == PIC_18F67J50) then 
const  USB_BASE_ADDRESS = 0x400 
//#define PLLEN_REQD 
//#define USE_ALT_ANCON 
end if 

Note that there is some logic to the groupings as there tends to be one or two 
non USB related features that can be included for each generic family.  I left 
some examples commented out. 

This might save an hour to two's work and it gives the full list of all PIC18 
USB parts. 
"""

If new PICs arrive, they won't be supported whereas if logic is based on some 
information in device files, they could be. That should remain an option. In 
any case, I'd suggest that, if not explicitely supported, compiling USB stack 
against a PIC should miserably fail if not included in this logic:

if target == ... then
    base = ...
elsif target == ... then
    base = ...
elif ...
   ...
else
   _error "This PIC isn't supported by USB stack"
end if

Seb

Original comment by sebastie...@gmail.com on 2 Apr 2011 at 9:16

[GoogleCodeExporter]

In general: when required information for the Jallib device files cannot be 
obtained from MPLAB .dev or .lkr files the 'standard' solution is to put it in 
'devicespecific.json' (in the tools directory). This file currently contains 
for example the default config bits setting and the ADC group.

The file devicespecific.json could be extended for USB library support, 
resulting in the declaration of one or more constants in the Jallib device 
files. When these constants are not defined the device doesn't have an USB 
module or the USB libraries do not support this device (yet).

This would require the following actions:
1. extend devicespecific.json with (for example) USBBASE = 0x....
   for every PIC which is supported by the USB libraries
   (to begin with for the devices mentioned in comment # 1)
2. adapt the dev2jal script to generate 
     const USB_BASE_ADDRESS = 0x....
   and generate new device files
3. Adapt the USB libraries to use new constants like USB_BASE_ADDRESS
   in the new device files

If this looks like a workable solution I need to know which contants are 
required (or desired) in the device files!

Original comment by robhamerling on 3 Apr 2011 at 7:51

[GoogleCodeExporter]

For now I can only see USB_BASE_ADDRESS as a required constant. Benefits will 
be immediate: all USB PIC, declared in devicespecific.json will be properly 
configured, other will fail (which clearly is good).

According to the name, it declares the beginning of USB RAM, but in USB 
libraries, an assumption is made: beginning of USB RAM is also the BDT 
locations. This isn't true for 18F27J53 for instance, though remaining USB RAM 
after BDT makes the whole thing working good.

So, to sum up, I'm not sure yet about the name. I'd say to be explicit and name 
it USB_BDT_ADDRESS. What's your opinion on this ?

Seb

Original comment by sebastie...@gmail.com on 3 Apr 2011 at 8:06

[GoogleCodeExporter]

OK, let us start with a const USB_BDT_ADDRESS in the Jallib device files.
When a separate buffer address is needed/desired we can add that later.

Original comment by robhamerling on 3 Apr 2011 at 8:18

[GoogleCodeExporter]

The if-then-else list in comment 1 contains duplicates!  
The 'LF' versions of USB PICs are not listed.
I'll try to have USB_BDT_ADDRRESS in all PICs with USB module.

Original comment by robhamerling on 3 Apr 2011 at 8:42

[GoogleCodeExporter]

With revision 2548 the device files of PICs with USB module (currently 42 
chips) contain:

  const word USB_BDT_ADDRESS = 0x....

with the location of the Buffer Descriptor Table.

The actual location itself for each of these PICs is contained in the file 
devicespecific.json (in the tools directory), specified with keyword USBBDT.

When a device file does not contain this constant:
 - this PIC doesn't have a USB module
 - this PIC is not supportted (yet) by the USB libraries
 - it may have been forgotten to add it to devicespecific.json  

Original comment by robhamerling on 3 Apr 2011 at 6:51

[GoogleCodeExporter]

Great! I'll update usb_defs.jal asap and then close this issue. Thanks.
Seb

Original comment by sebastie...@gmail.com on 3 Apr 2011 at 7:11

[GoogleCodeExporter]

Fixed as of rev. 2551. Tested few samples and md5sum check produced hex files, 
compared before and after changes. There are the same as expected. Closed.

Original comment by sebastie...@gmail.com on 6 Apr 2011 at 2:40

• Changed state: Fixed