Hardware projects are fun, but challenging. The object of Project
Amethyst is to provide a set of examples in the hope you can adapt and
learn from them for your own purposes. As is made clear by the licence
under which it is distributed, there is explicitly no warranty or
implied fitness for purpose. Levels of experience range widely and
your success will always reflect the effort you invest.
Required skills
Some experience with electronics is ideal, but not absolutely essential
if you are prepared to do some background research, be patient and take
it slowly. The level of electronics in, for
example, NARG is reasonably basic. The
Microchip PIC, the microcontroller used in this design, is very forgiving
and has an enormous following online.
Some experience with C and C++ will also be extremely useful, maybe even
essential, depending on how much customisation you want to do. If you've
dabbled a bit, then hopefully the code in the PA repo will be enough to
get you started. Debugging is an art at any level, but debugging
firmware is especially so. The ICD (in-circuit debugger) tool is
excellent — but it can't always be used when debugging things like
USB, where sometimes your only debugging tool is an LED or an
oscilloscope (if you have one!)
Get the tools
Most of the software tools required to develop Project Amethyst-based
devices are available for free:
FSX SDK (included with FSX Deluxe and FSX Acceleration), service
packs sp1a
and sp2.
Windows
Driver Kit (including Microsoft C compiler, headers and libraries)
GNUwin32 flex,
bison,
and make.
I use Cygwin's port of GNU make and although I haven't tested
it, there should be no reason why you can't use the GNUwin32 port.
Whichever you use, the GNUwin32 ports of flex and bison are crucial
because the Cygwin ports emit code that use headers not present in
the Microsoft C compiler.
Subversion
client. Again, I use the Cygwin port, but any should do. If you
prefer GUIs, have a look
at TortoiseSVN.
Microchip
C compiler C18. (The student/evaluation version should be
sufficient for most projects.)
A schematic capture and PCB layout package. NARG is done
in Eagle PCB. The free
version of Eagle PCB can view the PCB files, but the PCB is much
too large for the free version to edit.
Get the hardware tools (eventually). In addition to the components for
the hardware, you'll need a Microchip programmer/debugger such as the
ICD2
or ICD3.
I'm afraid you'll have to pay for one of those, though I believe there
are cheaper, 3rd party implementations available.
Get the Project Amethyst source package:
svn co https://proj-amethyst.svn.sourceforge.net/svnroot/proj-amethyst/pa/trunk proj-amethyst
There are three main parts — PCB, firmware and host driver —
briefly outlined in the following sections.
PCB schematics and layout
Coming soon...
Microcontroller firmware
Coming soon...
Host driver code
Coming soon...
Tips for digital design
Here is a very non-exhaustive list of tips and suggestions that may be
of assistance to novices. Any additional suggestions I haven't thought
of are welcome.
Take antistatic precautions. Chips that aren't mounted in a
circuit are more vulnerable to electrostatic discharge than a fully
assembled device although, even with those, you should take
reasonable care.
If you've never used a soldering iron before, take a look at a few
of the many excellent guides and tutorials online, for example Marshall Emm's
Electronic
Construction from A to Z to pick one at random.
In the real world, power supplies and wires have inductance, which
is an AC phenomenon that results in fluctuations of voltage whenever
current moves quickly, such as in a clocked digital circuit. The
practical upshot is:
Make sure that every power and ground pin pair has a small
100nF monolithic or ceramic capacitor connected as close to the
legs as possible. Surface mount caps are ideal, because
component legs themselves are a source of inductance.
Put two or three 'bulk' capacitors (electrolytics or tantalums)
around the PCB, eg by the power connector, and maybe one on the
opposite side of the board. A total capacitance of between 47µF
and 470µF is about right. Don't put too much in, or the inrush
of current on startup could overload your power supply and/or
blow fuses.
Since you probably won't want to shell out for the cost of a
multilayer PCB (the film and fab costs are roughly double!),
be sure to lay down copper pours attached to power and ground.
This provides the lowest possible inductance power to all parts
of the board. The trick is working out how to route your signals
without isolating parts of the pour!
An individual LED doesn't use much power, but by the time you've
got hundreds or thousands of individual diodes (each SSD has 8 of
them!), it all adds up, even if they're of the low-power (2-5mA)
kind. Don't be cheap on your powersupply. You can somewhat mitigate
the demand for power by taking advantage of the nonlinear,
integrating characteristics of the human eye (lights switching faster
than roughly 100 Hz are seen as a solid light) and
Pulse Width
Modulation (PWM). The PIC18F devices have at least two PWM
controllers which can drive the Output Enable input of the
constant-current LED drivers used by NARG — essentially giving
you brightness (and power consumption) control for free.
LED brightness is a function of current (not voltage), and LEDs of
different colours will often give different brightnesses at the same
current (something I forgot when designing NARG.) Also, the human
perception of brightness
is quite
nonlinear (Stanley Smith Stevens' Power Law).
Encoders and illuminated pushbuttons are usually better than
physical switches and pots because the simulator can set them as
required, and you won't have to worry about synchronising the two.
It's not impossible to use physical switches, but you'll need to
write extra code to ensure the simulator has the right idea of the
current state of your physical controls. When choosing an encoder,
use a design with a low frequency quadrature outputs (eg, one whole
cycle every four clicks rather than a whole cycle every click) in
order to manage the load on your PIC µC.
LEDs are cheap: be sure to add a couple on any spare IOs you might
have for debugging.
If you're going to construct a front panel for your interface,
don't forget to make allowances for the differences in height of each
component. SSDs are the worst offenders there. I used a set of
5x1x10mm standoffs which worked moderately well, but the parts I
selected were so cheap they are a bit unreliable. There are a
variety of other possibilities that could be discussed.
The PIC18F4550 µC is pretty cheap — about £5 in ones —
so don't be afraid to use several of them. NARG uses three, each with
their own USB interface.
Build a prototype proof-of-concept board on stripboard before you
commit to a custom made PCB. Put a couple of encoders, a few
buttons, SSDs and LED drivers and test it all out thoroughly. You'll
see traces of my early proof-of-concept experiments in the SVN repo.
Assembly on stripboard is a bit of an art, so take it easy and test
it at each step along the way.
dave_infj at users.sourceforge.net $Id: gsg.html 223 2012-01-10 12:40:52Z dave_infj $