Multiple i2c ports on the 1 picaxe possible???

OLDmarty

Senior Member
Hi all,

As the title suggests: is there a (sneaky) way to achieve more than 1 i2c "port" on the 1 picaxe chip (i mostly use 40X2).

I know there's a 3rd party i2c multiplexer device out there, to re-assign identical addresses to different outputs on the chip etc, but i'm trying NOT to add more hardware if possible.

I realise i can probably cheat by using the SPI port to control devices similar to my i2c devices.

Thanks in advance.
 

steliosm

Senior Member
Why do you need multiple i2c ports?
You can put multiple i2c devices on the same bus as long as they have a different i2c address.
 

OLDmarty

Senior Member
Why do you need multiple i2c ports?
You can put multiple i2c devices on the same bus as long as they have a different i2c address.
Yes, you can put upto 8 devices on one port, i have more than 8 devices, hence this whole posting in the first place.
 

hippy

Technical Support
Staff member
Why do you need multiple i2c ports?
Every I2C port should be run at the speed of the slowest connected I2C device.

If one has slow and fast devices it can be beneficial to have separate I2C ports for each.

For most PICAXE projects, running the faster devices at the slower speed won't usually be a problem.
 

westaust55

Moderator
Yes, you can put upto 8 devices on one port, i have more than 8 devices, hence this whole posting in the first place.
Is this a case that you have 8 identical i2c devices and those are limited to 8 possible addresses?

You can connect more than 8 devices if they are of different types.
I have a box with 7 EEPROM, 1 FRAM, 1 RTC, 1 SPE030 and 2 or 3 off IO expanders without problems.
 

OLDmarty

Senior Member
Is this a case that you have 8 identical i2c devices and those are limited to 8 possible addresses?
Yes, i have 8 identical devices, each with with their own address from 0 to 7 (actually 70h to 77h).
I actually need an additional 8 of these same devices, so i think i'm looking at 2 i2c ports, or at least a spare picaxe 'bit' to control an external gate to enable/disable each of 2 pseudo i2c ports....


You can connect more than 8 devices if they are of different types.
I have a box with 7 EEPROM, 1 FRAM, 1 RTC, 1 SPE030 and 2 or 3 off IO expanders without problems.
Oh, i get it now, because they all have different inbuilt addresses, so that makes sense.
Sadly that scenario doesn't help me as i intend to use upto 16 identical device types, but what you described above certainly is clever....
(i have to stop looking at i2c devices as only having a 2 or 3 bit address) ;-)
 

AllyCat

Senior Member
Hi,

I don't use X2 chips myself, but there could be at least three avenues to explore: The 40X2 "base PIC" chip has two I2C ports and you should be able to access the second by using POKESFR commands. However these I2C pins are also allocated to the SPI hardware so you may need to (also) adopt the second possibility, i.e. software emulation of the SPI or I2C hardware on other available pins. The SPI software is probably easier to write or use, and the I2C implementation can run up to 400 times slower than the dedicated hardware.

Thirdly, you could use more than one PICaxe chip. Even an 08M2 has fully functional I2C (host) hardware, so you could add one or more (or a larger M2) to a 20/28X2, depending on your total pin requirements.

Cheers, Alan.
 

hippy

Technical Support
Staff member
Yes, i have 8 identical devices, each with with their own address from 0 to 7 (actually 70h to 77h).
I actually need an additional 8 of these same devices
16 devices on a single I2C bus where each device is the same and has A2,A1,A0 addressing.

This does need an additional 4 output lines and only works if the devices don't latch their addresses at power-up. Though one could cycle their power if they do.
-
Code:
A >--.-----.-----.-----.
B >--|-----|-----|-----|------.-----.-----.-----.
     |     |     |     |      |     |     |     |
     |     |     |     |      |     |     |     |
    .---. .---. .---. .---.  .---. .---. .---. .---.  
    |x00| |x01| |x10| |x11|  |x00| |x01| |x10| |x11|
    `---' `---' `---' `---'  `---' `---' `---' `---'
      a     b     c     d      e     f     g     h

C >--.-----.-----.-----.
D >--|-----|-----|-----|------.-----.-----.-----.
     |     |     |     |      |     |     |     |
    .---. .---. .---. .---.  .---. .---. .---. .---.  
    |x00| |x01| |x10| |x11|  |x00| |x01| |x10| |x11|
    `---' `---' `---' `---'  `---' `---' `---' `---'
      i     j     k     l      m     n     o     p
A=0 B=1 C=1 D=1 Address %000 = a
A=0 B=1 C=1 D=1 Address %001 = b
A=0 B=1 C=1 D=1 Address %010 = c
A=0 B=1 C=1 D=1 Address %011 = d

A=1 B=0 C=1 D=1 Address %000 = e
A=1 B=0 C=1 D=1 Address %001 = f
A=1 B=0 C=1 D=1 Address %010 = g
A=1 B=0 C=1 D=1 Address %011 = h

A=1 B=1 C=0 D=1 Address %000 = i
A=1 B=1 C=0 D=1 Address %001 = j
A=1 B=1 C=0 D=1 Address %010 = k
A=1 B=1 C=0 D=1 Address %011 = l

A=1 B=1 C=1 D=0 Address %000 = m
A=1 B=1 C=1 D=0 Address %001 = n
A=1 B=1 C=1 D=0 Address %010 = o
A=1 B=1 C=1 D=0 Address %011 = p
 
Last edited:

OLDmarty

Senior Member
This would solve your problem with minimal effort:
(you could just get it in a PDIP if you don’t wanna’ use the breakout)
TCA9548A I2C Multiplexer PRODUCT ID: 2717 $6.95 https://www.adafruit.com/product/2717
I looked into that device a few days ago, but it gets very complex because my slave devices are the same address range as the device, and they suggest shorting address pins of the mutliplexer device to avoid addressing conflicts, i dunno, it seems rather messy.
In fact, it seems this multiplexer works perfectly on any slave device that is NOT in the x70 to x77 address range. (all my devices are x70 to x77).

However, The concept of that chip then lead me to find an alternate way to split one i2xc port into 2 pseudo i2c ports....
I'm certain this just needs to be an external TTL gate (or analog switch chip) being controlled byu 1 bit of the pickxe to steer the i2c data out of pseudu port 1 or port 2.
 

OLDmarty

Senior Member
16 devices on a single I2C bus where each device is the same and has A2,A1,A0 addressing.

This does need an additional 4 output lines and only works if the devices don't latch their addresses at power-up. Though one could cycle their power if they do.
Hi Hippy,
The devices i'm using do constantly re-check the address pins (A2,A1,A0) during each data frame, so they should work with your concept.

I'm assuming your 'x' bit is maybe the MSB of the i2C address pins on the devices? i guess it doesn't really matter which bit, as long as each bank of devices is 'crippled' by one of the control bits A,B,C or D.

I think this might be a challenge on the Holtek 16K33 devices, as they don't have dedicated address pins like most other i2C devices.
The address pins are shared with some of the LED row pins. The pins are connected via resistors and a diode and is checked at each data frame (according to the data sheet).
I know this complicates the way your A,B,C,D pins will interface to these devices, I'd probably have to insert an extra switch/gate inline with the address pins, and use A,B,C,D pins to enable/disable the gate accordingly.

Thinking about this more, the 16K33 address pins assume a '0' when left floating/open, so the new addressing (A,B,C,D) pins probably won't let this concept to work.

Thanks again for your wonderful ascii art too ;-)
 
Last edited:

AllyCat

Senior Member
Hi,

I think what Hippy is proposing needs three extra pins. A0 and A1 are wired "normally" to all 16 chips. but the A2s are driven by one of four active low pins (A, B, C and D) "decoded" inside the PICaxe (instead of A2). Thus the software would select a group of 4 chips by driving either A, B, C or D low and then write to one chip in the group at either I2C address 70, 71, 72 or 73 (7-bit addresses).

Cheers, Alan.
 

OLDmarty

Senior Member
Hi,

I think what Hippy is proposing needs three extra pins. A0 and A1 are wired "normally" to all 16 chips. but the A2s are driven by one of four active low pins (A, B, C and D) "decoded" inside the PICaxe (instead of A2). Thus the software would select a group of 4 chips by driving either A, B, C or D low and then write to one chip in the group at either I2C address 70, 71, 72 or 73 (7-bit addresses).

Cheers, Alan.
Hi Alan,

How do you calculate only 3 pins being added, when adding 4 pins (A,B,C,D) makes perfect sense for the 4 banks of devices? (curious)

In my post #13, i don't think these A,B,C,D pins are going to interface well with the 16k33 devices because of the shared address pins and the way an address is 'wired' - it's not a simple matter of making some bits tied to +5v or 0v, the address bits are scanned through a diode/resistor method.

So close.......
 

hippy

Technical Support
Staff member
I'm assuming your 'x' bit is maybe the MSB of the i2C address pins on the devices? i guess it doesn't really matter which bit, as long as each bank of devices is 'crippled' by one of the control bits A,B,C or D.
That is correct, assuming A2 is set by the PICAXE, only one bank will be set to 000,001,010,011 while the other three will be set to 100,101,110,111.

So long as only 000,001,010 ,011 are accessed you can control one of the banks, the other three will just ignore access to 0xx being on 1xx.

I think this might be a challenge on the Holtek 16K33 devices, as they don't have dedicated address pins like most other i2C devices.
It seems you are right, that won't work with the HT16K33 without additional hardware gating the PICAXE generated A,B,C,D to their A2 pins .

I'm certain this just needs to be an external TTL gate (or analog switch chip) being controlled byu 1 bit of the pickxe to steer the i2c data out of pseudu port 1 or port 2.
That should work; SDA to all chips, with SCL then gated to two signals, one to each bank of eight.

Another alternative is to bit-bang the I2C with one SDA and two SCL lines.
 

OLDmarty

Senior Member
16 devices on a single I2C bus where each device is the same and has A2,A1,A0 addressing.

This does need an additional 4 output lines and only works if the devices don't latch their addresses at power-up. Though one could cycle their power if they do.
-
Code:
A >--.-----.-----.-----.
B >--|-----|-----|-----|------.-----.-----.-----.
     |     |     |     |      |     |     |     |
     |     |     |     |      |     |     |     |
    .---. .---. .---. .---.  .---. .---. .---. .---.
    |x00| |x01| |x10| |x11|  |x00| |x01| |x10| |x11|
    `---' `---' `---' `---'  `---' `---' `---' `---'
      a     b     c     d      e     f     g     h

C >--.-----.-----.-----.
D >--|-----|-----|-----|------.-----.-----.-----.
     |     |     |     |      |     |     |     |
    .---. .---. .---. .---.  .---. .---. .---. .---.
    |x00| |x01| |x10| |x11|  |x00| |x01| |x10| |x11|
    `---' `---' `---' `---'  `---' `---' `---' `---'
      i     j     k     l      m     n     o     p

Hi Hippy,

I had to change things, so that a '1' will enable each bank of 4 devices. This is because a '0' can't be disabled with a gate, if the 16K33 pin is open or Hi-Z, it always equals a '0', so i had way to disable a '0' from a '0' lol. (i didn't want to add inverters and complicate code further).
By using a '1' to select the banks, i can now disable each bank easily with a '0' to control the Hi-Z buffer gate.
This means i'm adressing the upper 4 i2c addresses of these devices at $74, $75, $76 & $77.

Interesting to note that the 16K33's actually retain their last updated information, even when not addressed and even after a power cycle etc.
It's made me add further code to ensure 'blanking' the appropriate devices when needed, but that's all part of the usual housekeeping ;-)

I have used 2x 74HC244 Octal buffers with Hi-Z outputs.
Luckily enough, these chips are internally grouped as 2 groups of 4 buffers, so it works perfectly with your above ascii map of dealing with 4 i2c devices in a bank.

Attached is my drawing of the system i'll be using for 16x Holtek 16K33 LED driver devices.

I hope my info & drawing can help others to be sneaky with i2c devices.

THANKS again to Hippy for reminding me of "bank switching" once again ;-)

Marty i2C multiple 16k33 devices.png
 
Last edited:

hippy

Technical Support
Staff member
Excellent job and good to know it works. It's rather convenient that the octal 74HC244 is configured as a pair of 4-bit buffers.
 

OLDmarty

Senior Member
Excellent job and good to know it works. It's rather convenient that the octal 74HC244 is configured as a pair of 4-bit buffers.
I'm sure you planned it that way ;-)

I did start out by using 4016 quad cmos switches (which worked too), but there's only 4 switches per chip, so it results in 4 chips required instead of only 2 of the 74HC244 buffers....lucky me ;-)
 

AllyCat

Senior Member
Hi,
..... i'm trying NOT to add more hardware if possible.
Hmm, two 20-pin chips (and 4 PICaxe pins) seems quite a lot to add compared with the original concept of a second I2C bus (two PICaxe pins), or other possibilities such as an 08M2 (for the second bus) or a single 16-pin 74HC4053 triple two-way "analogue" switch (admittedlly now less easily obtained than the similar 4016/4066) which needs 1 PICaxe pin (i.e. the 3 pin differential I mentioned in #16)

Certainly a bit-banged second bus would be much slower (or POKESFRing the second internal hardware bus somewhat slower), but I don't believe you've specified if (or to what extent) speed is an issue. Something like a time/date display might easily use a "slow" bus for some of the digits, whilst I doubt if PICaxe Basic itself is fast enough for (say) a scrolling 16-cell text display.

Cheers, Alan.
 

hippy

Technical Support
Staff member
I doubt if PICaxe Basic itself is fast enough for (say) a scrolling 16-cell text display.
It might be possible with a fast enough PICAXE. I reckon it's about 2600 bits which needs to be put on the bus to completely refresh everything.

That's about 400us per bit to refresh it all in one second though one would likely want faster than that.
 

OLDmarty

Senior Member
Hi,

Hmm, two 20-pin chips (and 4 PICaxe pins) seems quite a lot to add compared with the original concept of a second I2C bus (two PICaxe pins), or other possibilities such as an 08M2 (for the second bus) or a single 16-pin 74HC4053 triple two-way "analogue" switch (admittedlly now less easily obtained than the similar 4016/4066) which needs 1 PICaxe pin (i.e. the 3 pin differential I mentioned in #16)

Certainly a bit-banged second bus would be much slower (or POKESFRing the second internal hardware bus somewhat slower), but I don't believe you've specified if (or to what extent) speed is an issue. Something like a time/date display might easily use a "slow" bus for some of the digits, whilst I doubt if PICaxe Basic itself is fast enough for (say) a scrolling 16-cell text display.

Cheers, Alan.
Hi Alan,

Yes, i agree, this project has slipped off the rails from my original question about using 2x i2c buses, but there's many ways to skin this cat.
I went with the 2x buffer chips as i had them handy and it was quick to implement for some immediate testing.

Yes, i would still like to potentially use just a simple 08M as a 2nd i2c port, but my inter-picaxe skills are lacking.
I need to get off my bum and master using Hserout/in between 2 picaxes to make this happen properly.
(i'll do some searching for inter-picaxe techniques shortly).

As for overall speed required, this intended display project is mostly very static with only some slow animation of maybe 100's of mSecs at best.

with thanks.
 

AllyCat

Senior Member
Hi,

I don't know about the 08M, but trying to use HSERIN with I2C on an 08M2 opens quite a can of worms, not the least that HSERIN and SDA share the same pin. I believe I have "solved" all the issues now and hope to post a full application in due course; but this link might be of interest, not so much for the "issues" but that Technical posted a simple software I2C solution in post #2.

Personally, I think a solution using (just) two pins on a single PICaxe should be quite possible, using either software or the internal hardware to drive the second I2C bus. Alternatively, a single HC4066 could be driven by two (complementary) pins to switch a single I2C bus to two destinations (banks of 8 chips). With a "trick", it might even be possible to use just 4 bipolar transistors and resistors to switch the bus. ;)

Cheers, Alan.
 
Top