Forum: Compiler & IDEs Syntax errors / Prog. aus CodeVision


von Claus (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,
Da ich Codevision gewöhnt bin, allerdings an meinem Privat PC ( also
nicht in der Firma) AVR Studio und WinAVR nun nutzen will,
kann ich die Codevision Quellcodes ja nicht einfach so
weiterverarbeiten.
Wo liegen denn die Fehler bezüglich der Operatoren?
Ich habe nirgens ein vergleich von CodeVision und GCC gefunden.
Als anhang mal ein Auszug Quellcode. Kann mir jemand sagen welchen
Operator ich wie ändern muss?

Danke

von johnny.m (Gast)


Lesenswert?

Wenn Du jetzt noch mitteilst, was für Fehlermeldungen Du bekommst,
dann kannst Du vielleicht geholfen werden...

An sich sieht der Code zumindest syntaxmäßig auf den ersten Blick OK
aus. Das Einzige, was mir so auffällt, ist, dass Du die iom8.h direkt
includest. Das macht man nicht. Es wird immer die io.h includet und im
Makefile oder der Project Configuration im AVRStudio dem Compiler
mitgeteilt, welchen µC Du benutzt.

von johnny.m (Gast)


Lesenswert?

...ach ja, warum benutzt Du nicht immer das 16-Bit-Register ADC(W),
sondern machst da irgendwelche komplizierten Verknüpfungen mit High-
und Low-Byte? In einen short passt auch das komplette ADC rein...
Außerdem gibt die Funktion read_adc ja den 16-Bit-Wert zurück, den Du
nur nicht auswertest.

von Claus (Gast)


Angehängte Dateien:

Lesenswert?

Hier mal ein paar errors.
Den oben geposteten Quellcode ergibt mit 7 errors.
Wenn ich die <avr/io.h> include dann bin ich mit 35 errors dabei.
deshalb hatte ich es direkt versucht.

Hier im Anhang mal ein Errorauszug.
Wie gesagt bin mit GCC nicht groß geworden g

von johnny.m (Gast)


Lesenswert?

> Wenn ich die <avr/io.h> include dann bin ich mit 35 errors dabei.
Vermutlich, weil Du dem Compiler den Controllertyp nicht bekanntgibst.

Wenn Du die "short" noch durch "unsigned int" ersetzt, verschwinden
auch noch ein paar Warnmeldungen.

Dann sollte in der Umrechnung
freq=a+(b*255);
mindestens das a nach float gecastet werden, also
freq=(float)a+(b*255);

Die #includes sollten sinnvollerweise immer am Anfang stehen.

Da a, b und freq nur in main verwendet werden, sollten sie auch
sinnvollerweise lokal deklariert werden und nicht global.

Muss jetzt grad kurz weg, schaue nachher noch mal vorbei...

von Claus (Gast)


Lesenswert?

Alles klar, werde den Quellcode mal noch etwas bearbeiten.
muss später dann auch weg, schau morgen wieder rein.
Danke bisher.
Ciao

von johnny.m (Gast)


Lesenswert?

Ach ja, es muss natürlich heißen
#include<avr/io.h>

von johnny.m (Gast)


Lesenswert?

Und nochmal:

Habe das grad mal compiliert. Der Fehler liegt beim #include<lcd.h> und
dem #asm ... #endasm (war ja klar, im GCC-C gibts das so nicht).

Mit #include<avr/io.h> und ohne das ganze mit lcd.h (die bei Dir eh
nicht verwendet wird) und das #asm ... #endasm compiliert das bei mir
fehlerfrei (und zwar so, wie Du es oben gepostet hast, was Dich
allerdings jetzt nicht daran hindern soll, die von mir vorgeschlagenen
Änderungen trotzdem vorzunehmen...)

von Claus (Gast)


Lesenswert?

Alles klar. In Ordnung. Muss halt nun irgendwie lernen von CodeVision
auf die GCC befehle umzusteigen.
Werde die Änderungen mal vornehmen und dann mal testen.
Danke!

von johnny.m (Gast)


Lesenswert?

Ach ja, das mit dem (float) oben brauchste net. Ist ja keine Division
drin, dann gibts auch keine Probleme, wenn das rechts vom "=" in
integer gerechnet wird, da der Wertebereich ja ausreicht (steht ja
"*256" und nicht "/256"...). Wenn Du rechts ne Division drin
hättest, müsstest Du es aber machen, da sonst Müll rauskommt.

Inline Assembler geht in WINAVR mit "asm volatile()". Mehr dazu in
der AVR-libc-Dokumentation.

von Claus (Gast)


Lesenswert?

So ich nochmal:
habs nun die Änderrungen vorgenommen und compiliert...
Build with 0 Errors / 0 Warnings ... klasse.
Sind immer eher so kleinigkeiten an denen sich alles aufhängt.
Bedanke mich auf jedenfall mal für deine Hilfe, meld mich nochmal wenns
noch Probleme gibt. Danke !!

von Claus (Gast)


Angehängte Dateien:

Lesenswert?

Soo ich noch mal...
Nun mal genau gesagt was ich denn machen möchte.
Und zwar habe ich ein Poti an den A/D Eingang angeschlossen, mit dem
ich eine Spannung zwischen 0 und 5 V einstellen kann.
Außerdem habe ich an PortD 3 LEDs angeschlossen, die mir folgende
zustände anzeigen sollen.
LED1 = Poti einstellung : kleiner 1,7 V
LED2 = Poti einstellung : bei ungefähr der Mitte 2,5 V
LED3 = Poti einstellung : größer 3,3 V

Ich bin bei der Programmierung gerade bei der erkennung der
mittelstellung ( 2,5 V ).
Die Variable freq nimmt ja einen Wert von 0 - 1 an.
Also wären die eingestellten 2,5 V dann genau freq = 0.5

Aber irgendwie scheint die Sache so nicht zu funktionieren.
Hast du da noch n Tipp für mich?

(als anhang der aktuelle quellcode)

von johnny.m (Gast)


Lesenswert?

Du wirst mit den Berechnungen nie exakt auf 0,5 kommen, u.a. weil bei 10
Bit ADC-Auflösung das letzte Bit immer ein bisschen wackelt! So genau
kannst Du das Poti gar nicht einstellen. Und da die Abfrage
voraussetzt, dass der Wert tatsächlich exakt 0,5 ist, dürfte das so in
den meisten Fällen nicht klappen.

Abgesehen davon hatte ich oben bereits darauf hingewiesen, dass es
nicht sinnvoll ist, ADCL und ADCH separat auszulesen. Nimm das
16-Bit-Register ADC und Du sparst eine Rechenoperation und eine
Variable. Außerdem brauchst Du Dir keine unnötigen Gedanken zu machen,
was die Reihenfolge des Auslesens angeht. Übrigens gibt die Funktion
read_adc() ja bereits das ADC(W) zurück. Warum schreibst Du nicht
einfach "a = read_adc(1);"?

Und noch was: Fließkommageschichten sind in dem Falle eigentlich
unangebracht. Versuche besser, das ganze in int zu rechnen (einfach den
ursprünglichen ADC-Wert auswerten).

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.