stm32 SPI, коннект между двумя чипами от st по spi Опции

[Connor]

Есть две борды борда 1(Б1) (stm32f407vgt) и борда 2(Б2) (stm32f303vet), между которыми необходимо обеспечить связь по SPI, вот настройка SPI для Б1 и Б2:
Б1 (Slave):

CODE

/* SPI2 De Initialization */
SPI_I2S_DeInit(SPI2);

/* SPI2 configuration */
SPI_InitTypeDef SPI2_InitStructure;

SPI2_InitStructure.SPI_Mode = SPI_Mode_Slave;
SPI2_InitStructure.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
SPI2_InitStructure.SPI_DataSize = SPI_DataSize_16b;
SPI2_InitStructure.SPI_CPOL = SPI_CPOL_Low;
SPI2_InitStructure.SPI_CPHA = SPI_CPHA_1Edge;
SPI2_InitStructure.SPI_NSS = SPI_NSS_Soft;
SPI2_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB;
SPI2_InitStructure.SPI_CRCPolynomial = 7;
SPI2_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_4;

SPI_Init(SPI2, &SPI2_InitStructure);

/* FIFO threshold */
SPI_RxFIFOThresholdConfig(SPI2, SPI_RxFIFOThreshold_HF);

/* Interrupt handler priority */
NVIC_InitTypeDef NVIC_SPI2_InitStructure;

NVIC_SPI2_InitStructure.NVIC_IRQChannel = SPI2_IRQn;
NVIC_SPI2_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_SPI2_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_SPI2_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_SPI2_InitStructure);

/* RXNE interrupt enable */
NVIC_EnableIRQ(SPI2_IRQn);
SPI_I2S_ITConfig(SPI2, SPI_I2S_IT_RXNE, ENABLE);

/* Enable DMA Tx requests */
SPI_I2S_DMACmd(SPI2, SPI_I2S_DMAReq_Tx, ENABLE);

/* Enable SPI2 */
SPI_Cmd(SPI2, ENABLE);

Б2(Master):

CODE

/*SPI3 configuration structure*/
SPI_InitTypeDef SPI3_InitStructure;

/*Default parameters*/
SPI_StructInit(&SPI3_InitStructure);

/*Configure SPI3*/
SPI3_InitStructure.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
SPI3_InitStructure.SPI_Mode = SPI_Mode_Master;
SPI3_InitStructure.SPI_DataSize = SPI_DataSize_16b;
SPI3_InitStructure.SPI_CPOL = SPI_CPOL_Low;
SPI3_InitStructure.SPI_CPHA = SPI_CPHA_1Edge;
SPI3_InitStructure.SPI_NSS = SPI_NSS_Soft;
SPI3_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_64;
SPI3_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB;
SPI3_InitStructure.SPI_CRCPolynomial = 7;

SPI_Init(SPI3, &SPI3_InitStructure);

/*Enable SPI3*/
SPI_Cmd(SPI3, ENABLE);

между ними необходимо передавать данные нижеописанным образом:
1. Б2, который мастер, шлёт 16-битный флаг SPI_FLAG (0x0001);
2. Срабатывает прерывание по RXNE в Б1, Б1 читает принятую посылку, сравнивает с нужным значением и включает DMA_Stream, который запускает передачу данных в Б2

Код

void SPI2_IRQHandler()
{
    SPI_FLAG = SPI_I2S_ReceiveData16(SPI2);
    
    if(SPI_FLAG == 0x0001)
    {
         DMA_Cmd(DMA1_Channel5, ENABLE);
    }
}

Частота на шине APB1, где находится SPI3 Мастера 32MГц, с baudrateprescaler = 64 частота обмена 500Кбит/c .

Теперь о проблемах, SPI_FLAG слэйвом я принимаю, а вот данные отправить ни как не получается, только если напрямую в коде где-то написать SPI_I2S_SendData, т.е. из прерывания я не могу отправить данные даже таким способом. Может я неправильно понимаю работу SPI? Подскажите пожалуйста в чём может быть проблема.

Лично я грешу на софтовый NSS, я так понимаю при отправке данных слэйвом мастеру, мастер не генерит SCK, может ли помочь решить проблему использование хардварного NSS? Спасибо

Сообщение отредактировал IgorKossak - Apr 21 2018, 18:52

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!

[AlanDrakes]

Частота обмена ВСЕГДА зависит от частоты мастера.
Ведомый кристалл только выставляет соответствующий уровень на пине MISO в момент(ы) смены тактового сигнала SCK.
Необходимое условие - частота обмена не более четверти тактовой частоты ведомого чипа. Заметьте, тактовой частоты его периферии.
Приведу пример:
Мастер: 8МГц. Ведомый: 8МГц.
SPI мастера тактируется от внутренней частоты с делителем /2. Результатирующая - 4МГц (внутренняя) и 2МГц (максимальная частота на пине SCK (здесь я имею в виду полную смену тактового сигнала 0-1-0)).
SPI ведомого тактируется от внутренней шины с делителем /4. Результатирующая - 2МГц (вроди бы, совпадает с внешней), но максимальная внешняя - 1МГц (тот же полный импульс 0-1-0).
Так что, мастер должен дёргать пином минимум в 2 раза медленнее.

500кБод - вполне достаточно 1МГц на шине. На шине ведомого. Ну и мастер должен с этой частотой данные читать.

[Connor]

Частота обмена ВСЕГДА зависит от частоты мастера.
Ведомый кристалл только выставляет соответствующий уровень на пине MISO в момент(ы) смены тактового сигнала SCK.
Необходимое условие - частота обмена не более четверти тактовой частоты ведомого чипа. Заметьте, тактовой частоты его периферии.
Приведу пример:
Мастер: 8МГц. Ведомый: 8МГц.
SPI мастера тактируется от внутренней частоты с делителем /2. Результатирующая - 4МГц (внутренняя) и 2МГц (максимальная частота на пине SCK (здесь я имею в виду полную смену тактового сигнала 0-1-0)).
SPI ведомого тактируется от внутренней шины с делителем /4. Результатирующая - 2МГц (вроди бы, совпадает с внешней), но максимальная внешняя - 1МГц (тот же полный импульс 0-1-0).
Так что, мастер должен дёргать пином минимум в 2 раза медленнее.

500кБод - вполне достаточно 1МГц на шине. На шине ведомого. Ну и мастер должен с этой частотой данные читать.

Спасибо, это действительно логично

Используйте стандартные методы.
Если слейв должен возвратить "быстрые" данные (например выборка параметра из RAM) то для этого таймауты не нужны и все можно
"прокрутить" в одном запрос-ответе.
Если же нужна задержка на подготовку данных (например отработка ADC) то это делается "наразвес", несколькими командами
1. Старт АЦП в слейве. 2. опрос регистра статуса слейва готовности данных АЦП. 3. Чтение слейва - данных АЦП.

В том и проблема, что именно в такой системе как реализовано у меня, АЦП конвертируют данные, DMA записывает их в буфер, который копируется ещё в один (на отправку мастеру), по приходу флага копирование данных в этот буфер прекращается и я отправляю этот буфер мастеру, но как я уже говорил, флаг у меня приходит, срабатывает прерывания, на слэйве запускается DMA по Rx запросу, но чтобы мастер начал читать адекватные данные, когда я начинаю слать слэйву "мусор", нужно выждать что-то около 500мс, что очень плохо, потому что обновлять данные я должен несколько раз в секунду, поэтому решением этой ситуации, как мне подсказали выше, это реализовать просто обмен по DMA без всяких флагов, что я уже сделал и что гораздо проще в итоге

Сообщение отредактировал Connor - Apr 25 2018, 06:15

[k155la3]

. . . .начинаю слать слэйву "мусор", нужно выждать что-то около 500мс, что очень плохо, . . .

Если сделаете аппаратную синхронизацию по времени цикла 1с по всей системе (например от мастера),
то проблемы с таймаутами и готовностью-неготовностью можете "разрулить" с использованием таймеров.
(не будет необходимости ожидания или контроля отработки для асинхронных событий между мастером и слейвом).
Например, мастер на такте 0 таймера дает команду слейву на старт АЦП. Время работі АЦП, скажем, 500 мс.
Соответственно, мастер дает команду опроса слейву на 520-ом такте, а слейв заботится о том, чтобы эти данные и все подготовительные операции
к 520-му такту у него были закончены.

[AVI-crak]

Если сделаете аппаратную синхронизацию по времени цикла 1с по всей системе (например от мастера),
то проблемы с таймаутами и готовностью-неготовностью можете "разрулить" с использованием таймеров.

Плавали, знаем...
Всё это будет работать до очередной хотелки клиента. После чего придётся переписывать почти весь проект, причём на оба чипа, и почти с нуля. Мне лень убеждать, но посмотреть со стороны всегда приятно.
И всё-же: разделяйте уровень железа и программной части, уровень интерфейса и протокола пакетной связи, а также разумно используйте абстракции данных на уровне приложения (алгоритма). При использовании подобного разделения - ваш проект можно масштабировать практически бесконечно (в разумных пределах), а так-же использовать части и даже целые куски в новых проектах - без подгонки напильником.

Реальный пример существующего проекта.
На ПП несколько чипов, в том числе и слабенький st для работы с сенсорным экраном (не я придумывал). Изначально алгоритм этого чипа был очень простым: получить координаты нажатия экрана, и в режиме слейва отдать главному чипу. Потом ему добавили работы в определении нажатия иконок - протокол связи стал намного сложнее и обрёл множество садового инструментария. Количество изменений в проекте между этими двумя точками - просто безумное. Переписывалось даже то, что имеет лишь косвенное влияние. А потом хозяин проекта узнал что существуют готовые железные контролёры сенсорных экранов, в которых эти функции реализованы изначально. Такого количества подстановок я не встречал даже у индусов. Количество изменений равнялось общему объёму проекта. Поле чего автор проекта решил пристрелить больное бешенством животное, и начать с нового листа. И с первых строчек прострелил себе ногу в трёх местах.

Я к тому что уровень адруино не лечится, если уже заразились - то постарайтесь не распространять заразу.

[k155la3]

Плавали, знаем...

Все понятно, кроме одного, зачем процитирован мой пост.
Если процитирован, то замечания по сути.
ps
Используя метод психоанализа я, кажется, понял в чем причина В терминах и их применении.

[AVI-crak]

Если процитирован, то замечания по сути.

Всё очень просто. Использование предсказания поведения внешней системы с использованием таймера - намного уменьшает гибкость общего алгоритма. То-есть если-бы внешней системой было железо, механика или нечто подобное - то реализация предсказаний оправдывается. Но в связке двух процессоров - это наличие недостатка в алгоритме.

[Alechek]

Но в связке двух процессоров - это наличие недостатка в алгоритме.

Делаю связку из нескольких процессоров с ипользованием half-duplex SPI (1 линия приема-передачи)
Вот тут без жесткого тайминга никак.... Вовремя надо направление переключить - мастер-приемник-то шпарит постоянно.