Потому что temp - целое.
Почитайте учебник по Си Кернигана-Ритчи или подобный, там хорошо изложено про преобразования типов в арифметике.

Применительно к данной конкретной ситуации - сделайте, как я советовал парой постов ранее. То есть, gc=((float)temp*0.5);

gc - какой тип данных?

2 vet
так тоже не работает в железке
не работает даже так:
float gc=0.0;
...
gc=((float)temp*(float)0.5); или gc=((float)temp*0.5);
temp=(unsigned int)gc;
long2char(temp);
...

, а в симуляторе AVR Studio пожалуйста любой вариант правильно исполняется.


2 topkin
даже перебрав все варианты в AVR Studio все работает, в железке нет.

Имхо,что-то с выводом на ALC.У тебя динамическая индикация,а работа с флоат жрет намного больше
времени.Поковыряй код там

Сообщение отредактировал WHALE - May 3 2006, 16:35

Может быть дело в оптимизации? Когда для AVRStudio проект компилировали, был включен профиль debug и настройки оптимизации по умолчанию? т.е без оптимизации? А потом переключаемся в release, автоматически устанавливается максимальный уровень оптимизации по размеру, компилим hex-файл и ... не работает... Такое бывает... Попробуйте при создании файла для заливки в контроллер отключить оптимизацию.

2 WHALE
ALC - это имеется в виду АЛУ?
и насчет индикации: пробовал запрещать все прерывания перед началом вычислений, а после вычисления разрешать (т.к. индикация осуществляется из прерывания), все равно не помогает. Таже ситуация в AVR Studio работает и работает правильно, а в железке нет.


2 Old1


Так как раз без оптимизаций всяких и компиллирую в Debug варианте.

Может это какая то особенность IAR`а v4.12 в evaluation варианте???? - косячная работа с float в реальном железе???

Сообщение отредактировал Serg_greS - May 4 2006, 04:04

А шьете тоже Debug вариант?
Помоему надо шить Release и все заработает.

Я ради интереса запустил код в JTAGICE+M16 (правда без оптимизации), так как ни странно код выполняется: формула вычисляется и с log() и c pow() , массив print[] заполняется, перекодировка работает, перекодированные данные в PORTC выбрасываются, разряды в PORTB двигаются, все это компилирую в том же IAR 4.12 и код гоняю в C-SPY... Проверьте все ли в порядке с динамической индикацией:временно отключите вычисление формул и запишите в переменную gc число (правдоподобное), если работает, проверьте вычисляется ли формула: на свободный пин контроллеоа повесьте светодиод и зажигайте/гасите его после вычисления формулы, или просто дрыгайте этим пином, а смотрите осциллографом (заодно и время вычисления увидите)...

2 Old1
Добавил светодиод на PORTD7, зажигаю его на 5 сек после init() и на время вычислений + ~0.6 сек. Так вот какая интересная штука получается: если в gc записать число и даже умножить его там на 0.5 все отображается, но только такое впечатление, что это выражение вычисляет компилятор, а в проц зашивается константа. А если вычислять gc=(temp*0.5); или gc=(di*0.5); или gc=((float)temp*0.5); или gc=(unsigned int)((float)temp*0.5);
то светодиод не загорается даже после init(); (как будто проц висит и даже не проходит инициализация)

Может у меня какая-то мега битая?
ATMEGA16
16PI
0539J

Old1 не могли бы Вы прислать свой .hex файл, который работает у вас

Сообщение отредактировал Serg_greS - May 4 2006, 11:00

Так оно и есть.

Маловероятно...

Нет проблем, завтра на работе скомпилирую hex и прикреплю к посту. Я код гонял в ИАРовском C-SPY+ JTAGICE, там используется UBROF формат (если я правильно понял )...

2 Serg_greS

Вот выкладываю файл с прошивкой, и на всякий случай исходник, который компилировал. Прошивайте. Для информации, основные настройки проекта: cpu - mega16; memory model - small; CSTACK - 0x80; RSTACK - 32; language- C;optimizations- high/size; output format - intel-extended. FUSы - заводские.

Спасибо что откликнулись, но только похоже что напрасно
Не работает
молчит не дышит.
А Jtag в фузах у меня выключен, т.к. он на порте С и светится только часть сегментов при использовании gc=temp;,
все остальные восстановил по умолчанию (у меня стоял внутренний генератор на 8МГц. Пробовал также и Jtag включить (т.е. все фузы по умолчанию)) - эффект тотже.
Пробовал откомпиллировать присланный исходник с теми же параметрами проекта, не работает, но с чудесами
у Вас hex кончается адресом 668, у меня d20, т.е. больше на n-е количество байт. Уже не знаю на что и думать . Тупик какой-то, или проц всетаки с брачком.

Странно все это...
Что за адрес 668? В моем hex последний адрес вообще-то 0хCDD... Чем прошиваете контроллер? При прошивке верификация проходит без проблем? После прошивки пробовали читать флеш и сравнивать с исходным файлом?...

прошиваю с помощью http://avr.nikolaew.org/progr.htm
верификация проходит без проблем

Сообщение отредактировал Serg_greS - May 5 2006, 12:48

Появилась мысль: если программирование и верификация FLASH проходит без проблем, код в симуляторе работает (и не в симуляторе у меня - тоже), у вас в железке работает,но только до тех пор пока в коде не появляются вычисления с плавающей точкой (при которых требуется больше оперативной памяти), то может быть в вашем контроллере какая либо область SRAM битая. Чтобы проверить ИМХО самый простой вариант взять другую М16 (если она есть), прошить и сравнить результаты, если же ее в наличии нет, тогда ради спортивного интереса и в целях самообразования стоит написать прогу для самотестирования SRAM (что-то вроде: записал байт в ячейку SRAM, прочитал, сравнил, и так по возможности проверить всю SRAM), залить ее в контроллер и посмотреть, что будет. Тут на форуме не так давно даже тема обсуждалась по поводу способов самотестирования AVR, поищите ознакомьтесь, может пригодится.