I agree with you about the compatibility (or the lack of). However, the other way would be to either patch the linker files individually for each project (with/without USB-ram), or to introduce two different 'CPUs' for compiler/linker.
Having to include the USB header is not different from including string.h or similar if you want to use them. So it is not too complicated or surprising for users. The other two solutions, however, are non-normal, unexpected operations. Every solution (except for ingoring the additional 2k ram if USB is not used) requires a 'non-conforming' action. The question is, which action is easiest. And including an USB header if you want to use USB is the most natural thing for every C programmer (except for people who started with C on an MSP) JMGross ----- Ursprüngliche Nachricht ----- Von: Crazy Casta An: mspgcc-users@lists.sourceforge.net Gesendet am: 18 Okt 2011 06:11:11 Betreff: Re: [Mspgcc-users] MSP430F5510 - USB RAM 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 ------------------------------------------------------------------------------ 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
