DJNZ rxDivide, RX_Done
MOV rxDivide, #Baud1x0
DEC rxCount
SZ
RR rxByte
SZ
JMP RX_Done
decided against using this code with the VMUSIC2 player
(non flow control code is fine). I will include the flow
control UART code in the download file (go to www.nuts
volts.com) so that you can use it with other projects.
PLAY THE MUSIC
RX_Buffer:
MOV W, #rxBuf
ADD W, rxHead
MOV FSR, W
MOV IND, rxByte
INC rxHead
CLRB rxHead.3
INC rxBufCnt
SETB rxReady
Update_CTS:
MOVB rxBufCnt.3, CTS
RX_Done:
BANK $00
ENDASM
Note the section called Update_CTS near the end
of this module — just one line of assembly takes care of
the CTS. What it’s doing is copying the value of bit 3 of
rxBufCnt to the CTS pin. We do this because the buffer,
has a maximum capacity of eight bytes; when we have
eight bytes in the buffer bit 3 of rxBufCnt will be high
and placing a high on the CTS line with cause the external
device (VMUSIC2, in this case) to stop transmitting
when it is configured for RTS/CTS hardware control.
Updating the transmit UART is equally simple: We
just abort the actual transmit section of the UART when
the RTS pin goes high. You’ll see that in the listing.
I tested the hardware flow control UARTs with a
Hyper Terminal and then proceeded to move forward with
the VMUSIC2 player. That’s when
things came to a big, screeching halt.
In Terry’s experiments with the
VMUSIC2 player, he simply wired the
CTS input low so that the unit could
send data any time it wanted to. This
works with the BASIC Stamp because
the serial input is ignored unless sitting
on a SERIN line. When using a
buffered UART, we could easily have
an overrun situation as the VMUSIC2
transmits position data as it’s playing.
Let me just cut right to the chase —
after a day and a half of experimenting,
I abandoned the idea of using flow
control with the VMUSIC2 player and
went to simple, non-interrupt code —
BASIC Stamp-style, if you will. The reason
for this is that when the CTS goes high
(our buffer is full), the VMUSIC2 stops
playing! This is not good and not worth
the trouble to deal with. In the end, I
have working code that gives my VP
UARTs hardware flow control, but I’ve
One of the great features of the VMUSIC2 player is
that you can reconfigure its baud rate by changing a file
on the memory stick. Terry has saved us the trouble of
creating these files and has two versions on his website
(see references): one for the BASIC Stamp 1 that operates
at 2400 baud; another for the BASIC Stamp 2 that
operates at 9600. While we could crank up the baud rate
for the SX, 9600 is fine as there’s not a lot of traffic and
that will let us move the VMUSIC2 player between the SX
and BASIC Stamp 2 without updating the firmware file.
So, before you get started you’ll need to copy the
file called ftrfb_9600.ftd to a memory stick, rename it
ftrfb.ftd, plug the stick into the player, and then apply
power. On the first power-up with this new firmware file,
it will be loaded into the VMUSIC2 player and will
configure it for 9600 baud ASCII input.
Okay, now, let’s play a file. Figure 1 illustrates the
connections to the VMUSIC2 player — which turn out to
be just exactly like Terry’s. Here’s the rub: The pin headers
on the back of the VMUSIC2 player are space at 2 mm
instead of the 2.54 mm (0.1 inch) like we’re used to.
The player does come with a short female-female cable,
but the pin spacing makes it useful on only one end. I cut
off one of the connectors and soldered male crimp pins
to the ends — this lets me prototype with the VMUSIC2
using any of my standard development boards (e.g.,
Parallax Professional development boards). Figures 2 and 3
■ FIGURE 1. VMUSIC2
connections.
September 2008 61