Following up on tonight's talk, Micro Controller Usb Devices

[Peter]

Antonio Sun <antoniosun at ...> writes:
> I just want to follow up on my question, which is on the micro controller
programming side. Could you give us a brief idea what micro controller
programming is all about please, Jan?

I am not Jan but I am an embedded mcu guy among other things so I'll jump in
here while sipping my Sunday morning (noonish) coffee:

Today's mcus (microcontrollers) consist of a cpu core, flash memory, ram and io
peripherals all in one integrated circuit which has pins for electrical
connection to the outside on it. Some of those pins are either reserved or
multiplexed with other pins and serve to clear, program, verify or update the
software stored in the internal non-volatile flash memory. Each mcu family has
its own protocol for programming which uses 1, 2, 3 or at most 4 pins for
so-called 'serial programming'. Sometimes those are an USB interface proper,
sometimes they are a serial interface, most times they represent a proprietary
serial synchronous interface. In most cases they are operated at low voltage
using a PC attached interface called a programmer, or an in circuit programmer.
This device toggles the programming pins in a certain sequence to perform
programming, verification and other functions on the mcu. The mcu can be
programmed while in the final circuit where it is destined to be used, or stand
alone in a socket. The former method is currently preferred. There are also
other ways to program the mcus which are reserved for production, using many
more pins and fast external hardware. This resumes the hardware side of 
programming.

The software side consists in writing code in some suitable language, such as,
assembler, C, Pascal, Forth etc., and then in assembling or compiling it to
object code, which is then transferred to the hardware programmer and to the 
mcu using a cable connecting the PC to the programmer. Most development is done 
on a PC or equivalent workstation, but sometimes it is done on the embedded 
device itself, if it has a suitable interface. An example would be an Andoid 
phone interfaced to a robot where programming can be done on the phone itself, 
using its screen etc., although that would be tedious and only used for 
touchups and mods. Also, simulation can be performed on the host machine (PC),
using suitable software, which can simulate the embedded target down to 
individual buttons, leds and displays, as well as deeper protocol and bit level
or even DC voltage level display and multi trace digital and analogue
oscilloscope type signal display. All these will be displayed on one or several
workstation (PC) screens and/or application windows. Sometimes dedicated
hardware interfaces are attached to a workstation to permit attachment of real
size and functional interface and peripheral hardware and the simulator running
in the PC uses these real hardware devices instead of the simulator avatars
thereof for simulation. This is usually an expensive and complex process which
is only used when other options are not satisfactory.

PC based mcu development software usually comes in 2 flavors: IDE and stand
alone components. An IDE is an integrated GUI which allows the user, in theory,
easy access to the individual software components used to develop, simulate and
program the mcu by clicking on buttons and by using familiar desktop widgets.
Such IDEs are widely used but many advanced developers prefer to use makefiles
and individual scriptable editors, compilers, assemblers and programmer drivers
instead. Basically an IDE is a click-intensive GUI application which requires
the developer to do a lot of clicking every time to complete a task, and a
scripted makefile based application set or project is a one stop self contained
do-it-all single cli command which performs all the necessary actions once
completed and tested (that takes a while). Beginners usually start with IDEs.

A further class of embedded debugging and development tools is represented by
ICDs which are In Circuit Debuggers. This device acts and looks like a
programmer hardware, being connected between the PC and and the target embedded
board with a mcu on it, and permits the developer to interact in real time at
pin io level with the target circuit, set breakpoints, alter code and so on.
ICDs can be very expensive but lately ICD hardware support has been embedded in
current mcus and it is common for more advanced programmers to have ICD
functionality built in and readily available for very little money. ICD capable
programmers start out at about $40 or so.

Embedded code development is done in C, assembler or other languages. C++ plays
a minor role for now, mainly due to the size of the created code which is
unwieldy for embedded use today. Embedded systems have many limitations which
make porting code from desktop applications a challenge. Intimate knowledge of
the drivers and hardware is required, advanced knowledge in applied electronics
and circuit building and measurement is required. There is no operating system,
every peripheral used will have to have a driver or specialized code which
enables relevant hardware parts and configures them. Each embedded code project
is different. Code reuse is high, but reused code is very seldomly unmodified,
at least for small mcus. Seeking help on forums and the like is a stumbling
block since each device is different and people can only answer in the context
of what they did before, assuming they are not talking out of their navels,
which is sadly frequently the case. Relying on standard C library functions is
a bad idea, as it causes code size bloat and frequently requires a mcu device
larger than the one which could be used with optimized code. This directly and
immediately impacts the project price, which can jump from $3 in hardware to
over $30 in a second by simply choosing the wrong mcu or development
environment (see above for code bloat). Basically embedded programming is
writing code literally 'on the bare metal' (or bare silicon), and can be very
hard and have a steep learning curve even for people with years of electronics
and desktop programming experience.

Easy free IDEs (Windows only from most makers, some also Linux) for popular
mcus are Atmel Studio and Microchip Mplab. There are also IDEs from Cypress,
ONsemi, STmicro and other MCU makers. This does not touch upon 32 bit embedded
micros such as pic32 (MIPS) and ARM based 32 bit embedded mcus from NXP, Atmel,
Intel and others, it refers only to 8 and 16 bit small mcus. 

The Arduino 'ecosystem' is based on vastly overpriced hardware modules which
frequently contain just a $2 Atmel mcu and $2 or anciallary parts following a
freely available schematic diagram (search for Arduino solderless breadboard
version for clues) , which sells for only $29 plus tax when fully assembled,
and is useless without more interfaces and parts (more $, almost as above).
I wish I could mark up my devices like that. It does have a free and easy to
start with IDE based on Fritzing!, which runs on Linux too and a wide
following. Working through examples made by others is a good idea for
starting out in embedded, but do not expect to become proficient before you
put down 10 or more working projects and probably 2 years or so of real work
on these things.

Also beware of many MANY non working projects, and self elected 'experts' and
their pretty pictures and code online which sometimes won't work or may be
seriously unsafe. If it works for one person, it does not mean it will also
work for you, unless you use the exact same parts and environment the original
author used. In some forums I am active in, in electronics, I see daily pleas
by Arduino users who have no clue about electronics or programming or safety or
even what a ground wire is for in a DC circuit, asking for help on how to
connect their Arduino project in impossible situations and or to lethal
voltages (mains, Tesla coil, powerful motors and fire starting accumulator
batteries, the works - totally scary). Meanwhile, here's a literally bare
solderless Arduino clone board:

  http://itp.nyu.edu/physcomp/Tutorials/ArduinoBreadboard

Wikipedia knows a lot about these things so people who are interested should
peruse that first. Again, BEWARE of so-called information you find in colorful
and attractive articles on the net posted by various people, and use
discernment. site:.edu links are usually better than the average.

Unlike pure software bugs, embedded bugs can and do frequently indicate a fault
by killing hardware which costs money and sometimes by causing a small fire or
physically exploding parts. In electronics, we call this the magic smoke. It is
said that if you keep the magic smoke inside the parts, they keep working, if
you let it out, then they cease doing that. Also, that if you put all of it
back in, once escaped, then they start working again. But I know no-one who
ever managed to put all the smoke back into a part ;).

-- Peter


--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists