Using C to program the 8051 family

magnitude

Ok - just did a search on the H8. Seems like prices in order of 6-7 $ for a

5MIPS one (sloooooooooooooooooooow)

I using Cygnal

these days:

25MIPS 80C51Fxx with onchip mixed signal design, ADCs, comparators and so on. Cost about from 1$ up ;-) 100MIPS types are there too - but haven't had the need yet....

Cheers

Klaus

Come Klaus, part numbers please.

80C51F304, 25MIPS, 11pin MLP package (about the outline of a SOT-23 BJT), 3$/100pcs at digikey (expensive retailer)

Barn - partnumbers, prices, specs?

Cheers

Klaus

The H8 "value series" is a bit cheaper: $3.99 for a 25MHz part w/ 128K flash and 4K RAM (8 32-bit registers that can be used as 16 8 or 16 16-bit register, 32-bit ALU, 8 adn 16-bit addressing modes, A/D, D/A, 2xUARTs, 16MB address space, etc. Free toolchain (Gnu) free OSes (eCos, uCLinux, etc.), nice regular instruction set, free IDE framework from Hitache that uses Gnu, IAR or other toolchain. Very nice part to work with.

--
Grant Edwards                   grante             Yow!  WHOA!! I'm having
                                  at               a RELIGIOUS EXPERIENCE
                               visi.com            right NOW!!

I'm gobsmacked! I've been writing code in many languages for 30+ years in several domains including deep embedded. I have learned over time that debugging methodology is far more important than anything else. Debugging is a simple application of scientific method.

begin begin Observation Hypothesis Experiment with yes/no answer until (this bug is fixed) until (number of bugs=0)

Of course, I admit to the failure case when there are no observed bugs to begin with.

The point is that your debugging tools are only an aid. The basis of testing for reliability is bottom-up testing. There's no point in testing higher level functions until the lower levels are themselves tested. It is vastly easier and very much faster to perform bottom-up testing using an interactive language than with a C debugger and an ICE.

When you say interpreted, what do you mean? Forth is always interactive (you can talk to the hardware through a text interpreter). Some Forths are implemented as Threaded Interpretive Languages (TILs) and some generative optimised native code as good as that produced by any C compiler.

Nearly all Forths provide all the target source code.

Most of the jobs I do in Forth are hard real time. Bomb disposal and anaesthetic ventilators are also safety critical.

An ICE is a wonderful tool every so often, but it's just one of the tools available. Of course you can ICE an interactive language. Of course you can ICE a TIL. Whether an ICE is an appropriate tool for either is another matter.

Apart from myself, Paul Bennett and Elizabeth Rather are regular Forth users and posters to this newsgroup. I've met Albert and the others face to face. I regard them all as professionals.

Stephen

-- Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time

133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: - free VFX Forth downloads

That depends on the timing requirements of the application. I have, on occasion, written realtime applications in interpreted Basic where speed was not an issue.

I haven't used Forth, but my recollection is that Paul Bennett, the hard-core Forth programmer in this group, uses Forth for critical applications BECAUSE the whole system can be verified. My understanding (IANAFP) is that you normally work with source of the entire system. In C, many implementations do not distribute the source for the entire library, let alone the compiler and linker, which are all critical components.

As far as debugging in hard realtime, I end up doing a lot of it with a scope/logic analyzer.

I do agree that C is a good language for critical realtime applications, assuming you are careful and know the implementation well.

Thad

Hitachi do sell some amazingly low cost processors. They are lacking however in certain areas of peripheral integration e.g. LCD drivers. Also, I hope IAR have cleaned up their act a lot because last time I used their C compiler on an H8 it was riddled with bugs and inefficiencies.

Ian

[...]

As always: the right mix of peripherals is the key. I've never needed an LCD driver.

Dunno, the Gnu tools work great for me.

The linker didn't have a feature I wanted -- so I added it. Try that with IAR or Keil or Hi-Tech or whoever. ;)

--
Grant Edwards                   grante             Yow!  YOW!! Now I
                                  at               understand advanced
                               visi.com            MICROBIOLOGY and th' new
                                                   TAX REFORM laws!!

A Forth application begins with a fully functional kernel which includes an interpreter so you know things work before writing your first word (command) so even at this early stage you know something about your hardware. Perhaps not the connected peripherials yet but at least the micro core, memory, power supply, and communication channel are known functional.

Then, as you begin to add your code, each word (think module or sub-routine) is incrementally compiled and immediately available for interpretative execution in real time.

Even assembler can be written and incrementally executed by calling the subroutine from within a 'word'. Many Forth environments also include a single-step debugger, including ours, which permit you to execute your code one word at a time, in real time, on the actual hardware. No simulators, no emulators, no In Circuit Emulators required.

Here are a couple of good articles that explain better:

-- Regards, Albert

---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts

916.780.7623

----------------------------------------------------------------------

Agreed, sorry if I implied otherwise.

-- Regards, Albert

---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts

916.780.7623

----------------------------------------------------------------------

Nope, Forth executes in real time. Better yet is that it executes on the actual hardware, not in an ICE.

Perhaps you aren't familiar with Forth for all dialects that I'm currently aware of give great detail and debuggability. Certainly greater than a compile-only language such as either Assembler or C.

Agreed, to a great extent. There are a lot of 'professionals' using the Parallax Basic Stamp for instance, just look at their success. It's incredibly cheap and quite functional for simple applications. I'm not a language zealot however, I will use the best tool for the job. I don't use Forth in systems administration or on web pages although it is possible. Basic has it's place but I don't care for it either.

Or perhaps I've made a well-kept secret public? The number of users says absolutely nothing about tool.

-- Regards, Albert

---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts

916.780.7623

----------------------------------------------------------------------

family?

Yes. Many of my complaints of the C language has to do with library functions written by others which are generic by nature. I see two faults with this which override the advantages in my opinion. First is that the library routines are rarely reviewed by the programmer, just plugged in and assumed to be correct. This is one of the major problems in Windows and even Linux/BSD too. Others have mentioned 'safety-critical' applications, do those same people review every line of code in their included libraries?

Secondly, few people turn off the optimizer when using C. Earlier C compilers didn't even give you this option. When I laboriously hack a chunk of time-critical code I don't want the compiler messing with it later after testing.

Third, C is essentially impossible to debug without a In Circuit Emulator. Even when using an ICE you cannot guarantee that your circuit will behave identically when the ICE is replaced with silicon. ICE's have different fan-outs, different rise times, different responses than a production 8051 from your favorite vendor. Yes, and ICE is _nearly_ the same but I've seen problems creep in shortly after production release or after a change in silicon or new vendor months down the road due to circuit performace affecting the microcontroller. Granted that is rare but I don't like being surprised this way.

Having done a number of biomedical applications, including one which still scares the hell out of me by taking a blood or cerebral-spinal fluid sample from teh patient, I demand a high degree of accountability from my designs. So much so that I admit to being paranoid about the subject. Clients who know what they are doing appreciate this paranoia.

Another arguement is personal preference which doesn't really speak to "Why not C?" but to what I believe is a better tool. I won't go into that here unless requested.

-- Regards, Albert

---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts

916.780.7623

----------------------------------------------------------------------

As an example of this in practice, considering writing a driver for a bank of status LEDs on a device.

1) Start by manually poking the LED output register, to check out the electronics and your understanding of the IO address mapping and bit->LED assignment. Turn the LEDs off, then light each one in turn, then light all four: 0 LED-PORT OUT 1 LED-PORT OUT ( power LED ) 2 LED-PORT OUT ( activity LED ) 4 LED-PORT OUT ( error LED ) 8 LED-PORT OUT ( battery low LED ) 15 LED-PORT OUT ( all LEDs )

...this is typed in interactively; every time you hit RETURN after each line, the action should be performed.

2) Ok, so let's write some code for this. Open up your source file and add some definitions:

VARIABLE led-state

( Set the LEDs. Store the new state in led-state ) : set-leds ( n -- ) DUP led-state ! LED-PORT OUT ;

: led-power-on led-state @ 1 or set-leds ;

: led-power-off led-state @ 14 and set-leds ;

: led-activity-on led-state @ 2 or set-leds ;

...

3) Send the sources to your development device (just get the terminal emulator to send them as if you'd typed them at the keyboard), and then test them:

led-power-on ( power on ) led-activity-on ( power and activity on ) led-power-off ( just activity on ) led-activity-off ( all off ) led-error-on ( should turn on error LED )

But wait! Rather than turning on the error LED, the last command instead turns on the battery-low LED. What could this mean? Let's look at the stored LED state:

led-state @ .

...and the FORTH system responds with 8, when the value should be 4 for the error LED. Looking at the code reveals that we've written:

: led-error-on led-state @ 8 or set-leds ;

Oops! That's what you get for being lazy and dropping magic numbers into your code. So edit the code to read:

1 CONSTANT power-led 2 CONSTANT activity-led 4 CONSTANT error-led 8 CONSTANT battery-led

: led-on ( mask -- ) led-state @ or set-leds ;

: led-off ( mask -- ) invert led-state @ and set-leds ;

: led-power-on power-led led-on ;

: led-power-off power-led led-off ; ... That fixes the bug, and reduces the chance of it coming back when you add more LEDs later.

If you were doing this under C, then:

1) The initial sanity check of the LED electronics would have to be written as a program unto itself, compiled, uploaded, etc. rather than just typed directly into the device

2) When the bug cropped up with setting the error LED, you wouldn't have been able to just examine the state of the system like that without expensive debugging hardware. You'd have had to go back to the source and add debugging code in set-leds, say, to output the value being stored to the serial port, then run the code again. But what if it was a timing-critical transient bug that didn't reliably come back when you tried that? With the FORTH system, you could examine the state of the system as soon as the bug had manifested.

3) If you were doing this in a seperate-compilation language, you would be less likely to run little tests of things as frequently as you could with something interactive, due to the increased cost of writing the test code as a monolithic block in your program, compiling/downloading/running, and looking through the results. If something looks wrong, then you modify the test to examine the problematic area in more detail, and try again until you nail it down. With an interactive system, you type test commands in and watch them execute before your eyes, and as soon as one goes awry you can then start looking for more detail there and then.

4) What hardware and software do you need to do this? A PC linked to the device under test by a serial cable, and on that PC a terminal emulator and a text editor for your source code. As opposed to a cross compiler and special download and debugging cables and/or special hardware. Which means you can write your software from your choice of Mac, Windows, Unix, or AmigaOS, rather than being constrained by what your cross compiler will run on.

When you are finished your development, and your text file on the host PC now contains complete sources for your application, you can reset the development board to a clean slate (the FORTH kernel), compile up the software, set the 'entry point' variable to point to your main routine (rather than the FORTH interpreter it points to by default), and then ask the development board to upload its RAM full of compiled code to the PC as a binary image that you can proceed to burn into EPROM and drop into production boards. But at the flick of a jumper, the FORTH kernel will run its interpreter after setup rather than your chosen entry point, so your field service personnel can boot the device up into a command prompt via a serial cable for maintenance (and if the board boots from flash, perhaps to upload new code). The command prompt can be used to access special test words you have written, or for a motivated engineer to write his own test routines for an interesting new problem. To get the same facility with a project in C would involve writing or incorporating a generic scripting language shell of some kind, then writing wrappers for your own test routines and hardware access code and so on.

ABS

snipped-for-privacy@aol.com (CBarn24050) wrote in news: snipped-for-privacy@mb-m06.aol.com:

No, I wouldn't be saying that about the current Keil package because like modern PCs it's gotten good enough that further improvementts don't really matter much to me. The 2500 never had a good rep. as I seem to recall.

--
- Mark ->
--

. Free toolchain (Gnu) free OSes (eCos, uCLinux, etc.),

Gnu,

I agree, Hitachi is a very nice processor family and not comparable with

8051's. I have a scheduler which is not suitable for 8051 projects because it won't compile (only when I simplify some structures). If you use 'complex' structures or function pointers then the 8051 is not the best choice.

But, for smaller projects it can be very nice programming (even in 'C') .

regards gerard zagema

Aye, there's the rub. How do you troubleshoot the memory and comm stuff?

--
Grant Edwards                   grante             Yow!  Will the third world
                                  at               war keep "Bosom Buddies"
                               visi.com            off the air?

By burning a PROM that tests it, or using JTAG from the CPU...

ABS

If a JTAG interface exists that's a valid alternative but how many 8051's have one other than Cygnal? Even if you have a JTAG interface though you can't easily put a subroutine or function into a loop for scoping.

I think I clearly stated that library errors are rare but when they occur diagnosis is quite difficult. In glibc there have been exploits in the tree on occasion which were later used to cause havok.

Another issue with library functions is that they are generic and sometimes wasteful in execution speed and/or memory useage where routines specifically written for the application will be more optimal.

-- Regards, Albert

---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts

916.780.7623

----------------------------------------------------------------------

16bit

Cbarn24050 - where's your part numbers, spec and price?

\..Klaus