People will turn away from a product when it doesn't fit their purpose
now, or in the foreseeable future.
(If I could ever get it built, I might be able to pass judgement.)
Errol Kowald
On Thu, 2010-08-12 at 12:42 +0200, JMGross wrote:
> Von: Peter Bigot
> Gesendet am: 30 Dez 1899 00:00:00
>
>
> > Re errata: to whatever extent binutils or mspgcc{3,4} already supports
> > chip-specific errata I'll have to retain that. To whatever extent I can
> > come up with a way to add support, I'll do so. But I expect this'll be an
> > on-demand sort of thing: having gotten away from the need to read every data
> > sheet to figure out where the flash sections start, I'm not going to start
> > reading every errata document to figure out what's broken on which revision
> > of which chip.
>
> Understandable.
> It is mostly the CPUx bugs which are compiler-specific.
> Some others (EEMx) may be of interest for the debugger or the
> JTAG connection.
>
> I think it is vital for mspgcc to take care of this or the (IMHO worse)
> IAR and CCS will make it vanish from the (new) users horizon.
> Once a product has the stigma of not supporting this or that, people
> tend to ignore it completely, even if it is a feature they don't need.
>
>
> > Names are TBD, but yes, I foresee something like:
>
> > -msp430=cpu (cpux, cpuxv2)
> > -mpy=none (mpy, mpy32)
>
> That will mostly do the trick. Yet there is some mechanism needed to ensure
> you don't mix incompatible object files. At least with a default warning you
> can
> deactivate manually by another compiler/linker option.
>
> Imagine ewhat happens if you mix MSP and MSPX code. Everything from
> fully functional to occasionally or always crashing can result.
> Same for the MPY.
> This can be left to the user, but then newbies (or those not aware of it) will
> start complaining too.
>
> > I'm going to do what I can to delay resolving peripheral addresses to the
> > final link phase. Having control of the standard header files should make
> > that easier.
>
> There should be a separate set of 'generic' header files which do not define
> any address, just extern volatile unsigned char variables.
>
> There are only a few registers needed for the libraries. MPY, WD, maybe
> a few more for certain types of processors.
>
> > I'm very sympathetic to your views on watchdogs, and would like to make it
> > easier to control that function. However, a large portion of the MSPGCC
> > user community is completely ignorant of the presence of WDT because it's
> > always been automatically turned off for them. I'm just not willing to deal
> > with the fallout from changing the existing default behavior.
>
> There could be a weak generic version which simply turns off the watchdog.
> But I won't recommend it.
> Every example from TI contains deactivating the watchdog as the first line.
> So almost every piece of code I've ever seen from users on e2e.ti.com
> deactivated the WD.
> Using a default startup sequence that triggers the WD instead of deactivating
> it
> will do no harm. Yes, it would be a bit slower, but who cares about few
> microseconds startup time.
> Those who do will program a DMA for copying :)
>
> Actually, it took quite some time until I discovered that the WD was
> deactivated
> in all of the projects I took over.
> The code was triggering the WD all the time, but nobody (before me) ever
> noticed
> that the WD was actually off (a HUGE security violation) from the beginning.
> All TI datasheets told that it is on after a PUC, yet it wasn't.
> Finally I discovered the startup sequence as the violator and wrote my own.
>
> I guess there are MANY people out there, who constantly trigger the WD and
> rely on it, not knowing that it is off all the time.
>
> JMGross
>
> On Tue, Aug 10, 2010 at 5:48 AM, JMGross <msp...@grossibaer.de> wrote:
>
> >
> > ----- Urspr=FCngliche Nachricht -----
> > Von: Peter Bigot
> > Gesendet am: 10 Aug 2010 01:17:03
> >
> > > What I propose to do instead is reduce the machines to those required
> > > reflect the chip CPU architecture (MSP430, MSP430X, MSP430XV2), and not
> > try
> > > to indicate things like available peripherals and the like as distinct
> > > machine types. The only other feature that affects generated code is
> > > presence/absence of hardware multiply support (none, MPY, MPY32), and I
> > > think that can be done without having to add another axis to the
> > > architecture matrix.
> >
> > This is AFAIK the only part that needs care, besides the X/XV2 thing.
> > Of course there are the errata which should be taken care of, or the
> > compiler
> > will possibly create code that will simply crash. This is mostly X/XV2
> > related
> > stuff (forbidden sequences of instruction, necessary NOPs, not doing some
> > PC/SP manipulations etc.
> > Unfortunately, this is machine dependent. SOmetimes it applies to whole
> > families or groups of processors, sometimes only single ones are affected=
> .
> >
> > I fear this could break the 'slim' concept you want to introduce.
> >
> > There can be, however, basic support for yet unsupported machines by
> > supporting the base architecture and MPY through parameters or
> > generic machine types. This allows compiler/assembler support for new
> > processors. (of course, linker scripts and include files are necessary, b=
> ut
> > these can be written by 'normal' people)
> >
> > I propose that an unknown mmcu will recognize a -core and -mpy parameter
> > and use the generic machines if given (or throw an error or assume non-X =
> no
> > MPY if not set). This way it would be compatible to the current mechanism=
> s
> > of forking inside header files etc.
> >
> > > If this works, the guts of binutils (the assembler and linker) becomes
> > > independent of specific chip details, except for the location of ld
> > sections
> > > (RAM, ROM, etc) and the base address of a few peripherals. Since TI's
> > now
> > > providing me with a table containing, for each chip, the necessary
> > addresses
> > > all the way down to individual info sections, it should be much easier =
> to
> > do
> > > this; plus, I believe it can be done in a way that allows new chips to =
> be
> > > targeted without having to rebuild the toolchain.
> >
> > Because of the silicon errata this can prove difficult to impossible.
> > Except there is a way to manually set errata flags.
> > But I don't know whether TI has a 'global' errata naming. I fear the
> > errata names are independent for each group of processors and same name
> > may mean different things for different processors.
> >
> > > Some of the questions that arise include:
> >
> > > *) Is it necessary to retain support for the existing machine definitio=
> ns
> > in
> > > binutils, at least to allow linking to legacy libraries that can't b=
> e
> > > rebuilt?
> >
> > I don't think existing libraries are a problem.
> > If they cannot be rebuilt, they'll work or not.
> > machine-dependent defines are already resolved during compilation.
> > All that's left is resolving the symbols and this is a
> > machine-independent process. Either they are provided in the
> > (properly) compiled project object files or they are missing and
> > linking is impossible.
> > Some special code (like the startup) depends on machine-dependent
> > information, but this is usually part of the linker scripts.
> >
> > > *) Can critical values like the address of the watchdog reset or multip=
> ly
> > > peripheral registers be correctly resolved using separate compilatio=
> n,
> > in
> > > such a way that attempts to link object files built for incompatible
> > > platforms fail with an understandable error message?
> >
> > I know that the compiler-generated MPY16 inline code linked fine on
> > machines with MPY32. Only the libraries didn't work as they were built
> > with different register addresses. If global, unresolved symbols were use=
> d
> > in these functions instead of static addresses, this should be doable.
> >
> > I can imagine a compiler attribute that forces a variable to be extern ev=
> en
> > if
> > it has been defined with a 'fixed' location in the header files.
> > So the linker can clean up things.
> >
> > Also, the functions using the MPY (or not) can be named differently, so t=
> he
> > compiler will generate different function calls depending on whether MPY1=
> 6
> > is used or MPY32 or none (it already does so for none and MPY16).
> > If they are in different compilation units, the linker will only link the
> > required
> > ones.
> > This unfortunately won't work for precompiled library functions which use
> > the MPY.
> > Another approach would be to add different libraries which are selected
> > depending on the MPY usage.
> >
> > There is, however, a problem with the watchdog register, which is
> > differently
> > for different MSPs.
> >
> > There I propose removing it completely from the init code.
> > It should be documented that the user must provide a proper
> > code snippet if he needs the WDT disabled at startup.
> > Personally, I strongly discourage stopping the WTD at startup, as this
> > renders the WDT practically useless. Either it is on all the time without
> > exception, or you do not really need it at all.
> >
> > On newer MSPs, the default times are long enough so the WDR won't
> > trigger even if you copy 18k of data (which is the maximum ram in any
> > MSP so far). The timeout is long enough for even copying hundreds of
> > kB.
> >
> > > *) What else am I not thinking of?
> >
> > Most problems are encountered during project progress.
> > That's an inevitable rule.
> >
> > JMGross
> >
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
