Using a Thermal Printer Mechanism

 Using a Thermal Printer Mechanism

The Casio CP-10 is a neat calculator that has a thermal printer attached. The calculator also has a built-in clock and can do useful tasks such as printing this month's calendar. The date range is also useful as it ends in 2099. The printer is a small mechanism that take standard 38mm thermal paper. I found out that the mechanism is the same one that the FP-12 printer uses. This is a small printer that is designed to attach to a variety of calculators and pocket computers.

I bought a CP-10 to see if I could re-use the printer mechanism instead of the receipt printers that I have bought off ebay in the past. They are relatively expensive (over £20) whereas the CP-10 can be had for half the price, if the CP-10 is listed as non-working. Unfortunately the CP-10 has a NiCd battery pack, as the printer mechanism take a fair current when running and the pack is used to supply that. This means that a lot of CP-10s have suffered battery leakage and failed. This is what had happened to my example. After a brief attempt to revive it I cut off the printer mechanism and attached a blue pill and some extra circuitry.

There's seven transistors, one for each thermal element, and one transistor that drives the motor. There's an input for the home position switch as well. The mechanism has a tachometer output that gives a series of pulses as a magnet rotates near a coil. The magnet is attached to the motor, so this arrangement gives a reading of the motor speed. The pulse may also be used for dot timing. Unfortunately my mechanism seems to have a broken tachometer output. The coil reads 25M resistance, which is a bit high for a coil of wire. (I have since bought a second CP-10, this one shows signs of life and its coil reads 82R, so is much healthier). After trying my own tacho circuit, then copying the CP-10 circuit, then building a higher gain circuit with an op-amp I decided that the tacho output wasn't reliable enough to use. This may not be too much of a problem if the motor is run off a stable supply as the speed of the motor should be fixed. I should be able to time the motor moving from home position back to home position and scale the dot timings appropriately if need be.

The output from my working CP-10 is like this:

That's the calendar printout from the CP-10. The FP-12 has a print width of 20 characters, the CP-10 also seems to have a print width of 20 characters.

My first attempt at printing was a little more basic than a calculator. I turned the motor on and fired one element of the print head repeatedly:

This is a start, at least I'm getting dots. The motor drive also performs line feeds and the dots show that. The horizontal dots are the feed across the paper. the sloping dots are where the head is returning and the paper is being fed. After some work with the code, including adding a font table and using the input from the home switch, this is the output:

This is a test printout that is printing the parameters of the code that printed that section. I am also using 20 characters as the width here, simply because the mechanism is set up for it. There's a row at the top of the characters that is faint, I think this is to do with the ground wiring I have used.

There is also an interesting effect which is best shown in the lines of asterisks. They are darker on the right hand side of the line. I'm pretty sure this is down to the heating of the printhead as elements are turned on. Every time a dot is printed, the printhead warms up a bit. This means that to get an equivalent dot, you don't need to turn the element on quite as long the next time. In the printout above, I have a parameter called 'DEC_PERIOD' which controls part of my correction for this thermal heating effect. You can see that the second from bottom section has a DEC_PERIOD of 1 and the asterisks are darker to the right hand side of the line. The section above it has a DEC_PERIOD of 2 and the asterisks are printed more evenly.  The correction code counts the number of elements that have fired, accumulates those counts and uses them to create a 'temperature' for the printhead.  The DEC_PERIOD value controls the cooling of the printhead. This does lead to a working correction as can be seen above.

I think the CP-10 code must also be doing something similar, as the calendar printouts above show an even darkness across all the lines.

The CP-10 must also be correcting for supply voltage variations. It runs off four NiCd cells which will present a range of voltages to the motor and hence different speeds of printing. I have attached my working CP-10 to a power supply and varied the voltage. The time to print a line definitely changes, but the characters printed remain in the correct positions. The printout is fainter when the voltage is lower. The code could be using the tachometer signals from the mechanism. I can't do this but I could measure the time taken to print a blank line and use that to adjust the dot timings. Interestingly it appears that the CP-10 does print one blank line after it is powered on. I wonder if that is a timing line and the CP-10 is doing what I will probably have to do if I want to correct for voltage?

Next step? probably a PCB. But do I use a blue pill or STM32 chip? Given the size of the mechanism, a blue pill is a bit on the big side, so I think a chip would be better. The only problem is that there is quite a shortage of STM32s at the moment. I've got a few so that is probably OK.

There's a video here of the prototype:

 

 

Casio FX-502P SD Card Gadget Prototype

 Casio FX-502P SD Card Gadget Prototype

A while back I made a gadget that attached to a Casio FX-502P via an FA-1 and stored programs and data on an SD card instead of a cassette . 

https://trochilidae.blogspot.com/2017/06/fx502p-cassette-interface.html

It decoded the frequencies that the FA-1 sent to a cassette recorder and wrote the data to an SD card attached to an Arduino Due. I had to use a Due as it was the only combination of  clock frequency and RAM that could keep up with the data stream coming out of the FA-1. 

The advantage of using this approach was that the cassette interface was a well-known format and fairly easy to decode. The disadvantage is the bulk of the final package. To get the data onto the tiny little SD card you need the FA-1 cradle and the gadget. A few weeks ago I suddenly realised that I could cut down on a lot of the hardware needed by attaching a gadget to the expansion port on the top of the FX-502P. This would involve interacting with the protocol that goes over the expansion port, but that shouldn't be a problem. There's a lot of detail here about the expansion port of the FX-602P and FX-700P.

As a base for a prototype I used the Sharp PC-G850 gadget, using the Blue Pill processor and the OLED display. The expansion port signals are attached to the 11 pin Sharp interface connector on the gadget using a cable.

The protocol that the expansion port uses is a bit odd. It seems to be the bus that the processor in the calculator uses to talk to the LCD controller. It has a single bi-directional  serial data line, a chip select, a command/data control line and a clock for the serial data. The data packets are of variable length, which makes it a bit hard to decode. Most packets are 6 bits long, there is one two bit packet and a 16 bit long data packet (holding an RS232 type character format that encodes a single byte of data. The clock edge that the data is latched on is different for transmitted and received data. And the data is inverted logic (0 is 3V and 1 is 0V, not forgetting that the calculator uses 3V as it's 'GND' and -3V as its VDD).

Once the signal levels are sorted (use 0 and 3V to power the STM32, invert data to get levels that match the known commands for the FX-602P) the data and clock can be fed to GPIO lines on the STM32, The bus runs at around 200kHz, so there's not a lot of time to process the packets. It is not feasible to have any delays so I run the decoding code purely in interrupts (one on the SP or clock line and one on the CE signal). The timing is so tight that initially I had problems with the serial port disabling interrupts (I presume that is what it was, disabling serial IO removed the problem), those problems went away with later code, but I can still disable the serial port access when packets are received.

The data that is sent and received is held in a RAM buffer, there is no time for access of the SD card, so the RAM buffer is stored and loaded from SD card when needed.

After quite a lot of reverse engineering of the interface (the FX-502P is not quite the same as the FX-602P) including capturing traces of communication between the calculator and an FA-1 adapter, I got some working code that could both send and receive data files from the calculator.

This gives a gateway between the calculator and the outside world. The calculator has a limited number of ways to send information over the interface. It can send or receive a single number (this is the quickest transfer), it can send or receive all memories

At this point the prototype was limiting the code as there isn't sufficient flash memory on a Blue Pill (STM32F103C8) to implement the features I wanted to add. The basic idea had been proven with the prototype, time to move on to a better platform. For that I chose the STM32F103RE device. Or, more accurately I chose the 64 pin QFP package. The STM32F103 family has nice pin compatible genetics, so several devices of different capacities will fit onto a particular footprint. Using the 64 pin QFP I can got up to 1M of flash and 96K of RAM down to 16K of flash and 6K of RAM. There's also a lot of GPIO on this package, way more than I need for this gadget.

It has a small 0.96" OLED display, an SD card module and a programming header that uses an STLINk V2. It also has a serial data header with TX and RX, and a header with 8 GPIOs on it (and power):

The PCB plugs into the connector on the top of the calculator. Optionally the PCB can supply power to the calculator, or it can run off batteries, there's a jumper for that. It's the red one. 

I have also used a USB socket breakout board for the USB connection, which supplies poiwer for the PCB and also provides a serial connection. I use a breakout board as the USB sockets have a habit of ripping off the PCBs and taking tracks with them. This way the tracks are on a disposable PCB, not the more valuable one. I've already replaced the USB socket and breakout board on the is PCB...

The code is based on the Arduino platform, so it can connect to the serial monitor of the IDE.

What can it do? Well, it can save and load programs and memories to and from the SD card, that's the basic function. It also uses several 'special' values to do other things. Things like displaying programs on the OLED display:

 With GPIO lines you can interface any I2C device, such as a real time clock. This is the STM32 displaying time in a display mode set up by the 502, using a DS3231 RTC module:

You can also read the time (and date) into calculator memories:

Of course, it is useful to be able to print things out now and again. Interfacing a simple thermal printer isn't difficult. The one I used accepts serial data so I attached it to the serial data header .The calculator can set up a print flag that sends programs and memories to the printer as well as SD card.

This printer does require a 2A supply, so can't run off the USB direct from the PCB.  

There was a printer that attached to the FX-502P, but it used magic metallised paper which is pretty much impossible to find these days, so a thermal paper option is a nice alternative. See here for more magic metallised paper experiments:

https://trochilidae.blogspot.com/2019/12/magic-metal-paper-in-seventies-casio.html
https://trochilidae.blogspot.com/2020/01/more-magic-metallised-paper-experiments.html

As well as the RTC, I've attached a sensor module and an accelerometer, but haven't done much with them other than read registers. There's also a text mode where the calculator has a text screen that it can place ASCII text on, and a graphics screen that it can place pixels on.

More information on these videos.

The gadget should work perfectly fine with an FX-501P, as it's the same code and hardware in the calculator as shown in this video:

The FX-602P and FX-601P use the same interface but a slightly different command set. It should be possible to get it to work, though, with some changes to the firmware on the gadget. 

The FX-702P tantalisingly uses the same connector as the 502/602 series calculators, and the same command set as the FX-602P, but unfortunately uses 5V signalling rather than the 3V of the 502/602. The pins used on the STM32 for the calculator interface are 5V tolerant, but there's a couple of issues. The first is that the STM32 should be able to sense the 5V logic levels correctly, but may have trouble driving 5V levels due to 5V tolerant pins still driving at 3V3. The second issue is that the data line is bi-directional and the 5V tolerance on STM32 devices only works when it is configured as an input. I have serial resistors on the calculator interface lines, which might help, but if there's a time when driving the interface that I drive the data line as an output and the calculator does the same then there could be problems. I may try this in the future, as it may work.