Компания MEAN WELL пополнила ассортимент своей широкой линейки светодиодных драйверов новым семейством XLC для внутреннего освещения. Главное отличие – поддержка широкого спектра проводных и беспроводных технологий диммирования. Новинки представлены в MEANWELL.market моделями с мощностями 25 Вт, 40 Вт и 60 Вт. В линейке есть модели, работающие как в режиме стабилизации тока (СС), так и в режиме стабилизации напряжения (CV) значением 12, 24 и 48 В.
Интересно, когда до вас дойдет, что моё отношение есть квинтэссенция общего отношения новичков к тому, чем вы занимаетесь?! И ваше отношение полностью укладывается в это...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
давайте я вам еще странного подкину? например, мне иногда начинает действовать на нервы довольно длинное написание всяческих имен и я прибегаю к сокращениям: Спойлерпереопределяем в укромном месте все или только используемые имена периферии:
/* ================== Core System Peripherals =========== */ #define B (*BKP) /* Backup Registers (0x40006C00) */ #define C (*CRC) /* CRC Calculation Unit (0x40023000) */ #define C1 (*CAN1) /* CAN1 Controller (0x40006400) */ #define D (*DBGMCU) /* Debug MCU (0xE0042000) */ #define E (*EXTI) /* External Interrupts (0x40010400) */ #define F (*FLASH) /* Flash Memory (0x40022000) */
/* === GPIO Port Registers ============ */ #define PA (*GPIOA) /* GPIO Port A (0x40010800) */ #define PB (*GPIOB) /* GPIO Port B (0x40010C00) */ #define PC (*GPIOC) /* GPIO Port C (0x40011000) */ #define PD (*GPIOD) /* GPIO Port D (0x40011400) */
Бедный тот, кому, возможно, придётся вникать в понаписанное Вами.
_________________ Платы для HLDI - установки лазерной засветки фоторезиста. ФоторезистыOrdyl Alpha 350 и AM 140. Жидкое олово для лужения плат (видео) - самое лучшее и только у меня. Паяльная маска XV501T-4 и KSM-S6189 (5 цветов). Заказ печатных плат - pcbsmac@gmail.com
Лучше бы рассказали, чем руководствоваться при выборе варианта работы USART через DMA или традиционно по прерываниям. Например, я анализирую код предшественника и вижу, что USART у него сделан через DMA, хотя какого-то напряженного обмена быть не может, т.к. скорость не выше 115200 и пакеты в среднем 8 байт. В итоге код очень сложный для новичка (меня), т.к. проследить связность сложно, все в разных модулях, и не очевидно, по каким событиям тот или иной код вызывается. В библиотечке modbus, которую я применил, все сделано на прерываниях, и разобраться гораздо проще, тем более, что там все на событиях RTOS. В доке на эту либо говорится, что DMA желательно применять при скоростях больше 115200, хотя обоснования так же нет. В случае RTOS и упомянутых скоростей еще проще можно вообще поллингом данных в отдельной задаче обойтись, и ничего, имхо, не потерять, а приобрести полную прозрачность кода.
Так что определяет метод работы? Какая логика?
Добавлено after 5 minutes 5 seconds: Просто в периферии stm32 огромное число разных режимов "можно то и можно это", но не всегда очевидно, для каких задач то или это предпочтительнее.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Бедный тот, кому, возможно, придётся вникать в понаписанное Вами.
мне кажется вы принижаете когнитивные способности "бедного того". данный простой пример не привносит новые сущности и вникать тут не во что. смотрим на референс: смотрим на код:
Код:
T1.CR1 = (T1_CR1_t){.DIR=1, .OPM=1, .CEN=1}.r;
насколько мощно здесь зашифрована суть действия, если учесть, что в правой части выражения находится стандартный для си инициализатор структуры?
Например, я анализирую код предшественника и вижу, что USART у него сделан через DMA, хотя какого-то напряженного обмена быть не может, т.к. скорость не выше 115200 и пакеты в среднем 8 байт.
Причём тут какой-то "напряжённый обмен" и длина пакетов? Если речь о STM32 с их примитивным UART, в котором даже нет FIFO, то даже без некоего "напряжённого обмена" с кадрами любой длины, при скорости 115200 бод, средняя частота прерываний от UART составит 115200/10*2 = ~23кГц. Что может быть слишком много для некоторых применений. Достаточно если в какой-то момент времени сумма длительностей более приоритетных ISR + запрет прерывания в фоне будет >= ~87 мкс - как тут же получите потерю принимаемых данных. Если будете работать без DMA. А DMA спасёт от этого.
Написал один раз драйвер UART с DMA и далее пользуюсь им во всех проектах на STM32. Хоть с 921600 бод, хоть с меньшими скоростями. Не переписывая каждый раз. Вот и вся логика. Это лучше, чем под каждый проект ваять и отлаживать заново.
При работе через DMA я получу одно прерывание в конце пакета, вы- 8. При отправке мне нужно обработать 2 прерывания,вам- 8. Заметьте, что количество прерываний при работе через DMA не зависит от длины пакета. Я уже не говорю о том, что при работе через DMA нет разницы, на какой скорости работает работает UART, 9600 бит/с или 10 Мбит/с.
ARV писал(а):
все в разных модулях
Поэтому логично использовать С++, тогда весь код оказывается в одном модуле. Спойлер
Код:
// Заголовок
class UART_base : public AbstractTransport, protected IRQ { ....... //---------- // Читает в буфер buff размером buffSize байты из буфера приёмника. // Работает в неблокирующем режиме! // Возвращает количество прочитанных байт или ноль в случае // отсутствия доступных для чтения данных. virtual int16 receive ( void* buff, int16 buffSize, MODE mode = NON_BLOCK ) = 0;
//---------- // Записывает buffSize байт из буфера buff в буфера передатчика. // Работает в неблокирующем режиме! // Возвращает количество записанных байт или ноль в случае // невозможности записи. lastError указывает на ошибку. // Перед вызовом send(..) во избежании склеивания отправляемых // посылок, необходимо вызывать getAvailableTxBytes(..) для проверки // того, что буфер передатчика пуст. virtual int16 send ( void* buff, int16 buffSize, MODE mode = NON_BLOCK ) = 0; ....... };
Лучше бы рассказали, чем руководствоваться при выборе варианта работы USART через DMA или традиционно по прерываниям
Применительно к МК уровня STM32 как раз нетрадиционным способом является приём-отправка одного байта с генерацией прерывания. Да, это возможно, как и наличие по мнению целого ЕС аж 42 гендеров. С ростом тактовой частоты процессоров прерывания становятся очень дорогими в части потери производительности из-за сброса кэшей опережающей выборки. Поэтому весь обмен через UART логично делать с использованием DMA, даже консоль.
Код:
class ConIO : public MB_RTU_UART, Task { };
Обратите внимание, что консоль использует методы приёма-отправки данных из класса Модбас, в котором весь обмен идёт с использованием DMA.
В случае RTOS и упомянутых скоростей еще проще можно вообще поллингом данных в отдельной задаче обойтись, и ничего, имхо, не потерять, а приобрести полную прозрачность кода.
Для новичка полезнее разобраться в работе того, что имеется. А не пытаться перекостыливать работающее хорошее решение, на кривое поделие. Иначе - так навсегда новичком и останется. Перекостыливание на более простой вариант (потому как "не понимаю как оно работает") - это не развитие, а деградация.
Применительно к МК уровня STM32 как раз нетрадиционным способом является приём-отправка одного байта с генерацией прерывания. Да, это возможно, как и наличие по мнению целого ЕС аж 42 гендеров.
И как же вы STM32 пользуетесь? Который в этом самом ЕС и разработан? Почему не чем-то православным?
Достаточно если в какой-то момент времени сумма длительностей более приоритетных ISR + запрет прерывания в фоне будет >= ~87 мкс - как тут же получите потерю принимаемых данных.
какой-то притянутый пример. 87мкс на 72мгц -- это что-то в районе 6 тыс инструкций. невозможно понять, кому и зачем может потребоваться такой объем работ при запрещенных прерываниях.
Цитата:
И как же вы STM32 пользуетесь? Который в этом самом ЕС и разработан?
сгущаете. чтобы пользоваться stm32, вовсе не обязательно долбиться куда попало.
Достаточно если в какой-то момент времени сумма длительностей более приоритетных ISR + запрет прерывания в фоне будет >= ~87 мкс - как тут же получите потерю принимаемых данных.
какой-то притянутый пример. 87мкс на 72мгц -- это что-то в районе 6 тыс инструкций. невозможно понять, кому и зачем может потребоваться такой объем работ при запрещенных прерываниях.
Научитесь внимательнее читать то, на что отвечаете: "сумма длительностей более приоритетных ISR + запрет прерывания в фоне." Что такое "более приоритетные ISR" (более приоритетные чем UART) - понимаете? Это когда какое-то событие должно быть обработано срочно, с минимальной задержкой.
И это не "в районе 6 тыс инструкций", а как правило - гораздо меньше. Читаем систему команд ARM.
На счёт "притянутости за уши": Обычная RTOS, упоминавшаяся здесь, может запретить прерывания (если критические секции в ней так организованы) на несколько сотен тактов запросто. А некоторые - может быть и более тысячи тактов в каких-то случаях.
Что такое "более приоритетные ISR" (более приоритетные чем UART) - понимаете?
понимаю я следующее: тому, кто допускает блокирование прерываний на 87мкс, вне зависимости от ситуации, лучше чем-то другим заняться, а не про стм32 рассуждать.. 87мкс в данном контексте -- это архитектурный просёр размером с галактику.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 15
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения