Hello i am using an STM32 as the host mcu for a SI4362 radio. the radio uses SPI communication to initialize. although i am stepping through meaning i believe to be receiving correct CTS from the radio it is not working. i would like to transmit everything i send and receive from the SPI out to a UART terminal for debug.
Here is a sample of what i am sending:
uint8_t RF_POWER_UP[7] = { 0x02, 0x01, 0x01, 0x01, 0xC9, 0xC3, 0x80};
I would like to send the bytes over SPI as designated in the datasheet, and then promptly send the output over UART for debugging more easily something like this:
uart_buf_len = sprintf(uart_buf, "\r\nSPI Test\r\n");
HAL_UART_Transmit(&huart1, (uint8_t*) uart_buf, uart_buf_len, 100)
HAL_GPIO_WritePin(SDN_GPIO_Port, SDN_Pin, GPIO_PIN_RESET);
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_RESET);
HAL_SPI_Transmit(&hspi1, RF_POWER_UP, 7, 50);
//convert RF_POWER_UP to something the UART can transmit in plain text
HAL_UART_Transmit(&huart1, RF_POWER_UP, 7, 50);
do {
HAL_SPI_Receive(&hspi1, (uint8_t*) spi_buf, 1, 100);
//convert spi buf to something the UART can transmit in plain text
HAL_UART_Transmit(&huart1, (uint8_t*) spi_buf, 1, 100);
} while (*spi_buf != 0xFF);
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_SET);
so i feel that writing a function might make the most sense. i found a helpful post using memcopy, but it converted the bytes into the equivalent ascii value basically returning the equal result. i am now actively searching the correct and appropriate return value for the needed function as well as propper code inside. i just wanted to make the edits to the post in the meantime as requested.
thank you
I found some helpful tools on this stack overflow that gave me what i needed. i dont quite understand whats going on with the shifting. if someone would like to bring clarity i would appreciate that.
void btox(char *xp, const char *bb, int n) {
const char xx[] = "0123456789ABCDEF";
while (--n >= 0)
xp[n] = xx[(bb[n >> 1] >> ((1 - (n & 1)) << 2)) & 0xF];
}
from what i gather i am calling the program with a pointer to the first address of an empty string identified in main using xp and likewise the byte aray using bb. also passing the size of the array of bytes as sizeof would only pass the size of the address.
xx[] is the array containing defining characters to be used for the byte to string conversion.
so running through a while loop until n-1 >= to zero
and i start to get very lost very fast.
it is working but i don't fully understand the code.
Related
I am interfacing the BMA253 Accelerometer with STM32 Discovery Board using 4 wire SPI. I am using the CUBEMX HAL Library. As a first step, I am trying to read the CHIP ID from the sensor register 0x00. The chip which should be read is 0xFA. The following code is added in the while loop just for the purpose of verification. As SPI is a active low protocol, I have configured PIN_2 to be high by default.
uint8_t result = 0;
uint8_t address = 0x00;
while (1)
{
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_RESET);
HAL_SPI_Transmit(&hspi1, &address, 1, 100);
HAL_Delay (100);
HAL_SPI_Receive(&hspi1, &result, 1, 100);
HAL_Delay (100);
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_SET);
}
Since it is in the infinite while loop, for the first two loop cycles I am getting 0xFF in the result. Then in the next two loop cycles, I am getting the correct Chip Id which is 0xFA. Then I am getting 0xFF in the next two loop cycles and this pattern is alternating infinitely.
I am not able to understand why I am receiving 0xFF first and then 0xFA.
Could there be a problem with the delay mismatch? I feel that 100ms should be fine.
I also feel that the SPI Receive is being incorrectly implemented. I am worrying because since SPI Read is an important function in retrieving the acceleration data, this function is the key.
I request anyone to please suggest me on what to do to get it working perfectly. Any help would be highly appreciated.
Thanks in advance.
EDIT: WORKING NOW
1. Followed theSealion's suggestion to set the first bit high.
2. Additionally, I had to configure the CPOL and CPHA in the SPI Configuration to either Mode 0 or Mode 3 as per the sensor requirement.
Please try the follwoing to ready the Chip ID
#define READ_REGISTER 0x80
uint8_t result = 0;
uint8_t address = 0x00 + READ_REGISTER;
while (1)
{
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_RESET);
HAL_SPI_Transmit(&hspi1, &address, 1, 100);
HAL_SPI_Receive(&hspi1, &result, 1, 100);
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_SET);
HAL_Delay (500);
}
According to the datasheet, if you want to read a register, the MSB of the command must be 1. And you do not need any within the communication.
I am taking a shot at writing a wrapper for the S1V30120 dectalk text synthesis IC in C language using the ESP IDF. I am running into a problem in the following code.
printf("Hello world!\n");
esp_err_t ret;
spi_device_handle_t spi;
spi_bus_config_t buscfg={
.miso_io_num=PIN_NUM_MISO,
.mosi_io_num=PIN_NUM_MOSI,
.sclk_io_num=PIN_NUM_CLK,
.quadhd_io_num=-1,
.quadwp_io_num=-1
};
spi_device_interface_config_t devcfg={
.clock_speed_hz=750000,
.mode=0,
.spics_io_num=PIN_NUM_CS,
.queue_size=7
};
ret=spi_bus_initialize(HSPI_HOST, &buscfg, 1);
assert(ret==ESP_OK);
ret=spi_bus_add_device(HSPI_HOST, &devcfg, &spi);
uint8_t rec[20];
assert(ret==ESP_OK);
uint8_t cmd[] = {0xAA, 0x04, 0x00, 0x05, 0x00}; // get information command
printf("waiting for rdy");
while (gpio_get_level(PIN_NUM_RDY) == 0){};
//create 2 transactions 1 for transmitting the GET INFORMATION command
//and 1 for getting the data back from the ic
spi_transaction_t t;
spi_transaction_t r;
memset(&t, 0, sizeof(t));
t.length=5*8;
t.tx_buffer=&cmd;
r.length=20*8;
r.rx_buffer=&rec;
ret = spi_device_transmit(spi, &t);
assert( ret == ESP_OK);
ret = spi_device_transmit(spi, &r);
assert(ret == ESP_OK);
printf((char*)r.rx_data);
/* Print chip information */
printf("Restarting now.\n");
I'm pretty sure connection should be in full duplex mode and I believe that is set up correctly. the information coming back should be 20 bytes but I am getting the error
rxdata transfer > 32 bits without configured DMA
at the moment I am following 2 pieces of code that may help.
an example of using SPI in the esp idf:
https://github.com/espressif/esp-idf/blob/3276a1316f66a923ee2e75b9bd5c7f1006d160f5/examples/peripherals/spi_master/main/spi_master_example_main.c
an example of using the dectalk ic in Arduino ide:
https://electronza.com/arduino-due-s1v30120-text-speech-code/2/
the dectalk ic protocol sheet:
https://github.com/MikroElektronika/Click_TextToSpeech_S1V30120/blob/master/datasheet/S1V30120%20Protocol%20Specification.pdf
and the SPI documentation for the esp idf:
https://gitdemo.readthedocs.io/en/latest/api/peripherals/spi_master.html
the protocol sheet also says something about sending 16 bytes of 0x00 after a transaction I've never seen that before though.
I hope I was thorough enough with all this information and I thank anyone in advance who can help!
You have used "1" for DMA in the line
ret=spi_bus_initialize(HSPI_HOST, &buscfg, 1);
But as mentioned in the docs, the DMA needs to be configured.
For external PSRAM available on these boards that means something like
pvPortMallocCaps(20, MALLOC_CAP_DMA)
Without DMA only 32 bits data are possible per transaction.
There are quite a few similar questions, but none seem to have quite the same issue. I am connecting an STML4 MCU to a 6-axis sensor (LSM6DS3). I have successfully implemented everything in I2C, but would like the extra speed of SPI (and DMA, if I can get these first steps working...). So for a first step, I am trying to read the WHO_AM_I register (0x0F) of the device, which should reply with 0x69. Here is the code:
uint8_t who = 0;
// Sanity check/debugging aid should get 0x5D
who = 0x43 + 0x1A;
// Set SS low
GPIO_WritePin (GPIOB, LL_GPIO_PIN_7, GPIO_PIN_RESET);
// while tx buffer is in use, wait
while (!LL_SPI_IsActiveFlag_TXE(SPI1));
// Send READ command to the WHO_AM_I register
(SPI1->DR) = 0x8F;
// while rx buffer is in use, wait
while (!LL_SPI_IsActiveFlag_RXNE(SPI1));
// Get data off the register
who = (SPI1->DR);
// Wait for everything to wrap up before setting SS high again
while (LL_SPI_IsActiveFlag_BSY(SPI1));
// OK, now we can set SS high
GPIO_WritePin (GPIOB, LL_GPIO_PIN_7, GPIO_PIN_SET);
On the scope/analyzer, I see everything run as expected, including the sensor sending back 0x69. However, when I set a break on the other side of this code block, I see that who goes from 0 to 0x5D to 0xFF. It never reads the 0x69. I looked through other code examples and some people have a second transmit with the data set to some dummy value (usually 0xFF or 0x0), so I also tried that, but the sensor seems to get confused during the second attempt and who ends up being 0x48. I have tried every permutation of waiting for the RXNE/TXE/BSY flags that I could have, as well as many many other things to get the variable to correctly read the SPI1 data register, including reading other registers off the sensor, but all to no avail.
So then the question is, how does one correctly read values off this register?
I should also mention that I can successfully write to the device's registers. I can send the command I want, then read it back and see that it worked on the scope, even though I can never get the values assigned to a variable in code. I always get 0xFF.
I include a screen of my analyzer showing the sensor sending back 0x69 from a single read request, as well as the garbled mess it sends if I try the "dummy transmit" method.
SPI always (if the receiver is enabled) receives the data when you transfer.
This is the problem with the libraries that you do not know what is there. SPI is a lot easier to program using registers.
I assume that your data is 8bits.
You need to set the 1/4 (one byte) FIFO threshold during the SPI initialization by:
SPI1 -> CR2 |= SPI_CR2_FRXTH;
next you need to read the data from the FIFO after every write (you need also to force the compiler to use the correct size (in this case 8bits) load and store instructions):
*(volatile uint8_t *)&SPI1->DR = 0x8F; // write exactly 8 bits to the FIFO
while (!LL_SPI_IsActiveFlag_RXNE(SPI1));
dummy = *(volatile uint8_t *)&SPI-> DR;
*(volatile uint8_t *)&SPI1->DR = 0; // dummy write
while (!LL_SPI_IsActiveFlag_RXNE(SPI1));
who = *(volatile uint8_t *)&(SPI1->DR);
I do not know what is the point of using the LL libraries.
instead of
while (!LL_SPI_IsActiveFlag_RXNE(SPI1));
use registers
while (!(SPI1 -> SR & SPI_SR_RNE));
You can also wrap it into the function:
uint8_t SPI_ReadWrite8(SPI_TypeDef *spi, uint8_t data)
{
while(!(spi -> SR & SPI_SR_TXE));
*(volatile uint8_t *)&spi->DR = data;
while (!(spi -> SR & SPI_SR_RNE));
return *(volatile uint8_t *)&spi-> DR;
}
And
SPI_ReadWrite8(SPI1, 0x8f);
who = SPI_ReadWrite8(SPI1, 0);
I am working on a library for controlling the M95128-W EEPROM from an STM32 device. I have the library writing and reading back data however the first byte of each page it not as expected and seems to be fixed at 0x04.
For example I write 128 bytes across two pages starting at 0x00 address with value 0x80. When read back I get:
byte[0] = 0x04;
byte[1] = 0x80;
byte[2] = 0x80;
byte[3] = 0x80;
.......
byte[64] = 0x04;
byte[65] = 0x80;
byte[66] = 0x80;
byte[67] = 0x80;
I have debugged the SPI with a logic analyzer and confirmed the correct bytes are being sent. When using the logic analyzer on the read command the mysterios 0x04 is transmitted from the EEPROM.
Here is my code:
void FLA::write(const void* data, unsigned int dataLength, uint16_t address)
{
int pagePos = 0;
int pageCount = (dataLength + 64 - 1) / 64;
int bytePos = 0;
int startAddress = address;
while (pagePos < pageCount)
{
HAL_GPIO_WritePin(GPIOB,GPIO_PIN_2, GPIO_PIN_SET); // WP High
chipSelect();
_spi->transfer(INSTRUCTION_WREN);
chipUnselect();
uint8_t status = readRegister(INSTRUCTION_RDSR);
chipSelect();
_spi->transfer(INSTRUCTION_WRITE);
uint8_t xlow = address & 0xff;
uint8_t xhigh = (address >> 8);
_spi->transfer(xhigh); // part 1 address MSB
_spi->transfer(xlow); // part 2 address LSB
for (unsigned int i = 0; i < 64 && bytePos < dataLength; i++ )
{
uint8_t byte = ((uint8_t*)data)[bytePos];
_spi->transfer(byte);
printConsole("Wrote byte to ");
printConsoleInt(startAddress + bytePos);
printConsole("with value ");
printConsoleInt(byte);
printConsole("\n");
bytePos ++;
}
_spi->transfer(INSTRUCTION_WRDI);
chipUnselect();
HAL_GPIO_WritePin(GPIOB,GPIO_PIN_2, GPIO_PIN_RESET); //WP LOW
bool writeComplete = false;
while (writeComplete == false)
{
uint8_t status = readRegister(INSTRUCTION_RDSR);
if(status&1<<0)
{
printConsole("Waiting for write to complete....\n");
}
else
{
writeComplete = true;
printConsole("Write complete to page ");
printConsoleInt(pagePos);
printConsole("# address ");
printConsoleInt(bytePos);
printConsole("\n");
}
}
pagePos++;
address = address + 64;
}
printConsole("Finished writing all pages total bytes ");
printConsoleInt(bytePos);
printConsole("\n");
}
void FLA::read(char* returndata, unsigned int dataLength, uint16_t address)
{
chipSelect();
_spi->transfer(INSTRUCTION_READ);
uint8_t xlow = address & 0xff;
uint8_t xhigh = (address >> 8);
_spi->transfer(xhigh); // part 1 address
_spi->transfer(xlow); // part 2 address
for (unsigned int i = 0; i < dataLength; i++)
returndata[i] = _spi->transfer(0x00);
chipUnselect();
}
Any suggestion or help appreciated.
UPDATES:
I have tried writing sequentially 255 bytes increasing data to check for rollover. The results are as follows:
byte[0] = 4; // Incorrect Mystery Byte
byte[1] = 1;
byte[2] = 2;
byte[3] = 3;
.......
byte[63] = 63;
byte[64] = 4; // Incorrect Mystery Byte
byte[65] = 65;
byte[66] = 66;
.......
byte[127] = 127;
byte[128] = 4; // Incorrect Mystery Byte
byte[129} = 129;
Pattern continues. I have also tried writing just 8 bytes from address 0x00 and the same problem persists so I think we can rule out rollover.
I have tried removing the debug printConsole and it has had no effect.
Here is a SPI logic trace of the write command:
And a close up of the first byte that is not working correctly:
Code can be viewed on gitlab here:
https://gitlab.com/DanielBeyzade/stm32f107vc-home-control-master/blob/master/Src/flash.cpp
Init code of SPI can be seen here in MX_SPI_Init()
https://gitlab.com/DanielBeyzade/stm32f107vc-home-control-master/blob/master/Src/main.cpp
I have another device on the SPI bus (RFM69HW RF Module) which works as expected sending and receiving data.
The explanation was actually already given by Craig Estey in his answer. You do have a rollover. You write full page and then - without cycling the CS pin - you send INSTRUCTION_WRDI command. Guess what's the binary code of this command? If you guessed that it's 4, then you're absolutely right.
Check your code here:
chipSelect();
_spi->transfer(INSTRUCTION_WRITE);
uint8_t xlow = address & 0xff;
uint8_t xhigh = (address >> 8);
_spi->transfer(xhigh); // part 1 address MSB
_spi->transfer(xlow); // part 2 address LSB
for (unsigned int i = 0; i < 64 && bytePos < dataLength; i++ )
{
uint8_t byte = ((uint8_t*)data)[bytePos];
_spi->transfer(byte);
// ...
bytePos ++;
}
_spi->transfer(INSTRUCTION_WRDI); // <-------------- ROLLOEVER!
chipUnselect();
With these devices, each command MUST start with cycling CS. After CS goes low, the first byte is interpreted as command. All remaining bytes - until CS is cycled again - are interpreted as data. So you cannot send multiple commands in a single "block" with CS being constantly pulled low.
Another thing is that you don't need WRDI command at all - after the write instruction is terminated (by CS going high), the WEL bit is automatically reset. See page 18 of the datasheet:
The Write Enable Latch (WEL) bit, in fact, becomes reset by any of the
following events:
• Power-up
• WRDI instruction execution
• WRSR instruction completion
• WRITE instruction completion.
Caveat: I don't have a definitive solution, just some observations and suggestions [that would be too large for a comment].
From 6.6: Each time a new data byte is shifted in, the least significant bits of the internal address counter are incremented. If more bytes are sent than will fit up to the end of the page, a condition known as “roll-over” occurs. In case of roll-over, the bytes exceeding the page size are overwritten from location 0 of the same page.
So, in your write loop code, you do: for (i = 0; i < 64; i++). This is incorrect in the general case if the LSB of address (xlow) is non-zero. You'd need to do something like: for (i = xlow % 64; i < 64; i++)
In other words, you might be getting the page boundary rollover. But, you mentioned that you're using address 0x0000, so it should work, even with the code as it exists.
I might remove the print statements from the loop as they could have an effect on the serialization timing.
I might try this with an incrementing data pattern: (e.g.) 0x01,0x02,0x03,... That way, you could see which byte is rolling over [if any].
Also, try writing a single page from address zero, and write less than the full page size (i.e. less that 64 bytes) to guarantee that you're not getting rollover.
Also, from figure 13 [the timing diagram for WRITE], it looks like once you assert chip select, the ROM wants a continuous bit stream clocked precisely, so you may have a race condition where you're not providing the data at precisely the clock edge(s) needed. You may want to use the logic analyzer to verify that the data appears exactly in sync with clock edge as required (i.e. at clock rising edge)
As you've probably already noticed, offset 0 and offset 64 are getting the 0x04. So, this adds to the notion of rollover.
Or, it could be that the first data byte of each page is being written "late" and the 0x04 is a result of that.
I don't know if your output port has a SILO so you can send data as in a traditional serial I/O port or do you have to maintain precise bit-for-bit timing (which I presume the _spi->transfer would do)
Another thing to try is to write a shorter pattern (e.g. 10 bytes) starting at a non-zero address (e.g. xhigh = 0; xlow = 4) and the incrementing pattern and see how things change.
UPDATE:
From your update, it appears to be the first byte of each page [obviously].
From the exploded view of the timing, I notice SCLK is not strictly uniform. The pulse width is slightly erratic. Since the write data is sampled on the clock rising edge, this shouldn't matter. But, I wonder where this comes from. That is, is SCLK asserted/deasserted by the software (i.e. transfer) and SCLK is connected to another GPIO pin? I'd be interested in seeing the source for the transfer function [or a disassembly].
I've just looked up SPI here: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus and it answers my own question.
From that, here is a sample transfer function:
/*
* Simultaneously transmit and receive a byte on the SPI.
*
* Polarity and phase are assumed to be both 0, i.e.:
* - input data is captured on rising edge of SCLK.
* - output data is propagated on falling edge of SCLK.
*
* Returns the received byte.
*/
uint8_t SPI_transfer_byte(uint8_t byte_out)
{
uint8_t byte_in = 0;
uint8_t bit;
for (bit = 0x80; bit; bit >>= 1) {
/* Shift-out a bit to the MOSI line */
write_MOSI((byte_out & bit) ? HIGH : LOW);
/* Delay for at least the peer's setup time */
delay(SPI_SCLK_LOW_TIME);
/* Pull the clock line high */
write_SCLK(HIGH);
/* Shift-in a bit from the MISO line */
if (read_MISO() == HIGH)
byte_in |= bit;
/* Delay for at least the peer's hold time */
delay(SPI_SCLK_HIGH_TIME);
/* Pull the clock line low */
write_SCLK(LOW);
}
return byte_in;
}
So, the delay times need be at least the ones the ROM needs. Hopefully, you can verify that is the case.
But, I also notice that on the problem byte, the first bit of the data appears to lag its rising clock edge. That is, I would want the data line to be stabilized before clock rising edge.
But, that assumes CPOL=0,CPHA=1. Your ROM can be programmed for that mode or CPOL=0,CPHA=0, which is the mode used by the sample code above.
This is what I see from the timing diagram. It implies that the transfer function does CPOL=0,CPHA=0:
SCLK
__
| |
___| |___
DATA
___
/ \
/ \
This is what I originally expected (CPOL=0,CPHA=1) based on something earlier in the ROM document:
SCLK
__
| |
___| |___
DATA
___
/ \
/ \
The ROM can be configured to use either CPOL=0,CPHA=0 or CPOL=1,CPHA=1. So, you may need to configure these values to match the transfer function (or vice-versa) And, verify that the transfer function's delay times are adequate for your ROM. The SDK may do all this for you, but, since you're having trouble, double checking this may be worthwhile (e.g. See Table 18 et. al. in the ROM document).
However, since the ROM seems to respond well for most byte locations, the timing may already be adequate.
One thing you might also try. Since it's the first byte that is the problem, and here I mean first byte after the LSB address byte, the memory might need some additional [and undocumented] setup time.
So, after the transfer(xlow), add a small spin loop after that before entering the data transfer loop, to give the ROM time to set up for the write burst [or read burst].
This could be confirmed by starting xlow at a non-zero value (e.g. 3) and shortening the transfer. If the problem byte tracks xlow, that's one way to verify that the setup time may be required. You'd need to use a different data value for each test to be sure you're not just reading back a stale value from a prior test.
I'm writing and reading values on a SD card in SPI mode. The frequency for writing and reading blocks of 512 bytes is set to 10Mhz. For writing a block it takes about 5ms and timing between blocks is about 10 ms.
Is any way to improve the speed of writing?
void sd_card_write_block(uint16 blockNumber, uint8* buffer)
{
uint16 blockLow = 0;
uint16 blockHigh = 0;
uint8 dummy = 0;
uint8 result = 0;
uint8 data_block_start_byte = 0;
uint8 write_command[SD_CMD_SIZE] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
uint8 dummy_buffer[DUMMY_BUFFER_LENGTH] = {0xFF, 0xFF, 0xFF, 0xFF,0xFF, 0xFF, 0xFF, 0xFF};
uint8 i = 0;
uint8 check_response[CHECK_RESPONSE_SIZE] = {0x00, 0x00, 0x00};
uint8 check_response1[CHECK_RESPONSE_SIZE] = {0x00, 0x00, 0x00};
uint8 r1 = 0;
uint16 retry = 0;
uint8 response1 = 0;
dummy = 0xFF;
//initialize the dummy buffer to keep MOSI pin High
for(i = 0; i < DUMMY_BUFFER_LENGTH; i++)
{
dummy_buffer[i] = 0xFF;
}
//set CS pin low
spi_select_slave( &spi_master_instance, &slave, true);
//send three clock cycles with MOSI HIGH (Ncs)
spi_write_buffer_wait( &spi_master_instance, dummy_buffer, NCS_LENGTH);
//block size was set in sd_init
blockLow = ((blockNumber & 0x003F) << 9);
blockHigh = ((blockNumber & 0xFFC0) >> 7);
//send SD CMD24(WRITE_SINGLE_BLOCK) to write the data to SD card
write_command[0] = 0x58;
//high block address bits, blockHigh HIGH and LOW
write_command[1] = (blockHigh >> 0x08);
write_command[2] = (blockHigh & 0xFF);
//low block address bits, blockLow HIGH and LOW
write_command[3] = (blockLow >> 0x08);
write_command[4] = (blockLow & 0xFF);
//checksum is no longer required but send 0xFF
write_command[5] = 0xFF;
spi_write_buffer_wait( &spi_master_instance, write_command, SD_CMD_SIZE);
spi_transceive_buffer_wait( &spi_master_instance, dummy_buffer, check_response, CHECK_RESPONSE_SIZE);
//send three clock cycles with MOSI High
spi_write_buffer_wait( &spi_master_instance, dummy_buffer, DUMMY_BUFFER_LENGTH);
//set bit 0 to 0 which indicates the beginning of the data block
data_block_start_byte = DATA_BLOCK_START_TOKEN;
spi_transceive_buffer_wait( &spi_master_instance, &data_block_start_byte, &result, SD_RESPONSE_SIZE);
/*takes so long because its similar to transreceivea and it discards the rx*/
spi_write_buffer_wait( &spi_master_instance, buffer, SD_BLOCK_LENGTH);
//read the microSD card response
spi_transceive_buffer_wait( &spi_master_instance, dummy_buffer, check_response1, CHECK_RESPONSE_SIZE);
do
{
// write dummy byte
spi_transceive_buffer_wait( &spi_master_instance, &dummy, &response1, SD_RESPONSE_SIZE);
r1 = response1;
// do retry counter
retry++;
if(retry > MAX_TIMEOUT)
{
spi_select_slave( &spi_master_instance, &slave, false);
break;
}
}
while(r1 == END_OF_BLOCK_RESPONSE);
//set the CS High
spi_select_slave( &spi_master_instance, &slave, false);
}
You can't, atleast not by much. The reason being that the SPI mode itself is the bottleneck. So, you can use a few tricks here and there to get that speed up, but you really won't be benifitting much from it. I'd advise you to use SDIO if you really need that much speed (It's not as complicated as you might think). If you're using an AVR, try the xmega lineup (Don't quote me on that, I'm not quite informed in the AVR, since I use ARMs), or switch to another lineup completely.
In order to get high write speeds, you need to:
- use a faster clock
- use a wider bus
- Write larger blocks (2k or 4k) at a time
In other words, you pretty much need to use the SDIO spec.
There's also ways to begin a large sequential transaction and not end it until all the data has been received (but maybe that's in the SDIO spec and not the SPI command interface). These sort of hints tells the controller that it can prepare a large section of the flash and not commit the write buffer until it's full.
And even then, you can end up with "very long" write cycles occasionally, so you cannot rely upon an SD card to stream high speed data off in real time without buffers on your side to handle the latency blips.
You should have posted your spi_write_buffer_wait code but consider something like this:
Rearange the stuff in your actual write function where you send the data. Think about it. You have to wait until the SD Card indicates you, that the byte was written successfully. Use this "useless" wait time to prepare the next data.
/* write a single block */
for ( i = MMC_BLOCKLEN; i > 0; i-- ) {
uint8_t data = *buffer;
buffer++;
wait_till_send_done();
xmit_byte ( data );
}
wait_till_send_done();
There you prepare the byte to send and also move the pointer one byte forward before you start waiting for the SD Card to indicate its successfull writing of the previous byte.
It is also a good idea to check the generated ASM code...
If you are about to write more than 512bytes of data, consider using multiblock writes (4k blocks for example at once).
Usually SD cards have internal block sizes of more than 512bytes. So to write 512 bytes, they have to internally read for example 4k, exchange your 512bytes and write everything back... so to write more data at once is always a good idea...