I'm against the idea of adding a USB specific header because it's different from what TI does. I think it will be easier to publish patches and all if the changes are minimal from the TI published code. It currently looks as if the difference will be a few lines of code in one file and the addition of a Makefile to describe the build process. I personally think the dual MCU idea is quite good and better than a separate header.
Alex On Wed, Oct 12, 2011 at 9:16 AM, JMGross <msp...@grossibaer.de> wrote: > > Yes, that's what I thought. > However, I don't know whether the USB part is in lowest power state after a > reset. > If not, you'll need to access its regsiters and therefore need the register > definitions > even if you don't use USB, to get the MSP to it s lowest power state. > > But if it is, my suggestion was to generally treat the ram as ram. > Only if someone explicitely includes the header file with the USB definitions, > then the lower 2k of the ram are occupied by a (dummy) buffer of that size > and a > fixed address, so that the linker will place everythng else above it. > So once you include the USB header, you'll get a dummy variable of 2 k size > that > happens to sit exactly where the USB needs to have its ram. > > Then there is no need for separate linker scripts. > > JMGross > > ----- Ursprüngliche Nachricht ----- > Von: Mathias K. > An: mspgcc-users@lists.sourceforge.net > Gesendet am: 11 Okt 2011 19:05:48 > Betreff: Re: [Mspgcc-users] MSP430F5510 - USB RAM > > Hello, > > the USB-Ram is only used by hardware if the USB-Periphery is enabled. I > use a custom linker map file to expand the RAM. I don't use USB yet. > > > Regards, > > Mathias > > Am 11.10.2011 12:51, schrieb JMGross: >> >> A possible way to handle this (at least on chips where the USB ram is right >> before and not behind the 'normal' ram) would be to have the USB-related >> includes in a separate header file that needs to be included manually. >> Within the header file, the USB ram is allocated as a fixed-address >> non-initialized buffer. >> >> This way, it would be placed there if the header is included and the ram >> would >> be free for the rest if not. >> Since the USB ram is before the normal ram, there is no need for a separate >> linker file, as the stack pointer init would be the same. The USB ram would >> just be normal ram in the memory map. >> >> But I'm not 100% sure whether you need to access the USB registers (and >> therefore include the USB header) just to send the USB part in lowest power >> state after power-up. I never worked with USB. >> >> JMGross >> >> ----- Ursprüngliche Nachricht ----- >> Von: Peter Bigot >> An: Mathias K. >> Gesendet am: 09 Okt 2011 18:11:30 >> Betreff: Re: [Mspgcc-users] MSP430F5510 - USB RAM >> >> Found an old related ticket at >> https://sourceforge.net/tracker/?func=detail&aid=3113886&group_id=42303&atid=432701 >> >> I've asked TI to provide the information necessary to support the solution >> described below in the next msp430mcu release. >> >> Peter >> >> On Sat, Oct 8, 2011 at 6:38 AM, Peter Bigot<big...@acm.org> wrote: >> >>> I don't believe so. >>> >>> One fairly simple solution would be to augment msp430mcu to detect >>> chips with USB RAM and to provide two MCU descriptions for them. >>> Viz., msp430f5510 which would reserve USB memory and msp430f5510nousb >>> which would combine it with RAM (assuming the two are contiguous). >>> The only difference would be in linker flags and the memory map. >>> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2d-oct >> _______________________________________________ >> Mspgcc-users mailing list >> Mspgcc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
