Может, потому что так оно и есть?.Z_h_e писал(а):Правда мне непонятно почему в формуле 1024, а не 1023.
. 
Код: Выделить всё
--- No source file -------------------------------------------------------------
0000037E LSL R30 Logical Shift Left
0000037F ROL R31 Rotate Left Through Carry
00000380 LPM R0,Z+ Load program memory and postincrement
00000381 LPM R31,Z Load program memory
00000382 MOV R30,R0 Copy register
00000383 IJMP Indirect jump to (Z)
00000384 CLI Global Interrupt Disable
00000385 RJMP PC-0x0000 Relative jump // вот тут получается останов
00000386 NOP Undefined
00000387 NOP Undefined
00000388 NOP Undefined
00000389 NOP Undefined
0000038A NOP Undefined
0000038B NOP Undefined
0000038C NOP Undefined
0000038D NOP Undefined
0000038E NOP Undefined
0000038F NOP Undefined
00000390 NOP Undefined
00000391 NOP Undefined
00000392 NOP Undefined в конце программы, а вот косвенный переход по адресу в указателе Z выбрасывает в заадресное пространство mega32. Как вариант, компилируете для камня с адресным пространством >32к.FeCat писал(а):это компиллятор по умолчанию добавляет
avr-gcc в этом случае не зацикливает программу, а перебрасывает её на нулевой вектор, т.е. выполняет пересброс.Demiurg писал(а):Возможно у вас включено какое-то прерывание, а обработчика нет. Компилятор в таких случаях автоматом делает такие программные заглушки.
Не надо было приводить даже такие картинки, в ДШ есть график на котором указано что Vref выше 0x3FF. И формулу расчета я не пытался оспаривать, как сделали разрабы камня, так и надо считать. Просто мои зачерепные опилки желают, чтобы максимум АЦП соответствовал опоре.WiseLord писал(а):Как по мне, первая картинка, под первую формулу, правильнее:
Что тут может быть непонятного, хрень какую-то насчитал я.WiseLord писал(а):Что-то я не совсем понял, что это Вы посчитали.
Хотел показать, что код АЦП не будет соотвествовать ИОН никогда и показал 
.Можно вставить обработчик по умолчанию ISR(__vector_default), но он же тоже не циклит, если сам это не сделаешь.ARV писал(а):avr-gcc в этом случае не зацикливает программу, а перебрасывает её на нулевой вектор, т.е. выполняет пересброс.
А Вы запустите в симуляторе код и в окне дизассемблера должно быть указано к какому участку исходного кода соответствует машинный.FeCat писал(а):Если отбросить железные проблемы, то почему такое может происходить?
И где же у нас выход из майн? Если майн вызывается.ARV писал(а):в одном месте: там, где происходит выход из main.
я пометил место, где онDemiurg писал(а):И где же у нас выход из майн?
Код: Выделить всё
int main(void){
} <<<< вот где-то тутКод: Выделить всё
32: 14 d0 rcall .+40 ; 0x5c <main>
34: 19 c0 rjmp .+50 ; 0x68 <_exit>
; что-то там всякое
00000068 <_exit>:
68: f8 94 cli
0000006a <__stop_program>:
6a: ff cf rjmp .-2 ; 0x6a <__stop_program>
Код: Выделить всё
00000000 <__vectors>:
0: 12 c0 rjmp .+36 ; 0x26 <__ctors_end>
2: 19 c0 rjmp .+50 ; 0x36 <__bad_interrupt>
4: 18 c0 rjmp .+48 ; 0x36 <__bad_interrupt>
6: 17 c0 rjmp .+46 ; 0x36 <__bad_interrupt>
8: 17 c0 rjmp .+46 ; 0x38 <__vector_4>
a: 15 c0 rjmp .+42 ; 0x36 <__bad_interrupt>
c: 14 c0 rjmp .+40 ; 0x36 <__bad_interrupt>
e: 13 c0 rjmp .+38 ; 0x36 <__bad_interrupt>
10: 12 c0 rjmp .+36 ; 0x36 <__bad_interrupt>
12: 11 c0 rjmp .+34 ; 0x36 <__bad_interrupt>
14: 10 c0 rjmp .+32 ; 0x36 <__bad_interrupt>
16: 0f c0 rjmp .+30 ; 0x36 <__bad_interrupt>
18: 0e c0 rjmp .+28 ; 0x36 <__bad_interrupt>
1a: 0d c0 rjmp .+26 ; 0x36 <__bad_interrupt>
1c: 0c c0 rjmp .+24 ; 0x36 <__bad_interrupt>
1e: 0b c0 rjmp .+22 ; 0x36 <__bad_interrupt>
20: 0a c0 rjmp .+20 ; 0x36 <__bad_interrupt>
22: 09 c0 rjmp .+18 ; 0x36 <__bad_interrupt>
24: 08 c0 rjmp .+16 ; 0x36 <__bad_interrupt>
00000026 <__ctors_end>:
26: 11 24 eor r1, r1
28: 1f be out 0x3f, r1 ; 63
2a: cf e5 ldi r28, 0x5F ; 95
2c: d4 e0 ldi r29, 0x04 ; 4
2e: de bf out 0x3e, r29 ; 62
30: cd bf out 0x3d, r28 ; 61
32: 14 d0 rcall .+40 ; 0x5c <main>
34: 19 c0 rjmp .+50 ; 0x68 <_exit>
00000036 <__bad_interrupt>:
36: e4 cf rjmp .-56 ; 0x0 <__vectors>
Вы не учитываете одну очень важную вещь. И это говорит о том, что вы не ассемблерщик. Пусть даже и так, вы обязаны заглядывать в дизасм. Иначе как вы оцениваете работу МК в тяжелых случаях.ARV писал(а):...
Код: Выделить всё
rcall main
, мне поясните, о каком срыве стека Вы говорите при выполнении команды RJMP PC-0x0000Z_h_e писал(а):...
ARV писал(а):avr-gcc автоматически генерирует последовательность cli; jmp PC - 0; только в одном месте: там, где происходит выход из main.
как бы я вам дизасм и привел в качестве подтверждения своих слов. а ассемблер у меня занимает ровно ту нишу, которую и должен - помогает в особо тяжких случаях, а в остальных полагаюсь на Си. перерос я ассемблер...Demiurg писал(а):вы не ассемблерщик. Пусть даже и так, вы обязаны заглядывать в дизасм. Иначе как вы оцениваете работу МК в тяжелых случаях
за подсказку спасибо, но теперь подскажите по подсказке: в каком именно месте срывается стек при вызове main? напоминаю код:Demiurg писал(а):Подсказка. Main вызван, а стек сорван
Код: Выделить всё
00000026 <__ctors_end>:
26: 11 24 eor r1, r1
28: 1f be out 0x3f, r1 ; 63
2a: cf e5 ldi r28, 0x5F ; 95
2c: d4 e0 ldi r29, 0x04 ; 4
2e: de bf out 0x3e, r29 ; 62
30: cd bf out 0x3d, r28 ; 61
32: 14 d0 rcall .+40 ; 0x5c <main>
34: 19 c0 rjmp .+50 ; 0x68 <_exit>Z_h_e писал(а):пока ARV изучает основы AVR
В том-то и дело, что стек может сорвать в любой момент. Незапланированное прерывание может быть включено в любой момент. Это может быть ошибка программиста. Сбой по питанию. Именно по этой причине делается переход на такой кусок код. Отключается глобально прерывание и глухое зацикливание. Если watchdog не включен, мк наглухо зависнет. Если включен, то мк зависнет до сработки сторожевого таймера.ARV писал(а):...
вы о чем вообще говорите? AVR систему исключений (exception) не поддерживает, и запланировать переход на какую-то заглушку в случае незапланированного "срыва стека" невозможно.Demiurg писал(а):Незапланированное прерывание может быть включено в любой момент. Это может быть ошибка программиста. Сбой по питанию. Именно по этой причине делается переход на такой кусок код.