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

по поводу заданного мной вопроса о DMA и альтернативах, я так ничего полезного и не извлек из написанного.
Ок, я не видел, где всего много, но я отлично видел, где всего МЕНЬШЕ - например, AVR. если сравнивать с тем, что было для меня основным, то в STM32 просто изобилие для голодного.
вот я как рассуждаю? кто-то сделал DMA и горя не знает. я не сделал DMA и тоже горя не знаю. есть ли тут подвох? и если есть, то где? то есть где та грань, за которой меня ждут боль и страдания? рассуждения про коней в вакууме интересны, но не несут полезной информации начинающему, т.к. его заботит не работоспособность его кода в случае нашествия марсиан, а работоспособность его конкретного поделия. и очень хотелось бы получать советы/ответы по конктерно поднятой теме, а не "вообще абстрактно", чем, извините, вы, jcxz, очень стратадете - ваша любовь вспоминать о архитектуре ARM вообще и свойствах ядра "аналогичного" МК крайне занимательна, но для начинающего бесполезна. меня меньше всего беспокоит архитектура ядра, поскольку я просто не вижу (и еще большой вопрос, плохо ли это) связи моих частных, относительно "высокоуровневых" вопросов с "низкоуровневыми проблемами" шин, арбитражей и т.п. "ядрёных" фич. как минимум, без дополнительных пояснений...
а я почему-то думал, что есть... если уж в AVR 2 байта есть во многих МК, неужто в STM32 нет даже 2 байт?!
меня пока что DMA немного напрягает. ведь это требует достаточно непрозрачной (сноска здесь и далее - для меня, новичка) инициализации режима DMA всякий раз после приема чего-то там (см. "лучше 2 дня потерять, зато потом за полчаса долететь"). Например, конкретно по модбасу - длина RTU-пакета не известна до момента его полного приема, или, как минимум, до приема четвертого или седьмого байта (по памяти, могу ошибиться). так как мне DMA тут может помочь? как его настроить, чтобы по прерыванию от DMA иметь готовый пакет в буфере? у моего предшественника сделано так (если я верно расшифровал его коды), что прерывание DMA вызывается и начинается анализ "сырых" байтов в буфере. то есть у меня сильное подозрение, что он тупо принимет N байт при помощи DMA и потом колдует с принятым массивом, выискивая в нем признаки пакета модбас и собирая пакет по кусочкам, если необходимо. по-моему, это намного худшее решение, чем тупое по прерываниям каждого байта... но есть ли лучшее - я пока не знаю...
а теперь цепочка моих рассуждений.
1. разработчики ARM (в частности, STM32) явно не глупее вас (и вообще всех тут присутствующих)
2. они зачем-то предусмотрели режим работы USART с прерываними, хотя это крайне тупо и неэффективно
вопрос: нет ли тут какого-то подвоха?

Добавлено after 9 minutes 33 seconds:

чисто теоретически модуль main.c может состоять (помимо списка инклюдов) из единственной строки go; - короче не придумать. но есть ли во всем этом смысл? в частности: куда вы потратили ту уйму времени, которую сэкономили на записи T1.CR1 = (T1_CR1_t){.DIR=1, .OPM=1, .CEN=1}.r; вместо TIM1->CR1 = TIM_CR1_DIR | TIM_CR_OPM | TIM_CR1_CEN;, которая, обратите внимание, аж на 5 (!!!) символов длинее?

Добавлено after 9 minutes 20 seconds:
да, еще в догонку к ранее сказанному... известно огромное количество промышленных modbus-устройств на 8-битных PIC и AVR (у которых нет DMA по определению), работающих на в 2-10 раз меньшей тактовой частоте, и прекрасно всё успевающих... где зарыта проблема вероятного "не успевания" STM32 при "неприличном" подходе по прерываниям USART?

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

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

тут не угодить. прошлый раз сетовали на сложность.


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


Добавлено after 27 minutes 23 seconds:

не вспомню уж где, а может и в этой ветке даже, озвучивался простой рецепт: канал DMA умеет вызывать прерывание, когда принята половина ожидающихся данных. если за эту половину принять объем, куда входит и длина пакета модбас (тот самый четвертый или седьмой), то дальше уже дело техники, как в обработчике прерывания рассказать каналу, сколько еще предстоит принять.


это на трех битах инициализации. их может оказаться больше. много больше. но не объемом единым. улучшается читабельность. сильно.

Нюанс с модбасом только в том, что для пакетов чтения это 4-й байт (условно), а для пакетов записи может быть как 4-й, так и 7-й. Т.е. нет однозначной половины пакета...

Вы же вроде не "не сделали", а не "не можете разобраться в уже сделанном". Разве не так?
А это - разные понятия.

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

Я ничем не страдаю. Не надо валить с больной головы на здоровую. Это вас взяли на работу, которую вы явно не тянете.

Ну вот - вы даже не удосужились до сих пор прочитать описание своего UART. Который вроде как пытаетесь "программировать".
О чём тут можно ещё говорить???

Modbus / не Modbus - это ни сколько не мешает использованию DMA.
Но какой смысл вам объяснять если вы всё равно не поймёте? Вы же ничего не хотите читать и изучать...

Добавлено after 4 minutes:
Интересно - что тот директор скажет через некоторое время про вас?

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

Добавлено after 2 minutes 35 seconds:
просто я действую по принципу "вам не обязательно знать принципы радиосвязи, чтобы пользоваться телефоном". чтобы использовать RTOS, Modbus и Cube MX в необходимом для решения моих задач объеме не нужно знать ядро ARM... а постепенное погружение в то, что было не нужно, но может пригодиться, как раз и происходит в обсуждении моих вопросов.

Добавлено after 2 minutes 3 seconds:
в частности, Cube MX не создаёт код для работы с DMA, хотя соответствующие "галочки" имеет. как минимум, надо добавлять руками буферы и т.п. но чтобы добавлять, надо понимать, зачем, как и почему. что я и пытаюсь понять.

Добавлено after 9 minutes 13 seconds:
одно могу сказать точно - я этого вряд ли узнаю но вот что с гендиром согласны 100% остальных работников, пожалуй, доказывает его правоту...

P.S. в порядке офтопа, косвенно имеющего отношение к теме.
предшественник страшно увлекался "выделением" смысловых участков кода в виде блоков, т.е. помещал их в фигурные скобки. ну, например, в таком духеиначе говоря, в его исходниках количество фигурных скобок в разы превышает необходимое и достаточное. интересно, есть ли какой-то смысл в этом? внутриблочных локальных переменных он не использовал, с переменными все по канонам - в начале функций. предположение, что такая форма разделения на блоки имеет смысл при отладке, позволяя добавкой if(0) "заремарить" в одном месте сразу огромный участок кода (см. выше - экономия на вводе символов //) лично мне представляется сомнительной... читабельность кода от этого явно проигрывает...

Я вот это самое могу сказать про ваши примеры "кода". Вот таких "кодеров" - надо гнать в шею от программирования.

В чём именно вам видется "просёр"? Всё работает, UART работает через DMA, и потому - не требует микросекундной реакции на ISR.
Да и загрузка CPU - намного меньше, чем если бы он дёргался за каждым байтом в ISR.

Да - и то что вы называете "блокированием прерываний" происходит в любом ISR на ARM - он тоже по вашему "блокирует все прерывания с нижележащими приоритетами". И чем больше прерываний и чем больше уровней приоритета у них - тем большее "блокирование". И в вашем коде тоже (если конечно он у вас есть). Вы этого не знали? Печалька.

Если бы вы читали доки на STM32, то давно бы поняли, что бит, который поднимает UART при приёме байта, уходит в NVIC и в контроллер DMA, поэтому говорить, что специально сделан механизм обработки передач от UART по прерыванию, наверно, слишком сильно. Просто в NVIC завели без затей ещё один сигнал.

Опытный образец моего ПЛК на STM32 измерял среднее и среднеквадратическое значения токов и напряжений по 12 каналам (160 точек за период по каждому каналу), крутил 4 Модбас-мастера и отвечал по 2 двум как ведомый (6 UART на 115200). Помимо этого на МК работал рантайм ПЛК, который отлаживался по USB. У меня даже мыслей запускать всё это без DMA. Сильно сомневаюсь, какой-нибудь AVR-восьмибитник потянул бы такое.

Максимальная длина пакета определена в Стандарте на Модбас, чего достаточно для приёма. Приняли посылку, сравнили адрес ведомого в посылке со своим и широковещательным- всё предельно просто.

Со стареньким F1 так можно сделать, однако если вы внимательно посмотрите на мою картинку то увидите, что на относительно новых STM32 поля SMS и TS состоят из двух половинок расположенных в разных местах, SMS[2:0] и SMS[3], плюс TS[2:0] и TS[4:3], потому придется инить 4 битовых поля четырьмя разными значениями... Не очень удобно, еще и много лишних символов ) В любом случае даже в том виде в котором инииализация есть сейчас, с комментариями, она уже достаточно размашистая чтобы переживать касательно разницы между TIM1 и T1, а я вообще в функцию передаю ужастно длинные TimSlaveMode::GatedAndReset и TimTrgi::Tim12_Trgo, например )

tonyk, вероятно, я знаю намного меньше, чем мне кажется, но:
1. Какое отношение к приему пакета с помощью DMA имеет определенная в стандарте максимальная длина пакета?! Там что-то около 125 регистров максимум, т.е. 255 байт вместе со служебной инфой. Но минимальный пакет 8 байт. И как следует настроить DMA: на прием 255 байт, или 8?
2. На счет ваших удивительных ПЛК скажу, что всё упирается в камушек. Современные ПЛК на современных ARMах ваши задачи прожуют и высрут. Хотя для AVR даже решаемые мной задачи могут быть на грани возможностей. Речь-то не об этом шла... Неужели суть вопроса проглядели?
3. Ответ "сделали просто так, до кучи" принимается, и убеждает меня в правильности подхода "вали кулём, потом разберем". Иными словами, не стоит париться о неоптимальности решений. Но я чувствую, что вы хотели что-то другое этим сказать... Что?

не можете, раз раньше не сказали.


я ж вроде объяснил?


87мкс перманентной блокировки -- это полное фиаско при проектировании системы. не поленился, посчитал сколько проходит времени от взведения флага RXNE и до возврата в основной код. обработчик при этом складывает принятое в кольцевой буфер. при 72мгц тактовой получилось следующее (вход+код прерывания+выход): 236ns+416.7ns+250ns=902.7ns для наихудшего случая.


вы даже не представляете насколько больше. ща вам совсем кисло станет. чтобы код прерывания юсарта не отработал в течение 87мкс, перед ним или поверх него должны втиснуться 96 прерываний с более высоким приоритетом. это для самой неблагоприятной последовательности, когда прерывания не сцепляются (tail-chaining). Если они начнут сцепляться, то время вход/выход значительно сокращается и потребуется 173 прерывания, чтобы не дать обработчику прерывания юсарта принять байт. 173 прерывания за 87мкс -- это прерывания происходящие через каждые 502 наносекунды или с частотой около 2 мегагерц. помнится вы тут двадцатью тремя килогерцами всех стращали? ну так кушайте.


О своем побольше думайте.

Добавлено after 29 minutes 19 seconds:

c новеньким h5 та же фигня. сцепка Tim3+Tim1 будет выглядеть ровно так же.


не велика проблема:

Спойлер

Код:

typedef union {
  uint32_t r;
  struct {
    uint32_t SMS   : 4;   // Bits 3:0   - Slave mode selection
    uint32_t OCCS  : 1;   // Bit 4      - OCREF clear selection
    uint32_t TS    : 3;   // Bits 7:5   - Trigger selection [2:0]
    uint32_t MSM   : 1;   // Bit 8      - Master/slave mode
    uint32_t ETF   : 4;   // Bits 12:9  - External trigger filter
    uint32_t ETPS  : 2;   // Bits 14:13 - External trigger prescaler
    uint32_t ECE   : 1;   // Bit 15     - External clock enable
    uint32_t ETP   : 1;   // Bit 16     - External trigger polarity
    uint32_t       : 1;   // Bit 17     - Reserved
    uint32_t SMS2  : 1;   // Bit 18     - Slave mode selection [3]
    uint32_t       : 2;   // Bits 20:19 - Reserved
    uint32_t TS2   : 2;   // Bits 22:21 - Trigger selection [4:3]
    uint32_t       : 2;   // Bits 24:23 - Reserved
    uint32_t SMSPE : 1;   // Bit 25     - SMS preload enable
    uint32_t SMSPS : 1;   // Bit 26     - SMS preload source
    uint32_t       : 5;   // Bits 31:27 - Reserved
  };
} T_SMCR_t;

размашистая она только для наглядности и читабельности. Как только в этом нужда отпадает, он убирается в заголовочник и задвигается куда подальше. А вот разница между TIM1 и T1, она остается.


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

Дальше что? Теперь вам нужно инитить SMS, SMS2, TS и TS2...

Инитить какими значениями? А остальные поля SMCR большей частью ETR касаются, который не нужен может быть или наоборот, ETR нужен, слейв не нужен. Потому я просто пишу:

Понятно какие параметры могут потребоваться для настройки слейва и никакие другие случайно передать не получится, а если нужен ETR, то добавится вызов configEtrf(). Да, будет некоторая избыточность, но зато с большей вероятностью мне не придется лезть в документацию и комменты к коду тоже особо сильно не нужны.


HAL плох не идеей, а реализацией, так же как ардуино. Во-первых, это C, где нет строгих перечислений, потому они там все дефайнят и аргументы передают как uint32_t, в результате вместо SMS_TRG_MODE можно случайно передать TS_TIM3 или любую другую ерунду, потому дополнительно добавляют кучу рантайм проверок, многие из которых срабатывают только иногда и т.д..

257. Ни 8, ни 255, а 257.
Судя по постановке вопроса, у вас нет понимания ни о работе Модбас, ни о возможностях UART в STM32. В некоторых STM32 встроены полноценные UART с аппаратной поддержкой Модбас.

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

Как видно - говорить о разделении работы на уровни: канальный, протокольный, etc. - здесь не имеет никакого смысла. Всё равно что младенцу рассказывать о дифф.уравнениях...

Рано вам ещё за реальные задачи браться.

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

Итак, по сути. Модбас не укладывается в модель OSI, т.к. был придуман еще до его изобретения, если я не ошибаюсь. Длина пакета него переменная в принципе, хотя наиболее частая длина 8 байт, но при ошибках может быть 6, а при записи большого количества регистров-катушек, как было отмечено, может быть до 257 байт.

DMA - это низкоровневое железо, которое надо настроить. краем уха я слышал, что есть режим DMA, когда он принимает до прихода некоего управляющего символа - это тут не катит, так как для RTU-пакета такого символа нет. Так же мне тут говорили, что можно настроить прерывание на половине приема буфера - это тоже не катит, т.к. эта самая половина заранее неизвестна. Настроить прием максимально возможного буфера тоже нельзя, т.к. в этом случае при передаче короткого пакета буфер никогда не заполнится, и всегда будет таймаут (на стороне ожидающего ответа). Так как же правильно делать? можно настроить DMA на прием 2 байт, это гарантированно позволит поймать нжные байты, по которым можно вычислить, сколько еще там в пакете будет, но это всего в 2 раза "лучше", чем прерывание на каждый байт.
что я упускаю? Не представляю, как еще можно все настроить...

это вы сейчас утверждаете, или предполагаете? я пока что обнаружил встроенную поддержку аппаратного переключения RX-TX, что и применяю. но никакой дргой поддержки модбас я пока не видел (но я и видел мало, как вы уже ранее верно подметили). я ранее интересовался: а как же девайсы на 8-битниках двадцатилетней давности модбас тянут?! И другие "приоритетные" задачи тоже как-то тянут...
a5021 тут недавно практически доказал, что для "перегрузки" байтами USARTа (т.е. для возникновения пропусков) надо создать невероятно дикую нагрузку остальной периферии, что представляется маловероятным.
может быть, не так уж и плох метод побайтного приема? для не грандиозных задач хотя бы? реализуется даже такими тупарями, как я, работает на уровне "профессиональных решениий"... что не так-то?

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

да все тут просто. определяем макросы. все что нужно и что не нужно:

Спойлер

Код:

/* Slave Mode Selection Macros */
#define SMS_DISABLED        .SMS=0x0, .SMS2=0    //  0000: Slave mode disabled
#define ENCODER_MODE1_X2    .SMS=0x1, .SMS2=0    //  0001: Encoder mode 1, x2
#define ENCODER_MODE2_X2    .SMS=0x2, .SMS2=0    //  0010: Encoder mode 2, x2
#define ENCODER_MODE3_X4    .SMS=0x3, .SMS2=0    //  0011: Encoder mode 3, x4
#define RESET_MODE          .SMS=0x4, .SMS2=0    //  0100: Reset mode
#define GATED_MODE          .SMS=0x5, .SMS2=0    //  0101: Gated mode
#define TRIGGER_MODE        .SMS=0x6, .SMS2=0    //  0110: Trigger mode
#define EXT_CLOCK_MODE1     .SMS=0x7, .SMS2=0    //  0111: External clock mode 1
#define RESET_TRIGGER_MODE  .SMS=0x8, .SMS2=1    //  1000: Reset + trigger (SMS[3]=1)
#define GATED_RESET_MODE    .SMS=0x9, .SMS2=1    //  1001: Gated + reset (SMS[3]=1)
#define ENCODER_CLK_DIR_X2  .SMS=0xA, .SMS2=1    //  1010: Clock + dir, x2 (SMS[3]=1)
#define ENCODER_CLK_DIR_X1  .SMS=0xB, .SMS2=1    //  1011: Clock + dir, x1 (SMS[3]=1)
#define ENCODER_DIR_CLK_X2  .SMS=0xC, .SMS2=1    //  1100: Directional clock, x2 (SMS[3]=1)
#define ENCODER_DIR_CLK_X1  .SMS=0xD, .SMS2=1    //  1101: Directional clock, x1 (SMS[3]=1)
#define ENCODER_X1_TI1      .SMS=0xE, .SMS2=1    //  1110: x1 TI1 edges (SMS[3]=1)
#define ENCODER_X1_TI2      .SMS=0xF, .SMS2=1    //  1111: x1 TI2 edges (SMS[3]=1)

/* Trigger Selection Macros (TS[4:0] = TS2[1:0] + TS[2:0]) */
/* Internal Triggers (ITRx) */
#define TRIG_ITR0           .TS=0x0, .TS2=0x0    // 00000: Internal Trigger 0
#define TRIG_ITR1           .TS=0x1, .TS2=0x0    // 00001: Internal Trigger 1
#define TRIG_ITR2           .TS=0x2, .TS2=0x0    // 00010: Internal Trigger 2
#define TRIG_ITR3           .TS=0x3, .TS2=0x0    // 00011: Internal Trigger 3
#define TRIG_ITR4           .TS=0x0, .TS2=0x1    // 01000: Internal Trigger 4
#define TRIG_ITR5           .TS=0x1, .TS2=0x1    // 01001: Internal Trigger 5
#define TRIG_ITR6           .TS=0x2, .TS2=0x1    // 01010: Internal Trigger 6
#define TRIG_ITR7           .TS=0x3, .TS2=0x1    // 01011: Internal Trigger 7
#define TRIG_ITR8           .TS=0x0, .TS2=0x2    // 01100: Internal Trigger 8
#define TRIG_ITR9           .TS=0x1, .TS2=0x2    // 01101: Internal Trigger 9
#define TRIG_ITR10          .TS=0x2, .TS2=0x2    // 01110: Internal Trigger 10
#define TRIG_ITR11          .TS=0x3, .TS2=0x2    // 01111: Internal Trigger 11
#define TRIG_ITR12          .TS=0x0, .TS2=0x3    // 10000: Internal Trigger 12
#define TRIG_ITR13          .TS=0x1, .TS2=0x3    // 10001: Internal Trigger 13
#define TRIG_ITR14          .TS=0x2, .TS2=0x3    // 10010: Internal Trigger 14
#define TRIG_ITR15          .TS=0x3, .TS2=0x3    // 10011: Internal Trigger 15
                                       
/* External Triggers */                             
#define TRIG_TI1_ED         .TS=0x4, .TS2=0x0    // 00100: TI1 Edge Detector
#define TRIG_TI1FP1         .TS=0x5, .TS2=0x0    // 00101: Filtered TI1
#define TRIG_TI2FP2         .TS=0x6, .TS2=0x0    // 00110: Filtered TI2
#define TRIG_ETRF           .TS=0x7, .TS2=0x0    // 00111: External Trigger

теперь любые инициализации:

понятия не имею, будет это работать или нет. просто иллюстрация принципа.


нормально у них и с тем и с тем, если смотреть, как на обучающие материалы раннего этапа.


это надо отдельных чудес иметь полну голову, чтобы вместо .SMS=SMS_TRG_MODE, .TS=TS_TIM3 что-то перепутать.
никто не убивается, что в TIM1->CR1 можно запихать USART_SR_RXNE и ровно по той же причине.

Теперь еще и единообразие инициализации потеряли ) Человек начнет код набирать, IDE ему предложит ".SMS =" подставить, значит нужно знать, что для этого поля у нас исключение и нужно подставлять макрос, а как эти макросы искать предлагаете? Раньше ваш макрос хотя бы с того же "SMS_" начинался, теперь нужно подставить нечто без специфического типа, начинающееся непонятно с чего и задефайненное непонятно где. Сравните с функцией:

Спойлер

Да постоянно люди путают, даже ST-ые определения в которых названия регистра и поля указаны. SMS_TRG_MODE, конечно, тяжело спутать с TS_TIM3, но в целом похожих названий более чем достаточно. SMSPS и SMSPЕ, например. ETP и ETF.

Вы давно используете Modbus-RTU и не знаете, что кадры в нём разделяются паузами? И тогда вроде как одно из очевидных решений - завести сигнал RXD на вход сброса/перезагрузки таймера и по таймауту принудительно останавливать DMA.
А в каких-то STM32, как выше уже упоминали, есть и аппаратная поддержка этого в самом UART.

То есть задействование трех периферийных устройств вместо одного считается правильным и эффективным решением?! Мда... Неожиданно.