Show Posts
Pages: 1 ... 54 55 [56] 57 58 ... 107
826  Using Arduino / Storage / Re: MEGA with cardinfo.h and "LC studio" SD card reader dont work on: October 08, 2012, 02:43:58 pm
A new card seems like a good idea.   

I worry that the problem may be noise on the SPI bus.  There are often SPI problems with modules like the LC Studio.  Most reliable modules have a 5V to 3.3V level shifter based on a buffer chip.   Level shifters based on resistors and diodes work poorly with some cards.

Some cards use edge detectors and the sharp signals of a buffer chip work better.

If you new card does not fix the problem, make sure the SPI wires are as short as possible.
827  Development / Other Hardware Development / Re: Teensy 3.0 on: October 08, 2012, 12:32:31 pm
Sorry, I forgot to mention the packed attribute. for FAT structs.

I replaced the name fpos_t with FatPos_t

I had problems with types like uint16_t in extractors and inserters so I changed them to C types int, long...

The diff file that makes SdFat compile is:
Code:
diff -rb ArduinoOldVer/SdFat/SdBaseFile.cpp Arduino/libraries/SdFat/SdBaseFile.cpp
335c335
< void SdBaseFile::getpos(fpos_t* pos) {
---
> void SdBaseFile::getpos(FatPos_t* pos) {
1110c1110
<   fpos_t pos;
---
>   FatPos_t pos;
1794c1794
< void SdBaseFile::setpos(fpos_t* pos) {
---
> void SdBaseFile::setpos(FatPos_t* pos) {
diff -rb ArduinoOldVer/SdFat/SdBaseFile.h Arduino/libraries/SdFat/SdBaseFile.h
32c32
<  * \struct fpos_t
---
>  * \struct FatPos_t
36c36
< struct fpos_t {
---
> struct FatPos_t {
41c41
<   fpos_t() : position(0), cluster(0) {}
---
>   FatPos_t() : position(0), cluster(0) {}
201c201
<   void getpos(fpos_t* pos);
---
>   void getpos(FatPos_t* pos);
205c205
<   void setpos(fpos_t* pos);
---
>   void setpos(FatPos_t* pos);
diff -rb ArduinoOldVer/SdFat/SdStream.h Arduino/libraries/SdFat/SdStream.h
122c122
<   void getpos(fpos_t* pos) {SdBaseFile::getpos(pos);}
---
>   void getpos(FatPos_t* pos) {SdBaseFile::getpos(pos);}
138c138
<   void setpos(fpos_t* pos) {SdBaseFile::setpos(pos);}
---
>   void setpos(FatPos_t* pos) {SdBaseFile::setpos(pos);}
185c185
<   void getpos(fpos_t* pos) {SdBaseFile::getpos(pos);}
---
>   void getpos(FatPos_t* pos) {SdBaseFile::getpos(pos);}
193c193
<   void setpos(fpos_t* pos) {SdBaseFile::setpos(pos);}
---
>   void setpos(FatPos_t* pos) {SdBaseFile::setpos(pos);}
diff -rb ArduinoOldVer/SdFat/bufstream.h Arduino/libraries/SdFat/bufstream.h
61c61
<   void getpos(fpos_t *pos) {
---
>   void getpos(FatPos_t *pos) {
72c72
<   void setpos(fpos_t *pos) {
---
>   void setpos(FatPos_t *pos) {
diff -rb ArduinoOldVer/SdFat/istream.cpp Arduino/libraries/SdFat/istream.cpp
70c70
<   fpos_t pos;
---
>   FatPos_t pos;
143c143
<   fpos_t endPos;
---
>   FatPos_t endPos;
231c231
<   fpos_t pos;
---
>   FatPos_t pos;
264c264
<   fpos_t endPos;
---
>   FatPos_t endPos;
323c323
<   fpos_t pos;
---
>   FatPos_t pos;
384c384
<   fpos_t pos;
---
>   FatPos_t pos;
407c407
<   fpos_t pos;
---
>   FatPos_t pos;
diff -rb ArduinoOldVer/SdFat/istream.h Arduino/libraries/SdFat/istream.h
138a139
>
144c145
<   istream &operator>>(int16_t& arg) {
---
>   istream &operator>>(int& arg) {
153c154
<   istream &operator>>(uint16_t& arg) {
---
>   istream &operator>>(unsigned int& arg) {
162c163
<   istream &operator>>(int32_t& arg) {
---
>   istream &operator>>(long& arg) {
171c172
<   istream &operator>>(uint32_t& arg) {
---
>   istream &operator>>(unsigned long& arg) {
256c257
<   int16_t getch(fpos_t* pos) {
---
>   int16_t getch(FatPos_t* pos) {
264c265
<   virtual void getpos(fpos_t* pos) = 0;
---
>   virtual void getpos(FatPos_t* pos) = 0;
271c272
<   virtual void setpos(fpos_t* pos) = 0;
---
>   virtual void setpos(FatPos_t* pos) = 0;
diff -rb ArduinoOldVer/SdFat/ostream.cpp Arduino/libraries/SdFat/ostream.cpp
158a159,160
>   putStr(str);
>   /*
164a167
>   */
diff -rb ArduinoOldVer/SdFat/ostream.h Arduino/libraries/SdFat/ostream.h
137c137
<   ostream &operator<< (int16_t arg) {
---
>   ostream &operator<< (int arg) {
145c145
<   ostream &operator<< (uint16_t arg) {
---
>   ostream &operator<< (unsigned int arg) {
153c153
<   ostream &operator<< (int32_t arg) {
---
>   ostream &operator<< (long arg) {
161c161
<   ostream &operator<< (uint32_t arg) {
---
>   ostream &operator<< (unsigned long arg) {

I suggest you try the bench example.  Remove this line to get it to compile:
Code:
  cout << pstr("Free RAM: ") << FreeRam() << endl;
828  Development / Other Hardware Development / Re: Teensy 3.0 on: October 08, 2012, 09:45:14 am
This beta of SdFat uses the above functions: SdFatBeta20120825.zip http://code.google.com/p/beta-lib/downloads/list.

The functions are at the top of Sd2Card.cpp

It also has the following function to initialize AVR SPI pins:
Code:
/**
 * 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
#if SET_SPI_SS_HIGH
  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.
829  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.
Code:
//------------------------------------------------------------------------------
/**
 * 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)));
}
830  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.
831  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.
832  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 AnalogIsrLogger20120810.zip http://code.google.com/p/beta-lib/downloads/list.  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.
833  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 https://www.sdcard.org/downloads/formatter_3/.

It would be helpful if you downloaded SdFat http://code.google.com/p/sdfatlib/downloads/list 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.
834  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.  
835  Development / Other Hardware Development / Re: Teensy 3.0 on: October 06, 2012, 05:10:00 pm
Quote
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.
836  Development / Other Hardware Development / Re: Teensy 3.0 on: October 06, 2012, 01:49:05 pm
I have this Maple version of SdFat http://code.google.com/p/maple-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.
837  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 http://www.jpl.nasa.gov/missions/.  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. 
Quote
Architecture Does not Just Happen
Architecture is About People
Divide and Conquer
Formalize the Interfaces
Identify and Eliminate Risk
Eliminate Dependencies
Ensure Full Testability
http://www.imatix.com/articles:how-to-build-utterly-reliable-systems

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

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.

Code:
 // 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
839  Development / Other Software Development / Re: New fast digital I/O and Software SPI libraries on: October 05, 2012, 09:00:05 pm
westfw,

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.
840  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.
Pages: 1 ... 54 55 [56] 57 58 ... 107