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

[parovoZZ]

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

Впрочем, все зависит от того, что считать дешевизной.

Дешевле 100 рублей в розницу со всеми налогами. А так и у MSP430 за 150 рублей DMA есть.

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

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

Так быть не может. Прерывание надо чем-то спровоцировать.

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

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

Скорее всего - да.

[Реклама]

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

[BARS_]

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

Во первых, далеко не весь.

Весь. Единственное, что делает драйвер - принимает и передает данные. При этом ничего не теряет в процессе. Ну и может еще сообщать о готовности. Если в коде драйвера содержится что-то еще - драйвер кривой.

 

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

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

У меня драйвер того же UART занимает строк 10-15 кода и располагается в обработчике прерывания. У SPI это может быть отдельная библиотека, т.к. может потребоваться некоторое разнообразие функций для работы со слейвом. В любом случае код там максимально простой и быстрый.

 

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

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

Давайте рассмотрим пример. Пусть в проекте есть дисплей. Тормоза в работе GUI - это ведь неприятно? Еще как. Но не самое неприятное. Ведь помимо GUI у МК может быть много других задач, критичных ко времени. У меня есть проект на 205 камне. Там стоит дисплей 320*240, микросхема ЛВС, работающая по SPI (W5500), GPS, который сливает пакет данных размером около 300байт на скорости 921600 и идет общение с внешней платой по SPI с тактовой 10МГц. Т.е. юзверь может клацать кнопки и выбирать что-то в GUI, одновременно с этим может идти работа по ЛВС на 2-3 сокетах (MODBUS TCP с пятью дестяками регистров), общение по SPI. При этом каждую секунду падает пакет от GPS, который еще и парсить надо, т.к. там NMEA. и все это должно работать максимально одновременно. МК справляется - очень даже. Достаточно код нормально писать. На ARM в принципе пишутся довольно большие проекты, иначе их нет смысла ставить. А более простые проекты, типа опроса десятка АЦП, контроля параметров модулей и общение по RS спокойно вывозят и 8-битники C8051F. 

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

Прерывание надо чем-то спровоцировать.

Например, записать первый байт в регистр. Дальше уже пойдет работать прерывание. Так что 99,9% кода драйвера находится в обработчике.

[Реклама]

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

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

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

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

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

[parovoZZ]

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

У SPI это может быть отдельная библиотека,

Ая вот тут кумекаю, кумекаю - никак не кумекается. На UART проще - закинул данные и поехал дальше. К тому же скорости на UART, как правило, в разы меньше тактовой.

Для SPI думается создать структуру вида:

struct SPI_data_t
{
  uint8_t  cmd;
  uint8_t  *data;
}

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

[Реклама]

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

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

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

[ARV]

А смысл написания абстрактного драйвера? Если кто работает профессионально - так есть и готовые драйверы (у того же атмела есть нечто вроде HAL), и можно думать о каком-то универсализме и переносимости... А для любителя, у которого выбор МК в половине случаев не под задачу, а из запасов - зачем вся эта универсальность?

Я сколько ни пробовал сделать "универсальные" библиотеки, всегда натыкался на бессмысленность попыток. 

В конечном итоге вся универсальность выливается в избыточность...

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

Для SPI думается создать структуру вида:

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

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

[parovoZZ]

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

если стремиться к "абсолютной" универсальности?

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

[BARS_]

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

Если кто работает профессионально - так есть и готовые драйверы (у того же атмела есть нечто вроде HAL), и можно думать о каком-то универсализме и переносимости

Готовые, как правило, содержат тонны бесполезного кода.  Да и переносимости никакой нет, по крайней мере для STM. Под каждую серию свой набор HAL.

 

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

Для SPI думается создать структуру вида:

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

 

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

но как быть со счетчиком байтов в пакете данных?

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

typedef struct {
	uint8_t Rx_Buf[512];
	uint8_t Tx_Buf[512];
	uint16_t Tx_Index;
	uint16_t Rx_Index;
	uint16_t Tx_Len;
} _RS1;

При работе с RS тоже есть нечто, похожее на CS. Только он переводит драйвер из режим приема в режим передачи. Перед началом передачи пин опускается, в конце поднимается.

[parovoZZ]

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

я для работы с RS

RS - это что?

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

Особого смысла нет.

Ну если говорить про радиотрансивер, то основной поток не структурированных данных идет при инициализации. Правда, у тех же СС1101 можно часть регистров записать одним куском данных. Вот и думай...

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

[BARS_]

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

RS - это что?

RS485

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

основной поток не структурированных данных идет при инициализации.

Если она проходит при запуске девайса и только один раз, то в принципе фиолетово, насколько скоростной там будет код.

 

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

Ну то бишь создал массив с командами/данными, а потом только инкрементируешь указатель на его элементы.

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

[my504]

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

Весь. Единственное, что делает драйвер - принимает и передает данные.

Это совсем примитивный драйвер. 

Если драйвер реализует более-менее сложную диаграмму, он во первых, расположен не в одном обработчике, а во вторых имеет софт позволяющий получить формат данных, укладывающийся в  абстракции основного алгоритма. Это может быть формальная сортировка или что то аналогичное. Собственно этот софт позволяет получить искомую переносимость ОСНОВНОГО алгоритма. Переносимость драйвера невозможна по определению - это по сути инструмент переносимости, а не объект.

По поводу скорости. Время занимаемое драйвером в котором ничего кроме установки флагов и выгрузки/загрузки физического интерфейса не может быть критичным для кода, но может быть критичным для другого драйвера. Это тот случай, когда ДМА позволяет разрулить коллизии. Я говорил о вариантах, когда  ДМА позволяет спрятать от основного кода лишние сущности, которые можно реализовать на прерываниях. При этом сами прерывания становятся более понятными. 

[BARS_]

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

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

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

 

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

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

Зависит от потока данных.

 

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

Я говорил о вариантах, когда  ДМА позволяет спрятать от основного кода лишние сущности, которые можно реализовать на прерываниях.

Вся проблема в том, что если передавать черед DMA мелкие пакеты, то скорость еще и упадет по сравнению с прерываниями, т.к. на запуск DMA будет уходить больше времени, чем на саму передачу без DMA. В общем с DMA все далеко не однозначно.

[parovoZZ]

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

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

Но не будем забывать про CS. Также науке известны случаи, когда на шине SPI более двух устройств. Поэтому тут без массива структур никак.

[my504]

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

Драйвер не должен реализовывать ничего, кроме приема/передачи. На то он и драйвер, он должен быть максимально простым и быстрым.

Вы путаете обработчик прерываний с драйвером. Это две РАЗНЫЕ сущности. В драйвер входят обработчики, но далеко не всегда только обработчики.

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

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

Это не бред. Это создание стандартного и удобного интерфейса для основного кода. Красота тут совсем не причем. Создавать этот интерфейс в прерывании - точно бред. Поэтому это софтовая часть драйвера. Посмотрите стек USB, например. Это типичный драйвер. В нем ОСНОВНАЯ ЧАСТЬ КОДА - это совсем не обработчики.

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

Вся проблема в том, что если передавать черед DMA мелкие пакеты, то скорость еще и упадет по сравнению с прерываниями, т.к. на запуск DMA будет уходить больше времени, чем на саму передачу без DMA.

Это вообще ерунда. Вы что нибудь слышали о непрерывных и однократных режимах ДМА? Запуск ДМА - необязательная процедура, если не считать первичный запуск и перезапуск в вачдоге ДМА (есть такая софтовая приблуда для ряда случаев). Во вторых, что Вы считаете пакетом? Я могу пересылать ОДНУ И ТУ ЖЕ переменную в ОДИН И ТОТ ЖЕ  регистр периферии. Бесконечно, с интервалом реквеста ДМА (таймер-прерывание-захват - что угодно, что может работать в качестве реквеста по даташиту). и ДМА будет иметь непрерывный режим работы и никаких запусков не потребуется.

[BARS_]

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

Но не будем забывать про CS.

Так а в чем проблема? Счетчик переданного досчитал и CS поднялся.

 

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

Также науке известны случаи, когда на шине SPI более двух устройств

Тоже не проблема, завести переменную, в которой будет лежать номер устройства. Да и то не обязательно, т.к. знать номер надо лишь при опускании CS. А поднимать можно все имеющиеся.

 

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

Вы путаете обработчик прерываний с драйвером.

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

 

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

Создавать этот интерфейс в прерывании - точно бред.

Где я писал про создании чего-либо в прерывании? Я русским языком написал, что в прерывании только пишутся данные в буфер. Что будет дальше происходить с буфером - совершенно другая задача. Он может вообще тупо обрезаться и уходить по другому интерфейсу.

 

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

Посмотрите стек USB, например. Это типичный драйвер. В нем ОСНОВНАЯ ЧАСТЬ КОДА - это совсем не обработчики.

Для какого устройства?

 

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

Вы что нибудь слышали о непрерывных и однократных режимах ДМА?

Представьте себе. Так вот при работе типа запрос-ответ - непрерывный режим не катит, ибо до тех пор, пока не сформирован буфер передавать нечего.

 

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

Во вторых, что Вы считаете пакетом?

Заголовок+данные+CRC. Либо хотя бы адрес+данные. Либо просто куча данных произвольной длины.

 

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

Я могу пересылать ОДНУ И ТУ ЖЕ переменную в ОДИН И ТОТ ЖЕ  регистр периферии. Бесконечно, с интервалом реквеста ДМА (таймер-прерывание-захват - что угодно, что может работать в качестве реквеста по даташиту). и ДМА будет иметь непрерывный режим работы и никаких запусков не потребуется.

Вот только это бессмысленно. Особенно, если при этом надо дергать некими служебными ножками. Вот опрашивать каналы АЦП по кругу - другое дело, или же запускать DMA для передачи массива из нескольких десятков байт. такое ощущение, что вы DMA вообще никогда не использовали.

 

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

Это вообще ерунда.

Прочтите, сколько тактов тратится на перезапуск DMA.

[ruhi]

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

Я могу пересылать ОДНУ И ТУ ЖЕ переменную в ОДИН И ТОТ ЖЕ  регистр периферии. Бесконечно, с интервалом реквеста ДМА (таймер-прерывание-захват - что угодно, что может работать в качестве реквеста по даташиту)

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

Поэтому запись в память и не предусмотрена нигде в качестве активатора ДМА канала.

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

[my504]

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

Вот только это бессмысленно. Особенно, если при этом надо дергать некими служебными ножками.

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

Служебными ножками дергает Output Compare, который и формирует запросы транзакций для самого обмена. Никаких проблем.

Не понял зачем Вы мне говорите о времени на запуск ДМА? Я ранее Вам сказал, что запуск ДМА нужен только для однократного режима. В случае непрерывного перезапуск не требуется.

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

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

Я просто в шоке.... 

Вы в курсе что запросы на транзакции может формировать целый список устройств? Писать Вы можете откуда угодно и куда угодно, но КАЖДАЯ ТРАНЗАКЦИЯ будет происходить лишь по запросу одного из устройств в списке. Например, я могу засылать в буфер SPI данные побайтно с интервалом в 1 час. Каждый час таймер определенный как источник запросов на транзакции этого канала будет переполняться и флаг этого переполнения выступит как требование транзакции.

[ruhi]

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

В случае непрерывного перезапуск не требуется.

Да, только тогда требуется ДМА канал с циклическим буфером, и работает это только на прием, кстати, как вы одиночную передачу запускать собираетесь, по какому, нафик, таймеру??? оно должно запускаться, обычно в произвольный момент времени, когда данные появились из произвольного источника!

А при наличии циклического буфера о:

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

Это создание стандартного и удобного интерфейса для основного кода

лучше не вспоминать!

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

Я просто в шоке.... 

Прямо как одна известная звезда

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

[my504]

9 минут назад, ruhi сказал:

Да, только тогда требуется ДМА канал с циклическим буфером

Причем тут циклический буфер? Я говорил о ДМА вообще. Вы хотя бы контекст разговора узнайте.

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

Для какого устройства?

Для МК, конечно. 

Скажем, стек для HID host или HID device  класса.

Типичный драйвер для обслуживания аппаратного USB модуля в МК.

 

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

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

А Вы не пробовали загружать в основном цикле некий параметр внешнего устройства, который висит на SPI (или  I2C), при этом сам обмен автоматически и непрерывно поддерживается DMA? Там для обмена вообще непрерывно шлется эта переменная и адресный байт впереди. Запустили - забыли. Считаем в суперлупе и иногда модифицируем переменную, которая и засылается в это внешнее устройство.

То же самое и с АЦП (внешним). Мне возможно вообще не требуется массив, а нужно только два значения идущие с интервалом в четверть периода измеряемого сигнала (разово и редко, а не подряд). Запускаю на Output Compare диаграмму реализующую эти две выборки. Стартанул диаграмму - забрал данные. Буфер 2 слова. Режим ДМА непрерывный.

[ruhi]

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

Причем тут циклический буфер? Я говорил о ДМА вообще. Вы хотя бы контекст разговора узнайте.

Это ж элементарно, извиняюсь, без запуска (и, значит, без остановки) он у вас бесконечно будет приходящие данные сохранять КУДА???

Бесконечной памяти не существует, остается только циклический буфер, В серии ATSAMXXXX для этих целей определен linked list of descriptors, например.

Что ж вы, элементарных вещей не знаете, а беретесь рассуждать о высоких материях .

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

[my504]

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

Это ж элементарно, извиняюсь, без запуска он у вас бесконечно будет приходящие данные сохранять КУДА???

Это же элементарно, когда циклический буфер имеет длину в ОДИН АДРЕС. Инкремент адреса ОТКЛЮЧЕН. И не надо приводить примеры конкретных МК. МК бывают разные.

ЗЫ. Кстати, цикличность буфера может и не иметь никакого значения, если в самих данных есть привязка к началу. Пиши себе по кругу... Без останова. Естественно, что по завершении сессии будет генерироваться прерывание ДМА... Но останова ДМА не будет.

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

[ruhi]

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

когда циклический буфер имеет длину в ОДИН АДРЕС.

Да, осталось только выяснить какую проблему решает копирование значения регистра в память посредством ДМА, при том что можно это значение прочитать непосредственно из регистра.

Ведь, тогда основная проблема это синхронизация алгоритма использования значения из регистра, с моментом появления (обновления) этого значения в регистре, и ДМА здесь ничем помочь не может, а будет лишней операцией, потому что алгоритм будет читать значение не из регистра, а из памяти ПОСЛЕ копирования этого значения в ЭТУ память из РЕГИСТРА через ДМА.

Да! вот так вот сложно, и похоже эта сложность не позволяет вам заметить избыточность применения ДМА здесь, о которой вам и пытался растолковать

@BARS_

на сколько я понимаю

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

[ARV]

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

какую проблему решает копирование значения регистра в память посредством ДМА

Преобразование АЦП, не?

[my504]

7 минут назад, ruhi сказал:

Да, осталось только выяснить какую проблему решает копирование значения регистра в память посредством ДМА

Ну, во первых, почему обязательно в память?

Можно и ИЗ памяти. Об этом я выше написал. Тогда к копируемым данным может быть пристегнуто один...три байта и все выплюнуто на внешнее устройство.

Но можно и в память,  как например для пары байт квадратурного детектирования. Буфер равен двум. Порядок значения не имеет. Можно в прерывании  от ДМА поднимать флаг готовности данных, но ни перезапуска, ни формирования диаграммы запросов транзакций не требуется. Вошел-вышел.

Можно, например, загружать DDS , что требует транзакции небольшого пакета, но с генерацией сигнала FSYNC (защелкивания). Мне что, каждый раз ходить по обработчикам меняя данные и дергая ногу FSYNC?

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

[ruhi]

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

Преобразование АЦП, не?

Что:

"синхронизация алгоритма использования значения из регистра, с моментом появления (обновления) этого значения в регистре"

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

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

Ну, во первых, почему обязательно в память?

Читайте выше еще раз, там было про прием и передачу (в память / из памяти):

 

58 минут назад, ruhi сказал:

Да, только тогда требуется ДМА канал с циклическим буфером, и работает это только на прием, кстати, как вы одиночную передачу запускать собираетесь, по какому, нафик, таймеру???

 

[ARV]

Синхронизация обновления значения в регистре требуется далеко не всегда. Например, семплирование звука: там важно обеспечить период поступления семплов, а не синхронность семплов с чем-либо. То есть АЦП прекрасно может обновлять данные хоть мильён раз в секунду в своем регистре, но для нужной нам дискретизации забирать эти данные надо строго 8000 раз в секунду, например.

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

[my504]

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

Читайте выше еще раз, там было про прием и передачу (в память / из памяти):

Это ВАМ надо читать выше. ПОСЛЕДНЕЕ обсуждение не имеет отношение к вопросу темы непосредственно. Это было замечание о ДМА вообще. При попытке Барса выдать какие то формальные правила применения ДМА.