Forum: Mikrocontroller und Digitale Elektronik Heizungssteuer mit ATMega32 von Busker


von Werner F. (frewer)


Lesenswert?

hallo freaks,

bin dabei das Heizungssteuerungsprogramm von Hr Busker (HeizV2_2) von 
Codevision nach WIN_AVR-GCC zu transferieren, da das Programm für die 
Demoversion von Codevision zu groß ist. Ich habe nämlich Probleme mit 
der Anzeige der Ta, die nicht auf den Sensor reagiert, obwohl ich mit 
einer eigenen Routine den Anschluss und den sensor positiv überprüft 
habe.
Da ich noch ein Newcomer in der C-Programmierung mit WIN_AVR bin, habe 
ich immer wieder Schwierigkeiten die richtigen Definitionen zu finden.

Z.Bsp: im Codevision steht:

eeprom signed int  MaxKesselTemperatur[ANZAHL_KENNLINIEN];

ich transferiere dies nach dem GCC_Tutorial in

uint16_t MaxKesselTemperatur[ANZAHL_KENNLINIEN] EEMEM;

Ich nehme uint16_t, weil in das Array Zahlen, wie 400, -350 geschrieben 
werden und sich bei einer Definition von signed int ... der Compiler 
stets mit einer Warnung meldet (.... truncated...), was ja 
"abgeschnitten" heißt.

Kann mir jemand helfen?

mfG
Werner

von Kesselflicker (Gast)


Lesenswert?

Wo ist der Source der nicht Kompiliert ???

Wie genau laute die Fehlermeldung ?

von R. F. (rfr)


Lesenswert?

hallo,

du portierst

eeprom signed int  MaxKesselTemperatur[ANZAHL_KENNLINIEN];


in

uint16_t MaxKesselTemperatur[ANZAHL_KENNLINIEN] EEMEM;

und erwartest Vorzeichen?

Gruss

Robert

" Kann mir mal jemand einen Lappen rüberreichen?
Ich muss mal meine Glaskugel polieren"

von Werner F. (frewer)


Lesenswert?

hallo,

zunächst vielen Dank für die Antworten. Habe das mit dem Vorzeichen 
verstanden und bin nach dem Tutorial hergegangen und habe statt "uint" - 
"unsigned int" jetzt das "u" weggelassen und was passiert? Jetzt habe 
ich eine ganze Tüte von Warnungen folgender Art, die vorher nicht da 
waren:

../Heizung.c:696: warning: pointer targets in passing argument 1 of 
'eeprom_read_word' differ in signedness

geändert in:
int16_t  MaxKesselTemperatur[ANZAHL_KENNLINIEN] EEMEM ;

#define lcd_int(w, a, p)     Raw_INT(LCD, w, a, p)

// die Fktion RAW
void Raw_INT(char output, signed int wert, signed char anzahl, signed 
char punkt_pos)
{
}


int main(void)
{
.... Befehle
static unsigned char kennlinie = 0;
int16_t myByte;

  lcd_gotoxy(4,0);
  myByte = eeprom_read_word(&MaxKesselTemperatur[kennlinie]);
  lcd_int(myByte/10, 2, 0);
..... Befehle
}

Ob ich zunächst nach myByte lese oder direkt in lcd_int das Lesen 
bewerkstellige, es kommt die gleiche Warnung.

Das Thema mit der Warnung "...... truncated ....." bezog sich auf einen 
Fehler meinerseits. Ich hatte einfach die Codevision Variante mit 
"eeprom signed int xxxxx" übernommen und Zahlen wie 400 versucht zu 
speichern.

Wie definiere ich also den eeprom-Bereich
"int16_t  MaxKesselTemperatur[ANZAHL_KENNLINIEN] EEMEM ;" richtig?

Oh, hätte ich die Hzgssteuerung nur nie angepackt!!!
Ganz abgesehen vom Thema Codevision - WIN_AVR, funktioniert bei irgend 
jemandem das Heizungsprogramm in Bezug auf die Außentemperatur? Bei mir 
ändert sich Ta nicht, auch wenn ich den Sensor verändere oder an den 
PINA 2 ein Poti anbringe. Mach ich das mit einer selbstgestrickten 
Routine, lese ich einwandfreie Werte aus.

Gruß
Werner

von Dietrmar (Gast)


Lesenswert?

> pointer targets in passing argument 1 of 'eeprom_read_word' differ in signedness

Wenn das erste Argument von eeprom_read_word() ein Zeiger auf const 
uint16_t * sein muss, Du aber ein signed int-Array hast, dann musst 
einen Cast vor dem Argument einfügen.

von Werner F. (frewer)


Lesenswert?

danke Dietmar,

dennoch bin ich nicht weiter. Welchen "cast" muss ich denn wohin 
schreiben?
habe mal mit char myByte versucht, gibt aber die gleiche Warnung.

Bei Codevision ist das offenbar ganz einfach. Dort heißt das Pendant:

Definitionsbereich:
....
eeprom signed int  MaxKesselTemperatur[ANZAHL_KENNLINIEN];
....

im Programm:
....
lcd_int( MaxKesselTemperatur[kennlinie]/10, 2, 0);

In Win_AVR ist das alles etwas schwieriger, weil eben zusätzlich zur 
Festlegung "Array in EEPROM" noch die besonderen lese/schreibe - 
Funktionen aufzurufen sind. Dennoch hab ich mich an das Beispiel im 
Tutorial gehalten:

uint8_t myByte;
//...
myByte = eeprom_read_byte(&eeFooByteArray1[1]);

Der Unterschied ist, dass ich wegen der Größe der zahlen mit "word" 
arbeiten muss.

von Denny S. (nightstorm99)


Lesenswert?

> Der Unterschied ist, dass ich wegen der Größe der zahlen mit "word"
> arbeiten muss.

Dann musst du das "Word" zerlegen in High und Low Byte!


Gruß Denny

von Dietmar (Gast)


Lesenswert?

> Welchen "cast" muss ich denn wohin schreiben?

Die Zeile hat der Compiler genannt, ebenso den Ort: als erstes Argument 
erwartet die eeprom_read_word()-Funktion was anderes, als das, was Du 
dort übergibst.

Von welchem Typ das Argument der eerom_read_word-Funktion sein sollte, 
steht in deren Deklaration:

uint16_t eeprom_read_word (const uint16_t *addr);

Da Dein Zeiger nicht von diesem Typ ist, musst Du dem Compiler per Cast 
explizit mitteilen, dass er so tun soll, als ob der Zeiger von diesem 
Typ wäre (was funktioniert, da es iun diesem Fall egal ist, ob signed 
oder unsigned - es ist so oder so ein Zeiger auf 16 bit, die gelesen 
werden sollen).

Bei expliziten Casts schreibt man den gewünschten Typ einfach in 
Klammern vor das Argument, z.B. eeprom_read_word((const uint16_t 
*)argument);

Lies ansosnten mal das hier:
http://de.wikibooks.org/wiki/C%2B%2B-Programmierung:_Typumwandlung

von Stefan W. (wswbln)


Lesenswert?

Werner Freytag schrieb:
>
> ...Oh, hätte ich die Hzgssteuerung nur nie angepackt!!!

Ach was!

Man wächst doch mit seinen Aufgaben und hinterher bist Du
a) froh, dass es läuft und
b) um viele Erfahrungen und Programmierkenntnisse reicher.

von Werner F. (frewer)


Lesenswert?

hallo Dietmar,

vielen Dank für die kleine Unterrichtsstunde. Mit den zeigern, der 
Dereferenzioerung und den cast's stehe ich offensichtlich noch gewaltig 
auf dem Schlauch. Dein Tip funktioniert beim Lesen mit 
eeprom_read_word() komischerweise funktioniert es nicht beim Schreiben 
eeprom_write_word(), obwohl dies laut Tutorial die gleiche 
Argumentstruktur hat. Vielleicht kannst Du mir da auch nochmal helfen, 
damit ich letztlich beide Wege kapiere. Vielen Dank im voraus!

mfG

Werner

von Werner F. (frewer)


Lesenswert?

hallo Dietmar,

zur Ergänzung meiner erneuten Frage hir die Warnmeldung (leider ist mein 
Englisch nicht so gut, dass ich wirklich die Warnung verstehe):

../Heizung.c:1098: warning: passing argument 1 of 'eeprom_write_word' 
discards qualifiers from pointer target type

eeprom_write_word((const uint16_t *)MaxKesselTemperatur[ABWESEND],600);

Danke für die Hilfe

mfG
Werner

von Dietmar (Gast)


Lesenswert?

Bei der Funktion eeprom_write_word() ist das erste Argument vom Typ 
uint16_t * (ohne const) - lass also das "const" im Cast weg. Die 
Compiler-Warnung teilt dir mit, dass der Compiler diese qualifizierende 
Angabe von sich aus ignoriert hat. const fehlt in der 
Funktionsdeklaration, um anzudeuten, dass die Funktion die Daten 
überschreiben wird: Die Daten, auf die der Pointer zeigt, werden 
definitiv nicht konstant bleiben.

> obwohl dies laut Tutorial die gleiche Argumentstruktur hat

Der Compiler liest Includes, nicht Tutorials ;) Der Prototyp der 
Funktion steht in <avr/eeprom.h>:

static inline void _attribute_ ((always_inline)) eeprom_write_word 
(uint16_t *addr,uint16_t value);

von Dietmar (Gast)


Lesenswert?

PS: Bei Casts musst Du vorsichtig sein, da der Compiler dadurch 
gezwungen wird, etwas anderes zu sehen, als er es normalerweise sehen 
würde. Im letzten Beispiel von Dir wird fälschlicherweise aus 
MaxKesselTemperatur[ABWESEND] (also einer Zahl) ein Zeiger gemacht. Da 
fehlt ein "&" vor MaxKesselTemperatur.

von Werner F. (frewer)


Lesenswert?

Hallo Dietmar,

vielen Dank für die Erklärungen. Habe das Gefühl, dass C doch nicht so 
einfach ist, wie ich es mir mal gedacht habe.
Tatsächlich klappt es jetzt. Ich werde mich dann mit dem neuen Wissen 
auf den Weg machen, die anderen Transfer-Probleme zu untersuchen. Habe 
das Gefühl, dass ich überall ähnliche Probleme mit Deklarartionen habe.

Wenn ich nicht mehr weiterkomme, melde ich mich wieder.
nochmals merci

Werner

von Werner F. (frewer)


Lesenswert?

Hallo Stefan,

ebenfalls merci! Habe mir Deine Entwicklung angeschaut. Die ist mir aber 
noch etwas zu "hoch", ich bin noch am Anfang der Technik.
ZZt habe ich eine analoge Hzgssteuerung - TA, bereits etwas "angegraut" 
und für eine Fußbodenhzg wenig flexibel -  und wollte sie durch was 
Neues ersetzen. Hatte mir das auch relativ einfach vorgestellt, aber die 
Software "Busker" macht einfach Stress und ich finde keinen 
Hardwarefehler an der Schaltung. Und meine eigenen Programm-Test's geben 
auch eine korrekte Temperaturanzeige auf meinem Board. Da der Codevision 
ganz schön teuer ist, dachte ich, dass ich mal zu Win_avr übergehe. 
Schade, dass die Compiler sich so sehr unterscheiden, Codevision ist 
offenbar viel einfacher.

Gruß Werner

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.