32K byte fram example

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got one of those adafruit 32k frams. It has one of those danged twi hookups, but I just spent a couple days getting the st ranger twi working, so I used that to read and write the fram. Seems to take 3 sec to fill 32k, about 90usecs per byte.

Attachment(s): 

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Seems to take 3 sec to fill 32k, about 90usecs per byte.

???  Surely that is going to be limited by the I2C, and your skill in flogging same.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess I could put the TWBR in a variable and keep speeding it up till it quits. Evidently 0x12 gives 400kbits at 16mhz on an uno. Whats the limit?

OK, it sped up to 32k in 2 sec when I read and write 2 bytes at a time, but changing the TWBR down from 12 doesnt seems to speed it up at all. Maybe the secret to making twi faster is to put all the check-for-int subroutines into macros, saves the call overhead?

 

Imagecraft compiler user

Last Edited: Sat. Dec 24, 2016 - 05:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I've been able to run i2c at around 800 kHz and that was with a 16 MHz main clock.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to the datasheet,  the I2C Fram can work at up to 1MHz bus speed.

The standard I2C bus is 100kHz.

 

Obviously,  a bus has to work with all the Slaves.  i.e. you must always Start at the slowest Slave's bus speed.   Once the Slave has acknowledged,  you can communicate at its fastest speed.

 

e.g. i2c_start() @ 100kHz,  i2c_write() @ 400kHz.    The AVR can't really go much faster.   An Xmega or ARM certainly can.

 

It is always sensible to read and write contiguous blocks of memory if possible.      Exactly like using an SPI RAM memory or even 24Cxxx EEPROMs.    Of course,  you don't need to worry about Pages when you have RAM or Fram.

 

You should be able to read the whole 32kB of Fram in 32k * 90us on a 100kHz bus i.e. 2.95 seconds.

In comparison,   a 23K256 SPI RAM can be clocked at 20MHz.   A 20MHz AVR can manage 10MHz SCK.   So 32kB will take 26.2ms

 

David.

Last Edited: Sat. Dec 24, 2016 - 08:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
I guess I could...

 

You just don't get it.  Think about it -- if it is taking you 90us per byte, but your I2C clock has you taking 2.5us per bit or 20us per byte, then you can only get a fractional improvement no matter how much you speed up the I2C clock.

 

So now it is back to your skill in flogging the peripheral.  There muse be a reason why you chose I2C in the first place, instead of e.g. the faster SPI.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Sun. Dec 25, 2016 - 03:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reason I bought the thing was: 1)it was only $9 2)Jim aksed about it and I thought I'd try and see how it worked 3)didnt see one with spi. Adafruit or Sparkfun have one? 4)last time I tried to twi something it was a painful multiday experience comparing other peoples byzantine bloated libraries or whatever word they use for subroutines nowadays. I was hoping I'd get the LightBulbEffect but evidently Not Yet.

 

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Bob,

 

It all depends on what you actually want to do.   You can have perfectly acceptable performance if you are storing blocks.    If you want random bytes,   it is extremely slow.

 

Likewise,  if you want non-volatile storage that is seldom changed or frequently changed fast "RAM".

 

The 23K256 can be non-volatile if you provide a backup battery.   Or you could use big 25Qxxx Flash memory chips.   Much like the "solid-state-disk" in this Laptop.

 

DataFlash chips are a happy compromise.   Easy to program.   You can access buffers like "temporary RAM".

 

Explain what you want to do.   I expect someone can show you how to achieve the "best" performance.

Your ATmega2560 can access an external RAM chip.   An Xmega can access a very big external RAM.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
If you want random bytes, it is extremely slow.

Really?  I'd have to look into that particular device, then.  I've had a family of apps with an older FRAM model with SPI interface, and AFAIK there is no "lag" other than the transmission time.  I guess if the framing/address was extensive then there would be a multiplier on the overhead.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You would have to set the read/write location counter for every random access.   Effectively 450us instead of 90us (for a consecutive location) read @ 100kHz.

 

You have the same situation with random access on an SPI device.    Except that the bus frequency is a lot higher.

Applies to 25xxx Flash or 45xxx DataFlash too.

 

All these devices can give perfectly acceptable performance in most microcontroller apps.

 

David.