[Spider 0]

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

А именно кривость проявляется в следующем. если после сборки открыть и посмотреть листинг вокруг строки sei(); перед циклом майна. То там какие-то хаотические куски кода, на которых проц то делает переполнение то ребутится. В общем ведёт себя неадекватно, а в main.c этого кода нет. Точнее есть но не в этом месте.

[NullPointer 0]

Да вроде бы в этом куске кода GCC как обычно распихивает константы по регистрам перед запуском сурового алгоритма :rolleyes:

 

PS: Makefile надо бы исправить: счастье что make сам догадывается что нет main.cpp, а есть main.c, и что оно C, и вовсе не C++ :)

[Spider 0]

А можете дать результат сборки вашей? lss и hex...

[NullPointer 0]

А можете дать результат сборки вашей? lss и hex...

gps_lss_hex_make_corrected.zip

[Spider 0]

Но всё же какой-то косяк...

К примеру вот такой lss получается:

bufferInit((cBuffer*)&uartTxBuffer, (unsigned char *)uartTxData, sizeof(uartTxData));
     6e6:    8c ec           ldi    r24, 0xCC; 204
     6e8:    93 e0           ldi    r25, 0x03; 3
     6ea:    68 e6           ldi    r22, 0x68; 104
     6ec:    71 e0           ldi    r23, 0x01; 1
     6ee:    4f e7           ldi    r20, 0x7F; 127
     6f0:    08 d8           rcall    .-4080   ; 0xfffff702 <__eeprom_end+0xff7ef702>

От куда это он пытается вызвать функцию? Что за бред?

[_Pasha 0]

От куда это он пытается вызвать функцию? Что за бред?

Вероятно, это косяк objdump

[Spider 0]

Вероятно, это косяк objdump

тогда это ещё косяк Proteus и ARVStudio ибо они в отладке на этот же адрес хотят перейти, да и на железе не работает.

[_Pasha 0]

тогда это ещё косяк Proteus и ARVStudio ибо они в отладке на этот же адрес хотят перейти, да и на железе не работает.

 

Дык поделитесь тайной: версия компилятора и содержимое makefile

В lss от SysRq такого косяка ведь нет :(

[Сергей Борщ 126]

От куда это он пытается вызвать функцию? Что за бред?

Это не бред. Не забывайте, что PC имеет ограниченную разрядность. Для меги8 это 13 бит. И при прыжке назад присходит отбрасывание старших разрядов. Итого, для меги8 это будет прыжок на адрес 6F2 - 4080 = 0xfffff702 & 0x1FFFF = 0x1702. Прием очень полезный, ибо команда rjmp не позволяет дотянуться до этого адреса прыжком вперед.

[Spider 0]

Дык поделитесь тайной: версия компилятора и содержимое makefile

В lss от SysRq такого косяка ведь нет :(

Using built-in specs.
Target: avr
Configured with: ../gcc-4.3.2/configure --enable-win32-registry=WinAVR-20081205 --with-gmp=/usr/local --with-mpfr=/usr/local --prefix=/c/WinAVR --target=avr --enable-languages=c,c++,objc --with-dwarf2 --enable-doc --disable-shared --disable-libada --disable-libssp --disable-nls --with-pkgversion='WinAVR 20081205' --with-bugurl='URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse'
Thread model: single
gcc version 4.3.2 (WinAVR 20081205)

Slave.taho.zip

[_Pasha 0]

Скачал. Собрал. Посмотрел. Описанного глюка не было. Полный отчет о make + lss в аттаче.

 

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

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

[ReAl 0]

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

1) Вроде как именно для 8-килобайтных AVR-ок такое поведение задокумениторвано, у 90s8515 и прочих просто нет команды jump (ну, по описанию :) ) и такое применение rjmp/rcall для 8-килобайтных - единственный способ достать до всего адресного пространства

2) -mno-wrap

[Сергей Борщ 126]

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

Это не вне пространства. Пространство памяти программ не безгранично, оно ограничено разрядностью счетчика команд и замкнуто в кольцо все той же разрядностью. Вас ведь не смущает, что таймер, досчитав до 0xFFFF переходит на 0? И SUBI Rx, lo8(-(const)) == Rx + const вас тоже не смущает.

 

Абсолютно аналогичный прием используется в ARM для доступа к контроллеру прерываний (лежит в конце памяти) из области векторов (лежит в начале памяти). Таким же образом высчитываются простейшие задержки на таймерах. Никакого криминала, чистая математика.

[Spider 0]

Спасибо за разъяснения. Будем продолжать учиться.

[ARV 0]

Было бы просто замечательно, если бы кто-то из глубоко вникших в AVR-GCC, посоветовал, как отключить (избежать, обойти) эту фичу с переходами "вне пространства адресов". в условиях недостатка средств отладка в протеусе - единственно возможный вариант, а он, зараза, не понимает, что ограничение разрядности аппаратно встроено в AVR, и не дает вести отладку... AVR Studio такую ситуацию отрабатывает верно, но вести в ней отладку проектов, завязанных на внешние сигналы, практически нереально :(