Project Logs

Collapse

• A Leap of Faith

  tomcircuit • 06/23/2024 at 15:35 • 0 comments

  I found a bit more time to work on this project - it was a bit of "work-work" in the way as well as some procrastination, because the next steps for this were fraught with peril: it was time to install the RCL57 MCU board into the TI-57 calculator. The first step was to carefully remove the (dead) TMC1501 DIP28 from the TI-57 without damaging the PCB. I ran into (er...created) this problem when I pulled the TMC1503 out of a TI-55 "donor unit"; I had to manually repair many broken traces due to delaminated pads or broken through-holes. With patience and care, I was able to extract the DIP and clean up the PCB without drama.

  I had hoped to use some low-profile Samtec 0.025" headers that I had obtained for this very purpose, but my hopes were dashed when I determined that the TI PCB hole diameters were sensibly sized for DIP pins, not 0.025" posts. I instead used machined-pin M-M header strips, which put the RCL57 PCB a bit further above the TI PCB than I would have liked. After a few test-fittings, however, I decided that everything would clear inside the calculator.

  Another step before installing the RCL57 PCB into its new home was to add the five pulldown resistors to the K1-K5 keypad column inputs. I decided to put these directly on the topside of the RCL57 PCB, 'air-wired' over the MCU itself. It looks only slightly ridiculous...

  With all these preliminaries out of the way, it was time for the moment of truth: installing the board into the TI-57. I was hesitant because of the frailty of the TI PCB - I don't know how many rework cycles it would withstand.

  RCL57 Board Installed into TI-57 - the "air wired" resistors are clearly visible.

  
  

  I connected the LiPo supply lid to the three position power connector and was rewarded with the rCL-57 "splash screen" after the calculator powered up - success!

  Apparently it’s hard to take a photo of the multiplexed LED display… 

  My current version of MCU firmware includes support for EEPROM storage of user programs, via the Program Manager feature, entered by simultaneously pressing 2nd and INV and CLR. I definitely need to test this more, but my limited trials with it are encouraging. I have two "Library Programs"  stored, one is the "hello" program and the others a "factors" program - both from the TI-57 Making Tracks into Programming manual. I will add more of these "library programs" soon - these are statically defined in the MCU source. I was able to copy these programs into two of the 20 "User Program" slots; so far everything is behaving as it should.

  I have in mind to add a feature to set the display brightness - maybe CLR with + or - simultaneously. I will have to look harder into my keypad scan logic to see if I can detect simultaneous keys in the same column.

  Anyhow, major milestone here!

• LiPo Battery Lid Progress

  tomcircuit • 05/14/2024 at 16:30 • 0 comments

  I was able to spend some time working on the 3D printed lid for this project. The RCL-57 electronics expect a supply between 3.3 and 5.0V, not the 9V from which the original calculator operated. Conveniently, a 3.6-ish volt LiPo cell does the job nicely, and the "rcl57_psu_debug" portion of the project includes a simple USB powered LiPo charger circuit that has served me well for HP Classic (35/45/55/65/67) and TI-58/59 calculator retrofits that I did previously.

  Yawn, nothing new to see here, move along...

  For the custom lid for the TI-57 calculator, I used the OpenSCAD lid design I made for the TI-58/59 calculator as a starting point. It only took 4 tries to end up with a tweaked lid that fits well and (more importantly) latches into the base. 

  The "walls" in the corner provide a bit of protection around the outside perimeter of the PCB, but otherwise nothing really special here. I am very happy with the latch - despite being printed in an unfavorable orientation, it doesn't want to shear off so easily. I added the "backstop" wall behind it to prevent overflex; hopefully that leads to a robust solution. I do need to add some LiPo cell retention features so that the cell isn't rattling around inside the calculator - but for now I can use a piece of double-sided tape to hold the cell. Hopefully that solution does not become another example of the mediocre being the enemy of the good.  OpenSCAD source and 3MF files are committed to the GitHub repository.

  Oh, some other tidbits:

  Another nod to @Jeff Parsons  who made the TI-55 ROM image easy to find  By including the TI-55 image in the Keil project, I am able to make my TI-55 "donor calculator" run the correct firmware, as opposed to pretending to be a TI-57. A #define in the software determines which ROM image to use, with the appropriate "splash screen" at power-on.

  I'm waiting on some samples from Samtec for low-profile 2.54mm pitch headers, so that I can actually put the RCL-57 board into a calculator directly, instead of relying upon the dip socket + header test setup monstrosity that I've been using. Other than my missing pulldown resistors, the hardware is 'good enough' and all that seems to remain is to polish the software - mostly the "program manager" for the EEPROM-based storage feature.

  3D printed lid w/LiPo charger board installed

  
  

  Lid fits nicely into the Majestic calculator back shell

• Power Save Mode

  tomcircuit • 05/06/2024 at 00:21 • 0 comments

  After getting the keyboard reading all sorted out, the TI-57 firmware isn’t being bombarded with false keypress data all the time. Imagine my surprise when, after sitting idle for a few minutes, I looked at the LED display and observed  a “marching decimal point” moving left-to-right across the display. It can only be the original TI-57 built-in power save mode. My own power save mode, a winking decimal at the leftmost digit, kicked in a few minutes later. 
  

  Now I need to measure current during each one to see which is better - I suspect it’s mine, because the TLC5929 is in sleep mode and the MCU is in idle mode the vast majority of the time. But the marching decimal points sure are fun!  

• DMA be Damned!

  tomcircuit • 04/24/2024 at 02:17 • 0 comments

  With moderately “stiff” resistor pulldowns on the five K1-K5 keyboard column inputs, it’s possible to read them using the STM32F103’s ADC. Of course, that’s not as easy as one might think. 
  

  The STM32 family has a very nice 12bit ADC subsystem, providing lots of input channels, ability to autonomously scan across them, in an arbitrary order, all in the background while the CPU chugs away. My initial thought was to configure the ADC to convert analog channels 0 through 4, which correspond to pins PA0-PA4, which in turn are connected to the K1-K5 keypad columns. In theory this can be done so that a software trigger starts the sequence, and either polling or interrupt at end of conversion. 
  

  Unfortunately, there is only a single ADC result register. So, after each channel is converted the results must be moved from the DR register to elsewhere in memory. The preferred way to do this, according to ST, is to use the DMA controller to do this, to be sure there is no possibility of data overrun and losing a conversion result. 
  

  I couldn’t get it to work. Even with a lot of experimenting. Most examples were using HAL library, whereas I am using Standard Peripheral Library. I just couldn’t get DMA based ADC to work  
  

  The ADC has a neat feature to allow up to four conversions to be “injected” into the queue. These injected conversions take priority over the ‘normal’ channel sequence, and more importantly each injected conversion has its own, dedicated, result register. So, I can convert one “regular” channel and then request four “injected” conversions. After all conversions are complete, I can unload the results from the one regular result register and the four injected result registers. 
  

  It works like a charm, and no DMA required. I might revisit DMA at some point, but this is a perfectly workable solution. If anyone has an SPL example of DMA based single scanned ADC conversion, please share with me!

• Keyboard Woes

  tomcircuit • 04/16/2024 at 00:37 • 0 comments

  At this point the display is working quite nicely - segment drivers are driving, current sinks are sinking, LED’s are emitting. Joy. 
  

  Tests with the keyboard, however, have been less successful. That slowly delaying segment driver output, and what I can only assume is a leakage path across the FETs, results in a very ugly multi-voltage waveform. No issue for the LED displays - LED's are current, not voltage, controlled beasties, so they light up when the should and stay dark otherwise. But, this leakage path voltage is a big problem for the keyboard column inputs - when a key is pressed, it is typically registering in several rows. All because the row (segment) voltages are interacting with one another; they are not ‘crisp’ CMOS levels
  

  I spent several hours thinking about how to tame the segment voltages. An initially promising solution was adding N MOSFETs to make CMOS P-P segment drivers. Challenging from a PCB area standpoint because it would double the number of MOSFETs but ultimately not a solution for the D and DP segments, because they are shared with the current sinks for D1 and D12. Driving either of these “segments” low whilst another segment is high would illuminate that segment on D1 and D12, very brightly.  
  

  I thought about how the TI engineers must have solved this. I concluded that this melange of voltages is only a problem for reading keys. The beautiful display was confirmation of this. So, rather than trying to tame the segment voltages, I shifted my focus entirely towards reading the keyboard columns. A “simple fix” would be to make the VIH threshold much higher than the garbage on the un-driven segment outputs. Easy to do in a custom IC, but not possible with a standard MCU. Reading the column voltages with an ADC, however, is the next best thing.

  I experimented with the ADC but quickly discovered that the STM32F103 MCU doesn’t allow the GPIO internal pulldowns to be enabled when a pin is configured as an Analog Input. So I added some leaded resistor pulldowns on my test setup. Voila! My random selection of 1.8K and 5.1K pulldown resistors dissipated all the nasty voltages on 6 of the 8 segment lines when a keyswitch in those rows is closed - there's a nice, crisp 3.3V pulse for the 700us active segment interval.

  When the columns are switched to the shared lines (D+D12 and DP+D1) the voltages are still ugly - this is unavoidable because of the shared digit cathode and segment anode arrangement on those two digits. The "high" level (green box, peak around 3.3V) is the segment driver row being read through a key column. The "medium" level (blue box, peaks around 1.7V) are the segment drivers for the other rows being read via the shared segment-digit path into the key column input. For these two rows (segments D and DP, rows 7 & 8 on the keypad) even with the addition of column input pulldown resistors, I will have to use the ADC to manually threshold the signal to something above, say, 2.5V. (Note: I suppose that I could add a series diode to the segment D and DP outputs to reduce this residual voltage to something below the MCU VIH threshold, but that means even more parts on the PCB...) 

  Unfortunately, this means a new PCB, to add pulldowns on the K1-K5 inputs…  I can prototype with the pulldown resistors tacked to the bottom of the TI PCB but I'm not super-happy with that as a long-term solution.

• When 700us isn't 700us...

  tomcircuit • 04/01/2024 at 17:42 • 0 comments

  I've assembled four of the rcl57 PCB.  Three actually function.  The fourth wouldn't connect via SWD to get flashed. Even after replacing and reworking the VQFN36 MCU I was not able to get it to work. So, I have three boards right now, one of which I have setup for test/debug.

  With the PCB populated, I can now see the effects of the few off-MCU hardware resources of the rcl57 circuit. One thing I really wanted to look into was the effect using the open-drain Pch MOSFET drivers for segment anode drivers. On the one hand, they can source a lot of current - more than 60mA or so maximum that will ever be needed. On the other hand, with just the PCB and no attached LED digits, I was able to observe that the PMOS segment driver outputs were high longer than the 700us low-going gate pulse. For example, in this screenshot, the segment output registers as "high" to my Saleae logic analyzer for about 1.1ms (top trace):
  

  Looking into the analog domain (lower trace), it's easy to guess what is happening: the segment output is slowly discharging into the input of the logic analyzer (high Z input). 

  When an LED is present between a segment output and a digit sink, the digital pulse width (top trace) is right in line with the gate pulse width - the voltage rapidly falls below 1.6V

  Looking at the analog voltage in this case (lower trace) it's clear what is going on - the LED discharges the drain output until the LED no longer conducts, at which point the residual charge simply leaks away. Therefore, when a segment is to be illuminated in at least one of the twelve digit positions, the segment voltage will discharge quickly through the LED(s). That's good news, and really means that nothing special needs to be done to discharge the segment outputs; the LEDs themselves will take care of this problem for us. 
  

  What about 'dark segment intervals' - segment intervals in which no LED in any of the digit positions is illuminated? Well, we're back to a slowly decaying >1ms pulse; there's no low impedance discharge path for segment drive output. This is a problem because the subsequent segment will get enabled after 800us and there will be about 300us of 'overlap' with two segments active at the same time:

  Why could this 'overlap' be a problem?  Well, if a dark segment interval is followed by a non-dark segment interval, the residual charge on the 'dark' segment output will dump through the digits that are subsequently enabled. That could end up looking like "sparkle" in the display. Sure, it would be a brief flash, but here's an interesting post on stackexchange that claims that around 150ns of "on" time could be visible.

  Ok, well, then why drive inactive segments at all? Why I am paying so much attention to the logic analyzer's "digital interpretation" of the decaying voltage on the segment driver outputs?  The answers to both of these questions are related, and all revolve around the fact that the segment driver outputs are also used for reading the keypad. If the segment isn't driven at all, then the corresponding row of the keyboard cannot be read. If the slowly decaying voltage were to take too long to decay, it could end up being "high enough" when subsequent segment keyboard reads take place - so keys from more than one row could potentially be read simultaneously, leading to strange behavior. The logic analyzer digital interpretation of the voltage indication an idea of what the STM32F103 GPIO pin would read.
  

  Ok, so for segment intervals in which there is no display activity, we need only to read the keyboard. So far, my plan to achieve this is the following:  as the display update function (hw_display_update) loops though the 8 segment intervals, if no digits are to be activated during this segment interval, the segment output is driven for only 100us, rather than 700us. At the end of the 100us, the keyboard row lines are read, and then the segment output is disabled...

  Read more »

• Power Supply and Lid

  tomcircuit • 03/13/2024 at 15:02 • 0 comments

  Rcl57mcu wants a 3.5-5V supply. So, even if I could resurrect the dead BP-7 NiCd pack/lid, it won’t work for this upgrade. I will instead recycle the tried-and-true USB charged 3.7V LiPo supply that I’ve used for HP Classic, HP-28S, and TI-58/59 supply upgrades. I will 3D print a new case lid that holds the LiPo and a small PCB with the charging circuitry. So, another PCB is needed, but it certainly doesn’t merit a 4-layer board. I created a separate KiCad project with the PSU and a “debug breakout board” on a common 2-layer PCB. The latter is to make it easy to program/debug the rcl57mcu through its 2mm pitch header pins. These pair nicely onto a single board with perforations in between. Adding this 2-layer PCB to my 4-layer PCB order only cost an additional $5 and avoided  shipping charges had it been ordered separately. 
  

  I had it in mind that the TI-57 with rcl57mcu could be operated while charging. That’s why I put a diode between VBAT and the source terminal of the PMOS LED Anode drivers - with the MCU driving the gate at 3.3V, the source voltage should be able to be as much as 1.7V higher, or about 5V, and still keep the PMOS drivers in cutoff. The LiPo charge voltage is about 4.2V, so no problem here. Physically, however, I don’t see a nice way to attacg a USB plug, so I will just put the USB receptacle on the inside of the lid - meaning the lid has to be open to charge. I guess one could still operate the calculator with an open back and dangling wires… My experience is that these classic LED calculators running from LiPo cells don’t need to be charged very often at all. 
  

  Maybe I will look into a wireless charging solution at some point - the lid area seems large enough to easily pull this off…

• Driving the Display

  tomcircuit • 03/02/2024 at 15:43 • 0 comments

  The TI-57 has a multiplexed 12-digit common cathode LED display. The corresponding 8 segments of all 12 digits are connected together; sort of. It turns out that TI economized on IC package pins by ”doubling up” the decimal point segment anode with the digit 1 cathode, and the “d” segment anode with the digit 12 cathode. This means it’s impossible to display a decimal point on the rightmost digit, and a “d” segment (the bottommost segment) on the leftmost digit. Each segment line is also connected to one row of keyboard switches. Each column of keyboard switches is common and connected to an MCU GPIO input. 
  

  Due to the “segment scanning” approach that TI chose to use, each segment driver must be able to source up to 12 digit’s worth of anode current - up to 60mA. This is too much for one MCU GPIO to supply, so I chose to use a P-channel MOSFET to drive each anode line; the MCU needs to drive the gate of the P-MOS low to source current to that anode line. At the same time, the cathode for the digit(s) that require that particular segment to be illuminated must be driven low to cause current to flow. Because any digit has at most one segment illuminated at a time, the “on” current per digit is 5mA. An MCU GPIO and series resistor could carry this current, but it’s easier to use a Constant Current LED driver to do this. I chose the Texas Instruments TLC5929 for this job. It’s essentially a shift register with 16 constant current sink outputs that are turned on or off via the serial control word. This device is particularly well-suited because it allows analog current adjustment via the serial word. It also features a Power Save mode that reduces the quiescent current to tens of uA when all outputs are off. These are both notable features of this device, and what drove me to choose it. The only downside of this device is that it requires a 17-bit serial control word, but the MCU SPI peripheral only supports 8 or 16 bit word lengths - so the serial interface must be “bit-banged”.
  

  During a display cycle, the MCU must process the display content segment by segment. The MCU must shift the correct digit enable outputs into the TLC5929 and enable the segment output by driving it low. Then pause for 800us to allow the LEDs to illuminate and be visible. At the end of this 800us period, the MCU samples the Keyboard Column inputs - if any keys in the keyboard row connected to that segment line are pressed, the corresponding keyboard column inputs will read as high. This 800us sequence is repeated for each of the segments - an entire display cycle lasts 6.4ms. The TI-57 ROM includes DISPlay instructions at the necessary intervals to generate a flicker-free display. The MCU can be put into a low power Sleep Mode for most of each segment’s 800us interval, keeping current drain to a minimum. Furthermore, the Power Save feature of the TLC5929 automatically reduces the current draw of that device anytime all of the digit output sinks are off. 

• Blue Pill Emulation

  tomcircuit • 02/28/2024 at 23:44 • 0 comments

  Another key part of ensuring that replacing the TI-57's TMC1500 "brain" is possible is to ensure that the MCU has enough throughput to emulate it. My initial assumption was that a 64MHz 32-bit ARM MCU should be more than up to the task of emulating a nearly 50-year-old PMOS chip. In this, I was supremely confident.

  What's better than being supremely confident, you might ask? Actually knowing, that's what!

  I had already started down the path of understanding Paul Novaes' excellent "RCL-57" emulation code - firstly by reducing it down to the "engine" (emulation core) and porting that to run under windows using Pelles C.  That yielded a tremendous amount of education, aided by a multitude of printf() statements! Next step was to take the basic emulation core and migrate it to Keil ARM MDK and target the STM32F103 MCU on a Blue Pill board. After a bit of text editor jackhammering, the code compiled into a tidy 7KB (including the TI-57 ROM image). I was hesitant to make any changes to ti57.c, state57.c, etc. but in the end I had to do this, anyhow, to make the ARM C compiler happy. This was a bit unexpected, because my experiments on a windows C compiler didn't require any changes. Par for the course with embedded software...

  The result was a 32-bit ARM M3 microcontroller at 64MHz executing ti57_next() in an infinite loop, with one pin toggling state after each instruction (the white trace in the figure below) and another pin indicating with a brief pulse when a DISPlay instruction occurs (the orange trace).

  On this target at 64MHz sysclk, each TMC1500 instruction takes around 5us - some more, some less. Recall that the TI-57 instruction rate is 5KHz, or 200us. So this particular MCU running at full speed is about 40x the throughput of the original. This can be put to use in one of two ways: 1. MCU clock reduction to save battery life, or 2. massive speedup versus the original.
  

  After more discussion with Paul, he suggested that 4x speedup vs original results in a pretty comfortable experience - so 50us per executed TMC1500 instruction. Playing with the MCU clock rate PLL multiplier and the systick timer, I determined that 24 MHz sysclk works pretty nicely - that's a 3X PLL multiplier (minimum is 2x). Most TMC1500 instructions take about 14us in this case. It's easy to put the MCU into sleep mode after each instruction executes, and then use the systick timer as wakeup. The end result is that one instruction gets executed every 50us, and average MCU current should end up right around 4mA.  Running the MCU at 64MHz sysclk and 50us systick increases the average current to 6.5mA, and of course still the same apparent 4x speedup (that's determined by systick interval).  I might consider an option at poweron (maybe hold-down a specific key during poweron) to run the sysclk at the maximum of 64MHz and run without waiting on systick - 'wide open throttle mode' - if that's somehow useful or interesting.  We'll see...

  To keep the overall "UI timing" of the TI-57, I chose to retain the 6.4ms display cycle timing. This preserves the flashing display rate (after an error, for example) and the PAUSE interval. So when the MCU is running actual TI-57 "calculations" it is running 4x the original, but when it is running DISPlay instructions (and keyboard scanning) it is running at the same timing as the original. 

• I didn't choose the MCU ... it chose me!

  tomcircuit • 02/28/2024 at 22:51 • 0 comments

  I like the STM32 ARM cortex MCU family. They are well documented, readily available, and cheap 'breakout boards' for them abound. The MCU retrofit must fit nicely in the space of a 28-pin 0.6" pitch DIP, so package size is key.  The STM32F103 is an ARM Cortex M3 MCU that can run at up to 64MHz from its internal 8MHz oscillator. It's available in a 5x5mm QFN36 package. It's also the same part (well, from the same family) as the MCU on the ubiquitous "Blue Pill" boards. So, there's a cheap evaluation platform available.

  There are not so many other choices in small-yet-still-hobby-solderable-package MCU, so I really wanted to make the QFN36 device work. 

  Of course, with 36 pins, that makes GPIO a bit scarce. I need 8 segment anode driver enables, 12 digit cathode sink pins, and 5 keyboard sense lines. That's about 3 too many. Also, making space for the 12 digit cathode ballast resistors (to achieve 5mA segment current) was clearly going to be tough. LED digit drivers with serial interfaces abound, and nice ones provide constant current sink outputs, eliminating the dozen ballast resistors. Well, ok, the driver has one resistor to set the current for the outputs, but that's a great convenience! I found a number of 16-output LED driver chips that use a simple serial interface. I opted for speed over pincount, and favored the simple serial "shift register like" interface over I2C. That means that the 12 digit cathode sinks can be controlled by just 3 GPIO pins - a net savings of 9 GPIO.

  The other approach would be to use a 3-to-8 decoder, such as an 74HC138. This would allow the 8 segment lines to be controlled by only 3 GPIO. But, that doesn't eliminate the ballast resistors and only yields a net savings of 5 GPIO.

  The STM32F103TBU6 has 128KB of onchip FLASH, which turns out to be far more than required. It also has SPI and UART and timers and all sort of other goodies that I probably won't need. 

  So, we have a winner based upon package size, availability, and onchip goodies.
  

View all 12 project logs