Пишу программу с использыванием WinAVR. Mega8535.
Есть предположение что подгорел один бит в регистре общего назначения.
Можно ли как-то в WinAVR закрыть доступ к этому регистру(не используюя при этом asm вставки). Например так что б он вообще не юзал R25, а вместо него использывал R18 или какой-то другой...

Сразу прошу прощения за жестокий офтоПище, ну не удержатся! Вы гражданин "ЖЖоте не по детски"! :-) Спасибо за хорошее настроение на выходные :-D:-D:-D

Т.е. Вы хотите сказать, что так не бывает? Ситуация принципиально возможная, не вижу ничего смешного.

2 bureau: Что заставило сделать такое предположение?

ну..ну. такие чипы наверное у атмела в самом охраняемом сейфе лежат, за семью замками, как в музее.
bureau - выставите ваш чип на аукцион, его с руками оторвут! серьезно! я готов за такой экспонат 100р. отвалить.. чтобы друзьям показывать. А еще и наспор можно выигрывать бешенные деньги..:-)

Нет, такие чипы уходят после тестирования в мусор в немалом количестве. Или Вы серьёзно считаете, что у них выход годной продукции 100%?

Нет, я так не считаю.
Вопрошающий сказал следующее:

Подгорел в процессе работы с чипом? Очень интересно! :-)

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

Интересно было бы услышать ответ bureau.

1) в чём выражатеся "подгорание"?
2) есть предложение проверить предположение маленькой тестовой программкой на ассемблере.

Не выйдет без перепиливания напильником и пересборки. Ключ -ffixed-имя_регистра существует, но с R25 не выйдет, так как они из оснвоной рабочей пары R25:R24, в которой передаётся первый аргумент и возвращается значение.

Кому смешно а кому и нет... Если заказ надо сдать через 2 часа а заменить нечем...


в начале просто сделал анализ режима работы и asm кода, который генерил WinAVR. Потом просто написал программку на asm "ЭХО" отправляю по ЮАРТу FF с компа и назад принимаю. Попробывал R16, обратно приходит FF, сделал mov R25, R16 и отправляю по ЮАРТу R25, принимаю FD. Если поставлю вместо R25 другой регистр то все нормально, а при R25 FD



ну если есть желающие то пожалуста...


Да, в процесе работы...

хорошо бы код в студию. может у Вас всетаки програмная ошибка? А то шаманство какоето...

делал проверку вот такой программкой

.include "m8535def.inc"
.def data=R25 ;вместо R25 подставлял разные регистры...

.org 0x0000
rjmp main

.org URXCaddr
rjmp USART_RXC ; USART RX Complete Handler



main:
ldi r31,low(ramend)
out spl,r31
ldi r31, high(ramend)
out sph,r31

ldi data, 0x59
MOV zh,data
;cp zh:zl, data
rcall USART_Init
rcall USART_Transmit



USART_Init:
ldi r16, (1<<RXEN)|(1<<TXEN)
out UCSRB,r16
;Óñòàíîâêà ôîðìàòà ïîñûëêè:
ldi r16, (0<<USBS)|(0<<UMSEL)
out UCSRC,r16
nop
ldi r17, 12
ldi r16, 0
out UBRRH, r16
out UBRRL, r17
ldi r17, (1<<ISC00)|(1<<ISC01)|(0<<ISC10)|(1<<ISC11)|(0<<SM0)|(0<<SM1)|(0<<SM2)|(1<<SE)
out MCUCR, r17
ldi r17, (1<<INT0)|(1<<INT1)
out GICR, r17
ldi r16, $61
ret

loop:


USART_Transmit:
sbis UCSRA,UDRE
rjmp USART_Transmit
mov data, r16
out UDR, data

Wait_Transmit:
sbis SPSR,SPIF
rjmp Wait_Transmit
nop
nop

sei
sleep

USART_RXC:
nop
sbis UCSRA, RXC
rjmp USART_RXC
in r16, UDR
rjmp loop

Как я понимаю проект уже сдан/сроки прошли. Сейчас разбор полетов.
Код конечео путанный :-).. Пока явно причину порчи не вижу. Порекомендовал бы Вам поаккуратнее со стеком работать. Поставте на вектор
просто reti
И вместо
rjmp USART_Transmit
Если пересылать другой код, вместо ff, данные не считая этого бита верные?
Зачем эти строчки?

сведите проверку до минимума. Может диодиком помигать, а то длинная цепочка получается.
Программа работает на другм чипе, с теми же условиями?(Вы говорили что заменить нечем....?!)

Соглашусь с add, и добавлю, уберите из вашей тестовой программы строки, начиная с Wait_Transmit и кончая sleep. А то непонятно, при чём здесь ожидание конца передачи от SPI и какое прерывание будит процессор из idle и что оно там делает с r25(:-). Оставшегося кода вполне достаточно для организации эха. И запретите все прерывания.

У меня есть более простая программка для проверки R25



Тестером померяйте - на всех выводах порта B должно быть "1".


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

А что, хорошая идея... чтобы твой код куча народа проверило По теме - один раз спалил ОЗУ, а процик работал. До первого ret конечно Но чтобы бы бит в регистре o_O

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


любой другой код который содержит во втором бите "1" в ответе принимаю во втором бите "0"

2 defunct: да, а проверка с использыванием порта это идея, как-то не подумал... сенкс

Давеча спалили (во время работы точнее пайки) at90can128. Очень интересно сгорела. Вела себя так, как будто закорочены два канала АЦП. Тем не менее они были не закорочены. После перепайки - всё стало работать нормально. Бывали и ещё более интересные вещи.

В одном изделии одна линия порта при сбросе устанавливалась в состояние 0 (или 1 я не помню). Но далее работала абсолютно нормально! В программе была введена CRC и она совпадала! После перепрошивки глюк прошёл и больше не возвращался. Да, кстати, глюк вылез у клиента после 1.5 лет работы.

Кто изучал BIOS PC знает, что там первый самотест тест регистров CPU. В жизни все бывает. М.б. теоретически такой случай здесь, но при этом uC будет глючить как бог душу положит.

Такая песня сплошь и рядом попадалась с Мега8 в TQFP корпусе.