Learning embedded coding, which uC?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I am teaching myself embedded programming as a career move. Could
somebody tell me which microcontroller(s) are most popular in the
industry right now? I've found tons of resources for eg: 8051, PIC, ARM
- but I'm not sure what's most likely to land a job.

Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

Depending on the needs of the application, the main ones seem to be PIC,
68HC12, MSP430, ARM and PC's on PC104 format. However, there is no need to
be limited to just one of those processors. Being able to select and use
any of them in a project is likely to be seen as a worthwhile capability.

Many of the development tools (editors, compilers, source repositories and
change tracking) will allow you to develop in a reasonably high level
language. I would suggest, though, learning a few assemblers (only for
small fragments of coding such as interrupt handlers, fast calculation
routines).

As for self tutoring on software development. For the most part I am self
taught in my software aspects. I have had a few courses in specific
assemblers and high integrity devlopment techniques. Noting you are in the
UK I expect that you shouldn't be too far from some centre for learning.
Why not see if there is a suitable course near you. Additionally, you could
look out for some of the free seminars that the processor companies run
from time to time.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

Learn one thoroughly - doesn't really matter which -  once you get used to micro
programming
techniques in general, learning a new chip doesn't take much effort.
PIC has the advantage of a quickly-memorized instruction set and vast amount of
free resources.
Probably best to start on 8 bit as skills scale better upwards than down.
Learning assembler will make you able to write much better C code when you move
onto bigger systems
as you will have a much better understanding of the underlying hardware.  




Re: Learning embedded coding, which uC?

Quoted text here. Click to load it


I was hoping folks would say PIC, because there's a Maplin shop nearby
that sells PIC programmer/tester kits (Velleman K8048), and I can drive
that from PiKdev on Linux. I figure on turning up to a job interview
with some 8-bit doohickey I designed, breadboarded and coded, plus spec
docs and code printouts. Should make up for lack of formal
qualifications :-)

I assume it's C all the way, though Ada95 and Forth wouldn't hurt?


Re: Learning embedded coding, which uC?
Hello Julian,

Quoted text here. Click to load it

If you can get that stuff locally at decent prices go for it. But mail
order ain't that bad. I get my MSP430 stuff in two days for very little
in shipping costs.

Quoted text here. Click to load it

In today's environment it's C and assembler. Usually inline assembler
which you can embed in your C code. I have never heard anyone in the
industry (medical in my case0 use ADA or Forth.

Important: You need a nice integrated programming suite, often free as a
limited version. You also need a reliable flash programmer, best would
be in-circuit programming so you don't wreck any pins.

Regards, Joerg

http://www.analogconsultants.com

Re: Learning embedded coding, which uC?
Speaking of In-circuit programming - I'm starting with the MSP430.  I've got
the TI Flash Programmer tool, but it only connects to header board or
socket.  What do I use for connecting to the chip in-circuit?  A 3M SOIC
Test Clip?  I'm not sure how to connect it to the TI Flash Programmer tool.

--
---------------------------------------------------------------------
DataGet & PocketLog  www.dataget.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?
Hello Baxter,

Quoted text here. Click to load it

You have to provide a header, typically in the same 14 pin
configuration. If there ain't enough space you can create an adapter
from the FET tool plug to whatever smaller connector like FPC you have
chosen.

In-circuit might be more practical with a bootloader, reducing it to a
serial link.

Regards, Joerg

http://www.analogconsultants.com

Re: Learning embedded coding, which uC?
Thanks everybody. Very informative!

I'll go with the Velleman K8048 (and PIC16F627). It's a kit, so I can
probably find some ZIF sockets to avoid the bent pin problem.
Compilerwise, I'm used to command-line tools (linux all the way, heh).
So, SDCC, PiKdev to drive the programmer, YaPIDE as graphical simulator
- all freebies. Gotta love Open Source :-)

Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

I know of at least three projects in medical systems using Forth (two of
them are life-critical). Forth is also used in a wide variety of space
applications and industrial control.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?
Hello Paul,

Quoted text here. Click to load it
What I meant was equipment that is sold in high volumes, not projects.
But maybe there is equipment that was programmed on Forth. I just have
never seen any.

Back in my university days in the 80's we had a few hardcore Forth fans.
They wouldn't touch anything else.

Regards, Joerg

http://www.analogconsultants.com

Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

I used to be one of them. At the time, I saw Forth as a sort of MSI
solution, between the 'TTL gates' approach of assembler and the MSI of
C, Pascal etc. It was also easy to get Forth cheaply for small
processors, whereas C tended to be very expensive and clunky.

Nowadays, reasonably good C is available for nearly all processors, and
Forth is a bit of a backwater. I'd certainly rather try to read even
badly written C than Forth, and not having to keep track of the stack
clinches it for me.

Paul Burke

Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

I would have thought that Anaesthesia Ventillators and Vaporisers would be
a reasonable volume production. I know that it can be hard knowing what
equipment is programmed with what language. Anyway, you have now heard of
such equipment being programmed in Forth.
 
Quoted text here. Click to load it

I can understand that sentiment. In my position as a Systems Engineer I get
to see more PLC Ladder, Literal and other languages than I do Forth.
However, if I am designing new equipment then I am likely to use Forth as
the programming environment for it.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

Yes, the number of Forth engineers is very small in comparison to the
number of C and Ada programmers. I have had no trouble convincing the
agencies, notified bodies or safety licenceing authorities that the Forth
coding was of an adequate standard and in compliance with the requirements
of the system. I have found that certifying Forth code for correctness is
rather easier than most other languages.

I have, in the past, done some coding in Fortran IV, D3, S80 and MUMPS. I
still, on occassion program in BASIC (Turbo-BASIC), Assembler (for various
processors), Ladder and PostScript. They are all fine for some niche or
other and, when used, are the most effective tool for the job. However,
Forth, for me, is very much a huge tool-shop (I mean the place where the
tools are created). That keeps it in the forefront for me, especially when
I am dealing with control systems.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?
On Fri, 29 Jul 2005 00:36:59 GMT, Joerg

Quoted text here. Click to load it

At least one of the products Paul mentioned uses our DocGen system
to produce documentation and test files from formal comments in the
Forth source code. DocGen/SC (SC for safety critical) is based
on Paul's methodology and produces code documentation that is
accepted by the US Food and Drug Administration.

As a side note, using documentation tools for software has
had a major beneficial impact on our code quality, and significantly
reduces the cost of reuse in safety-critical applications.

Stephen


--
Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?
Hello Stephen,

Quoted text here. Click to load it

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".

Quoted text here. Click to load it

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

http://www.analogconsultants.com

Re: Learning embedded coding, which uC?
Quoted text here. Click to load it

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?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

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
1993) has since also become the "Open Firmware" specification, IEEE
1275-1994.

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

Re: Learning embedded coding, which uC?
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

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.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

Can they what?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Re: Learning embedded coding, which uC?
On Tue, 02 Aug 2005 15:07:07 GMT, Jonathan Kirwan

[...]
Quoted text here. Click to load it

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
--
Change is inevitable, progress is not.

Site Timeline