Monitoring I2C traffic

[hwholmes]

I am a glutton for punishment. I understand that the 18M2 and others that have I2C capability are not inherently multimaster capable.

I have a use for many seperate uPs to announce a change in their status to a central computer. I have found a bridge for I2C to RS232 which is an I2C slave only. Thus poling is not an option and I wouldn't want to waste resources for low trafic poling anyway.

My problem is how to monitor the I2C bus for traffic while still performing background tasks of checking the status of inputs.

I am concerned about the resolution needed for watching the bus for start stop conditions and possibly missing a change of state while off checking on the input states and vice versa. Are the signals stable long enough for the basic interpreter to catch them reliably in multi threaded operation?

I am considering a few options but would appreciate any suggestions and critiques.

1 Use one thread of an 18M2 to monitor the bus while another is checking the inputs and formating the data. Then using HI2C functions to comunicate with the computer. My question here is whether one thread could resolve (in bit bang mode??) the traffic generated by another chip using HI2C functions. There is still the off chance of two chips starting at the same time which would need attention not supplied by the HI2C functions.

2. A more implicit resolution might be to (slightly) modify the pullup voltage on the CLK line when you are taking control (using another output to pull down through a 100K?? ohm resistor)and using ADC on another pin to determine that, if the voltage is lower than normal, another chip is in control. This could also detect simultaneous attempts in that 2 chips pulling down together would drop the voltage by two incriments. Of course something like this could be done with a third wire but keeping it to two would be more elegant.

I have seen the post about how to break up If's etc in multi-threading, I am also wondering how commands such as the ADC measurements affect timing and therefor resolution.

Any words of wisdom before I start my adventure?

 

[Dippy]

Just two questions:
All these "many seperate uPs" - are they PICAXEs?
1. Must it be I2C?
2. If so, could you have a single master polling the others?

The rest of it will probably need a time-slicing and/or interrupt approach.

I'm not up to speed on 18M2 but is it possible to make use of the I2C interrupt like you can with PICs?

 

[hippy]

The usual approach to multiple devices which can give unsolicited requests - want to provide data at unknown times - is to use a system of each flagging they have data available the want to be read, this is usually an output signal which gets asserted when such data is available. The master monitors all those signal lines and then begins communicating with each in turn, which de-assert the signals once that's done.

The signal line can actually be part of the communications line if serial but can be separate. The master doesn't have to check all signal lines as this can be handed off to another chip doing arbitration. It depends how things are implemented.

If you want a multi-drop, multi-signalling system I don't believe you can get away with anything less than three signal lines, and if you could it would get unbelievably complicated very quickly.

More information as Dippy suggest will help, some indication of application and what you are hoping to achieve, what data needs to be passed and which way, may help people offer some suggestions on how best to approach that.

@ Dippy : The 18M2 have no i2C interrupt capability. The X2's in I2C Slave mode can generate an interrupt when an I2C write occurs to them.

 

[lbenson]

It isn't i2c, but could this be a use for kranenborg's "SerialPower" true two-wire data+power network: http://www.picaxeforum.co.uk/showthread.php?t=7694

He's put a lot of thought into this, and may have considered and handled circumstances which you would encounter and have to work out yourself.

 

[hwholmes]

Thank you for the support ideas.

To fill in some gaps:

0. first I really like the ease ,general versatility, and priceing of the PicAxe family. I'm sorry that the multi-tasking 18M2 is still on a single core chip with no Hi2c input functions, but that just means I have to deal with the situation at hand.

1. I bought the i2c-rs232 bridge to unload the problem of conflicting interups from PicAxe single core processors. So I guess , at least for now I am committed to i2c (with no more than very minor variations which will not affect the bridge.)

2. My application is model railroad signalling and control. This ap is to read IR position detectors and relay the information back to a central PC running JMRI DCC interface which then will set signals, throw turnout switches, and control robot trains while I operate my train independently.
2.a Timing is a possible problem here. While the traffic is sparse it is necessary for the PC JMRI program to know about a train aproaching a turnout which is thrown against its path soon enough to clear the path by reversing the turnout. This encounters the delays of passing through the PicAxe, Bridge. Computer port buffer, JMRI steering logic, out through the control bus, to the switch control module, all in the time from when the train passes over the IR detector untill it reaches the turnout. At high speeds this may be less than a second. Yes it shouldn't shouldn't be traveling too fast for conditions but "Murphy Always Wins" and the floor is only a half second away.
4b. I think this excludes the time slot/polling approach to the protocol.

3. Murphy also suggests that nomatter how sparse the communications two detectors will ultimately be activated at the same time in different modules resulting in bus control conflicts.

Therefor since PicAxe processors to not impliment multi-master communication implicitly, I see the need to improvise a strategy outside the box, so to speak. This is why I was asking questions about timing/resolution with regard to multi-tasking and ADC measurements.

Is there any information about approximate instruction execution times available short of writing a hundred or so variations of a test program inserting variouswith counters and timers? This would help to understand how multi-tasking, interupts and alternate paths in programs would affect timing and signal resolution.

Sorry to muddy the water, but without knowing execution times I'm having trouble figuring out how to (or if I can) monitor several things at a time (detectors, signal processing, and i2c bus activity) with sufficient resolution to not miss any of them.

This is why I think I will try slight (5%??) modification of the clk pullup voltage as an analog signal to indicat the bus is in use. It won't happen quickly but I will gladly report back if anyone is interested.

 

[graynomad]

Assuming a form of interrupt is in place, how will you determine which "node" did the interrupt? If you have to then poll all of them won't that put you back where you started?

 

[Dippy]

I've never seen an I2C-RS232 bridge, but I'd dump it in favour of RS232-style asynch Serial. I think it's just another thing to get in the way.

If each PICAXE node uses hardware serial then you don't need to miss a byte.
If they all use crystals/resonators this will improve reliability.
You can use several bytes to detect for corruption.
You can use handshaking.
You can use a 3rd wire to indicate 'busy'. (Gnd, signal, busy)
You can use faster bauds with USART.

All this, maybe some extra buffering hardware, and some clever programming should allow you to send and confirm data quite rapidly.

"I'm sorry that the multi-tasking 18M2 is still on a single core chip with no Hi2c input functions, but that just means I have to deal with the situation at hand."
- I'm afraid we all have to do that. Even we poor Pro programmers are 'sorry' that we have to work with what we're given.

Apart from the control which will be done in your PC, the requirements of your system can easily be handled by an X2 PICAXE - or is there more that you haven't told us?


Somewhere on the Forum someone did some speed tests noting that speeds are variable.
There were some 'average' times given as time per command.
I can't remember exact figures but X2s were miles better flat out.

But, in many cases, it's how YOU use the command and how YOU structure your code that can make a huge difference.

 

[kranenborg]

Hello hwholmes

My SerialPower concept as referred to by Ibenson is not particularly fast with a number of 08M's used (which run at a maximum 0f 8 MHz and 4800 baudrate for serial commands), but in the mean time a number of picaxe variants have appeared that run at higher speeds and implement higher baud rates per MHz whilst not being much more expensive. For example the (still very cheap) 18M2 runs at 32 MHz and can run serin/serout commands at 38400 baud, which means an 8-fold increase over the maximum throughput for a 08M-based network. You could try testing with a network of three 18M2 chips (using the simple diode-mixing network implementation using separate communication and power wires, one 18M2 as the network master node and the other two as the application nodes) and test how many meaningful dataframes per second the application nodes can push to each other over the network. Be sure to calibrate their clocks using calibfreq to ensure proper comms at higher clock speeds.

I could imagine that by proper planning the number and functionality of nodes the SerialPower concept might be usable for you (but I also like to see a successful SerialPower application example of course!). It is essentially a multi-drop distributed system using timeslots (generated by the network master node, which is its sole, application-independent function) to avoid message collisions, where a node process pushes a message on the network during its assigned timeslot, whilst all others inspect it (and may act if needed). There is no pre-assigned master process (if there is then you don't need the SerialPower protocol , the master process can then simply use the Serout qualifier to address a certain node/process). You may think of SerialPower as a simplified LIN-Bus protocol implementation.

Regards,
Jurjen

 

[graynomad]

3. Murphy also suggests that nomatter how sparse the communications two detectors will ultimately be activated at the same time in different modules resulting in bus control conflicts.

Very true, and no matter what you test before transmitting there's a large delay between the test and the handshake during which time another node can test and think the line is free. The slower the test process the worse the problem.

As I understand it you're thinking of pulling several resistors into play, one per interrupting node. Ignoring the race conditions you can in theory tell that you aren't the only node with something to say, but then you need a priority system to determine which one backs off.

OR you have to implement some form of collusion detection, say transmit an arbitration byte and detect when your resessive bit has been overidden by a dominant bit. This in turn means a driver with open collector/drain outputs.

To do this detecting you either need to bit bang the data and test at the half-bit point (not an option for the Picaxe I think) or add some external hardware.

You can use several bytes to detect for corruption.

That's another option and a form of collision detection, add a checksum or CRC to the data. Your transmitting nodes will have to receive what they send and compare that with the transmitted data. Can a Picaxe Tx and Rx at the same time? Assuming they can you then need a system to determine when to retry because two (or more) nodes will all be in the same position.

 

[hippy]

Analogue arbitration on a single line can work ( I posted some code to the forum I recall ) and a single multi-drop TX line to master would work.

This is probably the most efficient mechanism to use. Have the master using background receive, each slave grabs the bus ( waits until it gets it ), sends its identifier and the event indicated. That can all run by itself in the background while the receiver just has to churn through id / event pairs, doing whatever it needs to, sending out commands to other 'output slaves'.

 

[kranenborg]

While the traffic is sparse it is necessary for the PC JMRI program to know about a train aproaching a turnout which is thrown against its path soon enough to clear the path by reversing the turnout. This encounters the delays of passing through the PicAxe, Bridge. Computer port buffer, JMRI steering logic, out through the control bus, to the switch control module, all in the time from when the train passes over the IR detector untill it reaches the turnout. At high speeds this may be less than a second. Yes it shouldn't shouldn't be traveling too fast for conditions but "Murphy Always Wins" and the floor is only a half second away.

Does your communication topology need to be so centralized? A local intelligent SerialPower node could take care of the IR sensing and reversing the turnout by itself, then later on inform the JMRI program (and simultaneously other processes/nodes on the network at the same time, because they all are listening)? This as an example on dealing with time-critical actions, using a distributed system to advantage.

/Jurjen

 

[hwholmes]

Last things first: (I even seated the "Z"s in the front of my classrooms when I taught High School Physics)

Jurjen

Does your communication topology need to be so centralized? A local intelligent SerialPower node could take care of the IR sensing and reversing the turnout by itself, then later on inform the JMRI program (and simultaneously other processes/nodes on the network at the same time, because they all are listening)? This as an example on dealing with time-critical actions, using a distributed system to advantage./Jurjen

Thank you for the suggestion, and yes I have considered it, (I even taught customers how to configure and program a Distributed Control System in my last job before retirement) but my turnout controllers are already installed (AC) and I would then likely need to use logic level power FETs to "push" the local buttons which involves more hardware and signal grounding precautions; then the cost per point keeps climbing. However I haven't worked out everything on the JMRI side either so it may still be necessary. If so, I'll probably limit it to those turnouts along the edge of the layout.
By the way, Even though I will need LOCAL power for my sensors (>50 ma/each X number of input port pins used??) I have been studying your SeriaPower system for ideas about what NOT TO FORGET. If I were less real time adicted I would surely give it a try. Very Impressive.

Hippy:

Analogue arbitration on a single line can work ( I posted some code to the forum I recall ) and a single multi-drop TX line to master would work.
This is probably the most efficient mechanism to use. Have the master using background receive,

Thanks, I will look for the code. Analog (sorry I speak "left pond" English) was the only one that made sense to me although I'm not yet sure how resistor tolerances will interact with the ADC resolution. Maybe selective choice of resistors will be needed.
Will calibration be needed?
The bridge is the slave and the JMRI program would be the receiving Master.
How to get JMRI (event driven) to process the data promptly is another problem but not for this forum.

Dippy:

I've never seen an I2C-RS232 bridge, ...
Somewhere on the Forum someone did some speed tests noting that speeds are variable.
There were some 'average' times given as time per command.
I can't remember exact figures but X2s were miles better flat out.

Thank you for catching me on this, old age I guess,
What I found is a SC16IS750 breakout board, from Sparkfun, that interfaces i2c to a UART. I plan to connect that to a USB (not 232 ) to serial Breakout board also from SparkFun.

Breakout Board for SC16IS750 I2C/SPI-to-UART IC sku: BOB-09981
Description: This is a breakout board for the SC16IS750, a handy chip used to convert I2C or SPI serial signals to a single-channel, high-performance UART
http://www.sparkfun.com/products/9981

Breakout Board for FT232RL USB to Serial sku: BOB-00718
Description: Basic breakout board for FTDI's popular USB to UART IC. Now with internal oscillator and EEPROM, the FT232RL is an impressive IC!
http://www.sparkfun.com/products/718

And I'll have a look see for the speed test information to which you refer.

graynomad:

Very true, and no matter what you test before transmitting there's a large delay between the test and the handshake during which time another node can test and think the line is free. The slower the test process the worse the problem.
As I understand it you're thinking of pulling several resistors into play, one per interrupting node. Ignoring the race conditions you can in theory tell that you aren't the only node with something to say, but then you need a priority system to determine which one backs off.

I appreciate the caution on delays but I think it should be minimal compared to waiting for a polled window.
I am considering using the LSBits of a main loop counter or some otherwise Random Value as a branch to a series of entry labels to a chain of successive NoOps to desync compeating masters. However just using the 18M2 in multi task mode may be enough variation due to the variability of the other task.

AnyOne:
With regard to the priority backoff and delays mentioned above, is there any command, traditionally used to achieve a very short time waster (NoOp or DoNothing)?
Will the compiler adversely optomize repeated "NoOps" into one?

Thanks again to all
Bert Holmes

 

[lbenson]

>command, traditionally used to achieve a very short time waster (NoOp or DoNothing)?

I think TOGGLE is one of the quickest commands if you have an output pin which is not connected to anything. I don't think the program editor does the kind of optimizing that a C compiler does, to eliminate commands which have no effect, and in any case TOGGLE does have an effect. You would be looking at about 250 microseconds per command at 4mHz on an 08M.

 

[lbenson]

Regarding delays, you can get millisecond resolution (plus about 250 microseconds) with PAUSE (at 4MmHz), and on M2/X2 parts, 10 microsecond resolution (plus 250 microseconds) with PAUSEuS.