Xenia

Про пайку в даташите ничего не нашла - температуры приведены только на рабочий диапазон. Конкретно меня интересует "дамский" контроллер STM32F103C8T6 :).

А до какой температуры можно греть микруху феном? Пусть не с шариковыми выводами, а с обыкновенными?

Замечание модератора верно - в самом деле информации слишком мало. Тем более что при обсуждении операции ввода вывода (или, как выразился топикстартер, "ногодыга") необходимо знать не только компилятор, то и тип контроллера. Но попробую сделать выводы из той куцей информации, что имею. Во-первых слово "ODR" сильно напоминает сокращение "Output Data Register", бытующего у контроллеров архитектуры ARM, в частности у семейства stm32. Отсюда очень вероятно, что дефиниция bit_addr (gpioa_odr_addr, n) обозначает n-ый бит регистра GPIA->ODR, а дефиниция #define ad9854_wr paout (5) обозначает 5-ый бит этого этого регистра, соответствующий пину PA5 порта контроллера. Следовательно дефиниция ad9854_wr = 0; означает обнуление этого бита и выдачей на пин PA5 низкого уровня. Однако если компилятор ругнулся на ad9854_wr = 0; То, скорее всего, потому что дефиниции следует располагать в обратном порядке #define paout (n) bit_addr (gpioa_odr_addr, n) // output #define ad9854_wr paout (5) и только после этого можно писать ad9854_wr = 0; Хотя я бы предложила вообще не пользоваться этими дефициями, а шевелить ножкой PA5 так: Ножку поднять: GPIOA->ODR | (1 << 5); // добавляем 5-ый бит в ODR Ножку опустить: GPIOA->ODR & ~(1 << 5); // стираем 5-ый бит из ODR Хотя правильнее дергать ножкой не через регистр ODR, через регистр BSRR: void Set_PA_bits( unsigned char val) { GPIOA->BSRR = ((uint8_t)~val << 16) | val; }

А вы уверены, что HC-05 должен работать на скорости 230400 без ошибок? Какие у него на этот счет паспортные данные? P.S. У меня HC-06, и я с ним работаю на скорости 9600 baud :).

На мой взгляд, вы придираетесь не по делу. Функция из HAL'а, которую я использовала в приведенном мной отрывке кода __HAL_GPIO_EXTI_CLEAR_IT( GPIO_PIN_1); как и многие из тех, которые начинаются двумя подчеркиваниями, является чистым дефайном, который определен так: #define __HAL_GPIO_EXTI_CLEAR_IT(__EXTI_LINE__) (EXTI->PR = (__EXTI_LINE__)) при подстановке моих значений он в превращается в выражение: EXTI->PR = 2 Где вы тут разглядели неатомарность? А во-вторых то явление, которое я описала, представляет собой парадокс, когда одни линии прерывания работают без сбоев до частоты 16 КГц, несмотря на то, что их соседки, считающие более высокие частоты, захлёбываются, не успевая сосчитать все импульсы. Тогда как если бы захлёбывание было вызвано нехваткой ресурсов, то эта нехватка отразилась бы на всех линиях, а не только на тех, которые считают на высоких частотах. Тогда как неатомарность не обладает лечебными свойствами. А какой момент времени считать выходом из текущего прерывания? На этот счет могут существовать два разных мнения: Первое: момент снятия флага. Второй: завершение обработчика оператором return. Который их этих двух случае вы имели виду, когда давали мне свой совет? Лично я придерживалась первого мнения, а потому и опасалась, что прерывание окажется законченным в момент снятия флага, и боялась, что не успела завершить процедуру обработки до этого момента.

Ну, я не утверждал, что это поможет)) Просто так несколько правильнее писать обработчик. А я наоборот опасалась, что если сниму флаг прерывания раньше, чем закончу выполнять обработчик, то прерывание сможет возникнуть еще раз, после чего станет неясно, какой из обработчиков выполнится первым.

Есть такое - у меня UART в связке с DMA гоняет текст на терминал (именно так я слежу за показаниями счетчиков), причем у UART'а 1-ый приоритет, а у DMA нулевой. Тогда как у EXII приоритет только 4-ый. Однако прошу объяснить мне, как наблюдаемый мною эффект можно объяснить через приоритеты.

Перенесла, но ничего не изменилось - наблюдаю всё тот же эффект. Проверила эту гипотезу - она не подтверждается, поскольку "от перемены мест слагаемых сумма не изменилась". Т.е. безупречный счет на остальных двух счетчиках продолжается вне зависимости от того, который из трех счетчиков я заставляю захлебнуться. Проверила логическим анализатором, но не непосредственно тактовую контроллера (поскольку ее выхода нигде на плате нет), а выход таймера при параметрах PSC=0, ARR=0 и получила частоту APB2=72 МГц. Прошу вас заметить, что я не на задержку жалуюсь, а на ее отсутствие (!), тогда как по идее "захлебывание" одного счетчика должно было бы вызвать захлебывание всех остальных, тем более при недостатке тактовой частоты. А если вы полагаете, что мой STM32F103 разогнан до тактовой частоты во много раз превышающую 72 МГц, то этого просто не может быть.

"Латентность" EXTI? Чтобы не создавать новую тему по мелочному вопросу, решила написать в эту тему, поскольку в ее заглавии есть и название моего контроллера (STM32F103), и EXTI, на которую у меня есть жалоба 🙂. Слово "латентность" забрала в кавычки, потому что латентностью обычно называют временную задержку между фронтом входного импульса и срабатыванием обработчика прерывания в ответ на него. Тогда как у меня несколько другая ситуация. Расскажу по порядку. Взялась я определять, с какой предельной скоростью можно считать импульсы по прерыванию (т.е. когда на активный пин контроллера подается заданная частота/меандр, а в обработчике прерывания EXTI к какой-то переменной/счетчику прибавляется единица). Один раз в секунду (чтобы число на счетчике численно равнялось частоте в Гц) счетчик подвергается ревизии, а переменная, в которой шло накопление, занулялась. Пока частота входного меандра не превышала 16 КГц, результат счета полностью совпадал с частотой входного сигнала. Но выше частоты 16 КГц начинались потери импульсов: при частоте 18 КГц терялось около 5-ти импульсов, при 20 КГц - около сотни, и т.д. по нарастающей. Казалось бы, этот эффект легко объясним латентностью прерывания (в ее обычном значении) и временем работы обработчика прерывания, где помимо полезной работы могут присутствовать еще и операции по сохранению и восстановлению рабочих регистров, неявно добавляемые компилятором. Но каково же было мое удивление, когда, запустив параллельно точно такой же счет по другому пину, получила всё те же 16 КГц безупречного счета на обоих! Запустила параллельно счет сразу на трех пинах - тот же самый результат: до 16 КГц безупречно, а выше начинаются потери. Как такое может быть? Ведь если потери импульсов происходят из-за "медлительности" системы прерываний на этом контроллере (72 МГЦ тактовая), то по идее прерывания по соседним пинам (EXTI1, EXTI2, EXTI3, ...) должны тормозить друг друга, но это почему-то не происходит. Более того, подав на один из трех пинов достаточно высокую частоту, чтобы счетчик "захлебнулся" (100 КГц), обнаружила что, вопреки ожиданиям, остальные два счетчика по-прежнему безупречно вели счет на частоте 16 КГц, хотя "захлебнувшийся"счетчик пропускал импульсы уже тысячами. Конкретика: все три прерывания были организованы единообразно и имели одинаковый приоритет: HAL_NVIC_SetPriority(EXTI1_IRQn, 4, 0); HAL_NVIC_EnableIRQ(EXTI1_IRQn); HAL_NVIC_SetPriority(EXTI2_IRQn, 4, 0); HAL_NVIC_EnableIRQ(EXTI2_IRQn); HAL_NVIC_SetPriority(EXTI3_IRQn, 4, 0); HAL_NVIC_EnableIRQ(EXTI3_IRQn); void EXTI1_IRQHandler(void) { counter1++; __HAL_GPIO_EXTI_CLEAR_IT( GPIO_PIN_1); } void EXTI2_IRQHandler(void) { counter2++; __HAL_GPIO_EXTI_CLEAR_IT( GPIO_PIN_2); } void EXTI3_IRQHandler(void) { counter3++; __HAL_GPIO_EXTI_CLEAR_IT( GPIO_PIN_3); } Входные меандры с заданной частотой генерировала тем же контроллером с помощью таймеров 1, 3 и 4 (здесь всё тривиально). Больше вроде бы никакой специфики у меня не было. Моё личное впечатление - как будто после выхода из прерывания это прерывание какое-то время "отдыхает", пропуская вперед остальные два процесса. А потому его "захлеб" работе остальных двух процессов не мешает. Но ведь такого не может быть! Т.к. хорошо известно, что порой приходится добавлять в обработчик задержку (я не добавляла), чтобы он не сработал дважды.

Прошла весна, настало лето, близится осень, но мои злоключения с шиной I2C на контроллере STM32F103C8T6 не только продолжились, но и приняли парадоксальный оборот. Начну с того, что моя "горелая" плата с контроллером снова заработала нормально с шиной I2C после того, как ... полежала 10 дней в ящике моего стола. После этого она нормально трудилась (с использованием I2C) где-то 3 месяца, а потом I2C у нее снова сдох. Никаких импульсов по линиям SDA и SCL не выдает (логическим анализатором смотрела), а драйвер STM32CubeMX после 10 миллисекундного ожидания выдает ошибку "BUSY", считая шину занятой (что обычно бывает, когда хотя бы на одной из этих линий нет подтяжки к питанию). Однако с потенциалом на линиях был полный порядок - на обеих стоял высокий уровень. Тогда из опасений, что порт сгорел, я взялась проверять у контроллера пины SDA и SCL, переключив их из режима I2C в режим обычного вывода (GPIO_MODE_OUTPUT_PP). Выставила высокий уровень, затем низкий - вольтметр показал, что пины правильно слушаются команд. Затем переключила в режим Open-Drain (GPIO_MODE_OUTPUT_OD), предварительно подтянув их к питанию парой резисторов , которые мне здесь посоветовали (4.7К). Проверила снова - напряжения на выходе снова послушались команд. После всего этого вернула режим I2C, и о чудо - I2C заработала! Но не долго - до первого же ресета или отключения питания. Стала разбираться тем, в какой момент шина I2C оживает. Выяснила, что для того, чтобы I2C-шина ожила необходимой войти в режим Open-Drain и на 100 микросекунд закоротить обе линии на землю (командой установки на линиях низкого уровня), чтобы пропустить по ним ток через резисторы подтяжки. Сразу же после этого I2C-шина начинала работать нормально, более не выдавая состояния BUSY. При этом повторную инициализацию I2C мне делать не пришлось - дело ограничилось манипуляцией с этими двумя линиями порта. Конечно это не навсегда, а только до первого обесточивания, но я поставила эту процедуру оживления в начало программы, после чего плата стала работать нормально. Прошу прокомментировать мой рассказ, а если можно, то предложить разгадку случившегося.

У меня точно такое впечатление - все функции, которые не используются (т.е. нигде не вызываются), компилируются, но к результирующей прошивке не линкуются. Просьба к топикстартру - могли бы вы выложить этот проект целиком? А то архив rs.zip я скачала, то там для IAR'а нечего нет.

Компилятор ругается на implicitly (Pe223), когда функция вызвана без прототипа. То бишь функцию сперва требуется объявить (чтобы компилятор понял какого типа у нее аргументы) и уж только потом ее вызывать. А на identifier ругается (Pe020), когда используете переменную и массив, которые прежде не были созданы. Это разные ошибки, а потому и коды у них разные - Pe223 и Pe020.

Выяснила, что у STM32F103 нет резистора, подтягивающего линию USB_DP к питанию. А у GD32F103 он есть?

Да вроде никакого. М.б. ноги растут от 10 кОм вместо штатных 1,5 кОм в "синих таблетках", но то к самому МК не имеет ни малейшего отношения. Моя таблетка не синяя 🙂 - она под RS232 заточена (драйвер повышающий стоит и разъем DB9 на плате). А USB кабель я сама присоединила к свободным штырям PA11 и PA12. Никакого подтягивающего резистора там не было, т.к. под USB эта плата не позиционировалась, но мне захотелось проверить, заработает ли она под USB, как CDC-девайс. 5-вольтовое питание тоже взяла от USB, а к внешнему источнику питания не присоединяла. Вот она у меня какая: https://aliexpress.ru/item/32858126641.html

А на stm32f103 он у вас поднялся? А то у меня сейчас проблема - на STM32F103RCT6 USB-CDC работает нормально, а на STM32F103С8T6 даже не определяется, как СОМ-порт. Никак не пойму, в чем может быть причина, т.к. программный код там и там одинаковый (но прошивки разные из-за того, что памяти разное количество), и оба они 103-и.

HСD-функции относятся к хосту (HСD = Host Controller Driver). Со стороны хоста нет проблем определить, что он подцепил девайса. В своем вопросе я даже пример с компьютером привела, когда обнаружение компьютером присоединения внешнего девайса легко диагностируется. И даже жирным шрифтом подчеркнула "как узнать об этом со стороны контроллера?", чтобы не нарваться на ответ, который вы мне дали. И, тем не менее, нарвалась. P.S. Кажется нашла средство, вот оно: if (hUsbDeviceFS.dev_state == USBD_STATE_CONFIGURED) { // устройство подключено } else { // устройство отключено }

Мой вопрос к пользователям STM32Cube по части реализации USB/CDC-device (код из Middlewares): Как со стороны контроллера (STM32) узнать, что его к персональному компьютеру подключили? При подключении USB-девайса персональный компьютер формирует виртуальный COM-порт, появление которого пользователь может увидеть в Диспетчере устройств (Device manager), но как узнать об этом со стороны контроллера? Знаю, что в процессе инициализации USB-устройства компьютер обменивается с ним какой-то информацией, а потому USB-устройство, по-видимому, должно знать, что его "инициализировали". Пыталась у hpcd_USB_FS статус звать, вот так: USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*)hUsbDeviceFS.pClassData; printf( "\r\nUSB State = %d\r\n", hcdc->TxState); Но статус показывает, что всё в порядке, хотя к компьютеру подключения не было. Что еще можно попробовать?

Отличие отличию рознь. Покупатели благосклонно относятся к отличиям, когда базовые функции совпадают, а отличие касается каких-то улучшений типа увеличенной тактовой частоты, большего числа таймеров и прочей периферии. Например, китайцы "клонировали" АЦП AD7705, создав его функциональный аналог под именем TM7705. Как видите, та же самая практика, какую я выше описала, - одинаковая цоколевка и схожее наименование. Однако, китайцы у своего изделия вдвое увеличили тактовую частоту (а точнее, допустив применение вместо частоты 2.4576 MHz вдвое большей). Тогда как у АЦП этого типа от частоты зависит точность измерений (почти вдвое увеличилось "resolution"). А огорчительно, когда замена оригинала на клон приводит к тому, что тот не работает, например, из-за того того, что в регистре, управляющим множителем частоты, биты местами переставили. Но когда биты переставляет сама самая компания-производитель, то всегда выпускает документ "Migration", где перечисляет всё то, что изменилось. А вот когда другая (и обычно конкурирующая) компания производит клон, то им западло такой документ выпустить, т.к. уж больно сильно не хочется признаться в клонировании чужой разработки. По тому же поводу вспоминается отечественный 1887ВЕ4У (от НИИЭТ) с претензией создать аналог Atmega8535. Помню, как на форуме почти пол года выясняли, чем они отличаются.

Лично я предпочитаю сравнивать не бренды между собой, а удачные их проекты. Например, бессмысленно обсуждать, хорош или плох бренд "Мосфильм" 🙂, т.к. выпускал он как хорошие, так и откровенно плохие фильмы. Просто крупная и богатая компания может позволить себе заквасить сразу множество стартапов, чтобы затем огромными тиражами тиражировать то, что показало успех (привлекло горячий спрос покупателей). Точно так же, как из под пера одного и того же писателя не всегда выходят бестселлеры, а песни одного и того же певца совершенно не всегда становятся шлягерами. Но широко расходятся именно удачные произведения, создавая их автору славу А вот серия STM32 от компании ST - несомненный хит! И именно поэтому до сих пор он является объектом для подражания тех же китайцев. Тому свидетельством - одинаковая цоколевка и схожие наименования. А поменяй китайцы в своем изделии назначение хотя бы пары пинов, то у них этот продукт никто не купит, убедившись, что STM32 на той же плате он заменить не может. Столь же удручают покупателя и те случаи, когда программатор ST-Link отказывается с ними работать.

Несомненно вернусь, тем более что и не уходила :). Мое кредо - прежде всего качество и только потом доступность. Причем считаю этот принцип актуальным, вне зависимости от того, какой природы санкции - внешние (запрещено ввозить в Россию) или внутренние (запрещено покупать импорт). Когда-то в СССР тоже что-то было запрещено, например, слушать песни Галича и слушать радиостанцию Свобода (по этой причине ее глушили). Тем не менее, люди ухитрялась слушать то и другое, вопреки запретам и трудностям. Правда я того времени не застала - родилась позже, но если бы жила в те времена, то поступала бы точно так же - слушала то, что хотела слушать, а не то, что мне навязывала пропаганда. Вот и в наше время практически каждый человек с высшим образованием пользуется VPN ровно по тем же самым причинам - пытаясь обойти либо внешние санкции (сайты не отдают контекст на российские IP), либо внутренние санкции (Роспотребнадзор заблокировал доступ к иностранным сайтам). С товарами ситуация приблизительно та же самая, с тем лишь исключением, что санкции обоих типов невыгодны не только покупателю, но и продавцу. В этом смысле обе стороны сделки заинтересованы в том, чтобы нарушить санкции. Однако при переправке товара через границу таможенным службам гораздо проще проводить цензуру "материальных ценностей". У нас еще на памяти, когда запрещали турецкие помидоры и грузинские вина под предлогом, что в них якобы были обнаружены вредные для здоровья вещества. А польские яблоки давили бульдозерами без всяких объяснений. Тем не менее, заметим, что обход таких санкций обычно производится по тому же принципу, что и VPN, - через третью/нейтральную страну. Причем в качестве этой третьей страны всё чаще выступает Китай. Причем контроллеры пресловутого STM нынче ст'оят у китайцев зачастую даже дешевле, чем их китайские аналоги, тогда как российские дилеры (типа "Чип и Дип"а) нагло греют руки на дефиците, который чаще всего сами же создают.

Если для шагового двигателя, то проще всего купить управляющею плату от 3D-принтера. Могу рекомендовать "MKS Gen М1.4" или "MKS Gen-L" (последняя чуть дешевле). Цены на Aliexpress приблизительно 1800 руб за первую и 1400 руб за вторую. Я же себе вообще на Авито с рук покупала за 1000 руб, например, здесь: https://www.avito.ru/moskva/orgtehnika_i_rashodniki/mks_gen_v1.4_3197159280 В этом случае разбираться с микроконтроллерами и программировать вообще можно не уметь 🙂 - плата управляется текстовыми командами - задается координата для каждого из 4-х моторов. Родные драйвера обычно на ток до 2А, но можно при желании подключить и внешние на любой ток.

А чем этот стм лучше того же esp32, у которого два раза по 240МГц - те же яйца, но в профиль, а если сравнивать гемор по разводке того же стма со всеми его питаниями и еспшки - то тут еспшка за день даже студентом разводится и на коленках припаивается. Ну а цена (в мойсере за 4 бакса) против двадцатки за стм, как-то тоже любовь к стму сильно притупляет. Да, я понимаю, что АЦПшка у СТМа наверное лучше, но они все встроенные в процессор - поганые. Если АЦП нужно - лучше все-таки внешнее. Дело в том, что топикстартер сам признался "Это будет первая работа с микроконтроллером (если с ним) и программированием", а в этом случае приходится рассчитывать либо на Arduino с ее библиотеками, либо на STM32 с его STM32CubeMX. Иначе при недостатке опыта такую работу он не потянет, и результат получится прямо противоположный ожидаемому - к программированию микроконтроллеров возникнет стойкое отвращение. А чтобы избежать "разводки того же стма со всеми его питаниями" я как раз и рекомендовала готовые платы китайского производства (они недорогие), где базовая обвязка микроконтроллера уже сделана. Они на Aliexpess даже маркируются как "совет по развитию", "минимальная плата", "макетная базовая плата ARM", "обучающая плата" и т.п, поскольку предназначены для начинающих. Тем не менее, даже продвинутые разработчики порой используют такие платы в своих конструкциях. Например, мой знакомый из Новосибирска хорошо отозвался о модуле TI Sitara AM3354 (всё собрано на одном модуле: Cortex-A8 600 МГц, 128 МБ DDR3, 1 ГБ NandFlash), который одно время довольно дешево продавался у китайцев для кассовых аппаратов (видимо потому и дешево, что выпускался большим тиражом).

На мой взгляд, прежде чем выбирать контроллер для управления чем-либо, следует сперва заняться ... самоанализом 🙂. Здесь главное определиться с тем, готовы ли вы слиться с контроллером в одно целое 🙂, превратив его с продолжение своих рук и мыслей, или рассчитываете на то, что поставите на контроллер или процессор Linux, и она всё сделает за вас. От этого выбора напрямую зависит, покупать ли вам плату с контроллером с развитой периферией (или по меньшей мере с пинами контроллера выведенными на "гребенку") или же покупать мини/микро-компьютер в "запаянном" корпусе. Лично для меня этот выбор был очевиден, т.к. возиться с живым железом люблю (и с этого когда-то начинала), а Linux воспринимаю, как мультиплатформенное продолжение DOS 🙂. Причем я вполне уверена, что из-под операционной системы (RTOS не в счет) ничем серьезно управлять невозможно, либо такие попытки выльются в бесконечную борьбу с операционной системой, пока не превратится в жгучую к ней ненависть 🙂. Если выбор сделан пользу контроллера, то рекомендую китайские платы на STM32. И хотя репутация STM32 в последнее время была подорвана, но не по своей вине, а по вине мирового дефицита полупроводников и/или внешней политики России 🙂 . В частности из числа "продвинутых" мне нравится контроллер STM32H743VIT6, работающий на частоте 480 МГц (что значительно быстрее, чем Arduino), который даже сейчас можно купить за 2000 руб (я когда-то покупала за 1600 руб): https://aliexpress.ru/item/4000235276780.html А плата на чуть менее совершенном STM32H750VBT6 доступна даже за 1300 руб (по той же ссылке). Усилия на освоение контроллера (любого!) не считаю напрасными, т.к. они "исправляют карму". Тогда как в наше время люди почти поголовно приучены к тому, чтобы не только жить на всем готовом (т.е. сделанном чужими руками), но и свои программы собирать из готовых модулей/библиотек. Жизнь такова. Однако в области микроконтроллеров осталась незатоптанная поляна, где всё еще можно что-то сделать целиком своими руками. И этой возможностью, на мой взгляд, стоит воспользоваться, пока она еще есть.

На ftp есть стандарты с тем же номером, только они Британские: ./DOC/STANDARDS/British standards/BS EN/BS EN 62037-1-2012.pdf ./DOC/STANDARDS/British standards/BS EN/BS EN 62037-2-2013.pdf ./DOC/STANDARDS/British standards/BS EN/BS EN 62037-3-2012.pdf ./DOC/STANDARDS/British standards/BS EN/BS EN 62037-4-2012.pdf ./DOC/STANDARDS/British standards/BS EN/BS EN 62037-5-2013.pdf ./DOC/STANDARDS/British standards/BS EN/BS EN 62037-6-2013.pdf Passive RF and microwave devices, intermodulation level measurement.

Я хочу датчик СО2 за приемлемую цену, работающий в диапазоне концентраций 1%-5%. Термостат не герметичен, т.к. создавался не для таких целей, а для сушки лабораторной посуды :). Хотя и бывают термостаты для выращивания бактериальных сред, имеющие нужные характеристики, но они слишком уж дороги. Поэтому расход СО2 происходит не из-за поглощения живностью, а из-за рассеивания в атмосфере следствии негерметичности термостата. Однако требуемая точность поддержания концентрации СО2 невелика - даже ошибка на 0.5% вполне допустима. Тем более что непонятно отчего, казалось бы в одинаковых условиях, одну неделю живность растет бурно, а в другую почти не растет :).