High speed I2C?

KenBash · 2008-01-11 20:19

I've been using the I2C functions to drive·the ·4 channel 16 bit DAC8574 chip for quite a while now and it works great. However... I have a new application needing higher speed analog.·

The chip is capable of going from standard speed ( 100kbs clock rate ) up to 3.4 mhz high speed mode.

I don''t see any provision for switching speed modes in the current I2cObject.

I've ttried searching the Parallax web, but didn't find anything specific on this.

·Has anyone already done a high speed I2c com function for chips like this?··· I'll bit bang it if necessary , but it would be nice not to have to.

Thanks,

Ken Bash

<subject added by moderator>

Post Edited By Moderator (Paul Baker (Parallax)) : 1/11/2008 8:45:42 PM GMT

Mike Green · 2008-01-11 20:32

Both of the I2C objects in the Object Exchange use Spin and are relatively slow as a result. The only assembly I2C routines are those that are part of FemtoBasic and can be used by themselves. They can do roughly 400KHz, but have been occasionally unreliable at the higher speed although others have used them at that speed without problems. They can't be run faster because they're very generalized and that adds significantly to the internal overhead. You'll have to write your own for higher speeds.

KenBash · 2008-01-11 21:01

Thanks Mike,

I KNEW you'd be one to answer and I know that·like a lot of us out here, I ·appreciate the effort you put into it.

I guess I'll look into doing an assembly function to make this work.

If I get something reliable... I'll post the code.

Thanks for the help.

Ken Bash

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
" Anything worth doing... is worth overdoing. "

··············································· ( R.A.H. )
····································

deSilva · 2008-01-11 22:06

Nick Mueller has posted this machine language version of i2c routines for his NNVAR a few weeks ago - thus it's not yet so well known...
http://forums.parallax.com/attachment.php?attachmentid=51206

Note: there are also Mike's femtobasic routines in the zip, but that's for reference only...

Mike Green · 2008-01-11 22:36

Nick's NNVAR uses the routines from FemtoBasic and, as far as I can tell, uses the 100KHz mode.

deSilva · 2008-01-11 22:50

What have I seen then???
Well it's the spdiFemto.spin file.... But from line 227 on it contains an I2C driver in machine code..
T'was some weeks ago... Sorry, I got confused with this - never used the NNVAR...

Nick Mueller · 2008-01-14 10:38

> Nick's NNVAR uses the routines from FemtoBasic and, as far as I can tell, uses the 100KHz mode.

That's *not* my I2C code! I think I said that, and I realy have to credit Mike's work.
I just cut out the most obvious SD-code (I think).

I am using it a 400kHz and I do not have the impression that it is making problems.

Just coming back from a fair of model-engine builders where I wanted to demonstrate my Prop-based ignition. But I failed to get the motor running I have built the system for as a demonstration-platform. I didn't get enough compression to get the motor running. I didn't get the valves tight enough (*not* my first ones). Anyhow, still a success.

I hope that I will find the time now to make an I2C-routine in ASM using Mike's code as a start.

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Mike Green · 2008-01-14 15:56

Just to clarify some things about the assembly I2C routines. These were originally written to use the 400KHz mode of I2C. When I tested them, there were occasional unexplained errors that, because of how they appeared, seemed to be due to the tight timing in some parts of the low level routines. I fiddled with these routines, rewrote them several times, adjusted the timing, but was unable to get them to work error free. When I slowed the timing down, the problem seemed to go away completely. At 100KHz, it seems to be "rock solid".

I know this is not the way to "test" a piece of software. I'd be nice to get an answer to why it wouldn't work at 400KHz since the timings seemed to be just adequate for the I2C EEPROM specs, but I don't have a scope nor access to one. I don't think it would be noise since I was using a Demo Board with an extra EEPROM on it with short leads and a bypass capacitor on the breadboard next to the EEPROM. Anyway, I made the bus speed configurable and made 100KHz the default.

tekochip · 2008-01-15 14:08

I was able to get the speed up to 400KHz, and you're right, timing is the issue with the higher speeds.· Sometimes the waitcnt instructions were too late and would roll over.· A better method might be to use a timer to prevent the problems with waitcnt rolling over.

Nick Mueller · 2008-01-15 14:34

> Sometimes the waitcnt instructions were too late and would roll over.

Did you use waitcnt after a write?
I just used a writeWait after every write and that worked well.
If you invest some time in coding a real blockwrite (in Spin), the writeWait isn't such a penalty and it also waits exactly as long as the device needs (IIRC, the time might vary, read the datasheet).

  if cNVVarEEPROMPageSize > 0   'a real paged write
    repeat
      chunk:= cNVVarEEPROMPageSize - addr // cNVVarEEPROMPageSize
      if size =< chunk
        i2cObj.writeEEPROM(addr, pSrc, size)
        size:= 0
      else
        i2cObj.writeEEPROM(addr, pSrc, chunk)
        addr+= chunk
        pSrc+= chunk
        size-= chunk

      i2cObj.writeWait(lDevAddr)
    until size =< 0  'defensive ==

Of course, that would be even faster in ASM.

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

ella · 2011-06-25 00:49

HI. Although High Speed I2C is not available yet via parallax, just in case, in one of my projects I've used SUB-20 USB with High Speed I2C (http://www.xdimax.com/sub20/sub20.html) . I did it for Microchip MCP4728EV D/A board. Works just fine. Now I'm trying to figure out how to get the same functionality from BASIC?

Bobb Fwed · 2011-06-27 12:54

Did someone mention there is a PASM I2C object in the OBEX? It may not be quite as fast as you are looking for (there is still a SPIN interface), but in my Memory Management object it speeds everything up about 5 times faster than the SPIN variety (but that's with significant overhead from the my container object, it's likely better than 5 times faster). http://obex.parallax.com/objects/611/

High speed I2C?

Comments