Q: Is the UBW easy to use?
A: It depends upon what you
want to do. If you just buy one from SparkFun, you
can easily be using your UBW in minutes. If you want to build your own
board from scratch and write your own firmware, then there are several
things you should know how to do. (building boards, soldering, writing
C code, microcontroller theory, etc.) If you just buy a board from SparkFun,
come with a version of Firmware D on it as well as the bootloader, so
just jump right in with no programming or soldering. How easy is that!
Q: I don't want to download any
new firmware. Can I use the UBW as it comes from SparkFun to make my
A: You betcha! (As they say
here in Minnesota.) It is really pretty easy. The UBW comes from
SparkFun with Firmware D. In order to run your EggBot, you need to be
able to write out bytes of data on Port B of the UBW. With FW D, you
should execute the following command once after you open up the COM
port: (assuming you are using Liberty Basic, and have opened the COM
port as handle #com)
Print #com, "C,255,0,0,0"
This command tells the UBW that you want Port A to be inputs, and Port
B and Port C to be outputs.
And then every time you want to write out a byte to Port B, you can use
the following command: (Assume OutByte is the byte we want to output.)
Print #com, "O,0,";OutByte;",0"
This command tells the UBW you want to output new values on its ports.
You are outputting zero on Port A (because they are set as inputs and
don't use them on an EggBot), your OutByte value on Port B, and zero on
Port C. Then you just need to do the normal step and direction
manipulations of OutByte to get your steppers to do what you want. Use
for/next loops between steps to change the step rate.
Q: Do you sell bare UBW boards
or completed units?
No, I don't. But you can buy pre-assembled and tested UBW
boards (the 28-SOIC version) with Firmware D on them from SparkFun.
inexpensive and are the easiest way to get started. You can also buy
nice plated through hole kits from SparkFun.
Q: Do I only get to use the
eight port B output pins (B0 through B7)?
A: Well, it depends upon which
firmware you load onto your UBW. If you use Firmware C, then yes, all
you get to use is Port B, and only as outputs. Firmware C v1.1 also
supports reading Port A bits 0 through 5 as inputs. For many things
be all you need! But if you use Firmware D you
will have complete access to all 19 I/O pins, as either inputs or
Q: How much current can I draw?
A: USB spec defines a max of
500mA from each USB port on a hub. I'd guess that with all LEDs on, the
UBW will use about 50mA. So you should use no more than 450mA for your
own uses. The firmware does ask the hub or PC for all 500ma when it
Q: Can I use the PRG button for
A: Yup. If you write your own
firmware (or modify one of the existing ones) you can use that button
for whatever you want. (Note the RESET button is hard-wired to MCLR, so
it isn't really available for your use like the PRG button is.)
Q: Can the UBW destroy my PC?
A: If you fire a UBW at your PC
with sufficient velocity, it may cause damage. Other than that, it
would be hard to do. USB is very robust from a physical/electrical
perspective. (Software is a whole different ball of wax.) You can't fry
your PC with a mis-wired UBW. You can fry the UBW if you do something
silly to it, but then you're only loosing a $10 processor that you can
get replaced for free. Not bad, eh? If you short power and ground on
the UBW, the USB hub will shut down that port without doing any damage
to the PC.
Q: Can I power the UBW from a
A: If you have the UBW
connected to your PC, then the UBW will be powered by the PC. You can't
turn that part off. But if you need to draw large amounts of current,
then you can supply your own circuits with your own power supply and
just connect the grounds and signals from the UBW and your circuits.
Then the UBW won't be powering your circuit, and your circuits won't
power the UBW.
A2: If you unplug the UBW from
your PC, you can always power it from a 5V supply in a stand-alone mode.
A3: In future versions of the
UBW boards, a jumper will be created to allow the connection between
UBW +5 and USB +5 to be broken so you can power the board without
worrying about conflicting with the USB power.
Q: What does the UBW look like?
A: Check out the pictures here.
Q: So why did you pick the
smaller PIC in each case?
A: Cost, really. You can easily
substitute a 18F2550 for the 18F2455, and a 18F4550 for the 18F4455.
only difference is less memory on the parts I chose, and thus they were
(slightly) cheaper. If you are sampling the part from Microchip for
free, then just get the bigger parts! Now SparkFun ships UBWs with
18F2553s on them, which are nicer because of the 12 bit ADCs that they
have. They still have only 32KB of Flash and 2K of RAM.
Q: How fast is a UBW?
A: That question is somewhat
ambiguous. I'll answer the question I _think_ you're asking: how many
bytes/second can I pump down to the UBW? That depends upon what USB
"Class" the firmware you are using implement. The maximum theoretical
speed of these PIC USB parts is 12Mb/s (mega-bits per second). With
Firmware C, I get about 500 to 800 Bytes/second to come out Port B
pins. With a custom firmware I wrote for a client, I've gotten
over 20K Bytes/second. If somebody develops a firmware based upon
Microchip's Mass Storage Class driver, or their Custom Driver, then it
should be able to reach 100K bytes/second if not more. Oh, and the RC
oscillator on the UBW runs at 4 MHz (or 20MHz for SparkFun version),
and the internal PIC PLL bumps
that up to 96MHz, then divides down to 48MHz to run the USB engine and
the PIC core. Which means that these boards run at 12MIPS (because
Microchip has a divide by 4 on their core clock.)
A2: If you are looking for Fosc
speed on all UBWs, it is 48MHz.
Q: What's different between the
SparkFun version of the UBW board and the initial design?
A: These web pages pretty much
follow the original design I did for the UBW board. There are a few
differences that SparkFun made when they started building their version.
Q: What is a Bootloader anyway,
and how does it work on the UBW?
- The resonator speed is 20MHz (now 24MHz) on the SparkFun board,
and 4MHz on
mine. The only place this makes a difference is in the bootloader,
which is why there's a separate SparkFun bootloader for 20MHz and for
- The pins of Port C are not brought out to headers, except for
pins 6 and 7
(Tx and Rx). This means that on the SparkFun board you'll normally just
use Port B and Port A (14 bits total) for your I/O. This isn't a big
deal, but it does cause the difference in "I/O count" between this
website (19 bits) and the SparkFun website (14 bits) because of the
'loss' of the 5 bits of Port C. (Two of which aren't really lost.)
- The physical dimensions and pin locations are different. This
isn't a big deal at all because of the really nice silk screen on the
A: The PIC's program memory is
ROM. You can erase chunks of it and write individual bytes into it.
What the Bootloader does is it sits in memory from 0x000 to 0x7FF in
Flash. Notice that it sits on the reset vector at 0x000! That means
that when you reset your UBW by pressing the reset button, the
starts executing code at 0x000, which is the Bootloader. The Bootloader
checks to see if you're holding down the PRG button. If you are not,
then it jumps to 0x800, which is where your main program (firmware D)
starts, and so the firmware starts running. If you _are_ holding down
the PRG button at reset, then the Bootloader starts running it's own
code, which listens for commands sent on the USB from the Microchip
Bootloader application (PDFSUSB.exe). Those commands include things
like 'erase Flash', 'program a section of Flash with this new HEX
file', etc. The Bootloader does not ever write over itself from 0x000
to 0x7FF, so it is always there, ready to help you if your main program
crashes and you need to reload the main program. Note that if you are
not writing your own code for the UBW but just using the firmware that
I supply, your only use for the Bootloader will be to update the
firmware on the UBW. Both the Bootloader and the firmware reside in the
UBW at the same time, but only one of them runs (based upon the state
of the PRG button at reset.). The Bootloader is exactly Microchip's
Bootloader, with a few tweaks to handle the slightly different hardware
in a UBW board vs. Microchip's USB demo board. So this
page from Microchip, which describes their Bootloader in more
detail, is a good read if you're interested. (Download their installer
file and you can read the information there.)
Q: Does it matter what baud
rate I choose when I open the COM port to the UBW?
A: Nope. It doesn't. There
really is no 'serial' link between the PC and the UBW. It is all
through USB. USB does not have a 'baud rate' feature in the traditional
sense of RS-232. The USB host chip on the PC schedules the bus
transactions as quickly as it can, abiding by all of the protocol rules
that define USB. (i.e. no fixed baud rate) In a traditional USB to
RS-232 converter product, the PC sends 'baud rate change' messages to
the converter chip, which then re-programs its RS-232 clock rate for
sending/receiving async serial data. The UBW does not currently have a
true RS-232 capability, so these messages are simply ignored by the UBW
firmware. The UBW simply uses the part of this standard USB RS-232
converter setup to the point where there is a getchar() and putchar()
function in the software of the PIC. The UBW does not then actually
send that data out its serial port. (It could, if one wanted to, but
does not at this point in time - FW D 1.4.2) Instead, it reads the data
coming from the PC and processes that data as commands. Thus, it makes
no difference to the UBW what baud rate or data bits or parity you use.
HOWEVER - it does matter if you select hardware handshaking. Why?
Because your terminal emulator may wait until certain handshake lines
are asserted before sending data down to the UBW. Since the UBW does
not implement any of the handshaking lines, this will never happen and
your UBW will appear to be dead. So make sure you DISABLE or turn off
any hardware handshaking. Don't use software handshaking either -
always set it to 'off' or 'none'.