нет, но меня жаба душит, когда за доставку надо отдать столько же сколько товар стоит.

бывает... закупи ещё чего-нить полезного

STM32F2xx_StdPeriph_Lib_V1.1.0/Project/STM32F2xx_StdPeriph_Examples/SPI/SPI_TwoBoards/DataExchangeInterrupt/

Нет двунаправленности, там один только передает, другой только принимает: void SPIx_IRQHANDLER(void) { #ifdef SPI_SLAVE if (SPI_I2S_GetITStatus(SPIx, SPI_I2S_IT_RXNE) == SET) RxBuffer[Rx_Idx++] = SPI_I2S_ReceiveData(SPIx); #endif #ifdef SPI_MASTER if (SPI_I2S_GetITStatus(SPIx, SPI_I2S_IT_TXE) == SET) { if (CmdStatus == 0x00) { SPI_I2S_SendData(SPIx, CmdTransmitted); CmdStatus = 0x01; } else { if (Tx_Idx < GetVar_NbrOfData()) { SPI_I2S_SendData(SPIx, TxBuffer[Tx_Idx++]); } else { SPI_I2S_ITConfig(SPIx, SPI_I2S_IT_TXE, DISABLE); } } } #endif /* SPI_SLAVE */ }

https://github.com/MaJerle

объем внушает, но там нет работы c SPI на прерываниях

void SendData (uint8_t * data, size_t size) { for(size_t i = 0; i < size; i++) { SPI_I2S_SendData(FLASH_SPI, data[i]); while( SPI_I2S_GetFlagStatus(FLASH_SPI, SPI_I2S_FLAG_TXE) != SET ); while( SPI_I2S_GetFlagStatus(FLASH_SPI, SPI_I2S_FLAG_RXNE) != SET ); SPI_I2S_ReceiveData(FLASH_SPI); // Считать данные в холостую } } void ReceiveData (uint8_t * data, size_t size) { for(size_t i = 0; i < size; i++) { SPI_I2S_SendData(FLASH_SPI, 0x55); // Отправить данные в холостую while( SPI_I2S_GetFlagStatus(FLASH_SPI, SPI_I2S_FLAG_TXE) != SET ); while( SPI_I2S_GetFlagStatus(FLASH_SPI, SPI_I2S_FLAG_RXNE) != SET ); data[i] = SPI_I2S_ReceiveData(FLASH_SPI); } }

где тут прерывания используются?

Есть из Челябинска? Надо сделать заказ в Элитане, а сумма заказа не большая. Кто-нибудь хочет присоедениться?

Я из Че, но в Элитане ничего не надо :)

обычно эта экономия выходит геморроем

где тут прерывания используются?

затупил

Когда до реализации I2C без блокировки на прерываниях и очередью на отправку и приём дойдете, позовёте, ок?

а на stm32 с ней что-то сложное?

Нет двунаправленности, там один только передает, другой только принимает: void SPIx_IRQHANDLER(void) { #ifdef SPI_SLAVE if (SPI_I2S_GetITStatus(SPIx, SPI_I2S_IT_RXNE) == SET) RxBuffer[Rx_Idx++] = SPI_I2S_ReceiveData(SPIx); #endif #ifdef SPI_MASTER if (SPI_I2S_GetITStatus(SPIx, SPI_I2S_IT_TXE) == SET) { if (CmdStatus == 0x00) { SPI_I2S_SendData(SPIx, CmdTransmitted); CmdStatus = 0x01; } else { if (Tx_Idx < GetVar_NbrOfData()) { SPI_I2S_SendData(SPIx, TxBuffer[Tx_Idx++]); } else { SPI_I2S_ITConfig(SPIx, SPI_I2S_IT_TXE, DISABLE); } } } #endif /* SPI_SLAVE */ }

А ифы на два разбить нельзя?

а на stm32 с ней что-то сложное?

Конечный автомат писать лениво,

А найти его реализацию не получилось, в итоге нужно еще будет, что то вроде менеджера сообщений

С I2c на прерываниях вообще как-то тихо, только с блокировкой, а такое на марс не отправишь

я для avr такое делал, всякие htu21 и bme280 опрашивать

надо будет на stm32 попробовать повторить

я для avr такое делал, всякие htu21 и bme280 опрашивать

Да и у меня какое-то не доверие к железному I2C у стм после знакомства с это шиной на stm32f103

надо будет на stm32 попробовать повторить

Полноценной шине на прерываниях с обработкой ошибок цены не будет, в инете ничего стоющего нет

Да и у меня какое-то не доверие к железному I2C у стм после знакомства с это шиной на stm32f103

я на 103-ем только и работал, пашет как часы

стандартные страдания получение данных по запросу через SPI детектед. Стандартное решение #1: дополнительный провод от слейва к мастеру для сигнала готовности данных. Стандартное решение #2: опрос слейва после таймааута гарантированной готовности данных. Стандартное решение #3: Поллинг слейва на предмет готовности данных. Стандартный вариант #4: Использование другого интерфейса - I2C, UART etc.

SPI - это боль для двунаправленного обмена. Например SD карты в режиме SPI да и SDIO только поллингом

я на 103-ем только и работал, пашет как часы

С этим не спорю, но трудности в ack nack у шины возникали

i2c на стм32ф1 серии имеет косяки для передачи 1 и 2 байт. все посылки что длиннее 2х байт аппаратно работают на ура. в ф0, ф3 и ф4 всё уже пофиксено и работает нормально

на ф1 с учетом особенностей тоже работает I2C вполне надежно - например часы, епром и датчик температуры на одной шине пашут и не тупят вполне

вообще на любых камнях нормально делать проверку на зависание и2ц по таймауту и ресетить шину ногодрыгом как описано в стандарте

т. к. зависают не только МК но и периферия вполне даже регулярно

А ифы на два разбить нельзя?

Выше приводил, у меня все как в примере, только без ифов. Не работает.

Выше приводил, у меня все как в примере, только без ифов. Не работает.

Не без а на два не через елсе

SPI - это боль для двунаправленного обмена. Например SD карты в режиме SPI да и SDIO только поллингом

Вот это новость. В нем изначально заложен двунаправленный обмен. Как же так?

я на 103-ем только и работал, пашет как часы

Вот Danil ответил, помню косяк был, а какой не помнил

Не без а на два не через елсе

Что-то недопонял.

Вот это новость. В нем изначально заложен двунаправленный обмен. Как же так?

Spi вроде совсем тупой интерфес, смотрим кто прерывание вызвал и его обрабатываем, в примере, рассматривается случай когда либо отправка либо прием

Может я гоню

Я правильно понимаю что после SPI_I2S_SendData сразу надо принять байт - SPI_I2S_ReceiveData(SPIx), или сработает прерывание SPI_I2S_IT_RXNE ?

Сработает прерывание, в котором забираешь данные

проблема с SPI в том, что нельзя спросить слейв и получить ответ просто так. SPI всегда одновременно передаёт и получает данные

По моему в нете были примеры-с рабочим спиаем

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

СПИ в стм32 такой же простой как и в атмеге

просто больше фишечек, которые часто не нужны. аппаратный CRC, кстати, очень годная штука

А мастер разве запрашивает данные? Он-же только включаем доступ-к устройству

в СПИ есть один мастер- все остальные слейвы.

А мастер разве запрашивает данные? Он-же только включаем доступ-к устройству

Только так. Клок и CS генерит всегда мастер

слейв спи устройство вообще ничего не может само

А да мы клоком данные требуем,

SPI хорош для потоковой передачи данных на высокой скорости

но адресация только отдельными линиями CS

мультимастер на СПИ почти нереалезуем без корявых костылей

Ну вообщем тот вариант, с прерываниями должен был-работать нормально

Только там данные либо забрал либо отправил и только в след прерывании остальное

слейв спи устройство вообще ничего не может само

Я имею ввиду програмнно

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

Тут я прозрел, он же может ничего не отдавать

Опять не так выразился, прощу прощения, вы все говорите верно

С точки зрения программиста нужно только ждать когда выставится флаг принятых данных

Правильно?

в каждый момент времени СПИ работает либо мастером либо слейвом. Прерывания вызываются соответствующие. У мастера ТХЕ - передача окончена, буфер пуст. у слейва RXC (или как то так) - прием окончен, байт в буфере

есть ещё прерывания по ошибке CRC если используется аппаратный

есть прерывание что буфер полон, но у стм32 есть шэдоу буфер. т. е. можно писать следующий байт пока предыдущий еще передаётся и читать прошлый пока принимается новый

в каждый момент времени СПИ работает либо мастером либо слейвом. Прерывания вызываются соответствующие. У мастера ТХЕ - передача окончена, буфер пуст. у слейва RXC (или как то так) - прием окончен, байт в буфере

То есть нельзя принять и отправить одновременно, но линии же две, я что-то не так понимаю?

Мне одновременно и не надо, надо запрос - ответ

Мне одновременно и не надо, надо запрос - ответ

Он у тебя есть, сам код кидал

не на прерываниях у меня и так есть, работает

не на прерываниях у меня и так есть, работает

Ты тут код скидывал на прерывании, точнее только функцию

Тебе может и не нужно, а мне любопытно стало

всегда, когда передаётся байт, в приемный буфер считывается байт с линии. его можно считать, но не обязательно вроде - но я точно не помню уже

не на прерываниях у меня и так есть, работает

Так ты запустил? Функцию написал, прерывание настроил, евенты запустил

в режиме слейва не обязательно грузить байт на отправку мастеру

всегда, когда передаётся байт, в приемный буфер считывается байт с линии. его можно считать, но не обязательно вроде - но я точно не помню уже

Спасибо,

в примерах от стм все есть - поллинг, прерывания и ДМА

в примерах от стм все есть - поллинг, прерывания и ДМА

Поллинг это кто

получается в момент отправки надо после отправки каждого байта также принимать байт и игнорировать его, пока весь пакет запроса не отправится?

получается в момент отправки надо после отправки каждого байта также принимать байт и игнорировать его, пока весь пакет запроса не отправится?

Там два регистра,

получается в момент отправки надо после отправки каждого байта также принимать байт и игнорировать его, пока весь пакет запроса не отправится?

Отправка отдельно, приём отдельно, то что в регистре что то есть, отмечается флагом

поллинг это опрос флага в бесконечном цикле

поллинг это опрос флага в бесконечном цикле

Буду знать

самый тупой вариант, но всегда рабочий

самый тупой вариант, но всегда рабочий

Но в ракетах не очень применим ::))

вот не факт. часто прерыввния разрешены только ОС. А все пользовательские процессы работают через её АПИ/ХАЛ и там тупление в цикле в ожидании флага вообще нормальная практика

получается в момент отправки надо после отправки каждого байта также принимать байт и игнорировать его, пока весь пакет запроса не отправится?

Функция прерывания будет вызываться как только один из флагов взлетит, а ты там уже смотришь какой взлетел

Отправка отдельно, приём отдельно, то что в регистре что то есть, отмечается флагом

где написано для чайников, почему нужно при отправке принимать также? Даже если слейв пока не примет запрос, ничего не отправляет

Функция прерывания будет вызываться как только один из флагов взлетит, а ты там уже смотришь какой взлетел

мля, это очевидно, вопрос не в этом

разделение ресурсов и процессорного времени и есть основная задача РТОСа

где написано для чайников, почему нужно при отправке принимать также? Даже если слейв пока не примет запрос, ничего не отправляет

Вы зря читали нашу переписку с Данилом

Данила с Данилом, я запутался в вас :)

где написано для чайников, почему нужно при отправке принимать также? Даже если слейв пока не примет запрос, ничего не отправляет

Не-нужно этого делать, но прежде чем отдавать вы должны быть уверены что регистр пуст

То есть вместо цикла ожидания вы прямо говорите мк, позовешь, когда будешь готов продолжить

Давайте разберемся, что у вас есть и что хотите

Нет двунаправленности, там один только передает, другой только принимает: void SPIx_IRQHANDLER(void) { #ifdef SPI_SLAVE if (SPI_I2S_GetITStatus(SPIx, SPI_I2S_IT_RXNE) == SET) RxBuffer[Rx_Idx++] = SPI_I2S_ReceiveData(SPIx); #endif #ifdef SPI_MASTER if (SPI_I2S_GetITStatus(SPIx, SPI_I2S_IT_TXE) == SET) { if (CmdStatus == 0x00) { SPI_I2S_SendData(SPIx, CmdTransmitted); CmdStatus = 0x01; } else { if (Tx_Idx < GetVar_NbrOfData()) { SPI_I2S_SendData(SPIx, TxBuffer[Tx_Idx++]); } else { SPI_I2S_ITConfig(SPIx, SPI_I2S_IT_TXE, DISABLE); } } } #endif /* SPI_SLAVE */ }

Вот есть такая хрень

Ифдеф убираем, на пару с ендифом

Cmdstatus и его тело

Хоть телеграмм на комп ставь :/

вот это не работает,отправляет какую то ересь: void SPI1_IRQHandler() { if (SPI_I2S_GetITStatus(SPI1, SPI_IT_RXNE) == SET) { uint8_t x = (uint8_t)SPI_I2S_ReceiveData(SPI1); fifo_put(&_rxFifo, x)); } if (SPI_I2S_GetITStatus(SPI1, SPI_IT_TXE) == SET) { if (!fifo_empty(&_txFifo)) { uint8_t x = fifo_get(&_txFifo); SPI_SendData(SPI1, x); } else SPI_I2S_ITConfig(SPI1, SPI_IT_TXE, DISABLE); } }

стою отладчиков, на SPI_SendData(SPI1, x)

передается правильная последовательность из пяти байт - 0x47 0x01 0x00 0x10 0x83

ну нормально всё вроде, только нахуя сразу писать код и мастера и слэйва?

ну нормально всё вроде, только нахуя сразу писать код и мастера и слэйва?

Так обработчик-прерывания же, а-если что-придет?

так это мастер отсылает запрос слейву и должен получить от него ответ

так, передается от STM32 правильная последовательность

так, передается от STM32 правильная последовательность

А приём?