So it seems to be a separate memory chip that has its chip enable mapped by the upper 5 address bits when accessed from the CPU, but is directly addressed by the USB. So for the USB controller, it has only 11 address bits and starts @0x000 That's a common practice on systems where the address/data bus are available externally (such as the ATMega), but it of course also works on a 'closed' system.
Then one question remains: is this ram as fast as the 'normal' ram? Or does it exhibit waitstates even if the USB is not accessing it? I guess it is the same technology as the 'normal' ram, so it will most likely be able to run with 25MHz without waitstates, but I don't know whether the additional selection circuitry and the 'multiport' feature introduces some limits. JMGross ----- Ursprüngliche Nachricht ----- Von: Crazy Casta Gesendet am: 20 Okt 2011 17:02:07 On Thu, Oct 20, 2011 at 8:10 AM, JMGross <msp...@grossibaer.de> wrote: > > This is actually a good idea. An optional linker flag. > Not necessarily limited to USB devices. > Currently, there are none, but I can imagine more devices > coming up which reserve a certain ram area for module operation. > > I don't know how the USB chip is connected. > Is the RAM actually memory-mapped internal RAM of the USB > chip (and maybe with waitstates) > or does the USB controller read and write data using DMA > to the MSP ram? > If so, are MSP ram and USB DMA implicitely adjusted so > that the ram begins where the USB controller expects it, or is > there a configurable 'DMA base address' in the controller, > set somewhere in the init code of the libraries? > The USB RAM is what they call "multiport memory". I'm not sure if they're trying to make a distinction from dual-port memory. It uses wait states, most likely prioritizing USB access if there's any choice. Endpoints can be sent to any divisible by 8 address in the USB RAM, but the 1904 byte block is always at the same address. The only reference I can see to USB disabled usage is in the introduction where it says "Buffer space is mapped into general RAM, providing additional 2 KB to the system" under the heading "When USB is disabled". It's fairly vague because it's not like the address is changing (afaict). > However, yes, the USB devices are the only MSPs with more than > 16k ram. (18k in total), so there might be interest in these chips > without ever using them for USB. > > The definition of variables with a location pragma is identical > to putting the hardware register variables on the places where the > hardware registers actually are. At least on IAR. > So that's what I would expect. > What happens on CC, I don't know. I do not use either one > (even though I wouldn't have to pay for a full CCS license) > Right, the point I was making is that they were doing this directly in the sample source, not a header file. I was extrapolating that perhaps this means that the compiler does not support automatic remapping of those areas. By no means is this proof. I've barely used the IAR tools for quite some time, since before the USB parts came out. Therefore, I have no idea what they do or don't support, just guessing :) ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
