glags

Тогда ставить фильтр смысла нет. Фильтр только для того - чтоб отфильтровать ВЧ помехи по питанию которые даёт сам микроконтроллер.

Показали бы схему, а то так тяжело гадать. И при правильном включении (используя аналоговую часть) надо ставить фильтр - например BLM21AH102SN1D.

Привет всем :) Купил экран http://www.buydisplay.com/default/7-tft-lc...4-gps-tablet-pc Подключил к STM32F439II, вроде всё настроил по даташитам, но тут вылезла проблема. Заливка цветами R, G и B нормально, а белый цвет выглядит так и мерцает граница белого и фиолетового поля. Подскажите пожалуйста в каком направлении хотя бы рыть? Извиняюсь за беспокойство, вопрос решён! Забыл инициализировать один порт цвета - конкретнее G7.

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

Привожу таблицу зависимости между ADC_JDR1 и JSQR Кол-во каналов (JL) ADC_JDR1 ADC_JDR2 ADC_JDR3 ADC_JDR4 4.................................JSQ1........JSQ2...........JSQ3........JSQ4 3.................................JSQ2........JSQ3...........JSQ4 2.................................JSQ3........JSQ4 1.................................JSQ4 Например если один канал, то заполняем биты JSQ4 и данные будут при этом читатся из ADC1->JDR1 В регистре JSQR 4 бита для JSQ4, если их заполнить 0011 это будет третий канал ADC что соответствует РА3.

Кто нибудь знает, есть ли такая возможность посмотреть в отладчике, сколько времени процессор тратит от одного брэйк поинта до другого? Или хотябы в тактах проца померять, и как их во время перевести. Есть просто моменты в которых важно время выполнения определённых процедур. Я понимаю что можно перед началом процесса запустить например таймер и в конце процесса посмотреть его значение. Но это геморно, хотелось бы попроще - средствами кокоса.

Там целая наука. Дело в том что инжектированных каналов может быть максимум 4 и каждый имеет свой регистр данных, а регулярных 16 и у них один регистр данных на всех. По этому данные из них можно читать либо по прерыванию (окончание преобразования) либо DMA. Здесь если всё писать то целая статья выйдет. Дело в том что АЦП не сложный, но навороченный. Например он может вызывать прерывания при достижении определённого уровня сигнала на входе и т.д. Скажу только про один момент с инжектированными каналами. В инжектированных каналах есть одно неудобство, когда конфигуришь один канал, то в регистр ADC1->JSQR надо заполнять его как четвёртый. Это многих сбивает с толку. Да SYSCFG мы для тактирования альтернативных функций и включали. Но для конфигурации порта мы их не используем. Просто в модере включаем аналоговый режим. Альтернативные функции касаются таймеров уартсов и прочего что конфигурится в GPIOA->AFR. Здесь на всякий случай :). Просьба, если всё запашет, то отпишитесь.

Полностью рабочий код инициализации ЦАП: ADC1->CR2 |= ADC_CR2_CONT; //Преобразования запускаются одно за другим ADC1->CR1 |= ADC_CR1_JAUTO | ADC_CR1_SCAN; //Разрешить автопреобразование инжектированной группы и SCAN означает брать номера каналов для сканирования из JSQR. ADC1->JSQR |= (ADC_JSQR_JSQ4_0 ); //Задаем номер канала (выбран ADC1) ADC1->CR2 |= ADC_CR2_ADON;//Теперь включаем АЦП Здесь получаем данные: ADC1->CR2 |= ADC_CR2_JSWSTART; while (!(ADC1->SR & ADC_SR_JEOC)); ADC1->SR =0; // Очищаем флаг «преобразование завершено» res = ADC1->JDR1;

Прошу прощения, я сразу не увидел. :(

Да Вы правы, старый компилятор этого не видел. __packed был действительно ранее задефайнен. Странно как старый работал. Я исправил ошибку убрав define.

STM32 лучше всего шить по SWD это порты РА13 и РА14. Через эти же порты и отладка работает. У меня для отладки и прошивки используются всего 3 провода это РА13, РА14 и земля.

Данный баг касается компилятора для проца STM32F407, на других процах не пробовал. Прикрутил у Кокосу новый GCC 4_9-2014q4, а он стал ругатся на библиотеку работы с USB (usb_conf.h). При чём на строку #define __packed __attribute__ ((__packed__)). Ругань такого плана warning: "__packed" redefined. С старым компилятором проблем не было (gcc-arm-none-eabi-4_8-2014q1). Ошибка не критическая и код создаётся, но всё равно напрягает. Может кто с таким сталкивался и знает как лечить?

Во первых в первой проге заремарен GPIOA->MODER |= 0x0000000C; во вторых RCC->APB2ENR |= RCC_APB2ENR_ADC1EN | RCC_APB2ENR_SYSCFGEN; надо ещё включить тактирование на SYSCFG в третьих перед каждым забором данных из АЦП его надо запускать как я написал ниже. :) ADC1->CR2 |= ADC_CR2_JSWSTART; while (!(ADC1->SR & ADC_SR_JEOC)); ADC1->SR =0; // Очищаем флаг «преобразование завершено» res = ADC1->JDR1;

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

тут шунт не нужен, у микрухи есть выход IS с помощю которого можно определить ток на нагрузке. С этой ноги я ток и контролирую. Пробовал я отслеживать ток на обоих обмотках и в онлайн с помощью ШИМ поддерживать его на уровне 3А при работе двигателя. Фигня получилась - движок крутится и переодически дёргается в обратном направлении. Не мог понять в чём причина.