Interprop comms using I2c
Dr_Acula
Posts: 5,484
I've got two propeller chips and have been using fullduplexserial for interprop comms, but I've still not got quite enough pins. I just need 2 more, so I have this idea that maybe I can borrow the I2C bus which has the eeprom chips.
I seem to recall some years ago a discussion about an I2C object that could set a propeller up as a master, and another propeller as a slave. Is this possible?
If I share the I2C bus with some other chips (analog and digital I/O for instance) will the max speed be 100 kbits per second?
Anyone got a favourite I2C object?
I seem to recall some years ago a discussion about an I2C object that could set a propeller up as a master, and another propeller as a slave. Is this possible?
If I share the I2C bus with some other chips (analog and digital I/O for instance) will the max speed be 100 kbits per second?
Anyone got a favourite I2C object?
Comments
I2C's original speed may have been 100kb/s but typical devices support 400k or even 1Mb/s or more.
However I don't think that I2C is the best for P2P comms as I prefer serial half-duplex, which is essentially what I2C is, half-duplex. However with serial it is much easier and you can easily have megabit speeds. One single I/O is all you need and maybe perhaps a series resistor, that's all.
For Prop-Prop, half duplex is a good fit, and if both props are XTAL based, you are not limited to 8 bit UART - it can be almost anything - 32b or even 9+b(Addr)+1b(Dirn)+[32b(data)] - ie quite similar to i2c in payload, but on one wire.
Something like 10b addr allows any Prop memory to be R/W and 512 HUB locations too, all from a small stub.
How few lines of PASM could that serial-server-stub pack into ?
Since you always use DIP props, I have 16 spare prop pins here, left over from my P8X16A. Perhaps you could cut a pair off and glue to the end of your prop
Now to your problem. What else do you have on your prop(s), such that you could share some of those pins?
I would expect I2C between props would be way too slow. But perhaps you could use the SDA pins as a 1-wire between the props???
This is for a dual prop touchscreen design. I have one working just now but it is a bit slow. Distributing the 64 pins in different ways should result in faster speeds. Ok, on the second prop, 16 for a data bus, (0-15) 8 for an address bus, (16-23) 2 for ram rd and wr (30,31) , 4 to talk to to a touchscreen (24-27). That just leaves 28 and 29 which are the I2C bus.
Yes, could use SDA for interprop comms. There are more spare pins on the first prop, so could have 2 dedicated pins on the first prop for an I2C slave in software.
I'll think about it some more. Data speed - need to send the data for a screen in a reasonable time, maybe 2 seconds, and it is 320x240x2 bytes = 153600, ok say 2 secs so 76,000 bytes a second, baud rate of 10x this, 760,000 bits per second. Well within the range of some of the objects out there. Both props have xtals.
I presume there may be a /CE on the touchscreen. If so, then you can connect that to a prop pin (could be from the second prop as you just need to keep it disabled while reading from the eeprom. Now you can share RD & WR with SDA & SCL.
BTW Why do you require 4 pins for the touch section? Presume it is /CS + SPI DI/DO/CLK. These could also be shared in some arrangement.
a Prop + SRAM,
or
a CPLD + SRAM
to emulate the HyperRAM
HyperRAM is like 2 x QUAD-SPI, and loads address in the first few clocks, then streams Rd or Wr data.
The CPLD codes some simple Load-inc-hold counters, and frees all address pins from main Props.
4 x QuadSPI RAM, (can come in TSSOP8, Microchip, OnSemi ) which even gives the luxury of some binary alignment for
512*256*4 = 524288 so two display pages can fit into 4 x 1Mbit parts
or addr as 256*256*8, but clock out in nibbles.
To address, all 4 nibbles have to be the same, which can be done quickly with an adder value of 1111H, 2222H etc
For a scan line on 256 boundary, lower 8 bits load as 00, and then 8b more of address cover the scan lines.
2 Prop registers store H.H.H.H and L.L.L.L Nibble-quads, and those simply move to the SPI pins during Adr-set.
A couple of dozen clocks should set the address, then streaming can be HW paced up to 20MHz or Display limit.
Assuming 10MHz, and ~30 clks for addr, a full screen copy-over is 13.5ms, or 25ms gives roughly 50% BUS time on refresh.
4 x QuadSPI can also morph to 2 x HyperRAM when they become available, with minor changes.
Address changes to repeat across bytes, as HyperRam are byte-wide, but that just changes the wide-adder value.
DDR clocking is another slight change,