i2c read times

Morning folks,

A (hopefully) straightforward question regarding i2c - if I have a picaxe i2c system where the master and all slaves are picaxe chips, what's the approximate time taken for the master to read one byte of data from a slave?

I'm planning on having multiple input devices connected to the various slaves, with the master simply polling a "status" byte on each slave to check for updates.

Also, if I were to increase the clock speed on all chips by the same value (eg. every device running at 64MHz), would that allow the i2c bus to also run at that speed, or is that tied directly to the internal resonator?

Cheers guys!
 

hippy

Technical Support
Staff member
The I2C bus speed is independent of the PICAXE operating speed which will either be I2CFAST (400kHz) or I2CSLOW (100kHz) with appropriate '_<MHz>' suffices added if non-default speeds.

At 100kHz each I2C bit transaction would be 10us. Looking at the I2C timing diagrams in the HI2CIN section of PICAXE Manual 2, though not high resolution, looks to be 0.5ms per byte read over I2C, which would match that. At 400kHz it should drop to a quarter of that.
 

Buzby

Senior Member
Hi Danners,

I2C is designed for short distance comms between chips, up to 30cm if I remember.

Are you planning for slaves many metres apart ?.

If so, I2C is not your best choice for comms.

( I know people have got I2C running over longer distances than the spec says, but it needs a bit of tweaking to make it reliable. )

Cheers,

Buzby
 
Hi Danners,

I2C is designed for short distance comms between chips, up to 30cm if I remember.

Are you planning for slaves many metres apart ?.

If so, I2C is not your best choice for comms.

( I know people have got I2C running over longer distances than the spec says, but it needs a bit of tweaking to make it reliable. )

Cheers,

Buzby
Uh oh...

My plan is to have many slaves scattered around a model railway, which could be up to metres away from the master... any ideas for alternatives? My problem is that I need the chips to be running while the data is read or written in the background...
 

hippy

Technical Support
Staff member
I have always imagined model railways to be a rather adverse electrical environments for high speed communications. That doesn't mean it can't be done but it may need care taking to have something reliable.

The starting point, before deciding how to do it, is to determine what needs to be done, what the slaves control and monitor, what data they receive or send, and how often.

I2C comms with a PICAXE isn't always as easy as it might seem be imagined to be because one cannot always rely on reading data when one desires. If the PICAXE is tied up doing something else then one may not get the data back.

I personally favour some sort of multi-drop or ring serial network, probably with separate networks for sending and receiving data. What's actually best will however depend on what needs to be done.
 

Buzby

Senior Member
My plan is to have many slaves scattered around a model railway, which could be up to metres away from the master... any ideas for alternatives? My problem is that I need the chips to be running while the data is read or written in the background...
That sounds like a 'noisy' environment, I'd definatley steer clear of basic I2C !.

However, the 'transparent' read/write of I2C is very attractive, so using a 4-wire I2C bus would be a suitable option.
See https://www.nxp.com/docs/en/application-note/AN10658.pdf for how to do it. ( See Chapter 4 )

( The X2 chips also support background receive with HSERIN, so thats another alternative, but it will need more code to execute a protocol. )

Cheers,

Buzby
 
I took a look at that, Buzby, but that does look suspiciously like you'd need a separate processor to convert the signals for the 4 wire system... I'm after simplicity, so I might avoid that :)

Hippy, I've already considered a serial-loop system, but the downside of that system is the delay it can introduce into the system if the chips are working when the data is received...
I suppose my next question would be is there another communication protocol where the master chip can read or write to/from a specific scratchpad address, in the same way i2c can?
 

Buzby

Senior Member
I took a look at that, Buzby, but that does look suspiciously like you'd need a separate processor to convert the signals for the 4 wire system...
It's not a seperate processor, it's a 'level shifter / line driver' type of chip, just like you would need with either RS485 or RS232 in a noisy environment.

The crux of the problem is that the IO pins of a 'normal' chip are not designed to drive long distances.

The 4-wire I2C still seems to be the best option, as it keeps the 'transparency' you need.

This document give a better range of examples : http://www.ti.com/lit/ds/symlink/p82b96.pdf

Cheers,

Buzby

EDIT : The ribbon cable example needs more control over the I2C pulses than a PICAXE can do.

Another EDIT : This module datasheet shows how the I2C signal is degraded over a long line, and how a bi-directional buffer cures the problem - http://sandboxelectronics.com/?p=1098
 
Last edited:

fernando_g

Senior Member
Reliable serial communications over long wire runs and/or noisy environments, is a problem that has been studied by engineers exhaustively.
All lead to the same conclusion: twisted pairs driven by suitable buffer ICs.

Therefore twisted pair cable is widely available and employed universally, regardless of protocol. Many times one finds salvaged CAT5 cable which is perfectly fine, but was discarded because the segment length was shorter than the original requirement.

So I'll join the chorus and advise the 4-wire system.
 

westaust55

Moderator
I have some PICAXE chips in use under my DCC controller model railway.
For some PICAXE based accessory decoders for lighting control (buildings, platforms, street) I have two PICAXE chips per decoder (only about 2 cm apart) interconnected using i2c.
When the first has collected around 64 bytes of data it sends a signal to the second PICAXE. That is &#8220;received&#8221; as an interrupt causing the second chip to background read the data from the first using i2c comms.
The first chip is a 20X2 running at 64 MHz as a Slave and the second an over clocked 28X2 running at 80MHz as the Master.
For the i2c I have defined my own speed and based on the PIC datasheet it is runnng at about 1,000 kHz.
As noted, very short distances involved For the i2c bus. I needed to run the i2c bus at the max possible speed so the 28X2 could read the data, decode and act and still be ready to fetch the next block of bytes via i2c.
There are adjacent boards With 08M2 parts controlling SG90 servos for rotating cranes over platforms and coaling stages.

What I have observed just recently (over the current Christmas-New Year period) is that the PICAXE on a module which receives control data from another module via RS232 comms and screened cable (1.5m total length) is getting some interference seen as lights momentarily coming on very occasionally.

My layout has an NCE DCC controller and I have an RS485 CAB bus of around 8 meters in length with multiple sockets for connection of CABs. One of those CABs is a PICAXE based devices for controlling points, signals and other accessories. Absolutely no problems with the RS 485 comms.

If you are interested, Both of these projects are posted in the finished projects area should you care to search and read.
 
I may or may not have knocked off at work, got home and promptly fallen into bed...

I'll do some more research into the 4 wire system then :) hopefully the encoder/decoder IC isn't too big and can fit onto an (already packed) 100x100mm PCB... Otherwise I might be forking out a bit more for the PCBs &#55357;&#56834;&#55357;&#56834;

Cheers though guys!
 

Buzby

Senior Member
... hopefully the encoder/decoder IC isn't too big and can fit onto an (already packed) 100x100mm PCB ...
It's an 8 pin DIP, and if you've not got room for that on a 100sqcm PCB then it must be a *very* packed PCB :)

Post a screenshot of the layout, I like optimising PCBs.

Cheers,

Buzby
 

darb1972

Senior Member
Is the PCB double sided? I would suggest and smd version on the bottom layer. Otherwise what about a very small riser board? Like Buzby, I'll bet there's a way of squeezing it in. I also love working on PCB layout (although it's bordering on the edge of madness at times!).

Better still, go 4 layer. Signal layer, Power layer, Ground layer and then another Signal layer. According to the Pros, that's the best possible layout of most PCBs as the two signal layers are separated by power and ground. Maximum shielding between signal layers and very close decoupling of rails. Probably a bugger to design though.
 
I haven't started designing any PCBs yet - I'm finalizing the specification first before throwing myself at designing the various types.

I actually need various designs:
MASTER which has 2 PICAXE chips, one for inputs and one for output devices, communicating through a MAX232 with a computer running JMRI;
POINT CONTROL which uses MOSFETs to switch the solenoid point motors;
BASIC LED OUTPUT which uses one LED output per GPIO on the PICAXE (optionally through a transistor for multiple LEDs in series) which is also used for signals;
MULTIPLEXED LED CONTROL for control panel lighting;
SERVO CONTROL for semaphore signalling and moving parts.

I'm hoping to save a bit of money and get the boards from Dirty PCBs, and if I want the best deal they'll be 2-sided, and a maximum of 100x100mm in size. I've standardized so far by using the maximum size, with M5 earthed bolt holes at identical positions at each side.

Once I start designing them though, I'll happily post the files here for you to take a look at :) I'm definitely still a novice!!
 
Just to confirm, having read through the data sheets and user manuals etc. Am I right in saying all I need then is either:

One dual, bidirectional bus buffer per PCB, with a CAT5 or similar cable going to each one, from a hub with its own bidirectional bus buffer for each cable,

Or two bidirectional bus buffers per board, with the cables forming a ring?
 

techElder

Well-known member
In another life while playing repairman, I hated boards of more than two layers! Always made repairs more complicated. In those days you couldn't be sure what net was on those inner layers and sometimes the designers caused layer shorts with less than optimal space around vias.
 
In another life while playing repairman, I hated boards of more than two layers! Always made repairs more complicated. In those days you couldn't be sure what net was on those inner layers and sometimes the designers caused layer shorts with less than optimal space around vias.
I've never actually ever tried to design boards with more than two layers... And when it comes to vias, I simply use the default setting in KiCAD, unless it's the point motor 0V return, which is high current - in which case I simply steer clear of all other tracks...
 

darb1972

Senior Member
In another life while playing repairman, I hated boards of more than two layers! Always made repairs more complicated. In those days you couldn't be sure what net was on those inner layers and sometimes the designers caused layer shorts with less than optimal space around vias.
Very true Tex. I only suggested extra layers for density. Many engineers seem to think that a 4 layer design is the holy grale of pcb design. As you rightly point out, not when it comes to tracing faults. I recently had a 4 layered pcb with a burnt section of track and a short on the logic rail. I'm still not sure where the fault was (couldn't isolate it, all smd) and it may well have been an "internal" track fault.
 
Sorry to bump this topic again,

Reading through NXP AN10658 and the datasheet for the NXP PCA9600 IC, I'm seeing that you can't use more than one on the "low" side of the circuit. Does that mean that each board needs one IC, these being connected with each other by a "web" of CAT5 cables? eg. a bus line around the layout, with PCBs designed to terminate multiple CAT5 cables together using straight tracks and no additional circuitry?

If that were the case, then I'd implement it with that in mind, with each circuit board having provision for 8-pin headers to connect to the "low" side without the need for another cable.
 

hippy

Technical Support
Staff member
I am not quite sure what you mean by "the "low" side of the circuit".

I am not familiar with the PCA9600 but looking at the datasheet it's a transparent buffer which would be placed on the master board, with one on each remote slave board.

The datasheet shows a multi-drop implementation but it might work in a star configuration as well.

Code:
Master PICAXE  PCA 9600              PCA 9600  Slave PICAXE
.-----------.  .------.              .------.  .----------.
|        SDA|--|SX  TX|--.--.-----.--|TX  SX|--|SDA       |
|           |  |    RX|--'  |     `--|RX    |  |          |
|        SCL|--|SY  TY|--.--|--.--.--|TY  SY|--|SCL       |
|           |  |    RY|--'  |  |  `--|RY    |  |          |
`-----------'  `------'     |  |     `------'  `----------'
                            :  :
                            |  |     PCA 9600  Slave PICAXE
                            |  |     .------.  .----------.
                            }--|--.--|TX  SX|--|SDA       |
                            |  |  `--|RX    |  |          |
                            |  }--.--|TY  SY|--|SCL       |
                            |  |  `--|RY    |  |          |
                                     `------'  `----------'
 
Last edited:
Sorry Hippy,

by "low" I simply meant the un-buffered side of the buffer IC, ie. the PICAXE side :) It's a Monday morning, and I'm definitely not 100% awake... (am I ever...?)

Taking a closer look at the diagram you mention, that's exactly what I'd be doing - a PCB into which you plug the "bus" CAT5 cable (in essence "cutting" into the cable", with lines coming off to "branch" cables which then go to the individual circuit boards, each of which have their own buffer chip.

I'll post the circuit board designs here in the near future, but in essence I'll basically use inter-board headers to save on CAT5 cables where possible, and simply leave them unpopulated if I don't need them.

Thanks for the help and advice though - I had no idea about the distance limitations of I2C before posting here!
 
Code:
Master PICAXE  PCA 9600              PCA 9600  Slave PICAXE
.-----------.  .------.              .------.  .----------.
|        SDA|--|SX  TX|--.--.-----.--|TX  SX|--|SDA       |
|           |  |    RX|--'  |     `--|RX    |  |          |
|        SCL|--|SY  TY|--.--|--.--.--|TY  SY|--|SCL       |
|           |  |    RY|--'  |  |  `--|RY    |  |          |
`-----------'  `------'     |  |     `------'  `----------'
                            :  :
                            |  |     PCA 9600  Slave PICAXE
                            |  |     .------.  .----------.
                            }--|--.--|TX  SX|--|SDA       |
                            |  |  `--|RX    |  |          |
                            |  }--.--|TY  SY|--|SCL       |
                            |  |  `--|RY    |  |          |
                                     `------'  `----------'
I'm not gonna ask how long that took... :)

But aye, that's exactly how I'd implement it. I'll just make it neat and tidy by using PCBs as breakout boards, and use the spare poles in the CAT5 cable to transmit the 5V & 0V power lines, and any different supplies I need to implement (certain pre-built model railway components need 12V, and don't have any provision for conversion to 5V...)
 

hippy

Technical Support
Staff member
I'm not gonna ask how long that took... :)
After many years of practice; just a minute or so :)

The trick is to get one important line right, then the rest is cut and paste, replace the bits not wanted with spaces, fill in what's missing.
 
Fair enough!

I'm just a couple of years too young to remember ASCII art properly :)

One quick question, when I design my PCBs, is there a specific forum room for that, or should I just post them here?
 

Buzby

Senior Member
This screenshot from the datasheet in post#9 shows how to wire a bus.

I2C_multidrop.PNG

The product shown also includes a power distribution bus, that's why the boards come in boost and buck versions, but you don't need that.

I2C with the NXP chip ( or the TI chip, or many other similar chips ) is the best option, as it keeps the 'transparency' of background writes, which makes any handshake protocol a lot easier to write.

Cheers,

Buzby
 
That looks simple enough :) so the boards would simply be replaced with the chips in the correct orientation, and ideally a 15V power supply?
 

hippy

Technical Support
Staff member
This screenshot from the datasheet in post#9 shows how to wire a bus.
That wasn't in the datasheet I looked at, clarifies things which weren't entirely obvious in the datasheet I found online. The moral, as always, is to look at all the datasheets and examples one can find.
 

Buzby

Senior Member
... The moral, as always, is to look at all the datasheets and examples one can find.
I must admit I find the NXP datasheets, ( for all their devices ), a bit daunting. That's why I tend to search for an equivalent from a different supplier.

( I'm so old I can still remember when the Maplin catalogue had datasheets and example circuits, now it's just drones and fitbits. :( )

Cheers,

Buzby
 
I gave up on Maplin when I discovered they charge (literally) 15x more than most places for simple things like resistors...
 

Buzby

Senior Member
I gave up on Maplin when I discovered they charge (literally) 15x more than most places for simple things like resistors...
The problem now is that 'most places' are on the Internet only, and if you are short of a bit that you need today there is nowhere else to go.

Maplin, and Tandy ( long gone now ) used to be good places to shop for real electronics. If only China could do 2 hour deliveries !

Cheers,

Buzby
 

Mark.R

Member
Danners, Did you ever get any further with this as I'd had similar thought for my brothers model railway, if he ever gets round to building it that is.

On the Maplin front, it doesn't look like its going to be with us much longer anyway!
 
Hey Mark,

I'm still on the research front at the moment; I'm definitely looking at using bus extenders for the i2c comms, however I'm starting to move towards using vanilla Microchip PICs to handle the control, and use PICAXE chips for the peripherals, ie signals and points.

My system has matured to the point where I could design a Functional Block Diagram, but I'm at home, in bed with the shipyard shut down... A description will do :)

3 main systems: user interface, interlocking and physical devices.

UI: can be any type of control panel, EnEx, IECC VDUs, trad model railway panel etc. As long as it can communicate with the interlocking using either serial or i2c with a standard set of commands (yet to be decided). These commands are ONLY route setting request, single item (individual point etc.) Request, or status request (read current status of points etc. From the EEPROM).

The interlocking will likely be a Microchip 32-but MCU, which contains the interlocking for the entire layout. It receives requests for routes to be set from the UI, and if valid will send the commands to set them. Upon the train clearing the block section (yes, I'm using full track circuiting), the route will gradually be cleared and the signals returned.

The peripheral control will consist of both PICAXE and Microchip MCUs. All purely output devices, such as points or signals, will be controlled by PICAXE chips running in i2c slave mode. However, any sensors and track circuits will be Microchip MCUs to use their i2c Multi-master functionality. This allows them to send rapid updates to the interlocking / status EEPROM.

Hopefully this helps :)
 
Top