Go Down

Topic: Hackscribble Ferro - new library for Ferroelectric RAM (FRAM) over SPI (Read 20768 times) previous topic - next topic

Hackscribble

Apr 23, 2014, 06:49 pm Last Edit: Sep 27, 2014, 10:46 am by Hackscribble Reason: 1
Hackscribble Ferro  is a new library to connect fast, non-volatile FRAM memory chips to the Arduino.

Version 1.0 supports Fujitsu MB85RS devices with capacities up to 32KB per chip.  You connect them using the SPI bus and you can have multiple chips working in parallel.

EDIT: Release 1.4 now supports 128KB and 256KB devices as well.

The Hackscribble Ferro library makes it easy to use this additional memory, with functions to create, write and read arrays of any type of variable, including user-defined structures, and an extensive user guide.

We would love to get your feedback on the library and ideas for improvements, either here or through our GitHub pages.

Regards
Ray at Hackscribble

arduino@hackscribble.com  |  www.hackscribble.com  |  www.twitter.com/hackscribble

Hackscribble.  Writing about making things
hackscribble@outlook.com

raschemmel

I would be willing to give you my feedback if you are willing to post the code and example schematic to add 32kb of FRAM to my
UNO (or Pro-Mini).
Arduino UNOs, Pro-Minis, ATMega328, ATtiny85, LCDs, MCP4162, keypads,<br />DS18B20s,74c922,nRF24L01, RS232, SD card, RC fixed wing, quadcopter

Hackscribble

Thank you, raschemmel

The link to the library page on GitHub was in my first post but maybe it wasn't clear.  You can find the library at  http://hackscribble.github.io/hackscribble-ferro-library/

You can get the code, example sketches and user guide from there.  The user guide discusses the hardware requirements.

And we have just added a second page with more details on hardware and example PCB layouts:  http://hackscribble.github.io/hackscribble-ferro-hardware/

We would appreciate any comments you have.

All the best
Ray at Hackscribble
Hackscribble.  Writing about making things
hackscribble@outlook.com

panther3001

#3
May 20, 2014, 04:48 am Last Edit: May 20, 2014, 04:50 am by panther3001 Reason: 1
Hey I really think this is great.  I don't have an FRAM chip yet but I've been wondering how to do high-speed data capture for quite some time now using Arduino, and this may be it! I'd like to do 50KSps analog data-sampling (which analogRead can do, as Simon Monk explains on pg. 81-83 [Sketch 04_11_analog] of his "Programming Arduino--Next Steps" book) into such a buffer, where I can then forward it to a PC running Processsing or something.

PS. For SPI level shifting, for a chip such as this, I hear that the 4050 hex buffers work great, and they are dirt cheap. here's some on ebay: http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&LH_BIN=1&_nkw=4050+hex&_sop=15

Sincerely,
Gabriel
http://electricrcaircraftguy.blogspot.com/
Visit my RC aircraft, electronics, & Arduino website at http://www.electricrcaircraftguy.com

Hackscribble

Thanks, Gabriel. This first version of the library is not optimised for performance. In particular, it uses the standard digitalWrite() functions to control the chip select pin on the FRAM.

I'm working on a new version of the library which is already showing significant improvements. And the next release will also include another example program to demonstrate the speed.

Taking your target of 50ksps, what size data item are you thinking about? 16 bit integers?

Regards

Ray
Hackscribble.  Writing about making things
hackscribble@outlook.com

fat16lib

Quote
I'd like to do 50KSps analog data-sampling (which analogRead can do, as Simon Monk explains on pg. 81-83 [Sketch 04_11_analog] of his "Programming Arduino--Next Steps" book)


It is possible to increase the ADC clock frequency and do 50 ksps.  At 1 MHz ADC clock you can get about 8.7 ENOB  (Effective Number of Bits) from the AVR ADC.  See the attached chart or this site http://www.openmusiclabs.com/learning/digital/atmega-adc/.

The problem is that at 1 MHz each sample takes about 14 usec to digitize so there is not enough time to write two bytes to the FRAM.

I have developed a very fast template class for 256 KB FRAM as part of this library http://forum.arduino.cc/index.php?topic=229485.0. See the attache chart for performance of the FRAM driver.  There is a very high overhead for small transfers to the FRAM.

Another problem is time jitter.  For data to be meaningful, the jitter between points must be very small.  There are many application notes on ADC time jitter (google "adc time jitter") .  The simple answer is for 10 bit data, you need less than 0.1 % time jitter.  At 50 ksps this is 0.02 usec.

It is possible to trigger the AVR ADC using a timer and achieve very low jitter.  I wrote an SD data logger that uses this method http://forum.arduino.cc/index.php?topic=228549.0.  It can log data at 40 ksps to an SD.  I plan to modify it to use FRAM and hope to achieve 50 ksps.


panther3001


Thanks, Gabriel. This first version of the library is not optimised for performance. In particular, it uses the standard digitalWrite() functions to control the chip select pin on the FRAM.

I'm working on a new version of the library which is already showing significant improvements. And the next release will also include another example program to demonstrate the speed.

Taking your target of 50ksps, what size data item are you thinking about? 16 bit integers?

Regards

Ray



I'm thinking I'll use the 10-bit built-in ADC on the Arduino, in high-speed mode. However, since voltage precision is not critical (nor feasible at these rates), I may map the values down to 8-bit values. Otherwise, yes, I'll store them in 16-bit integers.
Visit my RC aircraft, electronics, & Arduino website at http://www.electricrcaircraftguy.com

fat16lib

Quote
voltage precision is not critical

What is critical?   Why take data at 50 ksps unless the data means something?  What is the purpose of your measurement?

panther3001

fat16lib, that rate is fantastic!  40KSps is good enough for me!  I need to download and look at your information someday.  Logging to an SD card is great, and that rate is good enough.  I haven't ever used an SD card with the Arduino yet, however, but I have a few questions:
1) How much of the card can the Arduino access?  I thought it could only address so much of it, so even on a 16GB card you can only see like 2GB or something.  Is that right or am I confused?
2) How are you getting data rates from 80~650 Kilobytes (KB) per sec?  I have a friend using the SD Card library who got no better than ~6.5KB/sec in a quick test he ran.

Visit my RC aircraft, electronics, & Arduino website at http://www.electricrcaircraftguy.com

panther3001

#9
May 21, 2014, 04:55 am Last Edit: May 21, 2014, 05:11 am by panther3001 Reason: 1

Quote
voltage precision is not critical

What is critical?   Why take data at 50 ksps unless the data means something?  What is the purpose of your measurement?



For my application in mind, *time* is critical.  Voltage precision is not -- it could be 6-bit and that's good enough for me to get the gist of what's going on. 

I do a lot with Radio Control (http://electricrcaircraftguy.blogspot.com/), and in the process, I borrowed a digital Oscilloscope with 1GS/sec data-sampling in order to view, study, and learn how RC PWM (communication signals in this case) and PPM (also communication signals) work.  I have since then written code to read these signals. My skills were very elementary when I started, so I have progressed to harder and harder methods each time, little by little building up my skill-set over the past year, and getting to where I am today.  I started by using pulseIn(), then external interrupts, with the micros() function (4us precision) to take time-stamps, then external interrupts with my custom Timer2_Counter library (http://electricrcaircraftguy.blogspot.com/2014/02/Timer2Counter-more-precise-Arduino-micros-function.html), to get 0.5us precision time-stamps.  Then I also used pin-change interrupts, and most recently, even input capture, in order to read the PWM and PPM signals from an RC receiver and transmitter (ex: http://www.instructables.com/id/Arduino-to-MATLAB-GUI-Live-Data-Acquisition-Plotti/), respectively. 

However, I like being able to share my knowledge and help others, so I thought to myself, "how can I use an Arduino to teach someone PPM and PWM communication signals?", and to give them the ability to record and view them--with*out* an oscilloscope, and with*out* knowing before-hand how to read the signals directly?  Well, that's where I decided fast ADC reading is essential.  I need to be able to read pulses as short as 50~100us, so I figure I need 5~10 samples over that pulse to easily see that it even exists.  Let's say I get 5 samples over 100us, so that's 20us time-steps per sample, or 1/20us = 50KSps.  I didn't even know that was possible until 2 days ago when I saw it in my book by Simon Monk.  I want analog sampling so that I can see the voltage levels, as different RC systems use different levels.  Some are 0-5V, and some are 0-3V, and others may be different still.  I'd like to know which are which.  64-steps, or 6-bit resolution is adequate. 

Second, I like understanding equipment (the Arduino, for example) well enough that I can push it to its absolute maximum limits when needed, for various applications.  I'm an engineer, hands-on and research-oriented, and I am building up a skill-set and tools to be used for my whole life to come.   

Third, I'd like an Arduino-based Oscilloscope, and I want to know what the limitations are.  At this point, even an SD-card-based 6-bit 40KSps "O-scope" (ie: data sampling instrument) is good enough for playing around with.  I plan on buffering to some location (looks like an SD-card would work, even though until this moment I had *no idea* it would be fast enough to record the data), then I can packetize the data into binary packets (for speed and efficiency; I've already done this...see my instructables link above to see my binary data packets in my Arduino code), then I can send the data over serial to a receiving PC, and plot it "live" (wave by wave, updating as able).

Fourth, I do a lot of data acquisition, and want to know all limits when using an Arduino (relates to 2 above).  I do home projects for fun all the time and am interested in data collection, especially in regards to RC airplanes.

Fifth, I am curious about sampling audio.  The upper limit of hearing is 20KHz, so I think 40KSps to an SD-card is good enough for audio, right?  Even if crude, or distorted, I don't care.  This stuff is fascinating.  If an audio recording is understandable when replayed, I've succeeded as far as I'm concerned.
Visit my RC aircraft, electronics, & Arduino website at http://www.electricrcaircraftguy.com

fat16lib

Time is as important as amplitude in measuring a signal.  Even at 6-bit accuracy in amplitude you need sub microsecond accuracy in sample time to not degrade the information in your data.

How do you plan to keeping sampling time jitter to about one CPU cycle?

panther3001


Time is as important as amplitude in measuring a signal.  Even at 6-bit accuracy in amplitude you need sub microsecond accuracy in sample time to not degrade the information in your data.

How do you plan to keeping sampling time jitter to about one CPU cycle?


I know, but I'll take what I can get with an Arduino.  Ideally I'd get 1us precision (or better, like you said) in sampling, but 1MSps isn't going to happen, right?  I'm using dirt cheap Arduinos.  You can't beat that.  It's good enough to teach the basics of RC PWM and PPM, even if the sampling is crude.  The concept is what matters, and it's nice to be able to play with a device live while watching the signal change (even if time resolution stinks).

To keep jitter down, I planned on using timers to trigger the sampling event in an ISR....perhaps via an overflow timer, or an output compare.  That should work, right?  for 40KSps (sampling period of 25us), I could set the prescaler on Timer2 to 8, which gives me a 0.5us resolution, then I could hit a compare match every 50 counts (25us), stepping into an ISR to sample, and moving the compare match to the next desired location.

That's what I'd do, but we are speaking right at the edge of my knowledge right now.  I know you know waaay more about this stuff than I, at the moment.
Visit my RC aircraft, electronics, & Arduino website at http://www.electricrcaircraftguy.com

fat16lib

Quote
I planned on using timers to trigger the sampling event in an ISR.

No this does not work.  The timer0 ISR for millis can causes about 3 usec jitter.

For the binary logger I use timer 1 to trigger ADC start.  I then read the ADC in the ADC done interrupt in an ISR.  This means the ADC is triggered exactly when the compare match happens, no ISR involved.  See the AVR datasheet.

You must use a multiple of the ADC clock frequency with a timer or there will be jitter.

I was able to record data at 50 ksps with the AnalogBinLogger in 8-bit mode.  I attached a plot and the data file.

I used analogWrite(5, 100) so pin 5 is about 39% duty cycle and runs at about 976 Hz.  Pins 5 and 6 use timer 0 for PWM so the frequency is set for millis()/micros().

3.9 seconds of data used 198 KB in the binary file.  It became over 2 MB in the Excel CSV file that I attached.

Looks like your idea to demonstrate PWM will work.


panther3001

#13
May 21, 2014, 04:52 pm Last Edit: May 21, 2014, 05:03 pm by panther3001 Reason: 1
Hey this is great!  Thank you for your help and work, and information on how to do this.  Do you mind sharing your sketch? 
Visit my RC aircraft, electronics, & Arduino website at http://www.electricrcaircraftguy.com

fat16lib


Go Up