Hi,
I’m new to this forum. I’ve had a Logic16 (the original version) for a while now. Just found a reason to use it. I have a Revox FM tuner that uses the old CBUS serial protocol that predates the I2C protocol. The tuner uses a Philips MAB8440P MCU. The MCU talks to a SAA1061 output port expander, an SAA1057 PLL synthesizer IC (for the digital control of the tuner frequency) and a PCE2111 64 segment LCD duplex driver. As these 3 chips are on the same bus, I need to find a way of identifying what data is going where. There is a CLK (clock burst) pin, a DLEN (data latch enable pin) and a DATA pin. I have seen a number of references to the I2C protocol being similar to the older CBUS (section 10.1.3 page 18 of the i2c_spec.pdf file attached). I have attached a few data sheets that contain the timing diagrams/data for the devices mentioned above that ALL use the CBUS. There are NO documents available as far as I know that directly refer to the CBUS itself. If I find any,
I will post them here. If I need to, is it possible to modify the I2C protocol (or maybe someone more experienced than me could help me to do it)? Are there any tips on which trigger condition I can use to try to narrow down the information I require. I’m mainly concentrating on the LCD display to start with, as it’s a bit flaky. The data sent to the PCE2111 driver is which segment to light up, so if I could isolate this section of data, that would be a very good start. Thanks.
SAA1061.pdf (169.9 KB)
PCE2111.pdf (404.1 KB)
SAA1057_NOTE.pdf (3.5 MB)
i2c_spec.pdf (303.0 KB)
@davidjsbriscoe Welcome to the forums! It’s great to hear that you’ve found a reason to pull out your Logic16. Just to make sure I know exactly which model you are using, can you confirm that you are using the “SALEAE009 Logic16 (original)” at the bottom of the support article below?
There are 2 “out-of-the-box” solutions I can think of that might be able to decode your incoming data (CLK, DLEN, CBUS) at a surface level.
-
The 3 bus lines that you mentioned actually look more compatible with our SPI analyzer than our I2C analyzer. Our I2C analyzer doesn’t have support for a DLEN line, but our SPI analyzer does. However, our SPI analyzer will output the data “as-is” and will not discern between IC address and data. I’ve shared an image below as an example.
-
As an alternative, you could use our I2C analyzer, however, it doesn’t have support for looking at the DLEN line and would simply decode data whether or not the DLEN line is active (it will simply decode on the rising or falling edges of CLK depending on how you have the I2C analyzer configured). However, the advantage with the I2C analyzer is that it will discern between address and data. You can take a look at out I2C analyzer in action in the support article below:
I2C Analyzer - User Guide - Saleae Support
Finally, for your question below:
is it possible to modify the I2C protocol (or maybe someone more experienced than me could help me to do it)?
It is in fact possible! You would need extensive C++ knowledge to do so, and our SDK and anlayzer source code can be found below:
An easier alternative might be to create a Python High Level Analyzer (HLA) extension that sits on top of our SPI analyzer to decode address and data for your different ICs on the same bus. Information on creating Python HLAs can be found below:
Hope the resources above help!
Thanks for your reply.
I’m currently working on using a PIC microcontroller to send DATA,DLEN and CLK signals to the PCE2111 64 segment LCD duplex driver chip. I want to be able to isolate the specific data word that can for instance “light up” or activate the 8 segments of digit 5 on the display to produce the number ZERO. I have managed to do this by sending the following 2 32 bit words serially down the DATA wire.
//int32 low32 = 0x48010000; //SEGMENTS 5A,5B,5C,5D,5E,5F,5G and 5L segments ON, Rest OFF. Shows number ZERO on DIGIT 5.
//int32 high32 = 0x6C000001; // 4 BIT NIBBLE 1 (FROM LEFT) S30,31 NIBBLE 2 S27,28 NIBBLE 8 S1 LOW32 NIBBLE 1 S31 (5G), S28 (5L) NIBBLE 4 S17 (5A)
Is there any way of being able to HIGHLIGHT this (or further patterns that I identify) in the data stream. This would make it easier to isolate the LOAD bit and any ADDRESS bits that may also be present. The aim is to understand the output of the original microcontroller. Thanks.
@davidjsbriscoe We don’t have a “highlight” feature per-say, but we do have a way to highlight specific data by using a measurement box. You could use timing markers as well for this purpose. More information can be found below:
Hope these features are helpful!