question re i2c theory and operation

craigcurtin

Senior Member
Guys,

I have a picaxe 40x2 and an Arduino Mega operating together over i2c. I am migrating this particular project from my 40x2 to the Arduino platform.

Doing this in a staged approach - i made the Arduino the master of the i2c bus and the picaxe slave.

I have "passed" control of the DS1307 RTC from the picaxe to the Arduino, which now extracts and formats the time and passes it back through two variables in the scratchpad to the picaxe - all works as expected.

I am also passing some other scratchpad values back to the Arduino - these are being updated by the Picaxe based on sensor values it is reading.

Now my question(s)

I have a subroutine i call to get the time and this is where i define the i2cslave statements (as per below)

Code:
ReadTimeFromRTC:
{

 
 hi2csetup i2cslave, 160 '80 on arduino because of the 7bit -v- 8bit


hi2cflag = 0 ' reset flag
get 0,Hours,Mins ' get last 2 bytes written - Hours and Minutes


Debug
 
 
	'i2cslave %11010000, i2cslow, i2cbyte
	'readi2c 0,(workvariable1,mins,hours)


 'Convert to Decimal from BCD
	'let workvariable1 = mins & %11110000 / 16 * 10
	'let mins = mins & %00001111 + workvariable1
	'let workvariable1 = hours & %11110000 / 16 * 10
	'let hours = hours & %00001111 + workvariable1

Return
}
Does the hi2csetup survive the subroutine ending ? Or does the Picaxe slave "disappear" once this subroutine finishes ?

The reason that i ask is that when on the Arduino and reading the scratchpad that the Picaxe has updated - it appears every now and then i get a negative result i.e. the values returned are -1 (they are temperatures in C in Sydney so this an incorrect result)

Not sure if this is because in fact the Arduino can not get to the scratchpad sometimes or some other problem.

Also do i have to CLEAR the hi2cflag each time or is that just a convenience so i can poll the flag for any updates to the scratchpad (as these are times i just do this is a subroutine that is called each time through my main routine so accuracy to within 1 minute or so is fine.)

thanks

Craig
 

oracacle

Senior Member
i2c setup only needs to be done once (providing you are only using 1 slave - this shouldn't effect you as it is the slave)

however you have a debug, this interfears with the i2c bus on picaxe (i know i have been there), using the terminal and the srtxd command. if the results persistes then further investigation can be carried out
 

craigcurtin

Senior Member
i2c setup only needs to be done once (providing you are only using 1 slave - this shouldn't effect you as it is the slave)

however you have a debug, this interfears with the i2c bus on picaxe (i know i have been there), using the terminal and the srtxd command. if the results persistes then further investigation can be carried out
Thanks for that info on the debug - was not aware of that.

I will get rid of it and see if my problems go away

regards

Craig
 

westaust55

Moderator
I believe that it is not mandatory to clear the Hi2cflag unless you wish to specifically know that there is new data (through polling or interrupts).
 

inglewoodpete

Senior Member
When using a PICAXE as an i2c slave, you need to watch any commands that can hog the processor's attention. The debug command is an obvious one but I've had trouble with SerTxd causing corruptions. Often difficult when you're trying to debug your slave program!

The reason for the problem is that the i2c port only has a couple of bytes of buffering for incoming data. The hi2c port issues internal interrupts to get the incoming i2c data transferred to the scratchpad. If the processor has had to mask these interrupts due to time-critical commands, then i2c data can at times be overwritten by fresher incoming data.

Time critical commands are documented at the back of manual 2 and include debug, bit-banged serial like serin, serout, sertxd, owin, owout, readtemp.
 

craigcurtin

Senior Member
When using a PICAXE as an i2c slave, you need to watch any commands that can hog the processor's attention. The debug command is an obvious one but I've had trouble with SerTxd causing corruptions. Often difficult when you're trying to debug your slave program!

The reason for the problem is that the i2c port only has a couple of bytes of buffering for incoming data. The hi2c port issues internal interrupts to get the incoming i2c data transferred to the scratchpad. If the processor has had to mask these interrupts due to time-critical commands, then i2c data can at times be overwritten by fresher incoming data.

Time critical commands are documented at the back of manual 2 and include debug, bit-banged serial like serin, serout, sertxd, owin, owout, readtemp.
OK thanks InglewoodPete - i will put up with it then until i finish the transition to Arduino for this project.

Thanks Westy for confirming re the hi2cflag situation

Craig
 

craigcurtin

Senior Member
Guys,

As an extension to this - i intend to have a 24lc256 as a shared memory area, in the short term i will have a picaxe 40x2, arduino mega and a Rpi all accessing this as a shared area to communicate - i understand that if i declare them all i2cmasters then i will need to arbitrate the control myself - i intend to do so by using a single bit on the eeprom as the "its OK to access me now area" - each of the devices will check this for a Zero value and then lock the device whilst they do their updates and then unlock when finished.

I am just confirming that declaring a picaxe as a master does not do anything weird like locking access to the device that is declared ? It only tries to access it when i do a read and write command ?

Craig
 

inglewoodpete

Senior Member
PICAXEs are not designed to work in a multi-master configuration. That does not mean you can't make them do it though.

Something outside the usual configuration will require YOU to do the testing required to prove the viability of your concept.
 

Buzby

Senior Member
... i will need to arbitrate the control myself - i intend to do so by using a single bit on the eeprom as the "its OK to access me now area" - each of the devices will check this for a Zero value ...
That idea won't work reliably.

As each Master reads the single bit it is accessing the EEPROM anyway, so the bit can be read wrong.
Remember, an I2C 'read' starts with an effective 'write' of the address to be 'read'.
On I2C errors in reading give 0 bits where they should be 1.
 

craigcurtin

Senior Member
That idea won't work reliably.

As each Master reads the single bit it is accessing the EEPROM anyway, so the bit can be read wrong.
Remember, an I2C 'read' starts with an effective 'write' of the address to be 'read'.
On I2C errors in reading give 0 bits where they should be 1.
Hmm, OK guys thanks for this - i guess as InglewoodPete says i will need to do some testing and see what error trapping and recovery i can build in.

Craig
 

inglewoodpete

Senior Member
Hmm, OK guys thanks for this - i guess as InglewoodPete says i will need to do some testing and see what error trapping and recovery i can build in. Craig
You are unlikely to be able to develop a software-only solution using error trapping to determine i2c bus clashes. Both master chips are likely to reboot when large i2c errors occur.

Your options are either to 1) develop a protocol where one of the microcontrollers spends most of its time as an i2c slave with its own unique i2c address. The other controller relinquishes the master role and becomes a slave when requested by the first. Or 2) you use a separate, hardware handshake to arbitrate between the two microcontroller. Probably the simplest solution if you have the spare I/O pins required.
 

craigcurtin

Senior Member
Cheers thanks Pete, i have spares of all the components (i.e. 40x2, Rpi and Arduino) so will set it up in a test mode and see what happens in software first and then revert to hardware if required.

regards

Craig
 
Top