On Tue, Oct 18, 2011 at 5:22 AM, JMGross <msp...@grossibaer.de> wrote:
>
> 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)
>
An observation: some people might be insulted by a suggestion that they're
too inexperienced to see the superiority of your solution.
Since the standard MCU header already provides all the USB-related
peripheral registers and flags, including a second file to enable USB is not
natural. Disabling resources reserved for USB is the deviation from normal
practice that should require a "non-conforming" action.
I'll implement an mcu suffix solution as soon as TI provides me the
necessary information to produce new linker scripts.
Peter
>
> 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
>
------------------------------------------------------------------------------
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
