[ale] Working with custom hardware/microcontrollers

[Michael B. Trausch]

On Sat, 2010-06-19 at 15:49 -0400, Byron Jeff wrote:
> 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.

Indeed.  I have been reading about using these little things, and have
actually gotten a fair amount of ideas for what I could do with them in
things that I have already or want to have.  Of course, there is the
usual problem of learning to crawl before walking, and then getting
walking figured out before running... :-)

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

>From what I was looking at, it seemed to me that the AVR was a good
choice, though I haven't looked at ARM.  I can see what ARM can do, of
course; I have one in my phone.  It's probably overkill for a lot of the
things that I think I would want to do with embedded sorts of
development, as ARM is a general-purpose processor.  I wouldn't mind
starting really tiny.

The reason that I was looking at AVR is because of the fact that I can
use a branch of GCC with it, and that to me is awesome.  I like the
ability to write C code and then uploading a binary into the chip to be
its program.  I don't know that I would necessarily want to do the same
thing with an assembler language, though I wouldn't be against the idea
for simpler architectures.  I did learn 6502 and IA-32 assembler
languages in high school, though I didn't much like IA-32... I liked
6502 far better, though that could simply have been because of its
simplicity.  The runtime environment was so much simpler.

> 2) The software to drive the chip (assembly,C,other).

As I mentioned above, C would be very useful for me.  Though I suppose I
ought to learn assembly language first and then simply use C for the
more complex things... I don't know.  It depends on many things which I
just don't have a decent knowledge of yet, I guess.  It would seem to
me, also, that it would be a good thing to have a piece of software that
would be able to simulate a breadboard type of thing where I could
actually put together the circuit using simulated hardware on a virtual
breadboard and then be able to test/debug the chip's program on the
computer.  Though perhaps that might not be possible, as that would seem
to me to require a very powerful, versatile emulation environment that
has little to nothing in the way of static hardware for its emulation
environment.  I have yet to look for it, but I would be surprised if
something like that existed because it seems to me that it would be
extremely difficult to simulate everything that you could use in a
circuit in software, and do so accurately.

> 3) The system to program the chip (roll your own programmer, bootloader, buy a programmer).

Rolling my own sounds fun.  :-)  But then again, I am very much a DIY
type anyway, except when I'm not (does that make any sense?).

One thing that I do really want to do is learn how to make things that
can communicate using current technology.  There are multiple reasons
that I want to do this stuff, and one of those reasons is that I would
really like to create custom hardware for things that I implement
myself, even if it's something that is insanely difficult to do.

I know that in the past couple of years, I have gotten tired of buying
hardware that doesn't work correctly.  Stupid things, like USB→Parallel
port dongles, which *SHOULD* Just Work, do not.  Specifically, the one
that I purchased always eats the first byte of the print job, and
requires me to press the ON LINE button on my printer twice in order to
make it print.   So I had to work around it by prepending a NUL byte to
the print job and then pressing ON LINE twice so that the whole print
job would print.  That was annoying.  I imagine that I could, with an
understanding of how to actually talk to the host system and the
downstream device, come up with a way to work around that "properly".  I
could be wrong, but hey, whatever.

I wouldn't mind learning how to take a microcontroller, hook it up to a
USB port, and have it expose an interface like a serial port so that I
could then use that microprocessor as a comm controller.  It seems that
since old, simple ports are a dying breed (particularly in laptops, some
recent motherboards still have serial port and/or parallel port headers
on them) and USB 2.0 and USB 3.0 are here to stay, it is probably not a
bad idea to learn how to just create devices that work with USB without
playing the game of "let's be a pretend serial port".  It would seem
pretty nifty to me to create a device driver for a device that talks
over USB that doesn't necessarily fit an already existing class device
model, for example.  Why not?  If you can control the hardware and the
software, what is there that you can't do?

> 4) The development platform (Linux list, so hopefully a Linux box).

Absolutely.

> 5) hardware platform (develop PCB, wirewrap, solderless breadboard, buy a
> prototyping board).

As I mentioned above, a virtual environment for all of that would be
nice, too, though I don't expect that one exists.  It would be pretty
nifty, though, if you could do something like "single step" on an entire
board's state.  Let's say that I know what the inputs are going to be,
and I know that the outputs are going to be digital readouts on a set of
one-line displays (say, numeric readouts).  It'd be nifty if I could
"build" the circuit on my screen, and have a set of programmed fake
inputs and be able to see what happens with the output and get an idea
that it all works the way that I thought it would in my head.

In reality, I expect that this is something that, once I have gained
enough familiarity with the whole thing, will happen in my head with
growing accuracy.  Of course, that's just an assumption.

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

Awesome.

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

So, you build a circuit on the breadboard and when all is happy and
working, you move the circuit to the pre-made PCB?  Can you get PCBs in
various sizes?  Is it possible, for example, if you have a project that
you want to do and you know that you have only a very limited amount of
space, that you can get a board that fits that size?  Of course, this is
more forward-thinking than immediate, but as I said before I already
have a few things in mind that I would like to do with these sorts of
things, ranging from what seems to me like ridiculously simple to
probably too complex to do in a reasonable time frame.

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

So, by going the route of a boot loader you could do something like
design a circuit that can do things and install it in your target
environment, and so long as you give yourself a port to hook up to, you
can update the thing without having to rip it back out again.  Is that
right?

Say, for (a rather advanced example) that I wanted to retrofit a device
that had analog controls to be controlled by a µc and a display.  Let's
say that I already know and understand fairly well what both the system
inputs and outputs are, and I build a system that does what I want
initially.  Then, let's say that later, I learn that there's a better
way to do it in the µc's software, for example, a better method for
doing the same thing.  If I have a port that I can hook up to, say, my
laptop, then I can take my laptop to the port, hook it up, and upload
new software into the µc and it'll use that code in the future, right?

Seems nifty!

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

Makes sense.

I think that there's a bit of "information overload" in trying to get
started with this, at least, from what I gather looking around Google
trying to figure out where to get started.  I don't know that getting
down the road is going to be as difficult as getting started, simply
because I'm having *such* a hard time trying to figure out where to
start!

Some things that I would like to do also involve learning a lot more
than just the microcontroller stuff.  I need to learn about electronics
themselves, and electricity, and so forth.

The funny thing is that when I was a kid and working in a computer store
in Toledo, OH, the guy that owned the thing tried to get me interested
in working with hardware.  He thought that I would be awesome at it and
wanted to teach me electronics from the ground up; things like making
circuits and controlling them by using the computer's ports.
Essentially, making circuits that relied upon software running on a
general purpose computer to control them.  Seems to me that would have
lent itself to naturally evolving into working with microcontrollers and
standalone circuits.  It also seems to me that I was pretty stupid for
not taking him on on the education... but it simply didn't interest me
at the time.

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

I know that at least with the USB→serial wires that I do have (one USB
port, two serial ports), it does control a modem properly and it seems
to get all of the lines correct.  I haven't tested that extensively,
though.  It works well enough to actually control a modem from something
like minicom and it works well enough to use to manage my 24-port 100
Mbps Ethernet switch that has a serial port for a console.

I think I will follow up with you privately, though, with a whole host
of questions that I have if that's alright.  I'd like to try to sort out
my thoughts a bit and find a place to just plop down a bit of money to
get the materials to get started and work through learning the basics.
And I expect it will be a (relatively) long process if for no other
reason than the only thing that I really know about is software.  I
mean, I know a *tiny* bit about electronics, just enough to know that I
don't know a whole heck of a lot at all about it, really.  It would be
nice to pick all of that up at the same time---though I expect that in
reality, I probably need to learn about the basics of electronics before
I get too in-depth with playing with microcontrollers and circuits.  :)

	--- Mike