- Возможно ли на STM32 сделать так, чтобы один его ЦАП работал на
внутреннем Vref, а другой на внешнем? Kceния(93 знак., 18.07.2020 08:16, ARM, полностью)
- По моему там и АЦП обычно в куче. Работал с F1, F4, L4. - VLLV(18.07.2020 19:11)
- Имя, сестра! Имя! Они все заметно разные, указывайте конкретную
модель. - LightElf(18.07.2020 12:33)
- Мне любую назовите, которая это может. У меня же пока впечатление,
что не может ни одна. Kceния(463 знак., 18.07.2020 20:26)
- Задействовать встроенные (например в G4) операционники не вариант? - LightElf(19.07.2020 17:59)
- А в чём выигрыш по сравнению с "умножить в цифре и вывести на
единственный ЦАП" ? - Samx(19.07.2020 02:50)
- Если умножать, то пришлось бы по одной точке клевать - умножаешь,
выплевываешь в ЦАП, ждешь завершения операции. А у меня несущая
поступает на DAC1 непрерывно циклической передачей из буфера через
DMA (как у DDS). А огибающая, будучи низкочастотной, уже может
быть, не торопясь, вычислена (например, распаковкой MP3), т.к.
время здесь уже есть. Кроме того, мелкие нарушения периодичности
при изменении огибающей на слух незаметны, тогда как нарушения
периодичности несущей Kceния(110 знак., 19.07.2020 03:45)
- А что мешает умножить в цифре все значения несущей в буфере на
медленную огибающую, сохранить эти значения в новом (или в том же)
буфере, а уже потом "непрерывно циклической передачей из буфера
через DMA (как у DDS)" подать на DAC1 уже промодулированные
значения? - Xaoc(19.07.2020 18:18,
)
- Ну против джиттера есть буферизация. Скажем, по таймеру выводим
предыдущее рассчитанное значение и Samx(57 знак., 19.07.2020 04:11)
- Если по таймеру выводить, то еще медленнее будет, т.к. придется
зарекаться на самый медленный случай. А вы вообще в курсе, какого
порядка радиочастоты? - Kceния(19.07.2020 04:32)
- RF band: 47 MHz to 6.0 GHz: Xaoc(6 знак., 19.07.2020 04:56,
, ссылка)
- Это слишком жирно для меня. Моя задача скромнее: несущая 150 КГц,
представленная хотя бы 128-ю точками, итого 19.2 МГц на DAC (вроде
бы должен успевать). - Kceния(19.07.2020 05:19)
- вы можете сделать это ШИМом с входной частотой 19М а потом
отфильтровать этот ШИМ - General(19.07.2020 18:57)
- Хм. "Мелкие нарушения огибающей" (один сомножитель) не страшны, но
при этом несущая (второй сомножитель) зачем-то представляется 128
отсчетами на период. Samx(164 знак., 19.07.2020 14:37)
- Сотый раз спрошу, откуда такая "скромность" - 128 точек? - Kpoк(19.07.2020 11:18)
- Мы про эту задачу читали года два назад ещё. Сколько можно?
Некоторые за это время уже бы 500 проектов сделали! - fk0(19.07.2020 10:45)
- Задача может быть всегда одна, скажем, радиосвязь или телефония, но
иметь множество различных реализаций. Собственно и сам прогресс
идет в основанном за счет повышения эффективности решений, а не за
счет выдумывания новых задач. А ваше замечание того же рода, как
"Попов же уже изобрел радио, сколько можно этим заниматься?". - Kceния(19.07.2020 11:12)
- Вообще-то, ещё три года назад.. Увы и ах!.. Xaoc(20 знак., 19.07.2020 11:08,
, ссылка)
- А может банальный ГУН/АМ модулятор и не тянуть сюда ЦОС? - VLLV(19.07.2020 09:00)
- Для этого есть сразу RF-микроконтроллеры. lloyd(96 знак., 18.07.2020 21:14)
- stm32f103 + usb - а где конфиг порта?... POV_(324 знак., 10.07.2020 11:33,
, ARM, полностью)
- на какой реальной (а не теоретической) скорости можно затаскивать
данные по USB в одноплатник класса Orange PI One, ZeroPI, NanoPI и
пр. делаю приблуду, где первый какой-то старший STM32 снимет образ
специальной камерой и этот образ весом в 3 МБ надо максимально
быстро (не более 100...150мс есть на это) затащить в одноплатник
для последующего кручения-верчения. Sylvan(207 знак., 17.07.2020 11:06, ARM, полностью)
- [i.MX RT600] 300 МГц Cortex-M33, 4.5 МБайта SRAM, PowerQuad DSP, Cadence Xtensa HiFi4 Audio DSP 600 МГц, BGA 0.5 с прорежением,
-20 °C to +70 °C Evgeny_CD(906 знак., 16.07.2020 02:53 - 02:56, ARM, ссылка, ссылка, полностью)
- Есть ли в природе быстрая
арифметика конвертация данных 24->32 бит из массива для Cortex M7? BlackMorda(1321 знак., 07.07.2020 09:21, ARM, ссылка, ссылка, полностью)
- Не хочет USART2 в STM32L072 корректно работать на прием. BlackMorda(826 знак., 29.06.2020 19:39, ARM, ссылка, полностью)
- Как-то подобная проблема была, решилось переводом пинов в режим low
speed и включением внутренних подтяжек чипа. TX умудрялся насрать в
RX, несмотря на подключенный к ним ST232 - LightElf(03.07.2020 10:20)
- "Пауза одна секунда"??? А ничего, что от модема тут же обратно
данные попрут и их куда-то складывать нужно? - fk0(30.06.2020 10:49)
- а подробней можно про "все равно помехи"? У меня вот L476 тоже
связан с SIM800 но через USART3. Случайным образом на приеме
портились байты (абстрактные символы выскакивали). На любой
скорости от 9600 до 115200. Долго грешил на автоопределение
скорости. Выключил ее и в начале сразу задаю 115200. Стало реже, но
проскакивает. Вроде бы поигрался уровнями и вместо требуемых 2,8В
выставляю 2,6В. Стало вроде совсем хорошо. Но гарантии? - Лaгyнoв(30.06.2020 09:54)
- А если посылать единичный байт с интервалом сотню мс, есть сбои?
Два стопа на передачу в пакете, есть сбои? - VLLV(29.06.2020 22:15)
- "TXE устанавливается вместе с ошибками ORE NF FE" бррр, "ORE NF FE"
у вас данные как минимум не вычитаны из DR регистра. касаемо TXE
онтам всегда висит , смотрим на TCI флаг - Aleksey_75(29.06.2020 19:57)
- stm32, uart, борьба с эхом ))) Aleksey_75(640 знак., 02.07.2020 20:27, ARM, полностью)
- Если не склероз, эхо на LIN необходимо, чтобы определять коллизии.
Щетаю, что вам надо не подавлять его, а всячески пользовать. И
ориентироваться на RXNE/IDLE вместо TXE/TC. Ну и камень конкретный
указать, да еще и номера USART на нем, они часто разные. - LightElf(03.07.2020 10:12)
- Любое эхо можно отсечь. На то оно и эхо. il-2(635 знак., 03.07.2020 07:55)
- В общем случае от эха принципиально не избавиться. Такая же
проблема как с модемом (когда ATE1). Ты должен понимать протокол и
игноровать эхо. Трюки с запретом приёма сомнительные, т.к. требуют
исключительно точного соблюдения таймингов (на МК можно
извернуться, но и то с ньюансами), а если предположить "резиновый"
fifo-буфер на передачу и приём (как это происходит с типовой
операционкой), то никак. - fk0(02.07.2020 23:39)
- 1. Сталкивался еще на токовой петле. Нет красивого решения, эхо в
шлюзе может быть подавлено только для пакетного обмена, если
предусмотрен тайм-аут с запасом. 2. Сталкивался недавно в
оптическом канале см ссылку, но проект заглох, и хз как придется
выпутываться. - VLLV(02.07.2020 20:44)
- Что то не могу найти инфу - если я возьму stm32 , прошью его в
stm32duino - смогу ли я использовать arduino библиотеки для TFT
дисплея ili9341, или там нереальный гимор? Задача - вывести на
дисплей крупный текст, не парясь с попиксельныйм выводом, а юзая
вызов библиотеки. Что то под HAL и SPI не могу найти простого
решения для BluePill stm32f103c8t6 - Mty1(28.06.2020 01:02, ARM, полностью)
- Интересное поведение UART на STM32 Aleksey_75(552 знак., 27.06.2020 16:01, ARM, полностью)
- Любопытно, раньше мне казалось, что GCC от ARM под bare metal не
поддерживает Cortex-A*, а теперь четко написано, что он
поддерживает все известные Cortex - Evgeny_CD(21.06.2020 03:16, ARM, ссылка, полностью)
- У кого то получалось запустить SDMMC2 на STM32H743? Alt@ir(23 знак., 20.06.2020 06:10, ARM, полностью)
- git репозиторий тулсов и либ ST klen(271 знак., 18.06.2020 18:57, ARM, ссылка, полностью)
- STM32 UART работает со сбоями. Проект/код сгенерен в CUBEMX RxTx(894 знак., 16.05.2020 16:49, ARM, полностью)
- Еще раз повторюсь. Очень ценю вашу заботу и поддержку. Спасибо,
ребята! (но на этом не заканчиваем, продолжаем, продолжаем :))) - RxTx(17.05.2020 12:31)
- Всем спасибо, решено. - RxTx(16.05.2020 20:52)
- Что было-то? - NAUT(16.05.2020 21:12)
- Я пока что в командировке, так что "решено" это условно, временно.
Я к тому так написал чтобы не ломали голову из-за меня, как бы не
тратили энергию. Но если есть какие-то мысли, конечно пишите.
Приеду домой, буду разбираться, трассировать времянки итд. "Решено"
так: сделал код прерывания как можно более коротким, просто запись
в ring buffer. Об этом писал здесь: и один из UART'ов у меня уже
был так построен. Этот (отладочную консоль) я перевел, остался еще
один, RxTx(2428 знак., 17.05.2020 10:11 - 20:16, ссылка)
- Кстати в любой функции оперирующей с указателями на данные
доступными из нескольких потоков (тот же ring buffer) можно
запросто нарваться на перестановку порядка обращения к переменным.
И volatile не поможет: gcc все эти volatile аккуратненько вынесет в
конец функции и там запишет в том же порядке. Я на когда такое
впервые увидел, чуть не рехнулся пока баг разгадывал. Поэтому после
изменения указателей или после записи данных перед продвижением
указателя нужно обязательно fk0(383 знак., 17.05.2020 13:09)
- Приоритеты -- ещё один повод, почему блокирующихся функций в
обработчиках быть не должно. С равноприоритетными прерываниями оно
не так страшно. Про шаговый двигатель я вынес для себя на всю
жизнь: не нужно его крутить по шагам. Нужно крутить фазу с
фиксированным временным шагом. Достаточно коротким, чтоб на низких
скоростях разницы не было, а на высоких автоматически получается
пропуск микрошагов (иначе контроллер не успеет). И здесь важно,
чтоб джиттер был fk0(36 знак., 17.05.2020 12:26)
- Переменные status и b объявлены как volatile. Добавляем тормозов на
основании каких-то странных суеверий, видимо. - SciFi(17.05.2020 11:19)
- "В mainloop выгребаю из ringbuffer" - видимо без критической
секции, если во время выгребания придет прерывание и запишет в
буфер данные, то кирдык? запрещать прерывания надо бы на время
чтения - NAUT(17.05.2020 10:56)
- Не надо запрещать, поскольку именно эта схема "Один Писатель - Один
Читатель" с двумя изолированными и "догоняющими" друг друга readpos
и writepos переменными сравниваемыми в одном месте LockFree. RxTx(63 знак., 17.05.2020 11:15)
- Ну, кагбэ, вопрос "че делать, если в буфере нет места" - нужно
задавать до написания реализации ring buffer. Собственно вариантов четыре: LightElf(394 знак., 17.05.2020 21:47)
- +1. Проблемы с детектированием наезда, на необработанные данные,
обгона указателя чтения, можно решить, если использовать не
указатели, а индексы -- тогда освободятся старшие биты, в которых
можно хранить счётчик. Ну или если есть 64-битные атомики. А если
потеря данных не допустима, то увы, нужен семафор и условная
переменная. fk0(1191 знак., 17.05.2020 12:53, ссылка, картинка)
- скажет только под пытками. :-) - Лaгyнoв(17.05.2020 08:44)
- 1. IMHO, UART, таймеры, GPIO, *WDG - проще и практичнее
использовать LL HAL. Все равно, у вас смесь - инициализация - HAL,
непосредственно прием - используете регистры. На мой взгляд, если
уже использовать HAL - то использовать до конца. Другой вопрос, что
для простой периферии HAL избыточен. A.L.(282 знак., 16.05.2020 18:13)
- Это прекрасно, я только что задавал вопрос, как быть, если
результат кодогенерации куба подводит... Я только не понял, зачем у
тебя из USART1 перекладывается в отладочный порт -- какой в этом
смысл? Loopback test? Вначале сделай простой цикл в main, без
прерываний. Вызывать блокирующуюся функцию ITM_SendChar в
прерывании -- вообще идиотизм. Во-вторых где гарантия, что у тебя
отладочный порт _быстрее_, чем UART? А то будет, что ты в
обработчике прерывания зависаешь fk0(437 знак., 16.05.2020 17:07)
- Возможно какие-нибуь ошибки приёма - Vit(16.05.2020 16:55, ссылка)
- Поможите!!! Слетел ST-Link в Иаре. Все прекрасно работало, и
вдруг... В ST-Link Утилите прекрасно работает. Среда Win7 64, Iar 7.80.
Нутром чую, надо что-то почистить. - IBAH(25.05.2020 17:19, ARM, полностью)
- Может кто сталкивался, STM32F0, USART, HAL. Если есть эхо, все ложится. Задача имеет решение в плоскости HAL? - VLLV(30.11.2019 19:46, ARM, полностью)
- Когда я этим занимался то узрел драму, в хал отсутствует функционал
одновременной работы уарта на прием и передачу, только полудуплекс. - кaлян(18.05.2020 10:57,
)
- в жизни такого у меня нигде не было (одновременно прием/передача) - Лaгyнoв(18.05.2020 12:34)
- Значит жизнь ваша - блеклая и однообразная :) Куча протоколов связи, на двунаправленных каналах связи -
инициатором обмена может быть любая сторона соединения. Немного
непривычно, по структуре драйвера, но ниче-такова. - Cкpипaч(20.05.2020 09:17)
- реализация онвире через уарт, там tx rx замыкается гвоздем и все
что с девайса принимается только эхом. кaлян(192 знак., 19.05.2020 10:59,
)
- При работе с модемом это именно так. От него что-то прилететь может
в любой момент времени. - fk0(18.05.2020 12:46)
- а оно мне зачем? Мне нужно только то, что я спросил. - Лaгyнoв(18.05.2020 16:52)
- Мне кажется, если ты не понимаешь, то этот тот самый Данинг-Крюгер. - fk0(18.05.2020 16:57)
- Прознали, бляь, модное, теперича лепят куда угодно, к месту и не к
месту. Беда только в том что каждый считает что его-то уж точно
обошло, он не такой. Ан нет! Все не дискретно, а аналогово,
континуально. К каждому применимо. Не стыдно Данингом родиться,
стыдно Крюгером умереть =) - RxTx(18.05.2020 20:10)
- это кто? Я вероятно повторюсь. Зачем мне знать то, что мне
поступило на Rx, если я этого не спрашивал? Как-то я в последние 25
лет привык к тому, что я спрашиваю - мне отвечают. Меня спрашивают
- я отвечаю. Все известные мне протоколы обмена так устроены. - Лaгyнoв(18.05.2020 18:49)
- в L476, HAL. Без разницы - есть эхо от модема, или нет. Всё нормально. Просто ты должен помнить, что осмысленные символы поступят через N байт. - Лагунов(01.12.2019 14:25)
- встречал похожее, но не на F0. флаг ORE чистится не автоматом, а ручками - записью ORECF в USART_ICR. если возник при разрешенном приеме, то, пока не прочистишь, висишь в обработчике приёма - Vit(01.12.2019 10:25)