Проблема с ADC ATTINY461 Опции

[__nik__]

Столкнулся с тем, что часть программы, работавшая на M8, ATTINY26, m8535 отказывается работать на тани461, а именно п/п измерения фазы(полпериуда).
При изучении выяснилось проблема кроется в работе АЦП.
Проблема:
Как оказалось, АЦП работает как хочет, хочет в середине фазы выдаст значение =0, или, при отсутствии сигнала может выдать большое значение(выше обычного шума) из-за чего происходит ошибка в показании прибора.
но вышесказанное это вообще ничто, по сравнению с тем, что иногда (всегда по разному) за определенное количество ацп преабразований выдает их сумма равняется 0, что вообще не понятно.
Во время работы ацп, прерывания запрещаются и сканирование каналов не происходит, на время тестов это отключено, таким образом измеряем только один канал с внешним опорником на 4.096в.

если кто нибудь встречался с данной проблеммой, то посоветуйте как ее решить.
Условия работы и измерений:
Еще, скорость АЦП никак не влияет, синал 100% во время измерений присутствеут, контролировалось по осцилографу, макс сигнал составлял в пике ~2.3 вольта.

[__nik__]

Место глюка нашел при помощи AVR Dragon, он оказался в умножении с точкой ( * 419.0)
на что умножать не важно, результат всегда равен 0. Если убрать запятую, то считает верно но для меня недостоточно точно. Столкнулся еще с тем что не могу скорость АЦП переключить, это как то похоже это как то связано с иаром 4.21А.
еще раз хочу обратить внимание что таже программа работает в тани26....

[SasaVitebsk]

еще раз хочу обратить внимание что таже программа работает в тани26....

Вы сами себе противоречите, уважаемый. Значит не та же программа. Если бы ошибка, которая у вас явно присутствует и которую вы вначале списали на камень, а потом на IAR, происходила при обращении к оборудованию, то я бы поверил. Возможно файл объявлений ошибочный или даже проблемы с оборудованием каким то. Но ошибка, возникающая при умножении с использованием плавающей запятой (то есть данный кусок раскладывается в 2 десятка простых комманд) - не поверю.

Настораживает также упоминание вами прерывания и "случайности" ошибки.

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

Для ясности приведу два примера.

1) Пример с регистрами I/O
В голове находится следующая строчка
PORTL |= 1;
Компильнётся примерно в следующее
lds r16,portl
ori r16,1
sts portl,r16

В прерывании следующая строчка
PORTL |= 2;

А теперь посмотрите внимательно. Если прерывание придёт во время исполнения команды ori при этом бит D1 порта L в это время будет равен 0, то произойдёт следующее. В прерывании бит 1 будет установлен в 1, но сразу по выходу из прерывания он опять сбросится в 0. И вы будете в непонятках так как в голове вы с этим битом не работаете.

2) Пример с переменными
В голове находится следующие строчки
volatile uint16_t i,j;
if(i<j)...
Представим себе что i=0x1f, а j=0x23. Очевидно, что условие должно выполниться. Учитывая что переменные 16 бит, то сама операция пройдёт в 2 этапа

В прерывании следующая строчка
i++;

Представим, что прерывание произойдёт м/у сравнениями младших и старших байтов. Тогда первое сравнение будет F c 3. Потом идёт прерывание где i становится 0x20 и идёт сравнение 2 с 1. Результат - условие выполняться не будет. У вас возникнет ошибка.

Примечание: IAR пытается бороться с такими ситуациями путём предварительной пересылки регистровой пары, а потом уж самой операции. Но это я так для примера привёл. Так как если операнд 4 байта, то и это уже не спасает от потенциальной ошибки.


Проявляться такая ошибка будет крайне нерегулярно, так как необходимо:
a) прерывание в "нужном" месте
б) модификация "нужной переменной" или появление "нужного значения" переменной.

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

[__nik__]

Вы сами себе противоречите, уважаемый. Значит не та же программа. Если бы ошибка, которая у вас явно присутствует и которую вы вначале списали на камень, а потом на IAR, происходила при обращении к оборудованию, то я бы поверил. Возможно файл объявлений ошибочный или даже проблемы с оборудованием каким то. Но ошибка, возникающая при умножении с использованием плавающей запятой (то есть данный кусок раскладывается в 2 десятка простых комманд) - не поверю.

Настораживает также упоминание вами прерывания и "случайности" ошибки.

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

Уважаемый, я кажется раз 5 уже писал что прерывания запрещены, да и происходят они ~7 раз в секунду, только в нужныж мне местах, и только для передачи информации на второй процессор.

Для ясности приведу два примера.
1) Пример с регистрами I/O
В голове находится следующая строчка
PORTL |= 1;
Компильнётся примерно в следующее
lds r16,portl
ori r16,1
sts portl,r16

извиняюсь, я пользуюсь
PORTX_BitY=1;
что интерпритируется как:
SBI PORTX,Y
и если вы будете использовать (X<<Y), то это облегчит жизнь компилятору и программу на пару байт так как будет использовать лишь одну мнемонику вместо 3х

В прерывании следующая строчка
PORTL |= 2;

А теперь посмотрите внимательно. Если прерывание придёт во время исполнения команды ori при этом бит D1 порта L в это время будет равен 0, то произойдёт следующее. В прерывании бит 1 будет установлен в 1, но сразу по выходу из прерывания он опять сбросится в 0. И вы будете в непонятках так как в голове вы с этим битом не работаете.

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

2) Пример с переменными
В голове находится следующие строчки
volatile uint16_t i,j;
if(i<j)...
Представим себе что i=0x1f, а j=0x23. Очевидно, что условие должно выполниться. Учитывая что переменные 16 бит, то сама операция пройдёт в 2 этапа

В прерывании следующая строчка
i++;

Представим, что прерывание произойдёт м/у сравнениями младших и старших байтов. Тогда первое сравнение будет F c 3. Потом идёт прерывание где i становится 0x20 и идёт сравнение 2 с 1. Результат - условие выполняться не будет. У вас возникнет ошибка.

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

Примечание: IAR пытается бороться с такими ситуациями путём предварительной пересылки регистровой пары, а потом уж самой операции. Но это я так для примера привёл. Так как если операнд 4 байта, то и это уже не спасает от потенциальной ошибки.
Проявляться такая ошибка будет крайне нерегулярно, так как необходимо:
a) прерывание в "нужном" месте
б) модификация "нужной переменной" или появление "нужного значения" переменной.

ИАР может и пытается, но при максимальном уровне оптимизации он на все плюет, и если вы посмотрите на код который он сгенерил, то обнаружите что половина того что вы написали он попросту либо соединил в одну строчку, либо удалилю Вот такой он загадочный, и чтобы писать на С а не на АСМ время зависимые подпрограммы, приходится его порядком поубеждать чтобы он не своевольничал и не удалял то что его не просят, и тем более не уменьшал разрядность в математике, именно для этого и вводилось чтобы он использовал математику с точкой принудительно, не знаю это его ошибка или нет, но при float = Long/conct он не использует математику с точкой при максимальной оптимизации.

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

Вот с этим я пожалуй пока не соглашусь, и даже думаю выложу либо скрины либо видео с экрана того что происходит, но вот только как дракон нам по гарантии поменяют. Ошибка именно в * , я думаю не в самом умножении а гдето при пересылки данных, потому как начальные действия делает верно.
Утверждения на данный момент были сделаны при помощи АВР Дракон, правда он отработал всего сутки потом начал сажать питание испытуемой платы с нагревом 8ногой микрухи рядом с Мега128 на ней написано AHT). пришлось исследования свернуть и заменить * на /, правда точность жутко упала почемуто.