Bit-banging I2C

Lol. I think you are showing some ignorance. If you think a teacher should encourage kids to speak ambiguously you definitely are not qualified for teaching. I think few in this business would be good teachers... especially if they feel teaching is not "a real job".

His point was this was what he called, "waffle words" which are used to reduce the significance of what was being said. Better to find ways of speaking to emphasize what was being said.

This all had no impact on many of the kids who had little interest in learning, but I learned a lot from his teaching methods.

--

Rick

It is pretty easy. Read the spec think about it over night, a couple hours to implement and test. What we have found is we run across devices that don't always implement I2C protocols.

w..

Most code and testing of interface (with full timing and checking basic reading/writing device) for compliance worst case 2 days on a hardware mock up on a Eval board with a sample device.

Anything beyond that is problems due to MCU and/or device specification 'issues', or lack of understanding. Assuming you have already worked out how to use the MCU in question.

Having done all forms of I2C and SPI as from MCU hardware controllers, NXP I2C controllers, FPGA master and slave devices, software bit bang on MCU's and even back in day from PC printer port using Windows for Workgroups.

One device was FPGA EEPROM emulator capable of I2C over 2MHz.

Many other have posted many things to look at out far I would add

1/ reset on device, if Software bit banging have a way of resetting the device whether SPI or I2C, when software bit banging nothing like debug, actual bug, or even whilst uploading new code to screw up random clock sequences. Having debugged many devices. 2/ Making sure device can work with irregular clock drive, so many devices fail when they expect an exact regular clock. I2C and SPI do NOT need an exact clock as they are stateful bit operations. 3/ Will device do proper reset from 9 clock pulses and stop condition I2C spec reset many devices fails. 4/ Any software should check the ACTUAL pin voltages as often as possible even with one device a shorted I2C or SPI pin is a pain. 5/ Does your device nee an I2C Restart state which is slightly different to Start and make sure software/hardware can cope with it.

There are plenty of software bit bang examples I2C and SPI around as starting point. Plenty also of FPGA code. I have always reviewed these examples as often they are lacking, but a good staring point.

Having dealt with many devices generally I2C is easier, many issues with SPI controllers ranging from only do bytes or multiples, screwing up Chip selects, getting byte orders to match.....

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
  Raspberry Pi Add-ons 
 Timing Diagram Font 
 For those web sites you hate

Well... maybe.

--
Les Cargill

So, we are trying to do one-wire with a PC class (linux) master and FPGA slave. The master has file system I/O interface. We can do the protocol as slow as possible.

Yes, we will have to disable interrupts a few msec at a time.