FRAM Breakout - Adafruit New Product

@peekay123 I got 3 of the SPI FRAM chips heading your way from Adafruit. They should be there Wednesday or Thursday of next week.

Have fun!

@RWB, you rock! I can’t wait to start looking at that display buffer concept using SPI DMA. Dude, I owe you one :wink:

@peekay123 The custom Font hack was all worth it honestly.

Getting the Sharp Memory LCD up and working with the Spark Core is something I’m sure I’ll use in a future product so its well worth the investment.

I would like to see how low power we can make the spark core by having it only access the internet every so often to update data via Wifi and then refresh the Sharp Memory LCD which will say on 24/7 like the Pebble Watches.

@RWB, I am working on doing a power profile of the Spark with the existing sleep modes. I’ll be sharing my findings when I’m done. I have a project where my core sleeps 1 minute, wakes, reads some sensors and does a publish of the data and then goes into deep sleep for another minute. I am trying to measure the power profile of the spark when it wakes (wifi/cloud connect and publish) so I can figure overall power consumption.

@peekay123 That’s data that will be useful to lots of different people. Keep up the good work. I’m looking forward to your data.

@RWB, check out:

I got the Adafruit I2C FRAM breakout running under CoOS on my spark today as part of testing a new I2C driver I’ve been developing. Still a lot of testing to be done yet, but Read with DMA and interrupts seem to be working well. I have implemented Fast (400 KHz) and Ultra Fast (1000 KHz) along with the Standard (100 KHz), Adafruit uses the Fujitsu FRAM that supports Ultra Fast and I was pleasantly surprised to find the F103 did as well, even though that is undocumented.

Anyway, I ran a few read performance tests by reading 256 Kbytes of data (256 byte read x 1024 times)

100 KHz - 23,73 seconds or just over 10 Kbytes per second
400 KHz - 5.998 seconds or just over 44 Kbytes per second
1000 KHz - 2.444 seconds or just over 100 Kbytes per second.

AS I said, still a lot of testing left to do. I want to do a Spi driver along the same lines, as well Then I’ll clean it all up, write documentation and post it all on spark.hackster.io. (next month sometime hopefully).

1 Like

@pra, that is fantastic! @timb is working on a I2C library for the core and it may be worth working with him since you are so advanced!

I have been testing the SPI version of that breakout and it flies at 18Mhz (DIV4) but stops there since the part is not rated for 36Mhz (DIV2). I will be doing some speed test in the coming days. :smile:

I have this I2C driver pretty much finished now, and have completed a pretty extensive testing process. @timb, if you think this will be of help to you I’m more than willing to send you the code. It’s “C” not “C++” and not compatible with the spark wiring API. However, it does use interrupts and DMA and seems to work fairly well. Probably easy enough to steal from or put a Spark wrapper around.

In my testing, I got BERR (bus errors) at 1000 KHz. 800 KHz works fine with no problems. Adafruiit has 10K pull-ups on the breakout and that’s not much when its the only device on the bus. I’ve found from past experience you need a effective total resistance of around 1200 ohms for good clean clocks. Whether it’s the pull-ups that caused the problem I don’t know. At twice the nominal maximum, 800 KHz is pretty good.

Peter

1 Like

@pra That would be very helpful! Can you hit me with the code and some info up via email?

{contact+1403070875@timb.us}

Sent the files to you this morning

Hmm, didn’t get it. I’ll send you a PM with my normal email.

Hopefully this time :smile:

I have the Adafruit SPI 8K FRAM running under my OS utilizing a new SPI driver that uses DMA and interrupts. I’m running it at the maximum SPI clock speed the STM32F103 supports, 18 MHz. It took 138 milliseconds to read 256K bytes of data using a 256 byte buffer. This translates to a smidgen under 2 megabytes (16 megabits) per second. Could probably get the rate above 2 mbytes by using a bigger buffer.

1 Like

@pra, NICE!! I had it on my list to do add DMA SPI to the Core but you are there already! Can you a) Share the code and b) make the DMA stuff into a pull request? :wink:

Although this runs on a Spark Core, it doesn’t work with the Spark firmware. It’s probably possible to retrofit, but would require some workarounds for the mutex, message queues and memory management features I use from CoOS. I can send you the file if you want to take a look.

Let me know

@pra, bummer! No problem. Ideally, we use the same DMA structure with SPI that you used for the I2C code you passed on to @timb. Thanks!

If you send me a PM with your email address, I’ll send you the files. It would be easier to make my SPI driver work for SPI than adapt the I2C one. I also incorporated things you talked about back aways, such as setting speed and mode for each transaction so you can easily access multiple SPI devices. I support up to 8 concurrent devices. There is little value in DMA using the single byte at a time interface that wiring utilizes, so an additional SPI API that does block transfers is probably the way to go.

Okay guys, I have preliminary DMA working with I2C! Well, at least for reads. I’m having some write issues but should be able to clean that up shortly. The reads are occasionally returning bad data, so I think I’ve got a rouge pointer somewhere.

I’m also changing Spark’s Wire library a bit to make it more compatible with existing Arduino libraries. In addition to that I’m implementing a spark.I2C() mini-library that will give you lower level access to stuff.

@peekay123 I suggest you add a spark.SPI component like @pra suggested.

2 Likes

@timb, I am just starting to look at the SPI stuff. I will wait to see your code to make sure everything meshes and I will follow your lead on the spark. stuff. :smile:

2 Likes