WinAvr в вопросах и ответах

А его можно в vmlab интегрировать? Если да то как? Мне что бы смотреть память регистры и прочее.

Tohey писал(а):А его можно в vmlab интегрировать?

Да.

Tohey писал(а):Если да то как?

Как написано по линку выше.

нужна помощь.
пытаюсь написать код обмена данными по SPI, только вот них... ничего не получается...
пишу в WinAvr 20070122, отлаживаю в Proteus.
такая проблема: там прикошаченный код должет отправлять данные по SPI в два места... вроде все по даташиту написано, выставлено, но proteus от таких вещей просто зависает. передача по spi идет, но как-то её много слишком, не может быть этот интерфейс таким медленным.
думаю, что это у меня с C проблемы.
кому не влом, посмотрите, мож я как-то не так данные передаю...
мож proteus гонит? не лезу к жклезу пока не решу эту проблему, а то зря буду распаивать схему...

Вложения

test.c: (925 байт) Скачиваний: 553

Странно у тебя как то цикл for описан
for (i=0; 1<4; i++)
потом
for (i=0;1<8;i++)
потом
for (i=0;i,4;i++)
оно так будет до бесконечности крутиться. А последнюювообще не должнокомпилировать

Хотел спросить по WinAvr.
У меня как то странно он компилирует. Иногда целые строки пропускает и не компилирует.
Иногда то же самое компилируется замечательно.
например
...
while(1){
u = 1023;
tm=u/1000;
d[0]=(unsigned char) tm;
u %=1000;
...
строка u = 1023; не компилирует кода :shock:

присем за полчаса до этого спокойно работала. Компилятор никаких ошибок не выдает и код компилирует. Может что с оптимизацией напутал?
П.С. версия WinAvr 20070525 подцеплена к AVRStudio

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

и тут я начал писать про второго адресата... самое интересное в том, что тут прога и стала гнать... у меня такое ощущение, что компилятор гонит, потому как не могут одни и те же строки один раз нормально работать, а второй разгнать.
Вот в прилагаемом файле цикл for который первый, стал отчего-то бесконечным вместе с дерганьем ножек. он постоянно дергает ногой и шлет данные, хотя программа и закончилась благополучно.
а если раскомментировать строки внизу, то каким-то образом до второго устройства доходят нужные 8 байт, потом те, которые слались первому устройству, а потом (наверное, добить :-D) куча бесконечная нолей...
а может компилятор неправильно собирать hex? или ему такие вещи не свойственны?

Вложения

test.c: (941 байт) Скачиваний: 641

savage писал(а):У меня как то странно он компилирует. Иногда целые строки пропускает и не компилирует. ... Может что с оптимизацией напутал?

не напутал, просто по умолчанию компилятор сильно оптимизирует код, отбрасывая совершенно лишние куски. в частности в приведенном примере u=1023 - явно лишний оператор, т.к. в следующем можно сразу вычислить значение без дополнительной переменной. кстати, и сама строка tm=u/1000 тоже может быть лишняя, т.к. и это значение заранее известно...
чтобы компилятор генерировал код на каждый оператор - надо полностью отключать оптимизацию.

P.S. Отдельные строки - это еще цветочки! он целые функции выкидывает! и некоторые циклы запросто "оптимизирует" в бесконечный переход на самого себя без выполнения каких бы то ни было действий! Так что держи ухо востро!

Спасибо. Я чтото не допел что так может быть. Собственно строка u=1023; появилась во время отладки, когда в предыдущей строке он не захотел извлекать из АЦП данные. Он точно так же перед этим отбросил целую функцию которая читала из АЦП.
строки
tm=u/1000;
d[0]=(unsigned char) tm;
тоже по той же причине появились. после того как
строка
d[0]=(unsigned char) u/1000;
стала выдавать странные данные. т.е. u содержит 1023 а код
d[0]=(unsigned char) u/1000;
u %=1000;
d[1]=(unsigned char) u/100;
u %=100;
d[2]=(unsigned char) u/10;
d[3]=(unsigned char) u%10;
дает d[2]=2 а d[3]=3. d[0] и d[1] равны нули.

функцию, которая читала из АЦП он легко мог отбросить, если результат этой функции нигде не использовался. вот он и посчитал - зачем выполнять функцию, если ее результат никому не нужен? логично, в общем-то... но на этапе отладки может ставить в тупик

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

ARV
Спасибо!
Будем думать...

Да уж... Оптимизация....
Проект пришлось сделать в CodeVision. Там он уложился в 936 слов. Для интереса перенес в WinAvr. Там работоспособный код получился со всеми способами оптимизации кроме -О3. Причем выходной код получился размером 5к с хвостиком. :shock:

Код переносил один в один. Поменял только название функции прерывания по нулевому таймеру. Все остальное буква в букву. Ну хедеры естественно другие.

Да уж

...
Тут есть несколько предположений: либо сказывается то, что VinAWR бесплатный компилятор, либо все же оптимизация требуется (а для этого требуется корректировка кода)... либо еще что-то :)))

savage писал(а):Проект пришлось сделать в CodeVision.

Прекрасный компилятор.

ребят, подскажите как грамотно опросить кнопку?
я делаю

Код:: if(!(PINC & (1<<PC3)))

в программе всего лишь две процедуры:main и та, которая вызывается по нажатию кнопки.
при нажатии кнопки вызванная процедура зацикливается..
как быть?

savage писал(а):Причем выходной код получился размером 5к с хвостиком.

а вот интересно: под выходным кодом что подразумевается? hex-файл или bin?

bin. вернее то что пишет компилятор при компиляции.
Hex получается 13583b
в Codevision hex получился 5278b

CodeVision:
Program size: 939 words (22,9% of FLASH) т.е 1878Байт
WinAvr:
Program: 4840 bytes (59.1% Full)
Это после отладки и оптимизации (в плане кода С)

а исходничек сей удивительный можно узреть?

Вот собственно исходник. Каряво немножко...

Вложения

vs8535.zip: исходник на WinAvr; (1.63 KiB) Скачиваний: 565

У тебя в коде есть такой макрос RDAT - это число типа float, равное 0,005. в результате единственный оператор умножения на это число приводит к тому, что WinAVR прилепляет библиотеку действий с числами float - отсюда и размер. Если в операторе

Код:: ur=iind*RDAT;

заменить RDAT на его математический эквивалент 5/1000, т.е. так:

Код:: ur=iind*5/1000;

то в итоге мы получаем код размером в 1552 байта!

вот это я называю использование Си в микроконтроллерах - тут думать надо гораздо больше!!! И это, кстати, называется оптимизацией!