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

Да.



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

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

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

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

не напутал, просто по умолчанию компилятор сильно оптимизирует код, отбрасывая совершенно лишние куски. в частности в приведенном примере 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к с хвостиком.
Код переносил один в один. Поменял только название функции прерывания по нулевому таймеру. Все остальное буква в букву. Ну хедеры естественно другие.

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

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

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

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

а вот интересно: под выходным кодом что подразумевается? 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)
Это после отладки и оптимизации (в плане кода С)

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

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

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

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