Capturing MUX'd BCD from ICL7135

Hi all,

I have searched for taking a BCD output and capturing/reading the BCD (multiplexed) data with an Arduino, but only come up with 7-Segment implementations.

My idea consists of using an ICL7135 as the precision voltmeter and output to an Arduino/ATmega328. I have no problem building a 7135 with an LED display as it is very simple, but I want something a little different for the display. The 328 needs act as the decoder/driver to output to a ST7920 128x64 dot matrix display for a custom look rather than using standard 7-segment displays. More precise, I want to use (2) 7135’s, one for voltage and one for current and interface to (1) 328.

I lack a lot with intermediate to advanced programming and have no idea where to start with the code to catch the BCD output of the 7135. I can find no examples anywhere regarding reading BCD from code.

I have read a couple of other topics where Grumpy_Mike had commented about catching the BCD from a 7135, but could not find anything more within the forum nor Google.

Any help would greatly be appreciated.

but only come up with 7-Segment implementations.

It is exactly the same be it BCD or seven segment display it is just data.

I have read a couple of other topics where Grumpy_Mike had commented about catching the BCD from a 7135, but could not find anything more within the forum nor Google.

Yes I did this as an article in a magazine way way back. It used to be on line at my old University MMU. But last year the college who was hosting it retired and they took it down. I still have a copy of the web site so I will try and post the information here. I can’t do it now as I am on a mobile device, so I will try and get it on later today.

Here it is. The code was for a different processor and he language was BBC basic, but it should translate to C. Connect the strobe line to the external interrupt pin and have the ISR read the bit pattern and store it. Note the bit pattern contains not only the number but also the position of the number in the display. Keep reading until you have all the digits.

BBC25T.txt (13.9 KB)

Thanks Grumpy_Mike. The article was very informative and great detail on theory of the operation. I will take this and get started. I understand multiplexing, but struggle with the code. I will post my results in the near future to share with everyone, but may be a while. Thanks again.

Why do you want to use this chip? What range of voltages & currents do you want to measure, and with what precision? Surely there must be easier ways with more modern chips. What about using ads1115 for example? That has 4 channels, 16-bit resolution and programmable input gain amplifier.

The main and only reason behind it is because I already have an abundance of 7135's as well as voltage references on hand that I have had for close to 2 decades and they simply need to be used. No need to purchase anything else at the moment. The 7135's will be used as a panel meter measuring up to 20VDC and current up to 10A.

Ok, so you will need 3 Arduino pins for the display (MISO, CLK plus one other). Each 7135 will need, what, 11 pins each? Will the '328 have enough pins? With a bare '328 programmed using ISP and no need for a crystal, you will get 4 more digital input pins to use than with Uno/Nano.

Each 7135 will need, what, 11 pins each?

Just 8. Note the clever thing I do with the NOR gates to reduce the number of pins needed.

From what I can see and based on the outputs from Mike's schematic, I should only need 9 input pins for each 7135 by omitting the polarity output as it would not be needed for a panel meter and as you suggested using the internal clock, I may have enough... just enough.

Yes I did notice that right away with the NOR which was very clever indeed. I have not had the opportunity to really study your schematic, but I stand corrected on my last post of 9 pins. However, with the strobe output, it would still be 8 pins needed if polarity was omitted.

I did do a version of this for the Raspberry Pi for a book chapter but putting all the restive dividers on the PCBs I had put me off publishing it in that book. I used the Raspberry Pi running RISC OS but the inability to read all the GPIO ports in one go meant it did not even work correctly. So in that respect the old BBC computer was superior the the Raspberry Pi almost 40 years later.

Yep there are still old school designs and parts that just cannot be surpassed by todays technologies.

From the data sheet:

STROBE (Pin 26)
This is a negative going output pulse that aids in transferring the BCD data to external latches, UARTs, or microprocessors. There are 5 negative going STROBE pulses that occur in the center of each of the digit drive pulses and occur once and only once for each measurement cycle starting 101 clock pulses after the end of the full measurement cycle. Digit 5 (MSD) goes high at the end of the measurement cycle and stays on for 201 counts. In the center of this digit pulse (to avoid race conditions between changing BCD and digit drives) the first STROBE pulse goes negative for 1/2 clock pulse width. Similarly, after digit 5, digit 4 goes high (for 200 clock pulses) and 100 pulses later the STROBE goes negative for the second time. This continues through digit 1 (LSD) when the fifth and last STROBE pulse is sent.

So if the STROBE pin is attached to an external interrupt, and the 4 BCD pins are captured by the ISR on the falling(?) edge, only digit 5 needs to be connected to the Arduino. If digit 5 is high, the ISR knows that this is the first of the 5 digits. On subsequent interrupts, the digit 4, digit 3, digit 2 and digit 1 pins will be high, but these don't need to be read because they always follow that sequence. Therefore, only the 4 BCD pins, the STROBE pin and the digit 5 pin needs to be connected to the Arduino. That's only 6 pins. Would that work?

That would only work if you could ensure that you get every strobe pulse without any latency. In practice I found this not to be the case. Now this was back in 85 using a 6502 processor clocked at 4MHz running the BBC computer’s operating system, which like the Arduino’s real time clock interrupted things. On the BBC you had things like the frame flyback triggering interrupts to do things like synchronising screen updates, the equivalent of the millis function and the “flashing” colours of some modes. I certainly found it was not 100% on the Arm system of the Raspberry Pi when restricted to reading one GPIO pin at a time in machine code.

It would also mean waiting until you did get pin 5 high before gathering in the sequence.

The data sheet says that the external clock would typically be 120KHz, and that the measurement cycle takes 40,000 cycles which is 3 readings per second. The STROBE pulses will be spaced by 200 clock cycles which is around 1.67ms. The STROBE edge is 100 clock cycles after the BCD & digit pins change and 100 clock cycles before the next change. So the ISR would have around 0.83ms to respond and capture the readings on the BCD pins.

To me, that sounds achievable. Even if the ISR was delayed by the millis() interrupt, there should still be plenty of time to capture the BCD pins.

And by using a timeout, say 100ms, after a STROBE signal to reset the digit count to 1, you might not even need to attach any of the digit pins to the Arduino, just do it all on timing.

Neither the BBC micro (my model B was only 2MHz clock) or the Pi are real-time operating systems, so maybe that's why the latency was a problem?

my model B was only 2MHz clock

Was it a US one?

Was it a US one?

No, I believe it was made at the ICL factory in Kidsgrove, where my father worked as an engineer for over 20 years, and I had a summer job for a couple of months while I was studying in Manchester.

Interesting, I got offered a job there after my post grad research, but I turned it down in favour of a lecturing career in Manchester.

I never knew the made a 2MHz one, I wonder why they did that?

I never knew the made a 2MHz one, I wonder why they did that?

I didn't know they made a 4MHz one. I remember the ram clock speed was 4MHz, so that the CPU and video chips could access it on alternating cycles, avoiding contention with each other.

EDIT: was that the "BBC Master Turbo" with the faster second processor?

Oh I never had one of those. Looks like they identified a bottle neck and sacrificed processor performance for graphics. Maybe because it looked more impressive.