Вы б отложили чашку с кофейной гущей и гадали бы на Протеусе. Найти обращение к байту в интересующей структуре - дело 5 минут при помощи условных брекпоинтов. Тем более, что дефект у Вас стабильный и танцы с бубном не нада.

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

А что у вас были случаи когда компилятор менял местами поля в структуре?
Я таких случаев не помню.

Да и стандарт не позволяет. Но у страха-то глаза велики...

Вы, как всегда, пишете быстрее чем думаете.
1 и 4 кпируют волатайл переменную в R16 и далее все операции идут с регистром, что экономит порядка 20 тактов.
5 - ваш глюк.
3 - для одноразовой операции нет разницы, используется указатель или индекс. Всё равно будет с нуля браться адрес и вычисляться смещение.
2 - даже не знаю что и сказать.

А про порчу памяти от прерывания вам уже всё сказали. Не возникает лишнего прерывания. И я это вижу в железке на осциллографе, а не в протеусе, что суть кофейная гуща. Да ещё и пиратская (да да, есть такое понятие).

Компилятор НИКОГДА не переставит поля структуры. На то она и структура. По крайней мере за 5 лет работы в IAR и 8 лет в CV я такого не видел.


Это называется массив

Как говорят братья-мусульмане, Аллах, когда ночью спит, через стенку не видит

для тех кто начал читать топик с конца, даю справку:

речь шла не о компиляторах...




в данном конкретном случае - не важно как это называется. важно как это воспринимается.

Возьмите реализацию очередей из CVAvr-а. Я её и на WinAVR-е "портировал" - работает.

Структуры в CvAVR-е передавал, как байтовые массивы:



На компе, в программе на C# принимается как часы ... Даже второй МК (мега8), которая из себя изображает USB, нормально принимает. Там правда свои глюки есть, но то уже издержки эмуляции USB...
Изделие - ваттметр на Мега16, стек - 350 байт.

Сообщение отредактировал hd44780 - Aug 7 2012, 06:31

Не суть.

А что запретит прерывание по UART_RXC? Если прерывание не запрещены, то при следующем входном байте на UART будет снова вызван обработчик прерывания.
вы так упорото не хотите понять, что индекс массива у вас никак не защищён от переполнения вниз.

так это или не так легко проверить: поставьте проверку на индекс массива

Советовал уже использовать fifo гдето в первых постах.
У автора топика проблема с заполнением структуры данных АЦП а не с передачей.
Как по мне проглядывается ещё одна проблема - автор пытается заполнять структуру в прерываниях от ацп и одновремененно отправлять её по uart. Возможно там есть временное разделение - т.е. сначала структура заполняется, потом передаётся и гарантированно она не изменится в процессе передачи, но в целом подход неверный.
Было бы правильней проверять флаг необходимости передачи, при обнаружении с запрещёнными прерываниями закинуть всю структуру данных в fifo uart, сбросить флаг необходимости передачи, разрешить прерывания. Заодно можно обнулять индекс массива данных и инкрементировать его по каждому прерыванию ацп.

UART в режиме SPI. Если байт не будет отправлен, то он не будет принят, и RxC не будет. Посмотрите тушку прерывания - последний байт принимается, но отправки (UDR1 = ADC3_temp;) нет.
Это про порты АЦП речь.
С передачей в комп уже всё определилось - не она виновата.


У меня есть свой движок с очередью, пользую уже лет 5. Но в очереди есть смысл когда мы мониторим несколько портов и, главное, информация из этих портов может уйти произвольно.
В данном случае маршруты следования информации строго определены, делать очередь нет смысла.

Переписал прерывание через указатель, и всё заработало:


Результат:



Пока сделал только для АЦП №3.

Теперь думаю, как соптимизировать прерывание. Пробовал избавиться от ADC3_rx_compl и в мейнлупе поставить проверку
if( pADC3_rx_pointer == (&(Buf_ADC3[ADCBUFSISE - 1])) ) {}
Прерывание долбит непрерывно и не останавливается.
Уже поздно и мозг не варит, по тому не могу понять почему

Если pADC3_rx_pointer изменяется в прерывании, а анлизируется в основном цикле - она должна быть объявлена как volatile-указатель: unsigned char * volatile pADC3_rx_pointer = &(Buf_ADC3[0]);

В этом случае компилер ругается

Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement
*pADC3_rx_pointer++ = UDR1;

Регистры в IAR все volatile и компилер какбЭ намекает, что не может одновременно извлечь две volatile переменные для операции.

Хотя в реале, конечно, работает.

Вот так
*pADC3_rx_pointer = UDR1;
pADC3_rx_pointer++;
полегчает.

Компилер намекает, что порядок выполнения присваивания и постинкремента не гарантирован.