Философия аппаратного SPI - чем занять МК?

[parovoZZ]

35 минут назад, ARV сказал:

Это надо, чтобы искусственный интеллект в нем был

 

35 минут назад, ARV сказал:

Это известно только программисту

это да...

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[BARS_]

1 час назад, ARV сказал:

Это надо, чтобы искусственный интеллект в нем был  Как узнать, когда "заруливать" этим пином?

А что мешает иметь переменную, в которую записывается количество байт для передачи? Тогда работа SPI будет выглядеть так:

1.  Записать в переменную количество байт.
2. Опустить CS.
3. Записать первый байт в регистр SPI
4. В прерывание по SPI щелкать счетчик переданных байт и сравнивать с требуемым. Если мало, отправлять следующий байт.
5. При достижении требуемого значения счетчика - поднять CS.

Я по такому принципу работаю с UART.

А флаг опустошения буфера довольно удобная вещь. На тех же STM32 это позволяет получить безразрывную передачу данных по SPI. Там буфер живет отдельно от сдвигового регистра передачи и его опустошение возникает раньше окончания передачи. В результате новый байт данных оказывается в буфере еще до окончания отправки предыдущего.

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[ARV]

Только что, BARS_ сказал:

А что мешает иметь переменную

Мы тут мечтали об аппаратном дрыгании CS-ом, без лишних прерываний. Так-то оно все понятно...

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[BARS_]

3 минуты назад, ARV сказал:

Мы тут мечтали об аппаратном дрыгании CS-ом

Легко, но после каждого байта

[ARV]

Только что, BARS_ сказал:

Легко, но

не нужно  

[Alex]

Аппаратное дёрганье CS'ом, ИМХО, ненужная фигня. Использовать можно будет только с одним девайсом. Тогда каков в нём смысл, если можно CS девайса повесить железно и навечно.

[ARV]

Ну... чисто теоретически... при наличии DMA вполне можно было бы битик в регистре DMA-контроллера выделить под это. Скажем, со смыслом "Опустить CS на время передачи или приема буфера". Ну или как-то так, возможно, с вариантами...

[Alex]

А какой смысл, если устройство, висящее на SPI, всего одно ?

PS: Есть в PIC'ах такое (аппаратный CS), игрался я с ним. Даже SD-карта работала.

[BARS_]

26 минут назад, Alex сказал:

Тогда каков в нём смысл, если можно CS девайса повесить железно и навечно

В смысле держать его все время в опущенном состоянии? Не прокатит.

 

18 минут назад, Alex сказал:

Есть в PIC'ах такое (аппаратный CS)

Это в любом МК есть.

[Alex]

5 минут назад, BARS_ сказал:

Это в любом МК есть.

Судя по "мечтаниям", находящихся выше в теме, - не во всех. Или я что-то путаю ?

6 минут назад, BARS_ сказал:

Не прокатит.

Да, скорее всего...
Значит смысл, всё-такие, есть.

[BARS_]

1 минуту назад, Alex сказал:

не во всех.

Есть то во всех, вот только дергать его после каждого байта бессмысленно.

[ARV]

Только что, BARS_ сказал:

Есть то во всех

Есть-то во всех, да вот только дергается программно...

[my504]

11 минуту назад, Alex сказал:

Судя по "мечтаниям", находящихся выше в теме, - не во всех. Или я что-то путаю ?

Есть такое мнение, что путаете. Потому как в ПИКах нет никакого CS, а есть SS - slave select. Это не выход, а ВХОД выбора слейва, если этот SPI работает в режиме slave.

Делать аппаратный CS бессмысленно, ибо есть минимум ДВА вида CS. Один накрывает данные, а второй завершает. Реализовать CS  легко на Output Compare, от которого и запускается транзакция SPI. Скажем, для внешнего SPI АЦП я так и делаю. Тем более, что там CS - это и есть запуск преобразования.

Изменено 7 мая, 2019 пользователем my504

[BARS_]

2 минуты назад, ARV сказал:

дергается программно

Дергается именно аппаратно. На счет AVR не вспомню, на в C8051F и STM он может дергаться аппаратно после каждого окончания передачи.

 

2 минуты назад, my504 сказал:

Делать аппаратный CS бессмысленно

Было бы бессмысленно - не делали бы, а его делают. Вот только применения ему я найти так и не смог, ибо очень редко дело заканчивается одной передачей и передать надо подряд несколько байт при опущенном CS.

[parovoZZ]

48 минут назад, BARS_ сказал:

Легко, но после каждого байта

Не всегда. В передаче "команда и многа, многа данных потом" дернуть надо в самом конце, а не посередине. Иначе очередной байт данных превратится в команду. Хорошо, если не опознанную.

 

14 минуты назад, BARS_ сказал:

Это в любом МК есть.

Есть-то есть. Только назначение другое - перевести блок SPI в статус SLAVE. У новых аттинек есть бит SSD - отключает CS от физического пина. После чего последним можно пользоваться как обычным GPIO. В ATMEGA такого нет. Если SPI мастер, то CS можно только на выход. Или на вход, но только "1".

1 час назад, BARS_ сказал:

А что мешает иметь переменную, в которую записывается количество байт для передачи? Тогда работа SPI будет выглядеть так:

1.  Записать в переменную количество байт.
2. Опустить CS.
3. Записать первый байт в регистр SPI
4. В прерывание по SPI щелкать счетчик переданных байт и сравнивать с требуемым. Если мало, отправлять следующий байт.
5. При достижении требуемого значения счетчика - поднять CS.

Если есть свободная ОЗУ, то с таким алгоритмом не грех через указатель заносить данные в SPI там же в прерывании.

1 час назад, BARS_ сказал:

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

В аттиньке всё ровно тоже самое.

[ARV]

Только что, BARS_ сказал:

на в C8051F и STM он может дергаться аппаратно

Повезло кому-то  Можно в 595-е регистры полностью аппаратно выводить  

[my504]

Только что, BARS_ сказал:

Было бы бессмысленно - не делали бы, а его делают. 

Мне не встречался. 

[BARS_]

Только что, my504 сказал:

Мне не встречался. 

Выше я дал примеры МК. При настройке SPI указывается, какой режим работы 4 или 3 провода.

 

2 минуты назад, parovoZZ сказал:

Не всегда. В передаче "команда и многа, многа данных потом" дернуть надо в самом конце, а не посередине.

Так я о том и говорю...

 

3 минуты назад, parovoZZ сказал:

Есть-то есть. Только назначение другое - перевести блок SPI в статус SLAV

Ошибся, не в любом, а во многих. И именно при работе мастером.

 

3 минуты назад, parovoZZ сказал:

Если есть свободная ОЗУ, то с таким алгоритмом не грех через указатель заносить данные в SPI там же в прерывании.

Я, обычно, так и делаю. Данные пишутся в массив, а массив уже выплевывается сам в либо в прерывании, либо через DMA. Зависит от количества данных и типа МК. В UART делаю ровно точно так же.

[Alex]

31 минуту назад, my504 сказал:

Это не выход, а ВХОД выбора слейва

Марк, посмотри референс по SPI на PIC32. SS является и выходом (при мастере) и входом (при слейве).
Сам лично дёргал им, управляя CS'ом SD-карты.

PS: В более младших семействах - не знаю, есть ли аппаратный дрыг. Не встречал.

[my504]

1 час назад, Alex сказал:

Марк, посмотри референс по SPI

Да, есть режим фрейма, где генерируется синхроимпульс на этой ноге мастером (у 24-х/33-х тоже есть), но он не может служить ни накрывающим данные, ни загрузкой после транзакции. Это именно синхроимпульс для определенных протоколов и расположен он либо перед 15 разрядом либо прямо во время передачи 15 разряда. То есть использовать этот режим для какого нибудь 595-го, SPI АЦП или ЖК-сегментного стекла совершенно невозможно. Зато два МК легко синхронизируются путем соединения SS-ов мастера и слейва.

Изменено 7 мая, 2019 пользователем my504

[parovoZZ]

2 часа назад, BARS_ сказал:

Я, обычно, так и делаю. Данные пишутся в массив, а массив уже выплевывается сам в либо в прерывании, либо через DMA. Зависит от количества данных и типа МК. В UART делаю ровно точно так же.

Да, DMA - это сказка. Но в дешманских МК его нет.

А вот свою работу с SPI я перепишу через указатели. Идея мне понравилась))

[BARS_]

26 минут назад, parovoZZ сказал:

Да, DMA - это сказка.

Далеко не всегда. На малых порциях данных он не даст выигрыша.

[my504]

9 часов назад, BARS_ сказал:

он не даст выигрыша.

Выигрыш во времени - не единственный аргумент за ДМА. Выигрыша как такового может и не быть, зато структура алгоритма становится гораздо более простой и читабельной, не перегруженной мусором из драйверов. Поэтому, если есть свободные каналы ДМА, вполне уместны даже  достаточно редкие транзакции. Тут важен не размер пакета, а периодичность транзакций. Чтобы источник запросов на перегрузку данных (DMA request) мог быть автоматическим (таймер или иное событие).

10 часов назад, parovoZZ сказал:

Да, DMA - это сказка. Но в дешманских МК его нет.

Это не соответствует истине. Cortex M0/M0+ очень дешев и имеет DMA. ДМА так же есть в PIC24FJ256GA702, тоже недорогом МК.

Впрочем, все зависит от того, что считать дешевизной. За 20 рублей наверное в МК ДМА не будет.

[BARS_]

3 часа назад, my504 сказал:

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

Весь код драйвера находится внутри функции обработчика прерывания и особо не мешает. Да и скорость работы порой намного важнее, чем красивый код.

[my504]

23 минуты назад, BARS_ сказал:

Весь код драйвера находится внутри

Во первых, далеко не весь. Ну или обработчик содержит то, что не должен содержать - обработку данных. В состав драйвера так или иначе входит некая функция main-а, которая обрабатывая флаги выставленные в обработчиках прерываний, собственно и  занимается данными в первичной их обработке (так, чтобы они соответствовали уровню абстракций основного кода). Ну и структура самих драйверов, очень желательно. чтобы была прозрачной. А то получаются обработчики в которых играют половина имеющихся драйверов и в таком ISR черт ногу сломит.

Во вторых,  МК в котором драйверы создают настолько критический код, что нужно жертвовать структурой алгоритма - это неправильно выбранный МК. Очередной апгрейд под новые требования приведет к полной смене схемотехники. Скупой платит дважды.

Изменено 8 мая, 2019 пользователем my504