Доброго дня!

Proteus не показывает значение переменных типа float в пошаговом режиме. Как сделать чтобы отображал?


Спасибо!

Не использовать float переменных, особенно в прерываниях, особенно для подсчета каких-то там тиков таймера. И вообще, про float на 8битных платформах надо забыть.

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


В данном примере да, но насчет "вообще" позвольте не согласиться.

Сообщение отредактировал 777777 - Jun 2 2010, 09:23

Попробуйте так :
Запустите отладку кнопкой STEP

Выберите отображать окно :
Debug->Watch Window

В окне мышкой :
Add items (by address..)

Memory -> AVR Data memory
Name -> Присвойте имя(может быть любым, нп. такое же как у переменной)
Address -> из окна AVR variables скопируйте адрес( у вас он равен 0151, это из Y+4=0151, записать в формате 0x0151 )

Data type -> IEEE float
Display format -> Hexadecimal (так было )

volatile для переменной вы уже написали, осталось отключить оптимизацию компилятора.
Удачи.

Нафига ея отключать?

Кстати, аффтортопику на заметку - лучше вначале хоть какие-нить макабуки почитать или по меню полазать, а потом уже про глюки говорить. Глюки есть, но совсэм нэ там.

Для людей использующих флоат для подсчета тиков в прерывании, лучше вообще забыть, а вот когда научатся считать все в целочисленном виде (года через 2), можно начать вспоминать

Надо предложить модераторам ввести в правила пункт: "запрещается советовать отключать оптимизацию компиляторов".

Сообщение отредактировал 777777 - Jun 3 2010, 09:03

Так эта дла тага, чтабы прогу пооотлаживать.

С включенной оптимизацией по С коду сильно не попрыгаешь.
Да и сама переменная может в регистрах проца оказаться.

Весь вопрос в том , а какой тип переменной использовать, со временем, человек сам научится.

А с оптимизацией она не отлаживается?

Это еще почему? Вообще-то отлаживать ее надо в том виде, в каком ей предстоит работать.

И что? Это вызывает какие-то проблемы? Я, например, наоборот - огорчаюсь если какая-то переменная оказывается в памяти и начинаю думать что бы такого сделать, чтобы компилятор перенес ее в регистр.

А вы не понимаете, что этим хотели сказать?
Работать "она" может и без оптимизации.Вы, наверное, хотели-бы в идеале использовать uC без RAM ...
777777
Мой флуд смахивает на ваш

Хорошее предложение . Одобряю.




Я понимаю отлаживать не общую работоспособность чего-либо а 2x2=? .

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


Если вам так надо, пожалуйста. Но гораздо удобнее отладить прогу "как она есть", а перед заливкой в проц., скомпилировать с включенной оптимизацией.


Интересно, чем оно вам понравилось?

Убей не пойму - а что мешает прибегнуть к ассемблеру? Но и это требуется крайне редко - я обычно отлаживаю программу прямо в сишном тексте, отладчик позволяет шагать по строкам прогрммы, смотреть значения переменных и т.п. - что еще нужно для оладки? Да, иногда компилятор перетасовывает программу и при пошговой отладке она иногда "прыгает" в неожиданные места. Но ничего страшного не происходит, при ближайшем рассмотрении становится понятен ход "мыслей" оптимизатора .

Если ваша программа нагружает процессор на 1%, то наверное можно. Но обычно процессор выбирается так, чтобы он был загружен на 20...30%, а если проводится а поскольку отключение оптимизации делает программу медленнее раз в 5...10, то она становится практически неработоспособной - не успевает.
То же самое относится к ее размеру - если без оптимзации она не влезет в память - как ее отладить?

Наверное тем, что совет отключать оптимизацию является вредным.

Правильным подходом к делу, при котором прежде всего нужно думать и писать программы, а не исследовать отладчиком что же это такое получилось и латать некий исходник из
каких-то строчек. Это для латания жизненно необходимо соответствие какой-то отдельной строчки, какому-то отдельному "результату", ибо латающий практически никогда не уверен, в том, что он написал и уж тем более не представляет, как его понял (а действительно 2+2=4?) компилятор. При этом его мышление действительно ограничено разрозненными строчками и проанализировать десяток-другой уже не под силу. Вот на такой благодатной почве и растут не выпускающие отладчика из рук враги оптимизаций, ибо латанный-перелатанный подогнанный под ответ в окошке отладчика исходник при оптимизации рассыпается и тут уж начинаются обильные байки о глюках компиляторов . Если человек может с уверенностью без ошибок написать десяток-другой строчек, а в том случае, если и ошибся банально их прочитать и найти ошибку, то оптимизация у него включена и настроена с самого начала. Ну а уж про критические по времени исполнения куски кода вообще и говорить нечего.