Suche Hilfe beim Compilieren von fertigem C-Code

[D. K. (lemur)]

Hallo zusammen,

ich hab mir dieses Akku-Lader Projekt nachgebaut:
http://www.uwe-freese.de/hardware-projekte/akkulader/elektronik.html
Die C-Quellen gibt es hier: 
http://www.uwe-freese.de/hardware-projekte/akkulader/akkuboost2.zip

Leider scheitere ich an der Erstellung einer flashfähigen Hex-Datei für 
den µC.

Die Schaltung ist soweit fertig und läuft. (Den Quellen lag eine fertige 
Hex für einen Mega32 bei.) Allerdings möchte ich im Code 2-3 Sachen auf 
meine Bedürfnisse anpassen, und muss das daher neu übersetzen.

Ich hab bisher nur mit Bascom gearbeitet, war immer sehr zufrieden mit 
meinen Ergebnissen, wollte langfristig aber schon immer mal in C rein 
gucken. D.h. mit AVR-C hab ich bisher noch keinerlei Erfahrungen 
gemacht, daher meine Bitte:


könnte sich das jemand, von Euch mal runterladen und versuchen, bei sich 
ein Hex zu kompilieren, und mir dann sagen, was ich genau dafür brauche? 
(Welche Einstellungen scheinbar angepasst werden müssen)


Folgendes hab ich bereits versucht;
AVR-Studio sagt, falsche *.aws Datei, (urspr. AtmanAVR Projekt),
WinAVR kann nicht compilieren, da kein Makefile beiliegt,
AtmanAvr schreibt die aws um, öffnet auch – bemängelt aber das Fehlen 
der Source „ringpuffer.cpp“.

Der Autor, den ich darauf hin angemailt hatte, meinte,
die ringpuffer.cpp würde nicht benötigt und könnte weggelassen werden, 
leider nimmt AtmanAvr den Code auch nicht, wenn ich die ringpuffer.cpp 
aus der aws – Datei entferne.


Ich wäre euch sehr dankbar, wenn ihr zumindest einen Blick drauf werfen 
könntet, vielleicht hat ja der Ein oder Andere eine Idee, wie man das 
compiliert, oder sagt mir im besten Fall: „Das geht doch ganz einfach, 
Du musst nur xxx machen...“


Viele Grüße

[Karl H. (kbuchegg)]

Die grundsätzliche Vorgehensweise würde ich so ansetzen.

Lade dir von Atmel das AVR-Studio herunter und installiere es.
Meines Wissens ist in der Version 5 der WinAVR-C-Compiler schon 
integriert, wenn nicht: WinAVR downloaden und ebenfalls installieren.


Danach ein neues C-Projekt anlegen.
Zu diesem C-Projekt fügst du alle *.C Dateien hinzu, sowie alle *.H 
Dateien.
Builden und erst mal nachsehen, ob es Fehler gibt. Wenn die Software gut 
geschrieben ist, sollten da keine Fehler auftauchen und du kriegst dein 
Hex-File.

[D. K. (lemur)]

Das hab ich auch schon versucht,

leider kommen da mehr oder weniger schwerwiegende Fehler u. Warnungen;
Ich bin schon seit einigen Tagen damit beschäftigt, habs bisher aber 
noch nicht hinbekommen - daher meine Frage hier.

Ich kanns aber gerne auch nochmals versuchen und hier ggf. ein Fehlerlog 
anhängen, ich glaube nur das es wenig hilft, wenn man den Programmcode 
nicht dazu hat, daher hatte ich das ebenfalls mit meiner Bitte hier 
verlinkt.

[Peter (Gast)]

Schnapp dir doch einfach ein Makefile eines anderen Projekts und pass 
das einfach an deinen Controller und deine zu compilierenden Files an.
Mache ich auch immer so...

Grüße

[D. K. (lemur)]

@ Peter, okay - das werd ich gleich mal direkt versuchen.

[Karl H. (kbuchegg)]

> AVR-Studio sagt, falsche *.aws Datei, (urspr. AtmanAVR Projekt),

Die AWS Datei brauchst du nicht.

> WinAVR kann nicht compilieren, da kein Makefile beiliegt,

AVR-Studio macht sich das selber. Du brauchst nur alle C/H Files 
inkludieren

[D. K. (lemur)]

Erstmal Danke für die Ansätze, leider bin ich immernoch nicht wirklich 
weiter.

Mit dem anderen Makefile, wie auch mit dem neuen Projekt in AVR-Studio 
komm ich nicht weiter. AVR-Studio gibt mir 38 errors and 113 warnings 
zurück, bei denen ich a - nicht wirklich beurteilen kann, welche davon 
irrelevant sind und mir b - nicht vorstellen kann, das der Code nicht 
compilierbar ist.

Ich vermute, das damals (2005-2007), andere Header o. ä. zum compilieren 
genutzt wurden, die in der aktuellen Version abweichen, kann man das 
irgendwie umgehen?

Ich meine, der Code scheint ja vom Autor irgenwann mal mit diesen 
Sourcen erfolgreich compiliert worden zu sein, dass muss sich doch 
irgendwie reproduzieren lassen. Ich hab ja noch garnix geändert, ich 
versuche mit den originalen Sourcen, einfach neu zu compilieren...

Im Anhang mal das AVR-Studio Log und das Atman - Log, welches bedeutend 
weniger Fehler verursacht.

[Karl H. (kbuchegg)]

Das Projekt ist schon etwas älter und sollte eigentlich dringend 
überarbeitet werden. Da sind einige C No No's drinnen sowie Dinge, die 
mit heutigen Compilern anders gelöst werden.

[Karl H. (kbuchegg)]

> AVR-Studio gibt mir 38 errors and 113 warnings zurück,
> bei denen ich a - nicht wirklich beurteilen kann, welche davon
> irrelevant sind und mir b - nicht vorstellen kann, das der Code
> nicht compilierbar ist.

Lass dich nicht von der Zahl verrückt machen. Das ist immer das gleiche 
Problem, welches den Error bzw. die Warning hervorruft.

Ist die Ursache einmal beseitigt, sind mit einem Schlag alle weg.

[Karl H. (kbuchegg)]

Tausche mal die lcd_uf.c / lcd_uf.h gegen die beiliegenden aus.
Das sollte schon mal viele Problemkreise eliminieren, wenn ich mir keine 
Tippfehler eingehandelt habe

(PS: Ich geh auf die Version vom AVR-Studio)

[Karl H. (kbuchegg)]

Dasselbe nochmal mit den uart Funktionen

[Karl H. (kbuchegg)]

Mit den beiden Änderungen sollten fast alle Fehler/Warnungen weg sein.

Was bleibt dann bei dir noch übrig?

[D. K. (lemur)]

Karl Heinz Buchegger schrieb:
> Was bleibt dann bei dir noch übrig?

Tja, mit seiner lcd - Routine gibts immernoch Probleme, im Anhang mal 
das Log, mit deinen 4 geänderten Files, in AVR-Studio.

Vielen Lieben Dank erstmal für deine Mühe - mach Dir nicht zuviel Arbeit 
mit dem Code, ich dachte das könnte man mit zwei,drei fixes vielleicht 
doch zum Laufen bringen, scheint wohl nicht der Fall zu sein...

Ich werde, wenn ich die Muße finde, mich da drann setzen und den Code 
bereinigen und dabei noch c - lernen ;)

Erstmal danke an dieser Stelle, für Eure, insb. deine Karl Heinz, Mühe.

Viele Grüße
Lemur

[Karl H. (kbuchegg)]

Jetzt seh ichs erst.

AKKUBOOST2UTIL.C

Wieso hast du Dateinamen mit einem großen C?

Keine gute Idee!

bennene mal ganz fix alle Dateien *.C um in *.c
(Das ist wichtig, damit der gcc die Dateien nicht als C++ Files wertet! 
Siehe die Warnung:
cc1plus.exe: warning: command line option "-std=gnu99" is valid for 
C/ObjC but not for C++

[Karl H. (kbuchegg)]

Lemur M. schrieb:

> Ich werde, wenn ich die Muße finde, mich da drann setzen und den Code
> bereinigen und dabei noch c - lernen ;)

Damit wirst du ganz sicher kein C lernen.
Das ist so, wie wenn ich als nicht-russisch Sprechender die Sprache 
Russisch durch das Lesen von sibirischen Kurzgeschichten ohne weitere 
Anleitung lernen will - sinnlos.

[Karl H. (kbuchegg)]

Ich hau das ganze Zeugs bei mir mal in ein AVR-Studio Projekt rein. Ich 
hab allerdings nur Studio 4 mit einem etwas älteren WinAVR. Aber so alt 
auch wieder nicht :-)

[D. K. (lemur)]

Das mit dem großen "C", muss wohl beim kopieren entstanden sein ... :/

Die Idee mit dem lernen ging ehr in die Richtung, alten Code verstehen 
(die Logik dahinter erschließt sich mir schon, ist ja auch gut 
kommentiert), neuen Code ergoogeln, für das Projekt anpassen und 
einpflegen - Vorgang wiederholen bis alle Fehler weg sind ;)

Ich weis, gibt elegantere Möglichkeiten sowas "vernünftig zu lernen", 
allerdings hab ich dabei immer so eine Art Projekt - Motivation, zumal 
ich den Hardwarepart ja schon fertig aufgebaut hab, bis auf das Display, 
das ist noch in der Post.

[Paul Baumann (Gast)]

Karl-Heinz schrob:
>Das ist so, wie wenn ich als nicht-russisch Sprechender die Sprache
>Russisch durch das Lesen von sibirischen Kurzgeschichten ohne weitere
>Anleitung lernen will - sinnlos.

Das ist die verkehrte Herangehensweise: Statt Kurzgeschichten empfehle
ich "Lenins Werke" in der Originalausgabe.

;-))

MfG Paul

[Udo S. (urschmitt)]

Lemur M. schrieb:
> Ich weis, gibt elegantere Möglichkeiten sowas "vernünftig zu lernen",
> allerdings hab ich dabei immer so eine Art Projekt - Motivation,
Ein Ziel hilft immens, aber du brauchst die Grundlagen wie Datentypen, 
structs, Zeiger, Stringverarbeitung, die wichtigsten Funktionen, ...
Ohne das wirst du die Programme nicht komplett verstehen.

[Karl H. (kbuchegg)]

Wenn wer mitliest

Kann wer damit

#define CLOCK_MHZ 8 // 8 MHz Clock
#define sleep(X) delay((X), CLOCK_MHZ * 1000)
#define sleepus(X) _delay_loop_2((X) * CLOCK_MHZ / 4);

was anfangen. Ich finde im Projekt keine delay Funktion. Im Moment denke 
ich, dass es sich dabei um eine frühre Version von <util/delay.h> 
handelt. Kann das wer bestätigen?

Wenn ich das durch

#define sleep(X) _delay_ms((X))
#define sleepus(X) _delay_us((X))

austausche, müsste das IMHO gleichwertig sein. Zumindest sieht die 
Verwendung an den paar Stellen die ich mir angesehen habe, ganz danach 
aus.

[Karl H. (kbuchegg)]

OK. Ich bin durch.
Compiliert fehlerfrei mit den Standardeinstellungen.

Anbei das komplette Projekt für AVR-Studio 4

Probier mal aus, ob das HEX-File im Default-Verzeichnis noch läuft, ehe 
du anfängst zu ändern.

Wenn du ein neues Projekt aufsetzen musst. Nicht vergessen: 
Optimierungen auf -Os und die Taktfrequenz (8Mhz) in den Project-Options 
eintragen

[Karl H. (kbuchegg)]

Autsch. Da muss noch mehr gemacht werden. Die ISR 
Kommunikationsvariablen sind alle nicht volatile.


Edit: Der Autor könnte Glück haben. So wie das geschrieben ist, kann der 
Compiler da nicht viel optimieren.

[Karl H. (kbuchegg)]

UPdate

Puh, da hat der Autor aber noch viel Arbeit hinterlassen :-)

Ich belass es jetzt erst mal dabei bis du das bisherige getestet hast.

[Oliver (Gast)]

Karl Heinz Buchegger schrieb:
> Das Projekt ist schon etwas älter und sollte eigentlich dringend
> überarbeitet werden.

Der einfachste Weg sollte doch sein, den passenden alten Compiler zu 
verwenden. Die gibts ja alle noch aud sourceforge.

Oliver

[D. K. (lemur)]

Ich kanns jetzt nicht mehr testen, muss gleich weg, werde ich heute 
Abend aber auf jeden fall machen und hier berichten...

Wenn Du dir schon soviel Mühe wegen mir machst, will ich wenigstens 
"etwas" zurück geben. Ich fand das Eagle-Layout des Autors nicht 
gelungen, bzw. für die Zusatzplatine konnte man da nicht von Layout 
reden, wie dem auch sei, bin sicherlich kein Eagle - Profi aber das was 
ich "produziert hab", häng ich mal heute Abend ebenfalls hier rein.

Wenn dann jemand kommt, und das Projekt nachbauen will, hat er ein 
fertiges Layout zu deinem AVR-Studio Projekt ;)

PS: Weist Du zufällig, wo man in diesem Code die UART Geschwindigkeit 
von urspr. 38400 baud, auf 4800 baud ändert?,

Wäre das evtl in akkuboost2IO.c, Z.107

...
UBRRL = 0x0c;
...

geändert in

...
UBRRL = 0x67;   //0x67 = 103 = 4800 bps ???
...

[Karl H. (kbuchegg)]

Oliver schrieb:
> Karl Heinz Buchegger schrieb:
>> Das Projekt ist schon etwas älter und sollte eigentlich dringend
>> überarbeitet werden.
>
> Der einfachste Weg sollte doch sein, den passenden alten Compiler zu
> verwenden. Die gibts ja alle noch aud sourceforge.

Da sind auch ein paar 'unkoschere' C-Konstrukte dabei.
Die wichtigsten die ich auch Anhieb gesehen habe, hab ich mal 
korrigiert.

[Karl H. (kbuchegg)]

Lemur M. schrieb:

> PS: Weist Du zufällig, wo man in diesem Code die UART Geschwindigkeit
> von urspr. 38400 baud, auf 4800 baud ändert?,
>
> Wäre das evtl in akkuboost2IO.c, Z.107
>

...
> UBRRL = 0x0c;
> ...
>

>

Das ist die Stelle

> geändert in
>

...
> UBRRL = 0x67;   //0x67 = 103 = 4800 bps ???
> ...
>

Aber das macht man nicht so. Wenn der Compiler etwas ausrechnen kann, 
dann lässt man das auch den Compiler ausrechnen. Beim der nächsten 
Änderung (oder bei einer anderen Taktfrequenz) geht sonst die ganze 
händische Rechnerei wieder von vorne los. Das kann der Compiler genauso 
gut erledigen.

So

#define BAUD 9600UL      // Baudrate
 
// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)   // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.
 
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
  #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! 
#endif 


/* UART-Init Bsp. ATmega16 */
 
void uart_init(void)
{
  UBRRH = UBRR_VAL >> 8;
  UBRRL = UBRR_VAL & 0xFF;

  ...

macht man das.

AVR-GCC-Tutorial/Der UART

[D. K. (lemur)]

Joa, danke :) - so ähnlich kenne ich das auch von Bascom her, da wird 
das auch durch den Compiler berechnet...

Danke nochmals - bis später dann.

[D. K. (lemur)]

Karl Heinz, vielen lieben Dank – es läuft.

Hab dein AVR-Studio Code, incl. des Updates problemlos übersetzen 
können, danach geflasht und es scheint alles zu laufen (Display noch 
nicht angeschlossen - UART arbeitet wie vorgesehen)!!!

Nochmals ein großes Dankeschön für deine Mühe.

Anliegend wie bereits erwähnt die Eagle-Routings, der Schaltplan und das 
Board sind noch nicht konsistent, da ich erstmal mein Board fertig haben 
wollte und gewisse Änderungen noch nicht in den Plan übertragen hatte. 
Werde in einigen Tagen / Wochen, je nach Freizeit, den Eagle-Part 
nochmals überarbeiten und dann hier die Endversion zur Verfügung 
stellen; betrachtet es also momentan ehr als Entwurfstadium.

Grüße
Lemur

[Erwin (Gast)]

interessantes projekt,
das werde ich mir mal genauer anschauen,
läd der alle 32 akkus gleichzeitig (weil 32x2a= 64amp!!!) was hast du da 
denn für ein netzteil drann?

[D. K. (lemur)]

@Erwin,

das ist mehr ein Akkulagerplatz, mit Ent-/Ladefunktion, als ein reines 
Ladegerät für 32 Akkus. Die Zellen werden einzeln, nacheinander geladen 
 entladen  etc., entsprechend ihrem ermitteltem Zuststand und dann 
voll gehalten.

Das Projekt ist auf der Seite vom Autor recht umfangreich beschrieben:
http://www.uwe-freese.de  (Links im Menu auf "Akkulader" klicken)

Kann ich nicht direkt verlinken, sonst fehlt das Menu, doofes 
Framelayout :/

Ich verwende im Großen und Ganzen die selbe Schaltung, allerdings hab 
ich die Serielle Schnittstelle durch einen USB-Port (AVRCDC) ersetzt und 
die Relais für die Erweiterungsplatine direkt layoutet.

Grüße Lemur