your fish scale if you have a big motor.
That is the math you would use to choose your motors.
This will get you close to what you need for success.
Gordon McComb (of Robot Builders Bonanza fame) shared
his secret for success: the heft method. He would look at
his robot frame, pick up a motor, and hold it to gauge its
heft to determine its suitability. I myself do not have
Gordon’s calibrated arm, so I tend to do a little math.
Q. I want to store way-points and sensor data during a robot’s run-time. This really adds up and is way more than most EEPROMs I’ve seen can do.
I’ve been trying to get an SD card to work using an SPI
interface, but it just isn’t working. I can’t initialize the card.
How does this work?
Listing 1: SD Card Initialization.
— Thomas Q.
Boise, ID
uint8_t SD_Write(uint8_t b)
/**
Read and write a single 8-bit word to
the SD/MMC card. Using standard, non-buffered
mode in 8 bit words.
**Always check SPI1RBF bit before reading
the SPI2BUF register
**SPI1BUF is read and/or written to
receive/send data
*
PRECONDITION: SPI bus configured, SD card
selected and ready.
INPUTS: b = byte to transmit (or dummy
byte if only a read done)
OUTPUTS: none
RETURNS:
*/
{
SPI1BUF = b;
// write to buffer for TX
while( !SPI1STATbits.SPIRBF);
// wait for transfer to complete
SPI2STATbits.SPIROV = 0;
// clear any overflow.A. I have been fascinated with SD cards for a variety of reasons, and this gives me a great reason to work with them. I am currently having fun with Microchip
PIC24 devices and so used one of their demo boards with
an SD PICtail card for experimenting. The target hardware
isn’t all that important, so my code should work with
anyone’s microcontroller; just change how you deal with
the SPI hardware to get your required clock rates. An SD
card can take SPI clocks of 20 to 50 MHz, so there is no
issue about going too fast. As it happens, my 32 MHz
PIC24FJ64 part can only go 8 MHz, but that gave me pretty
good transfer rates (compared to serial ports, anyway) and I
was happy. The secret to success is to start out at a clock
rate of 400 kHz until the card is up and listening, then
move to the high speed clock. To fully understand the
interface — which is pretty simple — and the protocol —
which is slightly less simple, check out this site and get the
SD Association Simplified Specs: www.sdcard.org/dev.../
pls/simplified_specs.
}
This site took me a long way towards getting my SD cards
to work: http://elm-chan.org/docs/mmc/mmc_e.html.
There is a raft of information out on the net for
handling the reading and writing of data blocks to the SD
card, so that part was easy. The big thing to know is that
the SD card wants the block address in bytes, on 512 byte
boundaries; the SDHC card has a much higher capacity and
wants its block addressing done where each block is 512
bytes. My initialization code shown here takes this into
account by storing the attributes of the SD or SDHC card
being used so that the read/write routines know which
type of block addressing to use. Many thanks to the
pioneers of SD card usage that helped me with this work!
I have given my various routines here, but did not
bother with the actual block read and writes. I’ll leave that
as an exercise for the reader. If anyone is interested, you
can send me an email (see end of article) and I’ll do a more
detailed write-up.
There are a lot of constants in Listing 1. They refer to
various values for commands, which are pretty obvious
when you look at the specifications for SD commands. I
16 SERVO 09.2011
return SPI1BUF;
// read the received value
// Not worth code defining these since
// they are all the same.
#define SD_Read() SD_Write( 0xFF)
#define SD_Clock() SD_Write( 0xFF)
#define SD_Disable() nMEM_CS = 1; SD_Clock()
#define SD_Enable() nMEM_CS = 0
uint8_t SD_SendCmd(uint8_t cmd, LBA addr)
/**
* Send an SPI mode command to the SD card.
*
* PRECONDITION: SD card powered up, CRC7
* table initialized.
* INPUTS: cmd = SPI mode command to send
* addr= 32bit address
* OUTPUTS: none
* RETURNS: status read back from SD card (0xFF
* is fault)
* NOTE nMEM_CS is still low when this
* function exits.
*
* expected return responses:
* FF - timeout
* 00 - command accepted
* 01 - command received, card in idle state
* after RESET
*
* R1 response codes:
* bit 0 = Idle state
* bit 1 = Erase Reset
* bit 2 = Illegal command
* bit 3 = Communication CRC error
* bit 4 = Erase sequence error
* bit 5 = Address error
* bit 6 = Parameter error
* bit 7 = Always 0
*/
{
uint16_t n;
uint8_t res;
uint8_t byte;
uint8_t CRC7 = 0x95;
// Generic CRC7 byte
SD_Enable();
// enable SD card
