Show Posts
Pages: 1 ... 54 55 [56] 57 58 ... 107
826  Development / Other Hardware Development / Re: Teensy 3.0 on: October 08, 2012, 09:45:14 am
This beta of SdFat uses the above functions:

The functions are at the top of Sd2Card.cpp

It also has the following function to initialize AVR SPI pins:
 * initialize SPI pins
static void spiBegin() {
  pinMode(MISO, INPUT);
  pinMode(MOSI, OUTPUT);
  pinMode(SCK, OUTPUT);
  // SS must be in output mode even it is not chip select
  pinMode(SS, OUTPUT);
  // set SS high - may be chip select for another SPI device
  digitalWrite(SS, HIGH);
#endif  // SET_SPI_SS_HIGH

This version of SdFat does not have the new stuff to speed up large reads and writes.  That involves changes to use multi-block SD commands.
827  Development / Other Hardware Development / Re: Teensy 3.0 on: October 08, 2012, 08:45:16 am
Paul, I am doing a major redesign of SdFat to use better caching and faster SD commands so large writes/reads will be much faster.

I plan to support SPI and 4-bit SDIO on various Cortex M chips.  I also want to make SdFat RTOS friendly when using DMA.

I would love to have a better low level SPI library for each chip.

I need a way to restore the SPI speed and mode each time I access the SD.  I need single byte read and write for sending commands, receiving status, and polling for busy.

I need fast block read and write routines.  These could use a fifo or DMA.

I am ready to start testing with some prototype SPI functions I have done but for some reason my Teensy 3.0 has not arrived in California yet.

Edit:  I need the equivalent of these AVR functions.
 * Initialize hardware SPI
 * Set SCK rate to F_CPU/pow(2, 1 + spiRate) for spiRate [0,6]
static void spiInit(uint8_t spiRate) {
  // See avr processor documentation
  SPCR = (1 << SPE) | (1 << MSTR) | (spiRate >> 1);
  SPSR = spiRate & 1 || spiRate == 6 ? 0 : 1 << SPI2X;
/** SPI receive a byte */
static uint8_t spiRec() {
  SPDR = 0XFF;
  while (!(SPSR & (1 << SPIF)));
  return SPDR;
/** SPI read data - only one call so force inline */
static inline __attribute__((always_inline))
  void spiRead(uint8_t* buf, uint16_t nbyte) {
  if (nbyte-- == 0) return;
  SPDR = 0XFF;
  for (uint16_t i = 0; i < nbyte; i++) {
    while (!(SPSR & (1 << SPIF)));
    uint8_t b = SPDR;
    SPDR = 0XFF;
    buf[i] = b;
  while (!(SPSR & (1 << SPIF)));
  buf[nbyte] = SPDR;
/** SPI send a byte */
static void spiSend(uint8_t b) {
  SPDR = b;
  while (!(SPSR & (1 << SPIF)));
/** SPI send block - only one call so force inline */
static inline __attribute__((always_inline))
  void spiSendBlock(uint8_t token, const uint8_t* buf) {
  SPDR = token;
  for (uint16_t i = 0; i < 512; i++) {
    uint8_t b = buf[i];
    while (!(SPSR & (1 << SPIF)));
    SPDR = b;
  while (!(SPSR & (1 << SPIF)));
828  Using Arduino / Storage / Re: MEGA with cardinfo.h and "LC studio" SD card reader dont work on: October 08, 2012, 07:53:00 am
This card is a SDHC card so it should work with both SdFat and SD.h libraries.

The card fails on CMD58 which checks whether the card is a standard capacity card or high capacity card and returns the Vdd range supported by the card.

The card returns a status that it is not in a ready state.  This means power on initialization has not completed correctly.

CMD58 is only used in SPI mode.  A different set of commands is used by a PC or Mac in SDIO mode.  This card may work in a PC or Mac but fail in SPI mode.

Does it always return error code 0X8 with error data 0X1?

MMC cards also fail on CMD58 but your card is clearly an SDHC card.  MMC cards often fail with error code 0X8 and error data 0X5.
829  Development / Other Hardware Development / Re: Teensy 3.0 on: October 08, 2012, 07:24:40 am
Paul has now provided SD access for Teensy 3.0 in his beta 4 release. 

This is done by very clever emulation of the AVR SPI registers.  There is also an emulation of AVR PORT and PIN registers.

Look at arduino-1.0.1/hardware/teensy/cores/teensy3/avr_emulation.h to see how this is done with C++ classes.
830  Using Arduino / Storage / Re: MEGA with cardinfo.h and "LC studio" SD card reader dont work on: October 07, 2012, 07:51:02 pm
The card is not an SD card.  It must be a MMC (MultiMediaCard) since the error code is 0X8.

SD I/O can be a bit faster with a Mega but not much.  AVR SPI is not very efficient.

I have developed a version for Cortex M processors and will release it for the Arduino Due and Teensy 3.0.  It runs much faster than the AVR version.

I will provide an option in the AVR library to speedup the Mega a little.  Very few people use the Mega and most people use Print to write text files which is very slow.  Most people use the Uno and memory is precious with this board.

I have released examples that allow writing binary data much faster.  See  This example logs binary data from an analog pin at up to 100 ksps.  It uses a special API to create contiguous files and stream data using multi-block SD write commands.
831  Using Arduino / Storage / Re: MEGA with cardinfo.h and "LC studio" SD card reader dont work on: October 07, 2012, 04:35:30 pm
Is the 64 MB card an MMC card?  Also some old cards don't comply with the SD spec.

SD.h only supports SD cards that comply with the SD standard.  Macs and Windows machines support old cards but SD.h does not since this would increase the size of the library and few people use cards produced before the standard was finalized.

Also the SD standard requires 64MB cards to be formatted FAT12.  SD.h does not support FAT12 file systems.

How did you format the cards?  If you used Mac or PC utilities, the card may be formatted with a GUID partition table instead of MBR. PCs and Macs accept GUID partition tables but SD.h does not.

The SD standard requires a MBR partition table.  The best way to format SD cards is to use SdFormatter

It would be helpful if you downloaded SdFat and ran the QuickStart and SdInfo examples and posted any error codes from these programs.  These programs are in the SdFat/examples folder.

You can also force the 64 MB card to be formatted FAT16 by using the SdFormatter example in the SdFat/examples folder.
832  Development / Other Hardware Development / Re: Teensy 3.0 on: October 07, 2012, 07:19:53 am
Maple-DMA is not very interesting.  It polls using single byte SPI reads while the card is busy then sets up DMA and polls while DMA runs. This does not save any CPU cycles or reduce the write latency.  In fact there is a huge amount of unnecessary code due to the fact that this is an old version of SdFat.

Using the Freescale Kinetis SPI fifo should be as fast or faster.  A loop to deliver 3 MB/sec to the SPI fifo for 24 MHz SPI should be easy with the Freescale Kinetis.

Improving use of cache and multi-block SD commands will produce a much larger gain than DMA.  I can already get about twice the performance of the Maple-DMA version of SdFat on a AVR Mega with these improvements.  I hope to get about another factor of three on Kinetis.

DMA could be useful with a multi-threaded RTOS.  You could then build a true driver thread with the driver sleeping while DMA ran.

I plan to port ChibiOS and FreeRTOS to Cortex boards.  ChibiOS and FreeRTOS already runs on Maple.  I plan to integrate the RTOS kernels as a library so you can use the IDE core functions and other libraries in multi-thread mode.

Unfortunately my Teensy 3.0 seems lost in the mail so I can't start testing.  I ordered two more from Adafruit so something should arrive soon.  
833  Development / Other Hardware Development / Re: Teensy 3.0 on: October 06, 2012, 05:10:00 pm
The USB port on Teensy 3.0 is capable of USB host mode.  A Micro-AB connector allows future use of USB host mode.

Initially, Teensy 3.0 will ship with only USB device support.  USB host support, integrated in the Arduino(R)** environment with easy-to-use objects, is planned as a software-only upgrade in 2013.  Programming a project using USB host mode will require a second Teensy 3.0 and a board-to-board link using the I2C pins (2 wires and ground), to provide a path for the Arduino IDE to upload code.
Teensy 3.0 uses a Micro AB connector, not a Mini connector.
834  Development / Other Hardware Development / Re: Teensy 3.0 on: October 06, 2012, 01:49:05 pm
I have this Maple version of SdFat and it doesn't use DMA.

I have examples of Kinetis SPI DMA and plan to try it but it won't help much.

SD, DMA, and SPI don't work too well together.  The problem is the SD SPI protocol.  SD cards indicate busy in SPI mode by holding MISO high so you can't just setup a DMA transfer and go away.  The protocol uses control tokens in the data stream which is a pain.

The good news is that Kinetis has a four deep FIFO on SPI so I should be able to send/receive at 24 MHz easily.  That's only 3 MB/sec.

The real winner is having an SDIO controller like high end STM32 and the Due if these pin are brought out.

I plan on LFN.  I implemented most of LFN but didn't put it in the AVR version of SdFat because flash is so precious on 328 Arduinos.
835  Development / Other Software Development / Re: New fast digital I/O and Software SPI libraries on: October 06, 2012, 10:30:36 am
Languages and other tools help but are a small factor.  This has been the holy grail for over 30 years.  I have seen numerous language/tools projects that were going to insure reliable systems. 

I expected ada to takeover embedded systems but it hasn't happened.  The problem is that ada run-time checks seldom provide needed reliability no matter what AdaCore trys to sell you.

Good architecture and design are far more important than language.  The most important factor is a skilled embedded systems team.

Look at the record of the Cal-Tech Jet Propulsion Lab  An extraordinary number of successes and few failures.

Here is the table of contents from white paper by a systems house that builds reliable financial systems.  The same ideas apply to reliable embedded systems.  This is not about tools and languages. 
Architecture Does not Just Happen
Architecture is About People
Divide and Conquer
Formalize the Interfaces
Identify and Eliminate Risk
Eliminate Dependencies
Ensure Full Testability

836  Using Arduino / Storage / Re: Micro SD example - library SD "datalogger" on: October 06, 2012, 09:22:10 am

Disabling all SPI devices except the SD is required to initialize the SD.   However this may not be the problem here since the SD library make SS an output and sets it high.  For 328 chips SS is pin 10 so the code to disable w5100 is in SD.h.  For Mega this is often the problem with initialization of the SD on the Ethernet shield.

From D:/arduino-1.0.1/libraries/SD/utility/Sd2Card.cpp at line 228.

 // SS must be in output mode even it is not chip select
  pinMode(SS_PIN, OUTPUT);
  digitalWrite(SS_PIN, HIGH); // disable any SPI device using hardware SS pin
837  Development / Other Software Development / Re: New fast digital I/O and Software SPI libraries on: October 05, 2012, 09:00:05 pm

Your right, the cost of making apps based on the Arduino core reliable is too high.  That's one reason why using Arduino to build reliable critical systems is a bad idea.

There is a large literature of studies about the overhead required for reliability in well designed critical systems.  The typical number is 5% performance and size.

I spent most of my career around large particle accelerators and space experiments.  The above percentage matches my experience with real systems.

To achieve this low overhead means putting high priority on reliability in system architecture and design.

In your example, pin number is a variable and appears in every API function.  This mean lots of range checks in libraries that present pin number as a variable in their API.

Often pin number is a constant and you could use a C++ template so no run-time checks are require.  The code will be faster and smaller than the Arduino digital I/O implementation.

If pin number must be variable you can use a C++ object with pin number appearing in only one API function with only one check.

Ways to handle errors that occur deeply in embedded systems was solved in the 1970s for large embedded systems.
838  Development / Other Hardware Development / Re: Teensy 3.0 on: October 05, 2012, 03:56:58 pm
I just started porting SdFat to Teensy 3.0 and am really pleased with Teensy 3.0.  Paul's modified IDE works well.

SdFat has about 8,500 lines of code and it took me about an hour to get it to compile.  I commented out about 100 lines of AVR SPI code.

I found SPI examples on the Freescale website and am starting implementation of SD/SPI access routines.  This should not take long.

The biggest problem is also the biggest opportunity.  With AVR everything was based on the fact that SdFat would mostly be used on 328 processors with 2KB of memory.  This really limited how caching was implemented and what SD command sequences could be used.  Now I need to redesign SD access to take advantage of more memory and processor speed.

I am starting to redesign SD access for better performance.  While waiting for the Teensy 3.0 I experimented with a Mega.  I was able to increase write speed by almost a factor of three by using more memory and multi-block SD commands.

One shock was the old SdFat first ran much slower with more memory.  This is because I had multiple blocks in the cache and user memory and was not writing them in sequential order.  This slowed the write speed from 200KB/sec on an Uno to 90 KB/sec on a Mega.  SD cards love streaming multi-block writes and die with random writes.  Writing the blocks in the correct order increased the speed for this example from 90KB/sec to over 500KB/sec.

The Teensy will have 24 MHz SPI, a faster processor, and more memory so I hope to get 5-10 times faster file write speeds than SdFat on a Uno.

ARM for Arduino is great!

I have started looking at porting ChibiOS/RT to Teensy 3.0 and it also looks easy.  I will make the RTOS a library so you can use it with Paul's core routines and other ported libraries in a multi-tasking environment.
839  Development / Other Software Development / Re: how to go to STM32 / Arm on: October 05, 2012, 08:17:08 am
I suggest you try Teensy 3.0 also

I have one and it uses the Arduino IDE with gnu ARM tools.  It's real easy to use.  You just unzip the IDE like the standard Arduino IDE.

Soon, October 22, Arduino will release the Due  I suspect it will also be easy to install and use.
840  Development / Other Software Development / Re: New fast digital I/O and Software SPI libraries on: October 05, 2012, 08:07:59 am

If you hangout here long enough, you will become one of us and reliably won't matter.  I speak from experience, my standards are slipping.

For most programmers reliably is is handled by taking out the debug checks when software is released so the code is smaller and runs faster.

Here is a quote from long ago:
Turning off dynamic semantic checks once you've finished debugging your program is like taking off your seat belt once you've left the driveway.

This quote is wrong, modern programmers don't believe in seat belts or airbags.  We are at the level of automobiles 60 years ago, there are no seat belts.

Modern programmers don't diagnose and fix bugs, they turn Bohrbugs into Heisenbugs. One way to make life better for users is to convert Bohrbugs into Heisenbugs.

This is good enough because Bohrbugs are showstoppers for users: every time the user does the same thing, he or she will encounter the same bug. With Heisenbugs, on the other hand, the bugs often go away when you run the program again. This is a perfect match for the way users already behave on the Web. If they go to a Web page and it fails to respond, they just click “refresh” and that usually solves the problem.

Here is a definition:
Jim Gray drew a distinction between two kinds of bugs. The first kind are bugs that behave predictably and repeatedly—that is, they occur every time the program encounters the same inputs and goes through the same sequence of steps. These are Bohrbugs, named for the Bohr atom, by analogy with the classical atomic model where electrons circle around the nucleus in planetary-like orbits. Bohrbugs are great when debugging a program, since they are easier to reproduce and find their root causes.

The second kind of bug is the Heisenbug, named for Heisenberg’s Uncertainty Principle and meant to connote the inherit uncertainty in quantum mechanics, which are unpredictable and cannot be reliably reproduced. The most common Heisenbugs these days are concurrency errors (a.k.a. race conditions), which depend on the order and timing of scheduling events to appear. Heisenbugs are also often sensitive to the observer effect; attempts to find the bug by inserting debugging code or running in a debugger often disrupt the sequence of events that led to the bug, making it go away.
Jim Gray wrote this in 1985 and not much has changed.
Pages: 1 ... 54 55 [56] 57 58 ... 107