Shop OBEX P1 Docs P2 Docs Learn Events
I2C 2006 revision — Parallax Forums

I2C 2006 revision

Jared WoolstonJared Woolston Posts: 36
edited 2007-07-18 08:16 in General Discussion
Does anyone here see any problem with writing efficient code and clocking the SX to a sufficient speed to reach the max 1MBps transfer rate (note the big B) specified in the 2006 revision of the I2C specifications?

- Jared

Comments

  • JonnyMacJonnyMac Posts: 9,385
    edited 2007-07-17 20:54
    In assembly with a 50 MHz clock it would be no trouble; at 1M bps the period is 1 uS; at 50% duty cycle of the clock the on and off times are 500 ns -- at 50 MHz the instruction cycle is 20 ns. You can certainly set the appropriate TRIS register (to pull the pin low or let it float) is less than the 25 cycles you have available. Seems like board layout and those considerations are going to be greater concerns.
  • pjvpjv Posts: 1,903
    edited 2007-07-17 23:06
    Hi All;

    I'm imagining that the "big B" reference implies 1 MegaByte per second, and that is much more of a challenge. I have some experience at 10 Megabits per second , but only on a rather bursty basis. I suspect that sustained throughput at that rate is not possible except for contrived or trivial cases, or using clock rates higher than 50 MHz.

    Cheers,

    Peter (pjv)
  • Jared WoolstonJared Woolston Posts: 36
    edited 2007-07-17 23:34
    Yeah I figured it would be a pretty intensive for the chip...I was thinking 75-110MHz (of course care would need to be taken...I am not mistaken am I? the SX can run up to 110MHz if thermal and proper power filtering needs are met right?)

    I was also expecting this to pretty much be the only thing this chip does. The specific application I was thinking of is a data logging chip in a 'computer' composed of a number (10ish) of SX48's. The communication would be round robin style where each chip in the computer would only briefly burst data to the data logging chip which then writes it into an EEPROM bank after combining with data from the other chips. The net result being that the data logging chip is almost always in I2C communications with either EEPROM (of course limited to the EEPROM max speed) and the other chips which I would like to be as fast as possible so that they may have more time to deal with the tasks they are intended for.

    BTW, youre assumption is correct, i was refering to 1 megabyte per second.

    - Jared

    Post Edited (Jared Woolston) : 7/17/2007 11:49:20 PM GMT
  • JonnyMacJonnyMac Posts: 9,385
    edited 2007-07-18 00:03
    My mistake, guys, sorry -- and now I'm really thinking that circuit layout is going to be the bigger challenge.
  • Jared WoolstonJared Woolston Posts: 36
    edited 2007-07-18 01:08
    well, it seems to me that board issues aside, its a simple enough task as long as its bursting or the only thing the mcu does.
  • pjvpjv Posts: 1,903
    edited 2007-07-18 04:20
    Hi Jared;

    Are you not concerned about using up the limited number of write cycles for an EEPROM? Or do the new standards also make those limitations go away? Traditionally you might have 100,000 writes, possibly 1,000,000 before the thing is worn out, and at the rate you're talking that would take one second..... not much of a logger, I believe. On top of that, are there not (relatively) large delays of several milliseconds in flashing a page?

    Perhaps you might consider a parallel, or possibly a serial FRAM with unlimited writes although I can't recall their speed just now.

    Sounds like a killer project. And, yes, if you were to require it, there are some very neat ways of keeping multiple SXes precisely synchronized. I have been able to achieve this with somewhere around 100 chips at a time, all the while communicating at 10 Megabits per second.

    Have fun,

    Peter (pjv)
  • Jared WoolstonJared Woolston Posts: 36
    edited 2007-07-18 08:16
    Yea for keeping them neatly synchronized I was thinking of using a TTL oscillator to drive a sufficiently speedy transistor or a logic level MOSFET and just let that drive the SX chips. 100 SX chips....theres a small chunk of change. I had planned on having an extremely large bank of EEPROM. All being I2C and for a conservative estimate lets say each set of 8 EEPROM chips -most of the ones ive seen only support 3 bit addresses but my viewing is highly limited and very selective - has its own dedicated I2C bus. Removing the 2 lines its going to take for the data logging SX to get the data in the first place, I figure I can get roughly 17 banks (SX48s) of 8 EEPROM chips for a total of 136. As you said, there are paging time issues to deal with as well. Perhaps I will add a RAM bank as well, however, the data logging I am thinking of is less of second for second and more of for storing data of settings and calculated adaptations, all of which can then be read back into the system when appropriate. Also, it doesnt simply write data each time it recieves it, there is a small amount of processing which occurs, taking input from other SX chips to determine the 'weight' of the data and if it merits logging. Even more specifically, the 1MBps is exclusively for inter-SX communication, unless I happen to find an EEPROM which supports it.....really its intended solely to take load off of the other chips in the system (by reducing the time they spend communicating between each other and the data logging system.)
Sign In or Register to comment.