Software i2c slave

[Christopher]

Hi all

I have written some simple bit bashed psuedo code routines for I2C master from various app notes etc.

I am now looking for some routines to base my bitbanged I2C slave routines on....

Have you got any  example code to share ?

[Christopher]

THanks, I saw that but didn't see the attached C Code. I will have a look now

This document http://www.cypress.com/file/73106/download is pretty awesome because it's simplisting, but do not include the Write routine.

[MrAl]

THanks, I saw that but didn't see the attached C Code. I will have a look now

This document http://www.cypress.com/file/73106/download is pretty awesome because it's simplisting, but do not include the Write routine.

Hi,

They show a state machine drawing so you could probably go by that, or just look at a timing drawing and go by that.  When i did my bit banged master that's what i did (timing drawing).

BTW, do you use a loop for your master wait for ACK or just assume it comes in ok?  I used a loop just in case.
The tricky part is when the master is outputting a '1' and then immediately must switch to looking at the data line as an input.  If the slave is fast it could cause a buss contention.  True open collector (drain) outputs would eliminate any possibility of a buss contention, even during start up when things may not be as well defined, or else a small value series resistor.

[macboy]

THanks, I saw that but didn't see the attached C Code. I will have a look now

This document http://www.cypress.com/file/73106/download is pretty awesome because it's simplisting, but do not include the Write routine.

Hi,

They show a state machine drawing so you could probably go by that, or just look at a timing drawing and go by that.  When i did my bit banged master that's what i did (timing drawing).

BTW, do you use a loop for your master wait for ACK or just assume it comes in ok?  I used a loop just in case.
The tricky part is when the master is outputting a '1' and then immediately must switch to looking at the data line as an input.  If the slave is fast it could cause a buss contention.  True open collector (drain) outputs would eliminate any possibility of a buss contention, even during start up when things may not be as well defined, or else a small value series resistor.

I2C must use open collector (open drain) outputs. You are not allowed to drive the bus high, you must only let it float high through the pullup resistors. On a microcontroller, the usual way to accomplish this is to toggle the pin between output and input modes, while leaving the output latch set to a zero (low). When you set the pin to output, it drives low, and when you set it to input, it floats. You never want to set the pin to output and switch between outputting a 0 and 1. This can prevent not only proper and safe slave ACK generation, but also slave clock stretching.

[Karel]

On a microcontroller, the usual way to accomplish this is to toggle the pin between output and input modes, while leaving the output latch set to a zero (low).hing.

On a microcontroller, the usual way to accomplish this is to configure the pin as open-drain output.

[macboy]

On a microcontroller, the usual way to accomplish this is to toggle the pin between output and input modes, while leaving the output latch set to a zero (low).hing.

On a microcontroller, the usual way to accomplish this is to configure the pin as open-drain output.

Not all have this option. Obviously if MrAl was talking about bus contention, then his did not.

[Howardlong]

I reckon it's a rite of passage in the low level embedded world to write your own bit banged I2C master and slave code at some point ;-)

Once you've got basic blocking versions of each, for added points re-write them as non-blocking state machines. That's just the kind of project universities should do at undergrad level for EEs, it has real purpose, shows real understanding and is non-trivial.

[mikerj]

I reckon it's a rite of passage in the low level embedded world to write your own bit banged I2C master and slave code at some point ;-)

Once you've got basic blocking versions of each, for added points re-write them as non-blocking state machines. That's just the kind of project universities should do at undergrad level for EEs, it has real purpose, shows real understanding and is non-trivial.

The master is pretty easy, but getting bit bashed slaves working correctly at high bit rates can be tricky and tends to consume a lot of CPU cycles; not ideal if you have any other timing sensitive tasks.   Great as an educational exercise but if I wanted an i2C slave I would always choose a device with some level of hardware support.

[Howardlong]

I reckon it's a rite of passage in the low level embedded world to write your own bit banged I2C master and slave code at some point ;-)

Once you've got basic blocking versions of each, for added points re-write them as non-blocking state machines. That's just the kind of project universities should do at undergrad level for EEs, it has real purpose, shows real understanding and is non-trivial.

The master is pretty easy, but getting bit bashed slaves working correctly at high bit rates can be tricky and tends to consume a lot of CPU cycles; not ideal if you have any other timing sensitive tasks.   Great as an educational exercise but if I wanted an i2C slave I would always choose a device with some level of hardware support.

I totally agree, as a practical learning execise it teaches an awful lot.... including why maybe sometimes it's not the best solution.