On 30.1.11 10:17 , ChrisQ wrote:> Tauno Voipio wrote: > > Much more work to do, but a couple of other things. The stm32F series > has an external memory interface which should make it easy to drive > memory or mapped lcd controller devices. Both also have fancy dma modes, > but the nxp series also has a scatter gather dma mode via linked lists > in memory, which could be very usefull in optimising io bandwidth. > Together with the low end 1100 nxp series, they could replace just about > all applications here, including 8 bit. They are relatively cheap as > well. Time will tell, but nothing else seems to get close in capability > at present. > > What do you think and have you done any work with Cortex ?...There was an accident - the 10 years old production documents of an AT91 ARM7TDMI -based intelligent sensor card got destroyed, and the customers want a replacement. Our team had to create something fast, and we eneded up with a LM3S818 Cortex-M chip. Porting the old code to the new processor was done in two weeks and as a surprise to everybody, it worked. The toolkit in use is the GNU Compiler suite (GCC + GDB and binutils) for both targets. The most complicated thing in the porting was to change the multi- thread kernel for the newer interrupt and thread switching hardware mechanisms. The Cortex-M is surprisingly fast, especially for handling interrupts and thread switches. -- Tauno Voipio
TI's Code Composer does not clear bss data
Started by ●January 27, 2011
Reply by ●January 30, 20112011-01-30
Reply by ●January 30, 20112011-01-30
On 30/01/11 20:50, ChrisQ wrote:> Arlet Ottens wrote: > >> >> Translating the source reliably also includes clearing the BSS during >> start up. If you can't depend on the tool chain to translate "int a" >> correctly, why would you assume it does any better on "int a = 0" ? >> > The problem in the latter case is that the compiler has no implicit > awareness of the startup code that initialises int a = 0;, other than > reserving symbol table space and context for a. For a static / global > var outside function scope, the init is implied by including the startup > code at link time. ie: The compiler can't emit code to initialise a, > whereas > int a = 0; within function scope will result in code to initialise it on > function entry. >A compiler is part of a toolchain, which includes the assembler, linker, and (at least) basic standard libraries. The compiler should be able to assume that these tools work according to the standards for the given target, host, object file format and language. The compiler /does/ have an awareness of the startup that initialises data put in different sections - it knows that it can put them in specific sections for specific defined results. Of course, the compiler, assembler, linker and library don't have to use the popular ".bss" and ".data" sections - but if not, then they must have an alternative method of achieving the same effect. The C standards say that the file-scope statement "int a;", or "static int a", will result in the variable "a" being initialised to arithmetic 0. The compiler knows that's what you expect, and it is responsible for ensuring (in cooperation with the linker and library) that this is what you get. When the toolchain falls over at the first hurdle - the C run-time environment initialisation - I see no reason to assume that it does any better at anything else. It is more accurate to describe the CCS toolchain as being broken rather than the compiler, since the fault is in the combination.
Reply by ●January 31, 20112011-01-31
On Sun, 30 Jan 2011 16:06:05 +0000, ChrisQ <meru@devnull.com> wrote:>Jon Kirwan wrote: >> On Fri, 28 Jan 2011 19:54:56 +0000 (UTC), Grant Edwards > >>> The MSP430 would feel very >>> familiar to anybody who had worked with a PDP-11. >> >> About like a staple-gunned, sawdust-board knock-off bookshelf >> reminds me of one decently designed and fabricated from >> select Cherry pieces that the cheap version was intended to >> mimic. It's when you put hands on the two that you know >> which is much better than the other. >> >> Jon > >msp430 is about as close as you can get to pdp11 architecture, >without actually having one,Without getting into niggling issues such as binary object code compatibility (which doesn't matter to me) or source code compatibility for the assembler (which also doesn't matter to me), I see no reason at all why the instruction set designer failed to learn as well as should have been done, from what had already gone before. What isn't acceptable is to take wrong turns into dead ends when others have already surveyed the territory, examined those dead ends, and beaten down the right path for you for a much more successful path. The design of the PDP-11 is very good, but I've still no doubt at all that a clever designer may be able to do still better. Especially in a modern context that the old PDP-11 designers couldn't have anticipated. And I'd bow deeply to such a successful effort. But *this* designer made needlessly stupid mistakes. And to a German, that statement stings.>but the limited address spaceThe MSP430 (even before it was so named) possessed a 16-bit register size and a 16-bit address bus, so far as I'm aware. Same with the PDP-11. Newer versions of the PDP-11 had to deal with an expanding physical address bus width, and they chose one route. The MSP430 also had to deal with expanding physical address bus width and later incarnatins dealt with that need somewhat differently.>and lack of external address bus limits it's application.A huge advantage to modern designs is the ability to integrate so much into a single IC and this applies to the MSP430. It is not a problem when ICs include large memories within an IC package, don't include all the extra pins (which are, in many cases, the pricing driver) for an external address bus. Lower pricing, easier board design and stuffing costs, easier prototyping, etc., are pretty nice things to have. Had it been possible in the PDP-11 days, I'm sure it would have champed at the bit for such an opportunity to reduce all that external hardware and attending problems. The absolutely wonderful thing today is that there are so many options, even in this difficult economy period. One can buy in singles, or hundreds, or hundreds of thousands. One can buy SOT-23, DIP8, SOIC 44, or a 288-BGA. External bus or none. 8-bit ALU, 16-bit ALU, 32-bit ALU.... Hardware multipliers, hardware dividers, floating point (or not), etc. There are so many choices that in many cases there is more than one GOOD choice and one can instead choose based upon the kind of partner they are looking for. It's not a problem to lack an external bus. It's a matter of targeting.>Perhaps later versions have addressed this. ><snip>None that I've used. But I'm not keeping up to date on all the MSP430s coming out, either. Jon
Reply by ●January 31, 20112011-01-31
Arlet Ottens <usenet+5@c-scape.nl> writes:> On Sun, 30 Jan 2011 19:50:59 +0000, ChrisQ wrote: > >>> Translating the source reliably also includes clearing the BSS during >>> start up. If you can't depend on the tool chain to translate "int a" >>> correctly, why would you assume it does any better on "int a = 0" ? >>> >> The problem in the latter case is that the compiler has no implicit >> awareness of the startup code that initialises int a = 0;, other than >> reserving symbol table space and context for a. For a static / global >> var outside function scope, the init is implied by including the startup >> code at link time. ie: The compiler can't emit code to initialise a, >> whereas int a = 0; within function scope will result in code to >> initialise it on function entry. > > I see. You want to explicitly initialize all variables in function code. > I thought you were talking about adding an explicit '= val;' initializer > to static variables. Actually generating initialization code seems like a > waste, and also makes the code less readable, and harder to maintain. If > you have reason to doubt the correctness of the tool chain, it's easier > to do a code inspection of the start up code before using it. > >> Ime, you always end up having to modify the example startup code, add to >> it, or completely rewrite for a project. I don't think it's ever >> intended to be set in stone, even parts are mandatory for ansi >> compliance :-)... > > It varies. I would guess that in at least half of my projects, the > default start up code works just fine... and I've never had any > experience of BSS/DATA segments not being initialized correctly.I've had that experience.... but it's always because I *have* modified the startup code and messed it up :) Very often one has to initialise clocking, SDRAM etc before the C runtime. Rather than write this in assembler, I usually use C but without relying on statically initialised variables. (But I agree with David that outside of these special circumstances it is counterproductive to always second-guess the compuler and "manually" initialise these.) -- John Devereux
Reply by ●January 31, 20112011-01-31
On 2011-01-30, Arlet Ottens <usenet+5@c-scape.nl> wrote:> And for those case where the tool chain doesn't clear the BSS > properly, I would just fix the start up code myself, rather than > explicitly initializing my variables with '0'Definitely. Fixing a tool once is almost always better than working around a bug in a tool every day for the next ten years... -- Grant Edwards grant.b.edwards Yow! Does someone from at PEORIA have a SHORTER gmail.com ATTENTION span than me?
Reply by ●January 31, 20112011-01-31
On 2011-01-30, ChrisQ <meru@devnull.com> wrote:> Arlet Ottens wrote: > >> >> Translating the source reliably also includes clearing the BSS during >> start up. If you can't depend on the tool chain to translate "int a" >> correctly, why would you assume it does any better on "int a = 0" ? >> > The problem in the latter case is that the compiler has no implicit > awareness of the startup code that initialises int a = 0;, other than > reserving symbol table space and context for a. For a static / global > var outside function scope, the init is implied by including the startup > code at link time. ie: The compiler can't emit code to initialise a, whereas > int a = 0; within function scope will result in code to initialise it on > function entry.You're comparing apples and oranges. We were talking about static variables, and you're talking about automatic ones. -- Grant Edwards grant.b.edwards Yow! I was making donuts at and now I'm on a bus! gmail.com
Reply by ●January 31, 20112011-01-31
On 2011-01-30, Arlet Ottens <usenet+5@c-scape.nl> wrote:> On Sun, 30 Jan 2011 19:50:59 +0000, ChrisQ wrote: > >>> Translating the source reliably also includes clearing the BSS during >>> start up. If you can't depend on the tool chain to translate "int a" >>> correctly, why would you assume it does any better on "int a = 0" ? >>> >> The problem in the latter case is that the compiler has no implicit >> awareness of the startup code that initialises int a = 0;, other than >> reserving symbol table space and context for a. For a static / global >> var outside function scope, the init is implied by including the startup >> code at link time. ie: The compiler can't emit code to initialise a, >> whereas int a = 0; within function scope will result in code to >> initialise it on function entry. > > I see. You want to explicitly initialize all variables in function > code.Which doesn't even _work_ if you need a static varible. -- Grant Edwards grant.b.edwards Yow! Now, let's SEND OUT at for QUICHE!! gmail.com
Reply by ●January 31, 20112011-01-31
On 31/01/2011 16:37, John Devereux wrote:> Arlet Ottens<usenet+5@c-scape.nl> writes: > >> On Sun, 30 Jan 2011 19:50:59 +0000, ChrisQ wrote: >> >>>> Translating the source reliably also includes clearing the BSS during >>>> start up. If you can't depend on the tool chain to translate "int a" >>>> correctly, why would you assume it does any better on "int a = 0" ? >>>> >>> The problem in the latter case is that the compiler has no implicit >>> awareness of the startup code that initialises int a = 0;, other than >>> reserving symbol table space and context for a. For a static / global >>> var outside function scope, the init is implied by including the startup >>> code at link time. ie: The compiler can't emit code to initialise a, >>> whereas int a = 0; within function scope will result in code to >>> initialise it on function entry. >> >> I see. You want to explicitly initialize all variables in function code. >> I thought you were talking about adding an explicit '= val;' initializer >> to static variables. Actually generating initialization code seems like a >> waste, and also makes the code less readable, and harder to maintain. If >> you have reason to doubt the correctness of the tool chain, it's easier >> to do a code inspection of the start up code before using it. >> >>> Ime, you always end up having to modify the example startup code, add to >>> it, or completely rewrite for a project. I don't think it's ever >>> intended to be set in stone, even parts are mandatory for ansi >>> compliance :-)... >> >> It varies. I would guess that in at least half of my projects, the >> default start up code works just fine... and I've never had any >> experience of BSS/DATA segments not being initialized correctly. > > I've had that experience.... but it's always because I *have* modified > the startup code and messed it up :) > > Very often one has to initialise clocking, SDRAM etc before the C > runtime. Rather than write this in assembler, I usually use C but > without relying on statically initialised variables. >Yes, there are times when you need special code - but it should be special cases. Toolchains which target devices where this sort of thing is common often have hooks or special sections of some sort to make it easy to add board-specific startup code before standard C startup code, or to replace the standard C startup code. I too have written my own startup code for SDRAM setup using pre-runtime C code. You have to be a little careful to avoid things like stack usage if you haven't set that up yet, but it's quite possible to do this without anything more than a couple of inline assembly statements.> (But I agree with David that outside of these special circumstances it > is counterproductive to always second-guess the compuler and "manually" > initialise these.) >
Reply by ●January 31, 20112011-01-31
Jon Kirwan wrote:> On Sun, 30 Jan 2011 16:06:05 +0000, ChrisQ <meru@devnull.com> > wrote: > >> Jon Kirwan wrote: >>> On Fri, 28 Jan 2011 19:54:56 +0000 (UTC), Grant Edwards >>>> The MSP430 would feel very >>>> familiar to anybody who had worked with a PDP-11. >>> About like a staple-gunned, sawdust-board knock-off bookshelf >>> reminds me of one decently designed and fabricated from >>> select Cherry pieces that the cheap version was intended to >>> mimic. It's when you put hands on the two that you know >>> which is much better than the other. >>> >>> Jon >> msp430 is about as close as you can get to pdp11 architecture, >> without actually having one, > > Without getting into niggling issues such as binary object > code compatibility (which doesn't matter to me) or source > code compatibility for the assembler (which also doesn't > matter to me), I see no reason at all why the instruction set > designer failed to learn as well as should have been done, > from what had already gone before. > > What isn't acceptable is to take wrong turns into dead ends > when others have already surveyed the territory, examined > those dead ends, and beaten down the right path for you for a > much more successful path. > > The design of the PDP-11 is very good, but I've still no > doubt at all that a clever designer may be able to do still > better. Especially in a modern context that the old PDP-11 > designers couldn't have anticipated. And I'd bow deeply to > such a successful effort. > > But *this* designer made needlessly stupid mistakes. And to > a German, that statement stings. > >> but the limited address space > > The MSP430 (even before it was so named) possessed a 16-bit > register size and a 16-bit address bus, so far as I'm aware. > Same with the PDP-11. Newer versions of the PDP-11 had to > deal with an expanding physical address bus width, and they > chose one route. The MSP430 also had to deal with expanding > physical address bus width and later incarnatins dealt with > that need somewhat differently. > >> and lack of external address bus limits it's application. > > A huge advantage to modern designs is the ability to > integrate so much into a single IC and this applies to the > MSP430. It is not a problem when ICs include large memories > within an IC package, don't include all the extra pins (which > are, in many cases, the pricing driver) for an external > address bus. Lower pricing, easier board design and stuffing > costs, easier prototyping, etc., are pretty nice things to > have. Had it been possible in the PDP-11 days, I'm sure it > would have champed at the bit for such an opportunity to > reduce all that external hardware and attending problems. > > The absolutely wonderful thing today is that there are so > many options, even in this difficult economy period. One can > buy in singles, or hundreds, or hundreds of thousands. One > can buy SOT-23, DIP8, SOIC 44, or a 288-BGA. External bus or > none. 8-bit ALU, 16-bit ALU, 32-bit ALU.... Hardware > multipliers, hardware dividers, floating point (or not), etc. > > There are so many choices that in many cases there is more > than one GOOD choice and one can instead choose based upon > the kind of partner they are looking for. > > It's not a problem to lack an external bus. It's a matter of > targeting. > >> Perhaps later versions have addressed this. >> <snip> > > None that I've used. But I'm not keeping up to date on all > the MSP430s coming out, either. > > JonI still have a look at the TI msp pages from time to time, but I think you are right in that TI never saw it as a long term expandable architecture. Otherwise, why would they effectively sit on it for ten years while the rest of the world moved on ?. I guess in the end, a gp 16 bit register set doesn't translate well to > 16 bits worth of address space, however it's done... Regards, Chris
Reply by ●January 31, 20112011-01-31
Tauno Voipio wrote:> On 30.1.11 10:17 , ChrisQ wrote: >> Tauno Voipio wrote: >> >> Much more work to do, but a couple of other things. The stm32F series >> has an external memory interface which should make it easy to drive >> memory or mapped lcd controller devices. Both also have fancy dma modes, >> but the nxp series also has a scatter gather dma mode via linked lists >> in memory, which could be very usefull in optimising io bandwidth. >> Together with the low end 1100 nxp series, they could replace just about >> all applications here, including 8 bit. They are relatively cheap as >> well. Time will tell, but nothing else seems to get close in capability >> at present. >> >> What do you think and have you done any work with Cortex ?... > > > There was an accident - the 10 years old production > documents of an AT91 ARM7TDMI -based intelligent sensor > card got destroyed, and the customers want a replacement. > > Our team had to create something fast, and we eneded up > with a LM3S818 Cortex-M chip. Porting the old code to the > new processor was done in two weeks and as a surprise to > everybody, it worked. The toolkit in use is the GNU Compiler > suite (GCC + GDB and binutils) for both targets. The most > complicated thing in the porting was to change the multi- > thread kernel for the newer interrupt and thread switching > hardware mechanisms. > > The Cortex-M is surprisingly fast, especially for handling > interrupts and thread switches.Two weeks :-) - Illustrates better than anything how the use of near common architectures can save time, not to mention the benefit in terms of software reuse. Have you got the Joseph Yiu book on the M3 ?. Bought a copy on abe over the holiday and it's full of usefull info, code examples etc. Fills in most of the gaps in the data sheets and mfr code... Regards, Chris
