676038

...This is a known bug in EWARM 5.50 with value line flashloader. It is fixed in EWARM5.50.5. I advise you, if possible, to upgrade your EWARM version to 5.50.5 (available on IAR web site: www.iar.com). Else , you can use the attached patch to fix this problem with your installed version. It contains a readme that explains hosw to use it....https://my.st.com...

Появилось на сайте ST: STM32F105/107xx USB Host library (UM1021)

Хм... Похоже, действительно или-или. Теперь понятно, почему больше 16 ног одновременно не получится.

Можно. См. Reference manual, стр.191 "The 112 GPIOs are connected to the 16 external interrupt/event lines..." и далее по тексту. А вот про ограничение в 16 линий - требует уточнения. Просто для PA0 и PC0 будет один обработчик, и уже в нем надо смотреть, какая линия вызвала прерывание.

Судя по всему, подключаать напрямую можно. Похоже, что ВМ8051 собран на CP210x, а у нее I/O pins 5V tolerant. Ее гарантированный minimum output Hi = 3.0V-0.7V = 2.3V, что недостаточно для AVR (Min Input Hi = 5V*0.6 = 3V). Но это при наихудшем стечении обстоятельств. Однако практика показывает, что в обычных условия граничные значения проявляют себя крайне редко, и вероятность сбоев довольно мала. Сам имею положительный опыт подключения BM8050 с выпаянным MAX3232 (или того, что там было для преобразования к уровням RS232, подключал USART AVR к CP210x напрямую), все работает нормально.

А ножку OTG_FS_VBUS/PA9: Power supply voltage line к "Power Supply" подтягивать пробовал? см. STM32F105xx and STM32F107xx device bootloader AN2606, стр. 12.

Да можно и период, на малых скоростях ветра все равно мгновенное значение будет иметь бОльшую погрешность из-за механических особенностей анемометра (учет потери на трение, момент инерции ротора при легком порыве ветра, плюс всякие мелочи), поэтому для большей точности лучше усреднять значения за какой-то более существенный промежуток времени.

Возьми "Датчик скорости ветра ДСВ-2", продаются здесь:http://www.pribortke.ru/products/1171905633-1/. Там внутри оптора, схему можно найти в интернете. А дальше все должно быть просто, считай число импульсов за секунду и вычисляй скорость ветра.

В своем последнем варианте - по изменению состояния, используется PIN-Change Interrupt на все четыре пина, куда подключены два энкодера. Просто надо проанализировать логику работы и решить для себя, какое событие считать информационным, а какое дребезгом. Из моего опыта - все что срабатывает в то время, пока идет обработка обработчика - это дребезг. Вот его и сбрасываем заканчивая обработчик. Конечно, в этом варианте есть завязка на время нахождения в обработчике прерывания (время подавления дребезга), но у меня это оказалось не критичным.

Может стоит добавить, сейчас обрабатываю энкодер так: //PCINT8-14 interrupt implementation #pragma vector=PCINT1_vect __interrupt void handler_pcint1(void) { static unsigned char flag=0xFF; //переменная для хранения предыдущего значения порта unsigned char tmp; //переменная для хранения текущего значения порта tmp = PINC & 0x0F; //запоминаем состояние порта switch (tmp ^ flag) //сравниваем с предыдущим и выполняем действие если изменился соответствующий бит { case 0x01: if (((tmp >> 1) & 0x01) == (tmp & 0x01)) Execute(0x11); //если поворот первого энкодера вправо else Execute(0x10); //иначе это поворот первого энкодера влево break;//выход case 0x02: if (((tmp << 1) & 0x02) == (tmp & 0x02)) Execute(0x10); //если поворот первого энкодера влево else Execute(0x11); //иначе поворот первого энкодера вправо break;//выход case 0x04: if (((tmp >> 1) & 0x04) == (tmp & 0x04)) Execute(0x21); //если поворот второго энкодера вправо else Execute(0x20); //иначе поворот второго энкодера вправо break;//выход // case 0x08: !!! второй энкодер обрбатываем при изменении только одной линии, уменьшая чувствительность вдвое... } flag = tmp; //сохраняем значение для следующего опроса PCIFR|=(1<<PCIF1); //сбрасываем флаг прерывания если оно произошло во время обработки. Это такая защита от дребезга. }

Добавь в конце обработчика прерывания строчку типа: PCIFR|=(1<<PCIF1); //сбрасываем флаг прерывания, если оно произошло во время обработки. Это такая защита от дребезга. А в обработчике прерывания запрещать прерывания не надо, они и так запрещены, и разрешаются после выхода из прерывания автоматически (компилятором), хотя про Codevision я не уверен.

Я считаю, что обрабатывать энкодер в основном цикле - пустая трата ресурсов процессора, ведь обычно энкодер - это устройство ввода команд пользователя, и прибор обычно находится в ожидании таких команд. (Услилитель играет музыку 2 часа в день, а громкость мы выставляем за 5 секунд...) Обычно есть проблема с недостаточной чувствительностью (пропуски щелчков), а здесь же наоборот - и это хорошо. Значит надо просто посмотреть, как настроено прерывание - по переднему фронту, по заднему или изменению состояния. Если стоит измение состояния - то задать по фронту. Ну а если же настроено по фронту, то "real_volume = volume >> 1;" должно помочь.

В IAR надо еще определить putchar(), например так: /*********************************************************************** * Вывод на USART символа * ***********************************************************************/ int putchar(int c) { while ( !(UCSRA & (1<<UDRE)) ); UDR=c; return 0; }

Позволю себе маленькие замечания по коду: - При инициализации глобальных переменных присваивать 0 не надо, это делается автоматически. - Глобальну переменную encoder лучше объявить static и сделать это внутри функции ReadEncoder(), ведь она больше нигде не используется... А теперь по существу - опрашивать энкодер в главном цикле программы нехорошо, т.к. частота опроса становится непредсказуемой (на нее влияют обработчики прерываний и действия внутри главного цикла). Если уж сильно хочется опрашивать состояние энкодера поллингом, то лучше вызывать считывание состояния экодера из таймера - в этом случае хоть частота опроса будет стабильной и предсказуемой. Но при этом хорошо бы хоть примерно прикинуть максимально возможную частоту опроса, учитывая что надо опрашивать сразу два энкодера и несколько кнопок... Может, все-таки, лучше завести одну линию от энкодера на вход прерывания и опрашивать состояние энкодера только при возникновении этого прерывания? Тогда не придется тратить процессорное время на бесполезный опрос... Но я, конечно, не настаиваю.