Learning embedded coding, which uC?

Hello Stephen,

As long as SW folks write formal comments, that is. I have seen code that had barely any comments and other that contained lines such as "Works fine with xyz.dll but not the two others. Don't really know why so don't use the others".

Documenting well while doing the design and not as an afterthought always improves the design quality. In environments with mandatory design back tracking (design history) it's the only way to go. Here in this place projects won't be handled any other way.

Regards, Joerg

Of course you do but you work for:..

Forth based HIDECS Consultancy

I have been in the industry 20 odd years and come across very few using Forth. I think it is not very common. You get the work because you are known and have a history.

So for the OP to get food on the table learn C and assembler for 8051, ARM and PIC and then later learn Forth. Unless you are going to share leads and contacts with the op?

The general thrust of what you say matches my own experiences, too. I've never had a single client even _ask_ me, even as a matter of pure curiosity let alone one of legitimate concern, if I knew Forth. Not in my 32 years of programming (roughly, and coincidentally, about the time since Chuck Moore developed the idea.)

The dream of trying to forge a livelihood by becoming one of the few big fishes in a very tiny pond or puddle isn't an easy one to follow.

...

But I'd like to make another comment about Forth. I believe the PCI specification, which Intel touted as being bigger than just an x86 specification, notes support for two approaches for a board manufacturer to use in coding their initialization/boot code on their board (part of Plug and Play.) One is x86 code and the other is some kind of Forth. The intent was to allow non-x86 machines to properly initialize PCI based boards on a PCI bus (such as some DEC Alphas supported.)

A PCI board maker building a board for x86 machines, but wanting to support other platforms (Macs?), could code up both an x86 block of code as well as a Forth block. The x86 BIOS would naturally jump to the x86 code block, but the other platform would instead execute the Forth code block. Or a board maker could only supply the x86 code and be only compatible with x86 platforms. But a board maker supplying only Forth code could theoretically expect to run on all platforms supporting Forth. The only caveat here was the almost _chiding_ I got in a meeting I was part of with some folks from Phoenix discussing writing a new BIOS for 64-bit machines, when I brought up the question of supporting Forth in the new BIOS. It was clear they had no intent of doing so and I gathered, for the first time, that most 32-bit BIOS implementations on x86 didn't support Forth-coded initialization of PCI boards, either.

This early Forth requirement under PCI from Intel (early 1992 through

How all this plays into a job market, I've no idea. I currently do not believe that x86 machine BIOS's even bother with the idea, though I could be very wrong about that point. But if that is true, then a great many board makers focused entirely on serving the x86 market won't worry their pretty heads too much about it, either. But there are folks making boards for a non-x86 PCI market, slim and thin as that may be, and they may need to develop Forth code to initialize their boards, consistent with IEEE 1275-1994.

Can anyone comment on the details of all this?

Jon

... snip ...

Can they? It seems to me there are Forths and other Forths. If you start from words in Ascii coding there has to be some sort of kernel interpreter built in somewhere. IIRC words are generally tokenized into machine addresses, and at least those of the kernel would need to be known in advance. It sounds like a lot of wriggly worms.

Can they what?

Yes, that's true. When I worked at Intel, the internal documents on the PCI specification provided specific details on the Forth. Intel, at least on paper, was trying to push the PCI specification as a "green bus" (environmentally friendly low-power reflection wave rather than incident wave) and as a plug and play bus that transcended beyond their x86 architecture. They wanted PCI to be seen as not just an x86-only bus.

To get there, there was no escaping the need of some PCI cards to provide their own initialization code. And if the PCI bus was to be truly seen as not being exclusively x86, then there was also a need to support that initialization without forcing others to emulate x86 instruction sets. So that's why Forth was added to the spec, as I understand it.

The Forth spec was specialized and thoroughly spec'd, I believe. After a couple of years, it made it out of IEEE as a new Open Firmware specification, namely IEEE 1275-1994. I don't know if that has been since updated, though.

It would have been a disaster to have specified "Forth" and not to have specified the details.

As I mentioned, at least in theory, the requirement would be that the BIOS of any system supporting one or more PCI buses also provide a conforming Forth implementation, one that meets IEEE 1275-1994. In this fashion, a board maker could simply write appropriate Forth code and be certain that it would properly initialize the card on boot-up. There was no requirement that the operating system driver be on the board, though, so this is only about getting the card initialized.

My short experience in meeting with Phoenix BIOS coders was that there was "no way in hell" that they were going to provide Forth on an x86 machine. The PCI specification explicitly provided for two kinds of code blocks -- an x86 marked code block and an Fcode marked code block

-- if my memory serves here. But the BIOS writers for x86 machines, from what I took of their comments then, figured that since one of these options is x86 initialization code that they simply could be arrogant about it and demand that this code block be provided (or else it was "tough nuts" to the board maker.) I could have taken a wrong impression, but they didn't seem all that interested in providing Forth support when I talked with them.

As I recall, the process runs like this. The BIOS code finds and copies a code block out of the ROM image on the PCI board and into system memory. The BIOS then 'calls' this initialization module with three parameters (the bus number, device number, and function number.) Then the initialization code turns right around and calls the BIOS to convert these into the contents of the base address registers. At this point, the initialization code an set out to initialize the board/device. There are provisions for dealing with interrupt chaining, etc. But this is basically what is required under the device driver initialization model that Intel worked out (DDIM) and is part and parcel with Plug and Play, as I remember it.

In the case of using Forth here, the BIOS provides the tokenizer for the ASCII-based source code in the copied ROM image. The output of this tokenizer is Fcode. The BIOS would also provide the interpreter for this tokenized Fcode, which runs appropriate machine language that is specific to the processor, of course.

There is a PCI expansion ROM header and, if I remember, this includes a pointer to a ROM data structure. In that structure, pointed to by the header, the byte at offset 14H carries the special value called "code type" and is a 00h for Intel x86 code blocks and a 01H for Open Firmware Forth code blocks. So far as I'm aware, all the other values from 02H to 0FFH are reserved. I'm not positive, but I believe that a device or board may have several of these ROM structures and the BIOS may select from them. But I could be wrong about that.

Jon

If you're really interested in a good answer, I expect posting to comp.lang.forth would get you several. It's been a few years, but when I hung around there, it was a pretty lively and knowledgable group.

Regards,

-=Dave

I am sure that Elizabeth Rather would be able to provide the most detailed answer on that topic if you care to ask the question in comp.lang.forth. I know that the Open Firmware standard (IEEE1275) was developed from the work at Sun Microsystems and is included on each and every Sun workstation. The Forth code in the ROM, I think, would be a byte-coded version of the source code.

It's my own consultancy, yes.

While it may not be met very commonly in the majority of development circles it does emerge in a wide range of systems. One should at least look at Leo Brodies "Thinking Forth" to get a flavour for the philosophy behind Forth. You never know, it may improve the way you think about your approach to programming in other languages too.

Thanks, I will have a look. I do have a forth for my PC but having the time to play with it is another matter.

Forth is not something I would advocate for some one trying to get into the embedded world as a career. The market is too small and specialised. (besides you have most of it :-) After they have got started with C and the main stream 8 bit MCU (where the work is) they could move to forth later.

It is well known that C has many pitfalls and that creating safety critical programs in that language involves a lot of work.

This is specially the case for multitasking where tasks share resources. C has no built in mechanism for the safe execution of concurrent programs. A RTOS provides mechanisms for this but you can still bypass it and write an unsafe applications.

There are many other languages that make life simpler in theory.

High level concurrent languages:

- Ada

- Chill

- Modula-2

- Mesa

- Java - RTSJ Message passing conccurency

- CSP

- Promela

- Handel-C Synchronous languages

- Esterel

- Lustre

- Signal

- Statecharts Hybrid languages

- Polis

- SDL

- System C

- CCSS

Why do developpers still use C and asm when other languages would mean less risk and less effort ?

Are these languages only for academics, or do you use some of them in industrial applications?

I have heard of many of the languages on that list even if I haven't used any of them in earnest. One thing that I think we should ask of those posting such lists of languages is perhaps a short paragraph that indicates the sort of target machine resources required in order to do anything very useful with it. I know some embedded system developers still have to produce systems that use resource limited hardware (mainly as a means to keep the per unit cost down). I don't think the likes of Ada or Modula-2 would be the right choice for those (as an example).

In order to get some feel of proper system size you should perhaps quote the resource requirements in terms of how much is required per Function Point (or 100 function points if that is more sensible).

That explains it. I mistakenly assumed Mod51 was the name of the *language*. A google search for modula-2 8051 turns up a lot more hits.

Thanks

Ian

Hello Lanarcam,

It's a matter of discipline and good documentation. Treat it like hardware.

That requires even better docs and reviews. The most prevalent mistakes I see in C and other programming around me is the fact that most SW folks document after they are done. Or they do not document at all, thinking that a few comment lines are good enough.

I always document while designing. So when I finish the design the document explaining everything is completed at about the same time.

RTOS: We had good results with QNX. Seems to be pretty bullet-proof. But I am not a SW guy by trade.

In industry I have only seen C and assembler. Basic and Pascal are pretty much gone and people go with where there is the largest talent pool. That is C.

Regards, Joerg

Unfortunately that still does not guarantee error free concurrency. Do *you* know if a given operation will be compiled into an atomic one at the assembler level by your compiler?

Ian

What a load of rubbish. Good documentation only ensures the design is documented - it does not ensure the design is good. Code reviews only ensure the code works - not that it is a good design.

Ian

Agreed, but IME, lack of documentation is an excellent indicator of a poor design.

But that alone makes it worth the price, neh?

Regards,

-=Dave

Hello Ian,

I disagree. Without a good documentation process it is almost guaranteed that there will be misunderstandings between team members. Some of these can cause real havoc.

Reviews do increase the quality of a design, HW as well as SW. The reason is simple: The whole review team has a chance to understand what's going on and to ask tough questions. With docs there will be no tough questions and hence a potentially bad product can result.

Sad example: Recently a helicopter crashed about 10 miles from here, the most likely cause was engine failure because of a diaphragm installed in the wrong direction. Had there been a thorough enough design review I suppose someone would have asked the obvious: Why wasn't it designed "keyed" so that it simply will not go in when reversed? I have always asked this question when someone had a non-keyed connector in the drawings, prompting a correction. This would have saved two lives and maybe a third one. He is clinging on by a thread now and might not make it or be severely disabled later.

Regards, Joerg

Agreed, but the converse is *not* true.

Definitely no. I don't want to know it works, I want to know it works the way it is supposed to.

Ian

Hello Ian,

No, it doesn't. That's not my point. My point is that it significantly reduces the number of potential errors. There is no error free design by man on earth. But there are differences in design quality and my experience is that the level of documentation is quite proportional to design quality.

Compilers carry risks. You have to put trust into a product designed by someone else. That's a normal risk and you can't avoid it, short of writing your own compiler. It's the same when you step on an aircraft. While lots of meticulously documented procedures for pilots and others involved are meant to make that flight as safe as possible you still trust Boeing or Airbus that they did their stuff right. Believe me, their doc system is pretty much water tight. You can't even puncture a conformal coating with your scope probe without documenting that fact.

Regards, Joerg