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. ===================================================
[ARM. Summarize] Date: Tue, 18 Jan 2000 12:04:45 -0600 From: d.cary at ieee.org To: d.cary at ieee.org Subject: Re: Need help on choosing ARM C compilers I would really like to help document this ... ??? http://www.deja.com/ (beginning of original message) Subject: Re: Need help on choosing ARM C compilers From: grant@nowhere. (Grant Edwards) Date: 2000/01/10 Newsgroups: comp.arch.embedded,comp.sys.arm In article <9Oqe4.594$TK4.165735@homer.alpha.net>, Keith Jasinski, Jr. wrote: >Perhaps you can answer a few questions for me... > >The gcc and gdb I am aware of are from Cygnus (now Red Hat). >The only tools that I can find from them that target ARM are >$2500/seat (min 3 seats). That's if you want to buy pre-compiled, supported versions from Cygnus. >You say gdb is free, but how is that the case? Am I completely >missing the boat? They seem to have some cheap tools, but none >that will target an ARM processor. The standard gcc, binutils (assembler, linker), and gdb all support the ARM (as well as a bunch of other processors). The catch is that you have to either 1) Build the binaries from source specifying the host and target you want. or 2) Find somebody who has already build the binaries for the host/target combination you want. If you're willing to pay, Cygnus will build the binaries for you and then support them. That's what the $2500 is for. If you look around the web for a while, you can probably find somebody who has made available binaries for the target/host you want, but there are so many possible host/target combinations that there's no single ftp site that has all of them. Building gcc/binutils/gdb from sources isn't all that hard, but it does require a little effort -- mostly because the instructions for building gcc assume that it's for a full-up *nix, libc target environment. Building gcc for an embedded target requires you to skip some stuff you don't need. Somebody is working on updating the documentation for that. -- Grant Edwards grante Yow! Do you think the at "Monkees" should get gas on visi.com odd or even days? (end of original message) ------------------------------------------------------------------------------ You can view this message and the related discussion by following this link: http://www.deja.com/dnquery.xp?search=thread&svcclass=dnserver&recnum=%3cslrn87kgaf.qcm.grant@grante.comtrol.com%3e%231/1 We hope to see you soon at Deja.com. Before you buy. http://www.deja.com/ Date: Tue, 18 Jan 2000 12:09:32 -0600 From: d.cary at ieee.org To: d.cary at ieee.org Subject: Re: Need help on choosing ARM C compilers Reply-To: d.cary at ieee.org thanks for the info. http://www.deja.com/ (beginning of original message) Subject: Re: Need help on choosing ARM C compilers From: grant@nowhere. (Grant Edwards) Date: 2000/01/11 Newsgroups: comp.arch.embedded,comp.sys.arm In article ..., Keith Jasinski, Jr. wrote: >We are currently demo-ing a JEENI from EPI Tools for the >hardware/PC interface. We are looking at ARM SDT 2.5 for tools >(as well as a couple others) all in the multi-K$$$ range. We >really only need a compiler/linker/etc (to generate a file that >can be transfered to the hardware) and a debugger to run with >the JEENI. A software emulator is nice and desirable, but if >the software can be obtained for low-$$$, we can live without >it for now. Our environment is mainly Win95/98, although some >people here use NT. >What is it that people like Cygnus are charging big-$$$ to do >with gcc/gdb? They're charging for support and for the effort they put into setting up and testing pre-compiled binaries in an easy-to-install package. >You mention building binaries for our target environment, but >Win95/98 can't be that hard or unusual. Your target is ARM. Your host is Win32. Getting the gnu stuff built under Win32 is harder than building it under Unix. You need to have the Cygwin package installed. I would be happy to provide Linux(Intel) binaries, but that doesn't do you much good. ;) >Is the intelligence there to generate ARM code (ie: can it do >the job of turning a C or C++ program into machine op-codes >that the ARM will understand? Yes. The standard gnu tools can generate and link ARM code from C/C++. Gdb can talk to the EPI Jeeni via RS-232 or Etherenet and provide source-level debugging. However, when you build the compiler/linker toolset, only support for a single target processor is compiled in. By default, the target processor that is supported is figured out from the host: if you're building gcc on a SPARC machine, it will be compiled so that it generates SPARC code. However, you can tell the configuration utility when you're building gcc that you want to build a compiler that generates ARM code. >Basically, I could care less about support. Usually I find it >overpriced and underused. Support is nice for the first few >days until you get something working. Also, you mentioned (in >a previous message) good free support via web-site and >newsgroup. Can you elaborate where those are? There are mailing lists for cygwin, gcc, binutils, and gdb. >Where do I start getting what I am looking for? I found >www.gnu.org. The Cygnus site someone mentioned in a previous >message in this thread is not valid. I looked around on the Cygnus web/ftp site and didn't see cross-compiler binaries available for download. If you want to look, the Cygnus web site is: http://www.sourceware.cygnus.com/ I know you can download the whole eCos-ARM devleopment toolset: (eCOS RTOS sources along with pre-configured gcc, binutils, and gdb sources). But I don't see pre-compiled binaries anywhere. According to the web page below, if you get the complete Cygwin distribution, it includes an ARM cross compiler. http://www.windowstechedge.com/wte/wte-1999-02/wte-02-oss.html If you want to try out the gnu tools, I guess you've got a couple choices: 1) Install the cygwin package that is required for the gnu stuff to run under Windows -- the Cygwin distribution apparently includes an ARM cross-compiler (I don't know if includes an ARM aware version of gdb.) 2) Try out the gnu tools under some sort of Unix (I'd recommend Linux). Being able to compile the tools yourself from source is always a useful thing to be able to do, and I would exepct that it will be easier to do under Linux, and in the long run you'll be better off under Linux. I've made some enhancements to the ARM-RDI code in Gdb (the code that talks to the EPI Jeeni), so if you use gdb, you want a recent copy (not more than a couple weeks old). -- Grant Edwards grante Yow! I'm having a MID-WEEK at CRISIS! visi.com (end of original message) ------------------------------------------------------------------------------ You can view this message and the related discussion by following this link: http://www.deja.com/dnquery.xp?search=thread&svcclass=dnserver&recnum=%3cslrn87mrqh.24q.grant@grante.comtrol.com%3e%231/1 We hope to see you soon at Deja.com. Before you buy. http://www.deja.com/ [ARM.html] Date: Tue, 18 Jan 2000 12:12:21 -0600 From: d.cary at ieee.org To: d.cary at ieee.org Subject: Re: Need help on choosing ARM C compilers Reply-To: d.cary at ieee.org http://www.deja.com/ (beginning of original message) Subject: Re: Need help on choosing ARM C compilers From: karuottu at freenet.hut.fi Date: 2000/01/12 Newsgroups: comp.arch.embedded,comp.sys.arm On Mon, 10 Jan 2000 13:56:42 -0600, "Keith Jasinski, Jr."wrote: >Perhaps you can answer a few questions for me... > >The gcc and gdb I am aware of are from Cygnus (now Red Hat). The only tools >that I can find from them that target ARM are $2500/seat (min 3 seats). > >You say gdb is free, but how is that the case? Am I completely missing the >boat? They seem to have some cheap tools, but none that will target an ARM >processor. Heard about EPOC ? The rival for WinCE in those Nokia, Ericsson, Motorola, etc. 'handhelp computers', which one can use to make cell-phone calls too... At least Nokia and Ericsson use ARM... Ok, the toolset for EPOC is GNU-based and is freely downloadable (EPOC isn't). Please see: 'www.epocworld.com'... I think Atmel is going to release a GNU toolset for their AT91... My old 'arm-coff' tools (egcs-1.1-based) have been available for download over a year now... Please see: http://www.saunalahti.fi/~ankosk2/embtools.htm And check also Andy Hare's webpage: http://www.hare.u-net.com/mainpage.htm You will get just as much support as you are willing to pay, starting with $20-50 for up-to-date-prebuilt ARM tools 'as is' in diskettes or in a CDR... Cheers, Kai (end of original message) ------------------------------------------------------------------------------ You can view this message and the related discussion by following this link: http://www.deja.com/dnquery.xp?search=thread&svcclass=dnserver&recnum=%3c387d10df.18453344@news.nettilinja.fi%3e%231/1 We hope to see you soon at Deja.com. Before you buy. http://www.deja.com/ Date: Tue, 18 Jan 2000 12:18:01 -0600 From: d.cary at ieee.org To: d.cary at ieee.org Subject: Re: Need help on choosing ARM C compilers Reply-To: d.cary at ieee.org http://www.deja.com/ (beginning of original message) Subject: Re: Need help on choosing ARM C compilers From: "Andy Hare" <andy at hare.u-net.com> Date: 2000/01/13 Newsgroups: comp.arch.embedded,comp.sys.arm Hi, Actually the web address given for my homepage is wrong, this will only get the main pane and not the rest of the site. Please use http://www.hare.u-net.com/home.htm. I have pre-built versions of the ecos toolset and the insight debugger running under CYGWIN b20.1 on an NT machine. I have used the same toolset under windows 95 but sometimes the results are suspect. The debugger works fine with the ATMEL EB01 development board. I am looking at adding the toolset and insight to my download section of my web pages but they currently weigh in at 20+MB and I only have 25 MB of web space. I need to find a better method of compressing them than PKZIP. If you need any more pointers then you are welcome to email me and I will try and help. Andy Hare Kai Ruottu wrote in message news:387d10df.18453344@news.nettilinja.fi... > On Mon, 10 Jan 2000 13:56:42 -0600, "Keith Jasinski, Jr." > wrote: > > >Perhaps you can answer a few questions for me... > > > >The gcc and gdb I am aware of are from Cygnus (now Red Hat). The only tools > >that I can find from them that target ARM are $2500/seat (min 3 seats). > > > >You say gdb is free, but how is that the case? Am I completely missing the > >boat? They seem to have some cheap tools, but none that will target an ARM > >processor. > > Heard about EPOC ? The rival for WinCE in those Nokia, Ericsson, > Motorola, etc. 'handhelp computers', which one can use to make > cell-phone calls too... At least Nokia and Ericsson use ARM... > > Ok, the toolset for EPOC is GNU-based and is freely downloadable > (EPOC isn't). Please see: 'www.epocworld.com'... > > I think Atmel is going to release a GNU toolset for their AT91... > > My old 'arm-coff' tools (egcs-1.1-based) have been available for > download over a year now... Please see: > http://www.saunalahti.fi/~ankosk2/embtools.htm > > And check also Andy Hare's webpage: > http://www.hare.u-net.com/mainpage.htm > > You will get just as much support as you are willing to pay, > starting with $20-50 for up-to-date-prebuilt ARM tools 'as is' in > diskettes or in a CDR... > > Cheers, Kai > (end of original message) ------------------------------------------------------------------------------ You can view this message and the related discussion by following this link: http://www.deja.com/dnquery.xp?search=thread&svcclass=dnserver&recnum=%3cVkKf4.1299$bc6.87865@newsr2.u-net.net%3e%231/1 We hope to see you soon at Deja.com. Before you buy. http://www.deja.com/
http://www.robots.net/article/525.htmlSSV Embedded Systems has announced a very small StrongARM-based SBC. The new PNP/1110 board is just 45mm x 45mm (less than 2" square). It features a 206MHz intel StrongARM CPU, 64MB SDRAM, 16MB Flash, LCD interface, two serial ports, PCMCIA, CompactFlash, 10/100 Mbps Ethernet, 18 GPIO lines, and other I/O. It includes a full Linux 2.4.18 kernel with JFFS support and draws just 400ma at 3.3VDC.
started 1999-09-25
end arm.html