|
|
|
Issue
99, October 1998
X-Y Graphing Data
Logger
by
Alberto Ricci Bitti
Start
• Machine
Muscle
• Using
Componentware
• Low-Power
Guys
• Flash
Risc Glue
• The Graphic
Engine
• Casio
Protocol
• Main
Code
• Inside
The Box
• Setting
up the Casio
• First
Graph
• Modeling
The Data
• Broader
Vision
• Software,
References & Sources
CASIO PROTOCOL
The Internet is now an invaluable
resource for designers. After a night of browsing, I found
some commented programs for loading calculator programs
to and from a PC. I found only partial information about
how to transmit or receive single variables instead of
programs, but it served as a good starting point.
I assumed that the variable
transfer format probably wasn’t so different from
the program transfer format. Notably, even the official
Casio FA-122 backup software can be found online.
I knew that the communication
was a 9600-bps half-duplex TTL serial stream, and I knew
communications should start with ACK/NACK-style, single-character
messages. Packets follow, starting with colons ($3A) and
terminating with checksums.
I also had PIC samples, some
good ready-made serial and BCD routines, and a microjack
plug. That’s all I needed to start experimenting.
Using a TTL–to–RS-232
level converter, I connected the calculator to the PC
serial port so I could monitor what’s going on.
After I issued the Receive(X)
command on the Casio, it sent out a $15 character and,
after 1 s, it aborted (a $22 character sent to the PC
prior to interrupt communications).
I made a Visual Basic program
to issue various characters after that attention request
(see Photo 2). I quickly discovered that the calculator
was waiting for a $13 character.
|
Photo 2—I
used Visual Basic to discover the inner secrets
of the Casio protocol. With VB5 it’s easy
to set up a quick and dirty serial protocol
debugger. Tasks responding automatically to
a control character, trying various serial speeds,
or sending packet strings are left to a simple
program loop. Thanks to Visual Basic’s
interpretative nature, you can stop the program,
issue any other command manually, then continue
execution. This way you avoid writing lots of
code. Here, the characters sent by the Casio
are in red, and the analog interface response
is in black.
|
A request packet from the
calculator follows this vital sign from the PC (50 bytes,
starting with :REQ), where the calculator defines the
variable to be sent. As expected, all nontrivial packets
start with a colon character and are terminated by a simple
negated checksum. With the exception of the last packet,
all require an acknowledgement message from the recipient
($06).
Since I didn’t know
how a value packet is made, I reversed the situation,
making the Visual Basic program act as a Casio calculator
issuing the Receive(X) command that was just received.
At the same time, the real Casio calculator issued Send(X).
In this reversed setup, the calculator issued a 50-byte
variable-address packet, starting with :VAR.
I reiterated this process,
continuously reversing the sender with the receiver, sometimes
simulating Send(X) and sometimes simulating Receive(X).
Packet after packet, the whole protocol was discovered,
as depicted in Figure 2.
|
Figure 2—Here
is the main flow of the Casio communication
protocol. Apart from reversed-TTL logic levels,
it’s a familiar half-duplex with 9600 bps,
no parity, eight data bits, and two stop bits.
A level converter and inverter like the MAX232
is all that's needed to interface the Casio
to a PC serial port.
|
|
