[INFERION]

Mishany, А код где?

[Mishany]

#include <avr/io.h>
#include <avr/interrupt.h>
__attribute__((OS_main))


SIGNAL(SIG_ADC)
{
OCR1A=OCR1A*164/ADCH;
}

int main(void) 
{
    CLKPR=0x80;
    CLKPR=0x00;
    PORTB=0b00000000;
    DDRB=0b00000010;
    PLLCSR=0x02;
    while ((PLLCSR & 1)==0);
    PLLCSR|=0x04;
    TCCR1=0x61; //64
    GTCCR=0x00;
    TCNT1=0x00;
    OCR1A=0x00;
    OCR1B=0x00;
    OCR1C=0xFF;
    ACSR=0x80;
    ADCSRB=0x00;
    OCR1A=10;   
ADMUX=0b10100011;
ADCSRA=0b11111101;
sei();

while (1)
   {
   }
    
}

пробовал и в нижнем цикле, на ноге шима полный штиль))

[INFERION]

Я там ничего не вижу. Именно там, где мне интересно было посмотреть как читается, модифицируется и затем записывается обратно значение в OCR1A. Тупая копипаста не обязана работать - это вообще комментарий с ассемблерного полотна, стилизованный под Си. Как я нарисую в арифметической формуле проверку на переполнения через флаги статуса, к которым в Си прямого доступа просто нет? А без этих проверок глючить что угодно будет. Важно как именно объявлены переменные, и какие именно параметры заданны компилятору. Он ведь сам решает что в коде нужно, а что можно выпилить. И часто это делает неправильно. Поэтому можно заглянуть в листинг и посмотреть что он там нафантазировал выполняя Ваши капризы...

OCR1ACR1A*164/ADCH; - а этот код как себя ведёт на жесткой нагрузке? Если драйвер перейдёт в ДД из-за нехватки напряжения питания, какие световые эффекты нас ожидают?

[Mishany]

 Сообщение от INFERION :

OCR1ACR1A*164/ADCH; - а этот код как себя ведёт на жесткой нагрузке? Если драйвер перейдёт в ДД из-за нехватки напряжения питания, какие световые эффекты нас ожидают?

в том то и дело что он не хочет работать

[INFERION]

Я конечно с Си слабо знаком, но обычно работают с объявленными переменными, которым предварительно присваиваются значения с нужных I/O регистров. Даже ассемблер говорит о том, что невозможно в этой архитектуре работать непосредственно с I/O. Можно максимум бит какой-то поставить или убрать, и то не везде. И доступны только операции чтения и записи. Арифметические операции компилятор может и не осилить. Это ж ему нужно догадаться куда-то временно что-то скопировать, там повозится и затем закинуть обратно. Тем более что переменная то скорее всего uint_8t, тогда как арифметика требует 8*8=16 бит как минимум. Сам компилятор такую переменную не родит, он просто не понимает что от него хотят...

SviMik (22:01:33 24/10/2013)
компилятор имеет свойство брать для вычислений регистры той же разрядности, какой ему подсунули на входе.

SviMik (22:04:05 24/10/2013)
я могу написать как надо в одну строку, но это будет страшно. поэтому я лучше заменю на две
uint16_t xCR1A*164;
OCR1A=x/ADCH;

SviMik (22:04:42 24/10/2013)
тоже самое одной строкой:
OCR1A=(uint8_t)((uint16_t)OCR1A*164/ADCH);

INFERION (22:06:16 24/10/2013)
по-нормальному нужно брать ADCH:ADCL

[Mishany]

т.е. надо как то считать значение с OCR1A, в моем случае он походу нули считывает только.
это как в ADCH нельзя записать значение, из OCR1A считать)))

[INFERION]

ADCH и читается, и пишется, так же как и OCR1A. Почти все I/O и читаются, и пишутся. Пишутся даже PINB, при этом физическое состояние пина инвертируется.
Просто нужно использовать промежуточные переменные, выше я уже процитировал мнение более опытного (чем я) Сишника.

Та скорость АЦП, которая указана в конфигурации, спокойно может оказаться не по силам МК, ибо эта строчка кода будет выполнятся далеко не одну сотню тактов. Деление оно такое, да...

[Mishany]

попробовать:
uint16_t xCR1A*164;
OCR1A=x/ADCH;
// unit16_t -потому что максимально возможное значение 256*256=FFFF
может вообще убрать прерывание и запихнуть в вайл, и максимально понизить частоту ядра и предделитель ацп на 128 и в процессе вычисления выключать ацп?

[INFERION]

Зачем выключать АЦП? Наоборот нужно стремится повышать его скорость и количество выборок, а работать он должен синхронно со всем остальным и полностью на автомате. Включение АЦП слишком дорого обходится - ему необходимо время для расчехление. Я его прерывание не использую, считаю это лишним. Мне хватает одного общего прерывания, по которому стартует и сам АЦП, и по которому основной цикл синхронизируется. В самом прерывании только флаг ставится. Обрабатывать там что-то массивное - себе дороже...

[Mishany]

Нашел косяк в запусках, т.к. для тестов использую лампочку автомобильную Н3 55ватт на шунте получается напряжение выше питания ОУ и на выходе оу напряжение питания, у лампочки то нету падения напряжения как у диодов)))
откладываю испытания пока не куплю диодную ленту для испытаний ватт на побольше с запасом.

[Mishany]

моя формула не хочет работать в связи с низкой инерционностью всей системы в целом. надо выкидывать все конденсаторы и как то синхронизировать ацп с шим.
первоначальный вариант меня в общем то устраивает на 100%.
пробовал убирать откл/вкл ацп при расчетах стабильность свечения сразу кончается, при убирании

 Сообщение от Maksoff :

перечитал код, в этом месте аж передернуло.

(усредненное значение из некоторого числа замеров ацп)
- так же стабильность кончается.

[INFERION]

Я ведь выше расчёт привёл - любой регулятор должен уметь подстраиваться под реальные физические процессы, наоборот сделать гораздо сложнее, ибо из аппаратной части с самого начала выжимается максимум. Задержи вносит ёмкость и индуктивность - выкинуть их из импульсного преобразователя, который по определению имеет инерцию? Обрабатывать поток данных тоже нужно с минимальным квантованием по времени. Т.е. не страдать интегрированием семплов, чтоб потом фиг знает через сколько их там обработать - это тоже задержки. Ну и наконец - сам МК не всесильный и деление там, где оно ненужно, будет обрабатывать в десятки-сотни раз дольше, расходуя на это времени раз в 10 больше, чем мог бы обеспечить АЦП. Беззнаковое деление 32/32 жрёт под тысячу тактов (сейчас сходу точно не скажу - нужно в симуляторе погонять), а 16/16 мало, ибо деление дико ошибкогенерирующая операция, и в результате можно потерять очень много младших бит. Отсюда и проблемы с шумами - медленно и грубо...

По возможности деление и умножение нужно заменять на сдвиги, сложения и вычитания. Но это возможно только если умножать и делить приходится на константу. Деления на переменные, если это возможно, нужно заменять на умножения со сдвигами (делениями на константу). Беззнаковое умножение 16*16 кушает немного больше сотни тактов. Формулы приходится здорово уродовать под возможности камня. Это не ПК, который плавающую запятую жуёт быстрее фиксированной, а деление 64/64 выполняет за такт. Ассемблер это прекрасно показывает...