Мелкие вопросы по МК и ПЛИС.

[alexey_and]

спасибо! буду пробовать

[Gudd-Head]

Товарищи, кто-нибудь сталкивался с пиздежом враньём в Даташитах?
Стёртая ATmega8L со штатными фьюзами жрёт 5...6 мА при 4.7 В, хотя обещают около 2-х [12 мА вместо 10-ти на 8 МГц]
Корпус TQFP, МК просто распаян на макетке, к нему ничего не подключено!

[ARV]

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

[Gudd-Head]

Ничего не прошито. Я ж написал, она стёртая.

неконтролируемых утечках, если все пины находятся в режиме входов

Фууух, спасибо, полегчало. 1,9 мА. Странно, обычно я с потреблением не заморачивался и оставлял ноги висеть в воздухе в 3-м состоянии. И ДШ про то же подтверждает что так лучше не делать:

Unconnected pins
If some pins are unused, it is recommended to ensure that these pins have a defined level. Even though most of the digital inputs are disabled in the deep sleep modes as described above, floating inputs should be avoided to reduce current consumption in all other modes where the digital inputs are enabled (Reset, Active mode and Idle mode).

The simplest method to ensure a defined level of an unused pin, is to enable the internal pull-up. In this case, the pull-up will be disabled during reset. If low power consumption during reset is important, it is recommended to use an external pull-up or pull-down. Connecting unused pins directly to VCC or GND is not recommended, since this may cause excessive currents if the pin is accidentally configured as an output.

[oleg63m]

ЭТО ДАЖЕ ПРОСТАЯ CMOS ЛОГИКА НЕ ЛЮБИТ, ЧТОБЫ НОГИ БОЛТАЛИСЬ В ВОЗДУХЕ

[amd9800]

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

[hybroid]

Коты! Надо выбрать какой-то МК на ядре 51. Требуется минимум 17 портов i/o и UART. Тактирование не важно какое, всё не важно.. Ну и желательно чтобы какой-то дохлый таймер был.
Я это ядро вообще палочкой не тыкал, понятия не имкю куда смотреть.. Есть NXP, есть Silabs.. Пока выбор пал на P89LPC930. Может что скромнее есть?
Всунуть МК надо в курсач..

[petrenko]

"Скромнее" в смысле "дешевле" ? Или как ?

Atmel-овские варианты 51-ых устроят ?

[Gudd-Head]

Надо выбрать какой-то МК на ядре 51.

http://mymcu.ru/

[pokk]

Подскажите, как правильно усреднить данные АЦП.
Понадобилось мне вывести на индикатор данные из АЦП, что бы на индикаторе они сильно не прыгали сделал суммирование 64 значений, а после делением сдвигом. Так вот теперь значение на индикаторе более менее установилось, но если значение АЦП будет на границе перехода 0.9-1.0, то небольшое колебания АЦП опять приводит к прыганию данных на индикаторе.
Как от такого можно избавится ? Думал сделать округление, а не отбрасывание дробной части, но тогда та же ситуация будет повторятся но уже на границе 0.5.

[COKPOWEHEU]

Можно добавить гистерезис. В случае сложения 64 измерений, перед делением сравнивать с предыдущим значением и менять, только если разница больше определенного значения.

[КРАМ]

Понадобилось мне вывести на индикатор данные из АЦП, что бы на индикаторе они сильно не прыгали сделал суммирование 64 значений, а после делением сдвигом. Так вот теперь значение на индикаторе более менее установилось, но если значение АЦП будет на границе перехода 0.9-1.0, то небольшое колебания АЦП опять приводит к прыганию данных на индикаторе.

Не вполне понятно КАК Вы реализовали буфер этих 64 значений.
Буфер нужно заполнять ПО КРУГУ и вычислять среднее после КАЖДОЙ НОВОЙ ЗАПИСИ в буфер. Длина буфера должна быть примерно 0,25...0,5 секунд. Это даст полосу фильтрации такого КИХ ФНЧ с прямоугольным окном 2...4 Гц.
Не нужно слишком часто проводить измерения. Скажем, для буфера на 64 значения получится частота семплирования АЦП 128...256 Гц (период дискретизации сигнала 4...8 мс).

[Gudd-Head]

Буфер нужно заполнять ПО КРУГУ и вычислять среднее после КАЖДОЙ НОВОЙ ЗАПИСИ в буфер.

Почему нельзя сначала заполнить буфер, а потом вычислить среднее?

[КРАМ]

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

[ARV]

давным-давно додумался до обсуждаемого метода фильтрации (почему додумался? потому что ЦОС не изучал, а ТАУ хоть и изучал, но ничего не помню, поэтому все время изобретаю велосипед). в общем, код получается такой:

Код: Выделить всё

#define FILTR_DEPTH  64
static uint16_t adc_one_shot(void){
   ADCSRA |= 1<<ADSC;
   while(ADCSRA & (1<<ADSC));
   return ADC;
}

uint16_t get_filtered_sample(void){
   static uint16_t filtr[FILTR_DEPTH];
   static current_sample = 0;
   uint32_t sum = 0;
   
   fltr[current_sample] = adc_one_shot();
   if(++current_sample >= FILTR_DEPTH) current_sample = 0;
   for(uint8_t i=0; i<FILTR_DEPTH;i++) sum += filtr[i];
   return sum / FILTR_DEPTH;
}

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

[Kavka]

не самый оптимальный по быстродействию

Не рассмотривая оптимизацию под конкретную архитектуру...
Если от цикла избавиться в get_filtered_sample, то будет нормально.

Спойлер

Код: Выделить всё

uint16_t get_filtered_sample(void){
   static uint16_t filtr[FILTR_DEPTH];
   static current_sample = 0;
   static uint32_t sum = 0;
   
   sum =- fltr[current_sample];
   fltr[current_sample] = adc_one_shot();
   sum =+ fltr[current_sample];
   if(++current_sample >= FILTR_DEPTH) current_sample = 0;
   return sum / FILTR_DEPTH;
}

[COKPOWEHEU]

Не вполне понятно КАК Вы реализовали буфер этих 64 значений.
Буфер нужно заполнять ПО КРУГУ и вычислять среднее после КАЖДОЙ НОВОЙ ЗАПИСИ в буфер. Длина буфера должна быть примерно 0,25...0,5 секунд. Это даст полосу фильтрации такого КИХ ФНЧ с прямоугольным окном 2...4 Гц.

Хранить все 64 измерения по отдельности, тратить 128 байт на то, что требует двух, не говоря про скорость работы? У такого метода есть хоть одно преимущество перед другими?
1. Честное усреднение. Накапливаются 64 отдельных измерения в одной двухбайтной переменной, потом результат делится на 64, выдается в основную программу и сбрасывается. Следующая серия начинается с нуля.
2. Простейший цифровой фильтр. Очередное измерение добавляется к результату по формуле res=x*res+(1-x)*ADC. x=0..1. Новое значение можно получать при каждом преобразовании.
Первый метод выполняется чуть быстрее за счет меньшего количества математики, второй не требует снижения частоты измерения, при этом усредняет результат.

Понадобилось мне вывести на индикатор данные из АЦП, что бы на индикаторе они сильно не прыгали

Из этого следует, что састота вывода должна быть 0.1 - 1 Гц. При такой частоте нужное усреднение даст любой метод. Другое дело, что усреднение само по себе не поможет, разве что мигать будет не 2-3 младших бита, а всего 1.

[КРАМ]

У такого метода есть хоть одно преимущество перед другими?

Другие методы - это БИХ.
Как раз то, что Вы изложили...
Недостаток БИХ состоит в необходимости обеспечения устойчивости.
При ограниченной разрядности БИХ оказывается много хуже КИХ, поскольку быстро убывает вклад дальних семплов.
На самом деле ресурсы вычислителя при КИХ и БИХ для равной крутизны примерно одинаковы.

При такой частоте нужное усреднение даст любой метод. Другое дело, что усреднение само по себе не поможет, разве что мигать будет не 2-3 младших бита, а всего 1.

Как же не поможет, если амплитуда помехи становится меньше в 4...8 раз?
В этом фильтрация и состоит...
А если количество семплов в буфере увеличить, то можно и разрядность измерений (разрешение) поднять на 1...4 разряда.

[ARV]

Если от цикла избавиться в get_filtered_sample, то будет нормально.

может быть, может быть...
но ваш код не будет делать то, что надо. из суммы надо вычитать самый "старый" семпл, а не предыдущий - это раз.
что делать с самым первым семплом, когда весь массив обнулен и sum тоже? - это два.

[COKPOWEHEU]

Это может уменьшить мерцание, но не устранить его. Когда напряжение находится в середине младшего бита и от помехи рандомно меняется, будь там хоть 50 разрядов, при изменении старшего разряда будет мигание всех.
Поэтому я и говорил про гистерезис: точность несколько снижается, зато число на индикаторе будет меняться только по серьезному поводу, игнорируя единичные выбросы.

Недостаток БИХ состоит в необходимости обеспечения устойчивости.

Честно говоря, не особо углублялся в теорию. "На пальцах" он, как я понимаю, работает аналогично RC-цепочке. А там вся настройка в установке частоты среза, неустойчивости возникнуть неоткуда.

При ограниченной разрядности БИХ оказывается много хуже КИХ, поскольку быстро убывает вклад дальних семплов.

А недостаток ли это? Да, результат может отличаеться от прямого усреднения или КИХ, но пульсации меньше.

На самом деле ресурсы вычислителя при КИХ и БИХ для равной крутизны примерно одинаковы.

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