Re: [Mspgcc-users] MSP430F5510 - USB RAM

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Wed, Oct 19, 2011 at 5:16 AM, JMGross <ms...@gr...> wrote:

>
> Peter,
> that wasn't what I meant nor what I think I said.
>
> It is not a matter of experience.
>
> Everyone who learned C(++) first, has learned to
> include the necessary heeader file one by one, if
> hee wants to use the features they provide.
> So a separate USB header file is 'normal' for everyone,
> who learned C first before moving to the MSP.
> The MSP approach to have an all-in-one header file
> is the 'unusual' way to do things.
> (This is _not_ a judgement of which way is better!)
>

I agree it's unusual, but think it's odd that you believe it would be better
to make it more unusual by creating an exception to the all-in-one approach.

> However, having to configure a different MSP type
> (by a suffix) to have the ram available for USB or not
> is unusual for both, normal C programmers and
> MSP-experienced programmers.
>

If you can provide details on how CCS or IAR support re-use of the USB RAM
for non-USB purposes, I'd be happy to reconsider the approach I've
proposed.  If not, it seems to me we're breaking new ground here, and
treating it as a different MCU is a clean and easily understood solution to
a relatively unusual problem.

> >From a compiler programmers view, this may be
> the cleanest solution. But not really from a compiler
> users view.
>
> Of course, this is only my personal opinion (backed by
> some observations in the TI MSP forum), and if you
> decide to do things different, that's your decision.
>

The path I'm following is consistent with the hardware interface that TI
promotes in their headers, which they provide to me, IAR, and CCS.  I'm
certainly not going to tear apart those headers and rearrange them under the
delusion that I know better than they do.  If you'd like to convince them to
change what they provide to all MSP430 compiler vendors so each peripheral
is described in a different file, feel free to do so, and I'll update the
GNU toolchain to conform to that.  Otherwise, we'll continue to follow
existing practice as closely as possible.

Peter

>
> BTW: Maybe I wasn't clear about my suggestion:
> I didn't mean just enabling USB by the separate header file.
> I meant including ALL the USB related header information
> in a separate file that is not auto-included by MSP430.h
> So if someone wants to access the USB registers,
> he will need to include the USB.H and gets the USB
> ram assigned to the USB too. If he doesn't include
> the header, he will not have access to the USB registers at
> all. Just like printf() and other things.
> The thing I was unsure about was whether some USB
> registers need to be accessed even if you don't want to
> use USB. (e.g. to totally deactivate it)
> I have not enough experience with the USB module
> to be sure of that.
>
> JMGross
>
> ----- Ursprüngliche Nachricht -----
> Von: Peter Bigot
> Gesendet am: 18 Okt 2011 14:54:49
>
>
> On Tue, Oct 18, 2011 at 5:22 AM, JMGross <ms...@gr...> 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
> no=
> t
> 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=FCngliche Nachricht -----
> > Von: Crazy Casta
> > An: msp...@li...
> > 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 <ms...@gr...> wrote:
> > >
> > > Yes, that's what I thought.
> > > However, I don't know whether the USB part is in lowest power state
> aft=
> er
> > 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=FCngliche Nachricht -----
> > > Von: Mathias K.
> > > An: msp...@li...
> > > 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-relat=
> ed
> > >> 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
> r=
> am
> > 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
> (an=
> d
> > >> 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=FCngliche 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=3Ddetail&aid=3D3113886&group_id=3D4=
> 2303&atid=3D432701
> > >>
> > >> 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<bi...@ac...>  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
> Msp...@li...
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

Re: [Mspgcc-users] MSP430F5510 - USB RAM

Superseded by http://www.ti.com/tool/msp430-gcc-opensource

Re: [Mspgcc-users] MSP430F5510 - USB RAM