Очень медленная запись SPI в STM32

Мне очень нравится, как вы разбиваете свой код на три фрагмента. Могу предложить улучшения для каждого из них:

switch_library_number_1 ():

• Это может быть просто 2D-массив, number[][], или, если number_0, _3 _... имеют разную длину, это может быть массив указателей на них. Потребуются проверки на действительные num и offset. Это может быть незначительное улучшение скорости.
• Ваши массивы _6 _... в настоящее время находятся в стеке и доступны для чтения и записи. Сделайте их const, чтобы они не использовали оперативную память.
• В настоящее время вы возвращаете указатель на ячейку памяти в стеке - обычно это не работает, если это происходит случайно или случайно. Вам не следует обращаться к данным стека, когда вы находитесь вне области действия (функции), в которой они были определены. static const сделает это безопасным, поскольку его больше не будет в стеке.

основной цикл:

• Немного странно вызывать switch_library_number_1/2 на каждой итерации цикла. Вы знаете, что ваши данные будут просто в массиве. Его, вероятно, можно было бы заменить на write_spi(number[0][i]);, если number массив правильно настроен. Это должно дать вам некоторое улучшение скорости, так как это очень упрощает выборку данных.
• Кажется, у вас есть цикл занятости. Это непростая практика (держу пари, 100 - предположение, и обратите внимание, что компилятор может оптимизировать этот цикл). Если возможно, используйте функцию задержки, предоставленную библиотекой, или таймер, чтобы получить точные задержки. Это реальное требование подчиненного устройства SPI?

write_spi (символьные данные):

• char должно быть unsigned char здесь. chars могут быть подписаны или беззнаковые, поэтому, когда вы используете их как байты (а не фактические строковые символы), вы должны указать подпись.
• Кажется, вы ждете завершения передачи каждого байта, что безопасно, но немного медленно. Обычно это можно переписать в более быструю альтернативу wait_for_SPI_ready_for_TX; SPI_TX, где вы только ждете перед отправкой следующего байта. Обратите внимание, что вам также нужно будет дождаться полной передачи байта, прежде чем снова вернуть CS на высокий уровень. Это могло бы значительно улучшить скорость.

Еще кое-что, что следует учитывать:

• Каковы фактические часы SPI? Если увеличить тактовую частоту, может произойти огромное улучшение скорости.
• Как вы измерили это как "медленное"? Указывает ли он на медленные части кода (что это тогда? Если это не очевидно из C, то для чего они собраны?)
• У вас есть осциллограф / логический анализатор для просмотра реальных сигналов по проводам? Это может предоставить полезные данные.

У меня была аналогичная проблема с контроллером Cortex-M3 серии STM32F207, когда я наблюдал за линией TX через Oscillator, я увидел, что отключение CHIP_SELECT занимало слишком много времени для установки после того, как все данные были отправлены. Я понял, что это связано с управление флагами Итак, я немного поиграю с флагами управления. Вот как это сработало для меня;

static void SPI_Send(uint16_t len,uint8_t* data)
{
   uint16_t i;

   for(i = 0;i<len;i++)
   {        
     SPI_I2S_SendData(SPI1,*(data+i));
     while(!(SPI1->SR & SPI_SR_TXE));   
   }    
   while(SPI1->SR & SPI_SR_BSY);
   CHIP_SEL_DISABLE;
}

Я считаю, что это медленно, потому что вы также проверяете, что буфер приема не пуст, где вам не нужно.