Reply by jsm09a January 19, 20112011-01-19
--- In l..., David Smead wrote:
>
> What's the source of that claim?
>
> > ... in the safety critical world, you're lucky to get two lines a day (once
> > documentation and testing is taken into account).

Probably painful experience ;) Carrying on from above, if a "high level language" is a time multiplier, safety certified code is a time divider. We have a "moderate" safety piece of code whose executable file is 22K bytes and the corresponding documentation, test procedures/reports, etc is probably pushing 1000 pages ...

An Engineer's Guide to the LPC2100 Series

Reply by Nicholas Lusty January 19, 20112011-01-19
The cfg file syntax is explained at
http://openocd.berlios.de/doc/html/Config-File-Guidelines.html

----- Original Nachricht ----
Von: David Smead
An: l...
Datum: 19.01.2011 05:10
Betreff: Re: [lpc2000] Re: ARM Cortex M3 assembly language example

> Thanks, but I don't know how to interpret your source and find statements.
>
> On Tue, Jan 18, 2011 at 6:28 PM, Frank Sergeant
> wrote:
>
> >
> >
> > David Smead > writes:
> >
> > > I don't use ST processors yet, but am considering it. Could you share
> > > your OpenOCD config file?
> >
> > The OpenOCD config file is listed in the note
> >
> >
> > http://pygmy.utoh.org/riscy/cortex/led-stm32.html
> >
> > --
> > Frank
> >
> >
>
Nicholas Lusty
Mead House
High Street
Box
CORSHAM
SN13 8NN
UK
Tel: 01225 742619
Reply by David Smead January 19, 20112011-01-19
Thanks, but I don't know how to interpret your source and find statements.

On Tue, Jan 18, 2011 at 6:28 PM, Frank Sergeant wrote:

> David Smead > writes:
>
> > I don't use ST processors yet, but am considering it. Could you share
> > your OpenOCD config file?
>
> The OpenOCD config file is listed in the note
> http://pygmy.utoh.org/riscy/cortex/led-stm32.html
>
> --
> Frank
>
>
>
Reply by Frank Sergeant January 18, 20112011-01-18
"Donald H" writes:

>> Most example programs for the ARM Cortex M3 appear to be fairly "heavy",
>> perhaps requiring C and Eclipse

> If I use TECO, will my programs be smaller ?

Somehow, I think your programs would feel *larger* if you used TECO,
while actually remaining the same size. ;)
--
Frank

Reply by Frank Sergeant January 18, 20112011-01-18
Daniel Widyanto writes:

> For LPC17xx ARM Cortex-M3 assembly language example, try:
> http://embeddedfreak.wordpress.com/2009/08/09/cortex-m3-blinky-in-assembly/

Thanks for posting that. It looks like adding the ".thumb_func"
directive before a function would eliminate the need for the "... + 1"
in my vector table.
--
Frank

Reply by Frank Sergeant January 18, 20112011-01-18
David Smead writes:

> I don't use ST processors yet, but am considering it.  Could you share
> your OpenOCD config file?

The OpenOCD config file is listed in the note

http://pygmy.utoh.org/riscy/cortex/led-stm32.html
--
Frank

Reply by David Smead January 18, 20112011-01-18
What's the source of that claim?

On Tue, Jan 18, 2011 at 7:41 AM, Nicholas Lusty wrote:

> ... in the safety critical world, you're lucky to get two lines a day (once
> documentation and testing is taken into account).
>
> ----- Original Nachricht ----
> Von: rtstofer >
> An: l...
> Datum: 18.01.2011 06:22
> Betreff: [lpc2000] Re: ARM Cortex M3 assembly language example
> >
> >
> > --- In l... , Howard
> Hansen wrote:
> > >
> > > How much difference does the start up code make between the size of an
> > > application written in assembler and C? I have seen a comment by an
> > > author saying that the start up code for C source projects
> significantly
> > > increases the size of a small application byte file.
> > >
> > > Howard
> > >
> > >
> >
> > Sure, it doesn't make much sense to have 256 bytes of startup code to
> > support a 100 byte application.
> >
> > But, if the application is of a size where C is the best way to write it,
> a
> > minor amount of startup code isn't very significant.
> >
> > High level languages are simply a time multiplier. A programmer can only
> > write just so many lines of correct code per day and, in the past, this
> was
> > thought to be about 100 lines. If a high level language reduces the
> number
> > of lines of code in the application, it is a time multiplier. Assuming,
> of
> > course, that the resulting code runs fast enough to implement the
> > application.
> >
> > I guess it can also be argued that high level languages are also easier
> to
> > maintain and, in this regard, the HLL is a cost reducer.
> >
> > It is certainly possible to gain much of the structure of a high level
> > language with assembly language and macros. We certainly did that in the
> > early days of the 8080, Z80 and 8086.
> >
> > "It is possible by ingenuity and at the expense of clarity to do almost
> > anything in any language. However, the fact that it is possible to push a
> > pea up a mountain with your nose does not mean that this is a sensible
> way
> > of getting it there."
> >
> > Christopher Strachey
> > NATO Summer School in Programming
> >
> > Paraphrased from Chapter 1 of "A Compiler Generator" by McKeeman, Horning
> > and Wortman.
> >
> > Richard
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
Reply by Nicholas Lusty January 18, 20112011-01-18
... in the safety critical world, you're lucky to get two lines a day (once documentation and testing is taken into account).
----- Original Nachricht ----
Von: rtstofer
An: l...
Datum: 18.01.2011 06:22
Betreff: [lpc2000] Re: ARM Cortex M3 assembly language example

> --- In l..., Howard Hansen wrote:
> >
> > How much difference does the start up code make between the size of an
> > application written in assembler and C? I have seen a comment by an
> > author saying that the start up code for C source projects significantly
> > increases the size of a small application byte file.
> >
> > Howard
> >
> > Sure, it doesn't make much sense to have 256 bytes of startup code to
> support a 100 byte application.
>
> But, if the application is of a size where C is the best way to write it, a
> minor amount of startup code isn't very significant.
>
> High level languages are simply a time multiplier. A programmer can only
> write just so many lines of correct code per day and, in the past, this was
> thought to be about 100 lines. If a high level language reduces the number
> of lines of code in the application, it is a time multiplier. Assuming, of
> course, that the resulting code runs fast enough to implement the
> application.
>
> I guess it can also be argued that high level languages are also easier to
> maintain and, in this regard, the HLL is a cost reducer.
>
> It is certainly possible to gain much of the structure of a high level
> language with assembly language and macros. We certainly did that in the
> early days of the 8080, Z80 and 8086.
>
> "It is possible by ingenuity and at the expense of clarity to do almost
> anything in any language. However, the fact that it is possible to push a
> pea up a mountain with your nose does not mean that this is a sensible way
> of getting it there."
>
> Christopher Strachey
> NATO Summer School in Programming
>
> Paraphrased from Chapter 1 of "A Compiler Generator" by McKeeman, Horning
> and Wortman.
>
> Richard
>
Reply by David Smead January 18, 20112011-01-18
My start up file, crt.s, which does all the stack stuff, sets up trap
vectors, call functions to set up the clock and task manager results in an
object size of 348 bytes.

DaveS

On Mon, Jan 17, 2011 at 8:34 PM, Howard Hansen wrote:

> How much difference does the start up code make between the size of an
> application written in assembler and C? I have seen a comment by an author
> saying that the start up code for C source projects significantly increases
> the size of a small application byte file.
>
> Howard
>
> On 1/17/2011 3:09 PM, Frank Sergeant wrote:
>
> Most example programs for the ARM Cortex M3 appear to be fairly "heavy",
> perhaps requiring C and Eclipse, or a particular vendor's trial
> development tools. An example available on the Olimex site uses 4000+
> bytes to blink an LED.
>
> What about those who are less maximalist?
>
> I have written a short note showing an example LED-blinking assembly
> language program and how to assemble and link using the GNU ARM tools
> and how to burn it into flash using a JTAG adapter and OpenOCD. The
> binary is about 100 bytes.
>
> Even though this is an LPC group and the example is for the Olimex
> STM32-P103 ARM Cortex M3 board, most of the information would also apply
> to the LPC Cortex M3 chips.
>
> http://pygmy.utoh.org/riscy/cortex/led-stm32.html
>
> It runs on Linux (even the 32-bit Ubuntu 10.04 live CD) and the GNU
> tools are available for easy installation onto an Ubuntu 10.04 system at
> http://pygmy.utoh.org/riscy/ (look for "The Tools Bundle").
>
> --
> Frank
> http://pygmy.utoh.org
>
>
Reply by Daniel Widyanto January 18, 20112011-01-18
Hi,

For LPC17xx ARM Cortex-M3 assembly language example, try: http://embeddedfreak.wordpress.com/2009/08/09/cortex-m3-blinky-in-assembly/

Regards,
-daniel

--- On Tue, 1/18/11, Donald H wrote:

> From: Donald H
> Subject: [lpc2000] Re: ARM Cortex M3 assembly language example
> To: l...
> Date: Tuesday, January 18, 2011, 5:14 AM
>
>
> --- In l...,
> Frank Sergeant wrote:
> >
> > Most example programs for the ARM Cortex M3 appear to
> be fairly "heavy",
> > perhaps requiring C and Eclipse
>
> If I use TECO, will my programs be smaller ?
>
>
> ;-)
>
>
> , or a particular vendor's trial
> > development tools. An example available on the
> Olimex site uses 4000+
> > bytes to blink an LED.
> >
> > What about those who are less maximalist?
> >
> > I have written a short note showing an example
> LED-blinking assembly
> > language program and how to assemble and link using
> the GNU ARM tools
> > and how to burn it into flash using a JTAG adapter and
> OpenOCD. The
> > binary is about 100 bytes.
> >
> > Even though this is an LPC group and the example is
> for the Olimex
> > STM32-P103 ARM Cortex M3 board, most of the
> information would also apply
> > to the LPC Cortex M3 chips.
> >
> > http://pygmy.utoh.org/riscy/cortex/led-stm32.html
> >
> > It runs on Linux (even the 32-bit Ubuntu 10.04 live
> CD) and the GNU
> > tools are available for easy installation onto an
> Ubuntu 10.04 system at
> > http://pygmy.utoh.org/riscy/ (look for "The Tools
> Bundle").
> >
> >
> > --
> > Frank
> > http://pygmy.utoh.org