ARM microcontroller

updated 2004-01-04

latest ARM info is at

see also 

From: Stan Shebs <shebs at andros.cygnus.com>
Subject: Re: ARM Hardware debugger
Date: 23 Sep 1999 00:00:00 GMT
Organization: Cygnus Solutions
Newsgroups: comp.arch.embedded

"Keith Jasinski, Jr." <jasinski at mortara.com> writes:

> > What do you think of the ARM Software Development Kit versus other
> > manufacturers, ie: Windriver, Microtec(Mentor Graphics), AMC, etc?

Cygnus GNUPro is the best software, of course. :-)

But seriously, we're steadily working on more and more optimizations
for ARM GCC, GDB talks to the EmbeddedICE and (soon) other ICEs as
well, and there is a spiffy board support package that handles a
variety of ARM boards from several different manufacturers.  On top of
all that, you can also get Cygnus' RTOS eCos for ARM.  For details,
check out

        http://www.cygnus.com

and

        http://sourceware.cygnus.com

                                                        Stan Shebs
                                                        Cygnus Solutions
                                                        shebs@cygnus.com

The eCos OS http://sourceware.cygnus.com/eCos has been ported to the ARM.

Look at Europe Technologies www.europe-technologies.com, Hewlett Packard www.tmo.hp.com/go/emulator, Embedded Performance www.episupport.com, and DLI www.dli.de. 

From: William Gatliff <gatliff at haulpak.com>
Subject: Re: [Fwd: How to upgrade flash "on the fly"?]
Date: 24 Sep 1999 00:00:00 GMT
Newsgroups: comp.arch.embedded

Stephen:


> I'm using a embedded CPU and ONE external flash and RAM. It has its own
> compiler. I would like to know how can i program such that i can erase and
> program certain blocks (which do(es) not need to store the program) on the
> flash using the same system, i.e., program by ITSELF?

You didn't say *which* cpu or flash chip, unfortunately.

The trick in this case is to be able to run code from somewhere other than
the flash chip, while you're programming it.  In most cases, you can't fetch
code from a flash chip while you're erasing or programming it.

Standard approach is to compile a flash-programming application for
position-independence (a.k.a. "PC-relative"), and then memcpy() it into
RAM before you start erasing the flash.  Then jump to the RAM copy and
program the flash at will.

Knowing the CPU is important, because devices like the 8051 need external
hardware to allow them to run code from RAM.  In particular, you have to
wire-OR your PSEN and RD lines together, which does all kinds of ugly things
to your memory map.

Flat-address-model processors like the HC11, Z80 and 68K don't need this---
they can run code from just about anywhere in their address space without
modification.

Knowing the flash chip is important, because some of the most recent devices
are really two (or more) flash chips in one, and so you can fetch code from
one half while you're programming the other.

If you're planning on doing this for a commercial product, then plan on
attending an Embedded Systems Conference before your product ships.  There
are speakers giving presentations on exactly what you're trying to do, and
they will provide additional pointers on how to avoid some particularly nasty
failure modes specific to flash-based designs like yours.

b.g.

--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems
To teach is to learn.






From: gneuner at dyn.com (George Neuner)
Subject: Re: Code for a Small Parser??
Date: 24 Sep 1999 00:00:00 GMT
Organization: Dynamic ReSolutions, Inc.
Reply-To: gneuner at dyn.com
Newsgroups: comp.arch.embedded

On Thu, 23 Sep 1999 09:30:07 -0700, "Edward K"
<edwardk@NOSPAMpacscitech.com> wrote:

>Does anyone know of a C parser that is suitable for embedded
>applications? It needs to handle simple ascii commands.
>
>It would be great if it:
>
>1. Were public domain
>
>2. Easily modified for syntax
>
>3. Small memory footprint
>
>4. Documented (Ha Ha)
>
>Thx in advance for any help.
>
>EdwardK
>

Generally if you want a "small" parser, you write it yourself.
Generated code is typically larger than what you would do - the
advantage is simply that you don't have to write it all.

GNU's [www.gnu.ai.mit.edu] Bison & Flex combination is good, but the
minimum parser size tends to be around 20Kb.  Flex itself can do very
simple parsing jobs but it is limited to recognizing regular
expressions.  If you need more you have to add Bison which can
recognize LALR(1) grammars.  Both tools generate table driven automata
which can be difficult to debug.  Also inserting your own code into
the EBNF grammar can get tricky because of the way Bison works.

A better choice if you need more than regular expressions is either
PCCTS or ANTLR [both from www.antlr.org].  PCCTS recognizes predicated
LL(k) grammars and generates recursive decent parsers in "C".  Its
generated code supports custom parameters so you can easily pass
auxiliary data in and out of the parser.  PCCTS does still uses
regular expressions and a table driven automata for its lexer, however
you can fairly easily substitute your own hand-coded lexer or one
generated by Flex.

If your target supports C++, ANTLR is a much better choice.  ANTLR is
a newer version of the parser tool in PCCTS.  It now accepts EBNF for
both parser and lexer and can generate recursive decent code for
either in C++ or Java.  ANTLR itself requires the JDK to run because
it is written in Java.  Generated C++ code makes heavy use of the STL
so your compiler has to support that.

PCCTS and ANTLR are easier to use, easier to debug and more powerful
than Bison for dealing with complicated grammars.  For easy things,
any of them will do, although PCCTS with a hand-coded lexer will give
you the smallest code.


George Neuner
Dynamic Resolutions, Inc.
===================================================
The opinions expressed herein are my own and do not
reflect the opinions or policies of my employer.
===================================================

started 1999-09-25

end arm.html