Arduino.ru

У вас проблемы с этим? Вы хотит поговорить об этом? Ну и  в чём там сложности?

Это он явно не с тобой. И так понятно, что такое не для тебя. ))))))))))))))))))))

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

Та ладно. Твой высокопарный бред, типа этого, как всегда вне конкуренции. ))))))))))))))))

"Я пока не очень понял, о каких таймерах и референсах речь, но имея возможность в произвольный момент настраивать захват по любому фронту, нет никакой сложности измерять время между ними, т.е. получать параметры ШИМ в полном объеме."

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

Теперь проблем меньше. Вобще чтение мануалов и применение на практике полученой информации полезнее чем поиск в 48 пиновых stm - ках незадокументированной периферии. Ну если будут вопросы спрошу, пока хватает моего понимания вопроса.

И что это за практика такая, можно поинтересоваться? Результаты покажете?

Пока в процессе. Есть желание написать загрузчики во внешнюю память подключенную по FMC так что бы использовать сам мк как програматор. Ну и если можете помочь подскажите, почему если записываем в TFT с помощью DMA из буфера размещенного во внутреннем ОЗУ одним массивом, то все нормально. А если разбиваем на сегменты, два, восемь, шестьнадцать, то последние 10 - 15 строк последнего сегмента записываются в перемешку с мусором.

Стало быть и мануалы читаются вперемешку с мусором. И нечего было щеки надувать.

Стало быть не знаете, чего тогда спрашивать.

P.S. И все оказалось тривиально и до ужаса просто. Обычная невнимательность при написания дефайнов рабочих областей внешнег ОЗУ.

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

Спросить не стыдно, стыдно оставаться в неведении. Да и умение найти ошибки, пусть и свои,  тоже положительное качество.

Пальцы гнуть стыдно. Особенно, если кроме пальцев больше и нет ничего.

Так не гните, кто вас заставляет!!!

Примените это к себе. Вам же лучше будет.

Мальчик, иди учи уроки! И не кукарекай.......

Ну наконец-то вы вышли на комфортный для себя уровень общения.

А такому быдлу как ты по другому и нельзя, ты меры не знаешь. Иди уже молча доламывай свои пальцы. Только сначала ногти сгрызи. ))))))

Ухожу-ухожу. Не смею мешать вашим приятным беседам.

Сегодня добрался до EFM32, поюзал IIC в связке с OLED на SSD1306. Инит периферии гораздо проще, чем у STM, ИМХО. Нет дикого коэффициента TIMINGR, который с грехом пополам считается только с помощью Экселевского файла, есть просто и ясно - регистр предделителя, куда просто пишешь число и частота так же просто делится...сказка. Кстати, в режиме 1МГц весь экранчик заполняется очень быстро (пока таймеры не ковырял, не померяю точно:D).

Минусы - I2C слишком простой, т.е. нету крутых фич, типа пишешь в регистр количество байт, вскидываешь бит Старт, пишешь, читать будешь или писать, а дальше только флаги чекай да загружай/читай данные - нет, всё вручную. Подняли старт, загрузили адрес устройства, потупили в цикле, сбросили флаг (ВАЖНО! на этом долго ничего не работало), снова загрузили в регистр данные и так далее..

Вот весь инит:

    CMU->HFRCOCTRL = CMU_HFRCOCTRL_BAND_14MHZ;                       
	CMU->HFCORECLKDIV = CMU_HFCORECLKDIV_HFCORECLKDIV_HFCLK;         
	CMU->HFPERCLKEN0 |= CMU_HFPERCLKEN0_GPIO | CMU_HFPERCLKEN0_I2C0 ; 
	/* Инитим IIC */
        I2C0->ROUTE |= I2C_ROUTE_SDAPEN | I2C_ROUTE_SCLPEN;               
	I2C0->CTRL |=  I2C_CTRL_EN | I2C_CTRL_CLHR_DEFAULT ;              
	I2C0->CLKDIV = 0;                                               
       /* --------------- */ 
	GPIO->P[0].MODEL =  GPIO_P_MODEL_MODE0_WIREDAND | GPIO_P_MODEL_MODE1_WIREDAND;   // ОК на пинах IIC

Собственно, чего я сегодня про них вспомнил - у них есть встроенный ИОН на 2.5В и даже, вроде, на 5В, хотя я до конца и не разобрался в нём. фича нужная, потому что я, опять же, до сих пор не врубил, как померять напряжение питающего аккумулятора на STM32F0. Если есть варианты - готов послушать умных людей, а так, уже выписал себе еще 2 МК в QFN24 5x5мм.

И ещё немного об EFM32 - у них дикий режим маппинга, тот же IIC можно смаппить на 5 разных конфигураций пинов.

Короче, мне пока нравится, авось и до USB дойду.

Yarik.Yar, похоже ответ есть в этом поте

https://argrento.org/2011/07/04/power/

Спасибо, но это не подходит. Хотелось бы для любимого 20-пинового F4P6, а у него только AVDD есть, который должен входить в диапазон питания, но быть не меньше VDD. Хреноватый какой-то из него AREF...

У камней с выводами меньше чем 100 AREF подключен к Vdda. :-((

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

Я в свое время по этой причине отказался от применения MSP430. От подобной нудятины с души воротит.

Так он и на F0 примерно столько же занимает.

Как-то так:

#define VREFINT_CAL        (*(uint16_t*) (0x1FFFF7BA))
#define VDD_CAL            ((uint16_t)  (330))
#define ADC_VREF_CHANNEL   ADC_CHSELR_CHSEL17

uint16_t adc_vcc = VREFINT_CAL * VDD_CAL / read_adc(ADC_VREF_CHANNEL);

Вот же галлюциноген. Спрашивали, как на F0 померять, он пихает кусок вольного переложения даташита на F1, где работа АЦП совсем не рассматривается. Это уж не говоря, что сам АЦП на F1 немного другой, если сравнивать с F0.

Нахрена эта ссылка? Лишь бы чего-нибудь ляпнуть?

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

Не порите чушь. Похрен какое питание. И похрен на разделение: "When a single supply is used, VDDA must be externally connected to VDD."

Из чего следует, что при снижении питания снижается и напряжение AREF. Ну а в формуле есть значение   

#define VDD_CAL            ((uint16_t)  (330))

привязывающее нас к AREF = 3.3 v, а по сути с понижением питания при неразделенном питании цифровой и аналоговой части AREF изменяется следом за питанием. Включаем мозг, если он есть, формула теряет право называться правильной с матиматической точки зрения, выдавая неверное значение. Vdda = AREF должно оставаться неизменным на протяжении всего времени работы программы независимо от питания.

Два дебила. Есть же апнота по этому поводу. К чему ещё плодить сущности? ))))))))))))

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

Ошибку где увидели или, как обычно, просто повизжать приспичило?

Феерический бред. Оказывается вы не вперемешку с мусором мануалы читаете, а один только мусор и совсем не из мануалов.

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

V = ADC * V_REF / 4095.

В условиях производства STMicro замеряет напряжение опорного источника внутри МК при напряжении VDDA  (оно же V_REF в формуле выше) равном 3.3 вольта и результат преобразования в виде 12-битного значения регистра ADC_DR записывает в области калибровочных данных микроконтроллера по адресу 0x1FFFF7BA.

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

V = (*(uint16_t*) (0x1FFFF7BA)) * 3.3 / 4095

Опорное напряжение интересно тем, что испытывает лишь совсем незначительные изменения при значительных колебаниях VDDA. Для простоты его можно считать всегда одинаковым. Стало быть, V_измеренное_на_заводе всегда можно считать равным V_измеренному_в_любой_момент, если речь идет о измерении источника опорного напряжения. Отсюда появляется равенство:

(*(uint16_t*) (0x1FFFF7BA)) * 3.3 / 4095 = ADC * VDDA / 4095

если отбросить деление на 4095 в обоих частях, то оно приобретает вид

(*(uint16_t*) (0x1FFFF7BA)) * 3.3 = ADC * VDDA

откуда элементарно получается уже знакомая формула из моего примера выше:

VDDA = (*(uint16_t*) (0x1FFFF7BA)) * 3.3 / ADC

А чё вы так задёргались, оба? Есть доки, есть апнота. Что, 2 + 2 без чужой подсказки одолеть не можете?

Ошибку укажите. Или рот прикройте.

Как-то вы быстро сегодня спеклись.

Правильно вас назвали ДЕБИЛОМ , потому как если снижается Vdda то и снижается AREF. Процессор может работать в диапозоне от 1.7  до 3.3 в. В случае снижения питания в следствии разряда батареи ниже 3.3 в, формула будет расчитывать неправильное значение. Ваше утверждение справедливо только для питания равного 3.3 в. Если вы в физике полный лох это ваши проблеммы, идите учите физику.

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

Это наваждение такое с вами приключилось? С какой стати вас так проглючило, если МК имеет заявленые в даташите характеристики во всем диапазоне разрешенных питающих напряжения?

А какой закон физики здесь нарушен, вы говорите? Давайте уже поконкретнее. Если вы такой физик-математик, это же не составит для вас труда, не так ли?

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

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

Я фигею. Ему пишут "точность преобразования никак не должна зависеть от питающего напряжения", а он в ответ, что "из двух источников озвучина зависимость точности и адекватности измерения от опорного напряжения". Так кто тут дебил?

ИОН в STM32F0 обеспечивает заявленные производителем характеристики во всем диапазоне питающих напряжений и рабочих температур. Подымать ничего не требуется.

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

Да ну. Запитайте мк напряжением 2.5 вольта и подставте свою формулу. Увидите результат.

a5021, в STM32F0 нет ИОН.

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

Yarik.Yar​, думаю правильным будет разделить питание цифровой и аналоговой части. Собрать на mc34063 истояник питания аналоговой частью и спокойно измерять питание на цифровой части, т.е. потенциал батареи. Можно еще собрать на REF192 или TL431.

Тогда в даташите, вот в этом месте, характеристики приведения описываются.

Ну и что мы видим.  Где указано что это в диапазоне напряжений. Только зависимость опорного напряжения от температурного режима. Не более.

Прочитать Vrefint можно, но он будет снижаться со снижением питания.

Перевожу, специально для лингвистов (а так же физиков и математиков по совместительству):

"параметры, приведенные в таблице 24, заимствованы из тестов, осуществленных при комнатной температуре и в условиях питающих напряжений, приведенных в таблице 21."

На а это таблица 21, раз у самих рук нет.

Зайдем с другой стороны. а5021, задайте себе вопрос. Зачем кроме подачи на аналоговую часть чистого (хорошо отфильтрованного) питания разделили цепи питания в мк. Это все общие характеристики мк, и опять ни слова о том что при изменении питания напряжеие AREF остается неизменным.