[ale] Working with custom hardware/microcontrollers

[Byron Jeff]

On Sat, Jun 19, 2010 at 01:28:58PM -0400, Michael B. Trausch wrote:
> Hello,
> 
> Recently, I have kind of gotten fascinated with the idea of doing more
> things that would involve hardware, both attached to a PC and controlled
> by microcontrollers. 

A most excellent endeavor. One of my favorites.

> However, I am also finding that it seems a bit
> difficult to find enough information to get a solid start in figuring
> out what I need to acquire to do things.  It probably doesn't help that
> I'm very much a software person and know very little about actual
> low-level electronics, which is what I would like to learn about.

What you usually end up with is a blend of both. The low level electronics
is great for size (small) and precise control. Software is excellent for
flexibility and managing complexity.

> 
> I'm wondering if anyone on here has been in that boat and knows of some
> decent resources to use to get started.

The biggest problem is that there are a number of different directions you
can go. Lots of choices:

1) The actual chip (PIC, AVR, ARM).
2) The software to drive the chip (assembly,C,other).
3) The system to program the chip (roll your own programmer, bootloader, buy a programmer).
4) The development platform (Linux list, so hopefully a Linux box).
5) hardware platform (develop PCB, wirewrap, solderless breadboard, buy a
prototyping board).

What I will do here is tell you about my environment with the rationale for
my choices. I'm not saying they are the right choices for you, but
hopefully it'll give you some insight into how and why choices like these
are made.

>  I know that I would eventually
> need a breadboard to play with things (though what do you do with a
> circuit after you've prototyped it on the breadboard and then want to
> use it in something?)

Point #5 above. I prototype on solderless breadboards. Then since the vast
majority of projects I work on are one off (so no need for mass production)
I will either wirewrap a final version (with discrete components like
resistors, caps, and LEDs soldered into machined solder sockets) or solder
onto a prototyping board. For example Radio Shack still carries a solder
board that matches their solderless breadboard here:

http://www.radioshack.com/product/index.jsp?productId=2102846

I have made several attempts to get into the PCB making business. But in a
lot of ways it's a rough go. You have to design, route, print, expose,
develop, etch, and drill just to get a solder stage. Or send out a design,
pay quite a bit of cash, then wait for the results. I find I'm too
impatient to follow through on either of these options. If I were making a
dozen, it may be worth the time, effort, and money. But like I said, I
generally do one off projects.

> and that I would need to find a decent amount of
> reading material and also buy collections of wires, resistors,
> capacitors, microcontrollers and all that jazz.  I just don't have a
> clue where to start.

So let's tackle the others.

#1: Microcontroller: Microchip PIC. Not the best architecture in the world.
It takes some getting used to. However, in terms of cost, getting chips,
and having usable hobby formats (DIP), they are really hard to beat. Also
they have decent Linux software support in terms of languages. Right now
I'm trying to get up to speed on their enhanced midrange line (specifically
the 16F1936 and 16F1937). However for hobby use I would recommend stepping
up to their 18F 16-bit line. From a part standpoint, I think that the best
balance of size and performance can be found using 28 pin DIP parts. While
lots of folks are attracted to the smaller size chips, it can be
frustrating to be a pin or two short of the goal. So develop with the
larger footprint, then downsize if it turns out you don't need all of the
real estate. The 28 pin parts fit nicely on a breadboard too.

With PICs always get parts with the internal oscillator. It gives you back
3 potential I/O pins and saves the trouble of having to wire up a clock.

Given those contraints, the first part I would suggest is the PIC 18F2620.
If you do decide to downgrade to the midrange family, then the 16F1936 and
16F886 are good choices and much much cheaper (like 1/3 the cost) of the
18F2620.

Be aware that Microchip has a sample program that will send chips to you
for free (if you are an educator) or a nominal fee. Ships FedEX directly
from the plant. You can use samples to stock the chips that you would use
for projects. You can find that page here:

http://www.microchip.com/samples

Mouser and Digikey can supply larger quantities if needed. I bought 10
16F1936s from Digikey for development a few months back.

#2: Software. Whether or not you plan to stick with it, it's worth the
investment to learn some PIC assembly. Often assembly is used as a code
trading and algorithm description language. So even if you don't actually
write in it, you need to be able to read/understand it because it'll serve
as a Rosetta stone for lots of code out there. Write a small to medium
sized project or two in PIC assembly just to get the nuances of how it
works. The you can look at some higher level languages. One good choice
that spans all these chip families is JAL:

http://www.casadeyork.com/jalv2

JAL (version 2) is a not to terribly complicated high level language that
compiles for PIC 16F and 18F parts. It comes with a boatload of libraries
that can control a lot of different types of items both on and off chip.
It's being actively developed and has an active user base. There is a JAL
tutorial document posted on the site somewhere that's a 100+ page PDF
showing how to use the language.

For Linux the Microchip assembler and simulator are in a package called
gputils:

http://gputils.sourceforge.net

Note that as of 3 months ago, the Enhanced midrange (16F1936/37) parts are
not supported by either the assembler nor the simulator. If you need it, I
had a patched version that one of the Microchip guys wrote for the
assembler.

JAL is available from the site above. A quick compile and it's ready to go.

> Many of the things that I would like to do can be done by purchasing
> something that someone else has made, more likely than not, and adapting
> it for my usage.  That's fine, but I actually want to learn about these
> things, and I have a few ideas for what I think might be somewhat small
> projects that would enable me to learn how to do things assuming I can
> find a base to start working with.

Good point. That leads to the other items on the list:

#3 Chip programming. This is a religious topic among embedded developers.
Many feel naked without a full hardware chip programmer/debugging
environment. Personally I'm a fan of the bootloader. It's software that is
loaded on chip that gives the chip the ability to program itself. You hook
up to the chip directly to the PC and simply download the code right into
it. Doesn't have on chip debugging, but I've found that all of my
successful project have happened with a bootloader.

The problem is the chicken and the egg. You need a programmer to get the
code onto the chip so that it can program itself. I've finally decided to
change the semantic term for this device and call it a "code dumper". It's
my personal PIC crusade. For years I maintained a code dumper that attached
to the parallel port. But as you note below, that's a dying breed. More to
come on this.

As for actual bootloaders, it's easy to go cheap and simply use the onboard
hardware USART to connect to the serial port. The Tiny bootloader:

http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm

is one of many implementations. This host driver:

http://sourceforge.net/projects/tinybldlin

can be used to download code using Linux/Python. That page also lists a ton
of other bootloader options.

As of late I've been using Frank Seargent's PikMe bootloader:

http://pygmy.utoh.org/pikme

Unlike Tiny, PikMe doesn't use the hardware USART, but any available I/O
pin. Frank also has some python software to drive it. I sent him an update,
which I believe he has posted in the ZIP on the page.

> Eventually I would like to have learned enough to do bigger things, such
> as creating custom self-sufficient hardware for various specific
> applications, though I don't have any clue where I would go about doing
> something like that.

Start small, work your way up. The one piece of advice that I have for you
is to make sure to learn how to manipulate the onboard hardware systems
(USART, I2C, SPI, PWM, timers, ADC, capture/compare, comparitors, etc.)
inside and out. It takes some work to learn. But it'll save you a ton of
effort later on when you want to build real projects because they become
set it and forget it devices. 

As you poke around for tutorials you'll see a lot on the 16F84, which was
Microchip's first Flash programmable chip. It had very limited hardware
support. So you'll find that the code goes in circles trying to handle
tasks that the onboard hardware of later chips handle with ease. So take
such code with a grain of salt.

> 
> Oh, yeah, and here's something else that I don't have: real serial
> ports.  I do have a USB thing that has multiple serial ports coming off
> of it, but I don't know that I could program them in the same way as a
> "real" serial port.

This is a part of my project for my current code dumper. What I've found is
that there are subtle flaws in the USB/serial implementation and that it
varies from chipset to chipset. Pretty much the only thing you can trust is
that serial transmit and receive will be on point. But while with some
modem control works, other don't. Or while some chips can properly send a
break signal, others can't.

Once you have a bootloader loaded, then it doesn't matter to terribly much
anymore. Simply attach your project to the PC via the USB to serial
connection and use it to communicate. However, the "code dumping" without a
true programmer has turned out to be a challenge.

One solution is to break down and buy Microchip's PicKit 2 programmer. It's
USB, and has code:

http://mcuee.blogspot.com/2007/06/pickit-2-under-linux-mini-howto.html

to drive it. Personally I would still use it as a code dumper (therefore
freeing up Microchip's programming pins). But again the choice is up to
you.

I still have enough old machines around with parallel ports that this
hasn't become a dealbreaker for me... yet. But it's getting there.

>  Probably would be to my advantage to learn how to
> use USB as a communications mechanism for such hardware, wouldn't it?

Yes and no. USB to serial offers a simple option without having to invest
in USB. Also Microchip offers several chips that have USB interfaces. The
cheapest/smallest of these are the 18F13k50 and 18F14k50. They could be
used standalone, or in conjunction with a larger PIC chip.

I would caution on step at a time. In virtually all cases (Except for the
JAL USB library), USB is quite a beast. So if you can afford to offload the
USB task to another device, do so.

I hope this helps. Feel free to contact me if you want more information.

BAJ

> 
> 	--- Mike
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-- 
Byron A. Jeff
Program Coordinator: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjeff