WildFire Credit-Card Sized Linux Board
Posted 1 Feb 2005 at 17:17 UTC by steve
According to a LinuxDevices.com
Automation has a new credit-card sized single board
computer, called the WildFire,
with a 64MHz Freescale ColdFire
5282 Version 2 processor. The board includes 2 or 4MB of Flash (plus
another 512KB on-chip Flash), 64KB of SRAM, and 16MB DRAM. The board is
intended for use with Free Software
development tools like the GNU GCC tool chain and can run uClinux. Of particular
interest to robot builders will be the
extensive list of I/O. The board has 24 general purpose I/O ports, 7
interrupt or I/O ports, a 16 I/O port timer (plus 4 additional interrupt
timers and watchdog timer), 8 analog inputs (10 bit, 140KHz), 1 CAN
port, 3 RS-232 serial ports, an LCD/keypad connector, and a 10/100
Ethernet port. It also has a battery-backed clock and has a zero power
hibernation mode. Technical
documentation (PDF format) for all those ports is also available.
The WildFire board is available
now for $199.
It looks like a fine little board, but a few details bug me.
My "Find" command didn't work with the PDF, but it appears that the I2C
bus, present on the processor, is not externally available on the board.
Also, I couldn't determine what type (aside from 2 or 4 x 16) of LCD
could be used.
There's a note for the LCD contrast that says something like (regarding
the contrast) "This adjustment is touchy". This raises a flag to me
that the contrast-adjustment voltage is not ranged well.
The photograph shows no routing on the top layer - it looks to me like a
Does anyone have one of these working now, or is it a little on the
I exchanged some email with them and learned that the photo on the
website is, in fact, an older photo of a beta-version of the board. But
they do have real, shipping boards now. They also hope to ship the board
with a version of uClinux that will run right out of the box soon. Right
now, it apparently takes a little tweaking to get Linux running - much
like it does on some of the other Coldfire and ARM boards.
I2C, posted 2 Feb 2005 at 20:10 UTC by steve »
I hadn't noticed the lack of a direct I2C connector. I assumed they were
just calling the I2C connector the CAN port. Isn't CAN just a protocol
that runs on top of I2C? (I may have no idea what I'm talking about
here!) On the Mini-ITX board,
there's a header for the I2C port and you just run the Linux CAN
protocol stack if you want CAN vs raw I2C. So, does this mean
you can't use non-CAN I2C devices with this board? That would be
as there are begining to be a lot of I2C bus robot parts around. Ron
Grant is running his new sonar array over an I2C interface.
Hmmm...I wonder about that "Debug Port" - is it a JTAG port or one of
the BDM style things like the older Motorolas used?
"jeffkoenig" is pretty sharp: The web images were indeed of a Beta
version. We have updated our website to show the "real thing" which is
available and is in stock.
The "Technical documentation" links to the Programmers Reference
Manual. The WildFrire Users Manual may be a more interesting first
The WildFire LCD/Kpd port hooks up to a standard up to 2 line x 40
character or 4 line x 20 LCD, as well as a 4 x 4 matrix keypad.
LCD contrast is controlled by a 1 turn pot with less than a 1/4
turn "sweet spot", depending on LCD. A multi-turn pot would have been
nicer and a tempertature compensation circuit, nicer yet ..at the cost
of more realestate and money.
Jeff is correct: the I2C bus is not externally available on the
WildFire SBC. We were not aware that this was important for robotics
(Duh!). Now that we are aware, we will ensure that this bus is made
available on the WildFire's successor.
Yes, BDM debugging has been used for quite a while by Motorola and
now, Freescale, and it keeps getting better. For instance, BDM support
built into the ColdFire chip now allows breakpoints in Flash and real
But, most users will find that serial debugging with the dBUG monitor
burned in the WildFires flash, is more than adequate for most
However, BDM debugging does offer some advantages (for a price):
- Simplicity resulting from only one program running at a time:
the user program.
- Registers and memory can always be inspected, remaining
unchanged, even after a program crash.
- Interrupts are normally halted in BDM mode and therefore
interfere less in the debugging process.
- The program can be stopped at any time without any alteration
of registers or memory.
- It is completely un-intrusive. It is handled by an on-chip
module that is separate from the CPU.
- All serial ports remain available to the user. No serial port
is encumbered for debug service.
A kudos to Intec! I can certainly envision laying out a carrier board
for this module - all it would need is an H-Bridge, some power
conditioning, and connectors for sensors. Perhaps an analog mux for more
The serial ports and I/O make this board a real standout, IMHO.
(Oh, and my apologies for getting the LCD part wrong. Should have read
the docs better...)