Arduino Forum upgrade scheduled for Monday, October 20th, 11am-4pm (CEST). Sorry for the inconvenience!
Pages: [1]   Go Down
Author Topic: Can someone help me figure out what this loop is doing?  (Read 491 times)
0 Members and 1 Guest are viewing this topic.
Manchester, New Hampshire
Offline Offline
Edison Member
*
Karma: 4
Posts: 1371
Propmaker
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Code:
  // send CRC
  uint8_t crc = 0XFF;
  if (cmd == CMD0) crc = 0X95; // correct crc for CMD0 with arg 0
  if (cmd == CMD8) crc = 0X87; // correct crc for CMD8 with arg 0X1AA
  spiSend(crc);
 
  // wait for response
  for (uint8_t retry = 0; ((r1 = spiRec()) & 0X80) && retry != 0XFF; retry++);

The bit there where it waits for a response is confusing me. 

If I understand this correctly, a byte is read from the SD card into R1.  R1 is then ANDed with 0x80.  So it appears to be looking to see if a particular bit is set in the reply.  If no bit is set, then that side of the equation evaluates to false.

Then retry is compared to 0xFF.  If it isn't 0xFF, then it evaluates to true, and the loop continues.  This makes sense.  It's trying 255 times to get the response its looking for.

But it's the first part that doesn't make sense to me.  If it's waiting for a response from the card, why does it continue only if a particular bit is not set?  Wouldn't a card that is not responding return 0?  And wouldn't 0 & 0x80 evaluate to false, and cause the loop to exit prematurely?

Logged

Copenhagen, Denmark
Offline Offline
Edison Member
*
Karma: 33
Posts: 1228
Have you testrun your INO file today?
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

A loop finishes on a false in the test condition. So it is looping until either 0x80 bit is false or it has tried 255 times. (As the && will be false if either term is false.)
Logged

Sydney, Australia
Offline Offline
Edison Member
*
Karma: 33
Posts: 1288
Big things come in large packages
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Wouldn't a card that is not responding return 0?

Not necessarily. It depends on the specification for the card. It could also be that the programmer wanted to make sure that he was looking for the top bit and not just a non-zero value, which could be noise on the comms line, for example.
« Last Edit: January 07, 2013, 02:24:08 pm by marco_c » Logged

Arduino libraries http://arduinocode.codeplex.com
Parola hardware & library http://parola.codeplex.com

Leeds, UK
Offline Offline
Edison Member
*
Karma: 80
Posts: 1733
Once the magic blue smoke is released, it won't go back in!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

If the card did return 0, then you would get:

0x00 & 0x80 = 0 = false, which means the loop would be broken.
Logged

~Tom~

Manchester, New Hampshire
Offline Offline
Edison Member
*
Karma: 4
Posts: 1371
Propmaker
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

If the card did return 0, then you would get:

0x00 & 0x80 = 0 = false, which means the loop would be broken.

That's why I'm asking.  I would expect the card to return 0 if it's not responding.  But maybe it returns 0xFF instead, until it responds, and then it responds with that particular bit not being set. 

Anyway I guess this code was not what was broken because I found the issue elsewhere. 
Logged

Global Moderator
Netherlands
Offline Offline
Shannon Member
*****
Karma: 234
Posts: 14296
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

0xFF is also -1  a very common error value ...
Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Manchester, New Hampshire
Offline Offline
Edison Member
*
Karma: 4
Posts: 1371
Propmaker
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Well I was thinking more along the lines of the data line just being stuck high while the card isn't responding.
Logged

Pages: [1]   Go Up
Arduino Forum upgrade scheduled for Monday, October 20th, 11am-4pm (CEST). Sorry for the inconvenience!
Jump to: