If you're looking for corner conditions, the section to read is 29.2.4.3 (SLAU208H). In the second paragraph it states that the memory is implemented as "multiport" memory. That the SIE (piece of USB hardware) allows the CPU/DMA access, but reserves priority via wait states. The third paragraph states that when the USB module is disabled "the buffer memory behaves like regular RAM." Not sure exactly how specific they're being there. It also states that before and after changing the USB enable bit you should not access the USB RAM for 4 and 8 clock cycles respectively. The reason given is "... as doing so reconfigures the access method to the USB memory." Paragraph four states that accessing the USB buffer memory by CPU/DMA is only possible if the USB PLL is active. I'm guessing this is only if the USB module is active (not sure if you can even have the USB PLL on without enabling the USB module).
P.S. On a side note, why doesn't my dictionary know what USB and DMA are? I can sort of understand PLL, but USB and DMA? On Fri, Oct 21, 2011 at 4:31 AM, JMGross <msp...@grossibaer.de> wrote: > > 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 > ------------------------------------------------------------------------------ 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
