Hallo und moin moin, meine erste Berührung mit einem Atmega16 benötigt nun doch ein wenig fachliche Unterstützung und ich hoffe ihr könnt mir ein wenig den Weg weisen... Mein im Aufbau befindliches Projekt ist ein Punktschweißgerät welches mit besagtem AVR läuft (oder auch nicht) ;-) Nachgebaut habe ich dieses Gerät wo ihr auch Schaltplan und Code findet.. http://www.pittnerovi.com/jiri/hobby/electronics/welder/index.html Mein Problem ist, das der Atmega sich je nach Eingangsspannung anders verhält. Bei ca. 4,95V funzt fast alles richtig, Kondensatorspannung lässt sich nach oben und unten einstellen, Schweißzeiten lassen sich einstellen und über den Fussschalter kann der Schweißimpuls ausgeführt werden. Beim betätigen des Fußschalters springt das Display in eine andere Anzeige wo die Schweißenergie angezeigt wird und wieder zurück wenn der Fußschalter losgelassen wird. Was aber keinerlei Funktion hat, ist die Push Funktion des Encoders ! Erhöhe ich die Vcc nun ganz gering auf z.B. 4,99V , ist nun auch eine Funktion vorhanden wenn der Encoder gedrückt wird. Das Display schaltet dann in den Anzeigen hin und her. Leider macht es das nun auch von allein, wenn die Schweißspannung ( VCap ) eingestellt wird. Sowie die Spannung erreicht ist und die Led anzeigt das man nun schwei0en könnte, springt das Display in die Anzeige für Energie und über den Fußschalter kann kein Schweißvorgang mehr ausgelöst werden. Mit Drücken des Encoders komme ich nun zwar in die "normale" Anzeige zurück aber nun ist auf einmal die Soll und Ist Spannung unterschiedlich sodas die LED aus ist und nicht geschweißt werden kann. Stellt man nun die Spannung neu ein das sie wieder gleich sind, springt das Display wieder in die Energieanzeige--- grrrrrr. Schalte ich den Fußschalter passiert nichts solange die V soll und VIst am Cap nicht passt... passt diese dann, startet der Schweißvorgang nun auch ohne das der Fußschalter gedrückt ist. Puh, ganz schön verwirrend.... OK, ich kann die Vcc ein paar mV runterfahren und eigentlich geht dann alles bis auf die Push Funktion des Encoders die ich ehrlich gesagt auch gar nicht ganz verstanden habe. Aber ich würde schon gern verstehen wie durch ein paar mV mehr oder weniger am Eingang eines Atmega so unterschiedliches Verhalten möglich sein kann. Glücklich wäre ich auch, wenn mir jemand sagen könnte was im Code geändert werden muss damit die Schweißzeit länger eingestellt werden kann. Im Moment kann der Vorimpuls lt. Display auf 2 , die Pause auf 15, und der Hauptimpuls auf 15 gestellt werden. Ich gehe mal davon aus das es millisekunden entspricht oder entsprechen soll. Ich würde für Versuche aber gern Schweißzeiten bis 50ms einstellen können was ja wohl im Code angepasst werden müsste, oder ? Wäre toll wenn ihr mir helfen könnt... Jörg
Jörg Gubba schrieb: > Erhöhe ich die Vcc nun ganz gering auf z.B. 4,99V Wie machst Du das? Ist da kein 7805 verbaut? Veränderst Du die Steuerspannung? All das Beschriebene Verhalten liegt bestimmt nicht an der Spannungsversorgung des µc
Moin, zuerst kamen die 5V aus einem Regler von DimensionEngeneering. Da es Schaltregler sind, dachte ich der stört vielleicht irgendwie rein. Daraufhin tauschte ich gegen 7805 und ich konnte schonmal schweißen ohne das die Schaltung dieses Eigenverhalten zeigt. Allerdings fehlt so die Push Funktion vom Encoder komplett. Das ganze ging 15-20 Minuten bis es wieder Anfing wie vorher, das Display schaltete um, die Pushfunktion ging aber schweißen war nicht gezielt möglich weil sich wieder alles instabil verhielt. Die Spannung des ersten Reglers ist ziemlich genau 5V und die vom 7805 ganz leicht darunter. Leichte Erwärmung genügt um die Spannung ganz leicht anzuheben war meine Erklärung und ich nahm ein Labornetzteil um das Verhalten zu simulieren. Hiermit kann ich nun durch geringe Änderung der Vcc stabil einstellen, wie sich die Schaltung verhält. Bis ca. 4,95V kann ich mit arbeiten aber EncoderPush / Displayumschaltung keine Funktion. Ab 4,96V ... dann mit Pushfunktion/Umschaltung aber auch starken Eigenverhalten der Schaltung. Jörg
In einem Schweißgerät hast Du Stöungen auf deinen 5V die ein Vielfaches dieser paar mV betragen. Versuche mal ein paar Pufferkondensatoren in der Schaltung zu verteilen (Elkos und Keramik)
Naja, auf der Schaltung sind doch schon viele Kondensatoren und das Verhalten zeigt sich ja nicht wenn der Entlade/Schweißimpuls ausgelöst wird. Ich habe jetzt aber 2 andere Atmega16 probiert.. mit dem Ergebnis das bei einem keine Änderung auftritt wenn die Spannung leicht angehoben wird, Pushfunktion Encoder reagiert auch nicht sowie VR2 lässt sich nicht justieren. Zeigt im Display 39...V und wenn das Poti justiert wird gehts nur leiocht runter und springt dann auf 0 . Der dritte Atmega Zeigt wieder das Verhalten vom ersten, aber die Entladestufe arbeitet nicht. Ich werd echt irre... Bestelle jetzt am Besten nochmal 2 jungfreuliche Atmegas. Könnte sich bitte jemand den Code ansehen und mir sagen wie ich die Zeiten der CAP Entladung ändern kann damit ich sie länger einstellen kann? Geht jetzt nur bis max. 15ms und ich würde gern bis 50ms einstellen können. Gruss Jörg
Hast du mal an den Werten in dieser Zeile gedreht?
> const uint8_t timemax[3]={200,150,150};
Jörg Gubba schrieb: > nicht. Ich werd echt irre... Bestelle jetzt am Besten nochmal 2 > jungfreuliche Atmegas. Ich denke ehrlich gesagt nicht, dass es an den Megas liegt. Ich kanns nicht beweisen, aber ich würde den Fehler erst mal in der Platine suchen: kalte Lötstellen, ungewollte Kurzschlüsse, etc. Also das volle Programm, was einem beim Aufbau einer Platine so alles passieren kann. > > Könnte sich bitte jemand den Code ansehen und mir sagen wie ich die > Zeiten der CAP Entladung Ich hab mir den Code angesehen .... und entschieden, dass ich mir den nicht antun will.
Ok, dann baue ich zum Vergleich am besten nochmal eine 2te Steuer-Platine, ist ja nicht so sehr viel drauf. @ Krapao Nein, habe an den Werten noch nichts geändert. Kanns ja mal versuchen ob es Einfluss auf die max. Schweißzeiteinstellung hat. Danke @ Karl Heinz Das macht mir Mut wenn sich hier jemand den Code nicht antun möchte ;-) dann muss ich mir ja nicht blöd vorkommen wenn ich als Laie fast nur Bahnhof verstehe. Erstmal Vielen Dank an alle
Dann probiere mal andere Werte. Die Zahlen dienen zur Skalierung der drei Bedienpotentiometer mit denen du die Zeiten einstellst. Ich vermute 150 und Voll aufgedrehter Poti#2 oder #3 entspricht 15ms. Die erste Zahl steht für die Solldauer der ersten Entladung, die zweite Zahl für die Pause zwischen erster und zweiter Entladung und die dritte Zahl für die Solldauer der zweiten Entladung. Wenn du Werte über 255 haben willst, vergiss nicht den Datentyp von uint8_t nach in uint16_t zu ändern. Achtung: Ich kann mir vorstellen, dass eine lange Dauer Schäden anrichten kann. Hauptsächlich durch Überhitzung (Festschweissen etc.). Und du musst beachten, dass die Kondensatoren nicht unendlich Energie liefern können, d.h. lange erste Entladung heisst kürzere oder keine Wirkphase der zweiten Entladung!
Vielen Dank Krapao, werde es am WE mal versuchen, vorher komme ich leider nicht dazu. Bislang habe ich auch nur das Hex mit Ponyprog eingespielt und muss dann erstmal sehen womit das umschreiben und compelieren am besten geht. Ja du hast natürlich Recht, der Kondensator mit zur Zeit 1F ist mit den Zeiten fast am Ende, sprich er wird fast komplett entladen. Die längeren Zeiten möchte ich einmal dafür, das ich die Kapazität auf 2-3F erhöhe. Zudem möchte ich die Schaltung auch gern ganz ohne Entladekondensator testen und anstatt Kondensator Lipo-Zellen verwenden. Ich habe im Lager noch einige 5000er Kokam Eizelzellen und möchte mal 10 Stück parallel mit Kupferschienen verschrauben. 150A Dauer/ 250-300A 2-3 Sekunden sollte genügen um auch 50ms ausreichend Strom zu liefern :-) Die Schweißzeit muss dann halt länger da ich nur mit 3,5-4V arbeite. Ich bin mir aber etwas unsicher ob die Fets das Abschalten mitmachen. Mit Kondensatorentladung müsste beim Abschalten der Strom deutlich geringer sein weil er da schon weit entladen ist. Die Lipos halten ihre Spannung aber und die Fets schalten evtl. zu langsam ab. Nur ne Vermutung...
Jörg Gubba schrieb: > Ich habe im Lager noch einige 5000er Kokam Eizelzellen und möchte mal 10 Stück parallel mit Kupferschienen verschrauben. 150A Dauer/ 250-300A 2-3 Sekunden sollte genügen um auch 50ms ausreichend Strom zu liefern :-) Kurzer Nachtrag hierzu da es vielleicht einige lesen die sich nicht so gut mit hochstromfähigen Akku-Zellen auskennen.... Die Stromangabe bezog sich auf 1 Zelle! Also wäre es bei der geplanten 10 P Verschaltung dann ein Block aus 10 Zellen parallel mit Gesamt 50Ah Kapazität und 1500 A Dauer - 2500-3000A 2-3 sek und geschätzten 4000-5000 A Peakströmen um 50ms . Tip für alle HiFi Highend User... Es gibt wohl kaum stabilere und saubere Versorgungsspannung für Endstufen oder auch Vorverstärker als Akkus. Hierzu dann aber keine Lipos sondern LiIon oder besser FePo4 Zellen..
Moin und schönen Wochenanfang, ich hab nun übers WE versucht den Code zu compelieren.... leider ohne Erfolg. Hab AVR-Studio genommen und vorher WinAVR installiert weil dort ja wohl die im Code angegeben .h Dateien zu finden sind. Geändert habe ich am Code noch garnichts, bekomme aber folgende Fehler beim compelieren. Kapier es echt nicht, der Code wurde ja von dem der ihn geschrieben hat auch ohne solche Fehler compeliert. Warum gibt AVR Studio diese Fehler ? /usr/bin/sh: NUL: Permission denied rm -rf welder.o welder111.elf dep/* welder111.hex welder111.eep welder111.lss welder111.map Build succeeded with 0 Warnings... /usr/bin/sh: NUL: Permission denied avr-gcc -mmcu=atmega16 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=147456UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT welder.o -MF dep/welder.o.d -c ../welder.c ../welder.c:154: warning: return type defaults to 'int' ../welder.c: In function '__vector_18': ../welder.c:252: warning: suggest parentheses around assignment used as truth value ../welder.c: At top level: ../welder.c:278: warning: return type defaults to 'int' ../welder.c: In function 'delay_ms': ../welder.c:316: error: 'XTAL' undeclared (first use in this function) ../welder.c:316: error: (Each undeclared identifier is reported only once ../welder.c:316: error: for each function it appears in.) ../welder.c: In function 'delay_ms10': ../welder.c:321: error: 'XTAL' undeclared (first use in this function) ../welder.c: In function 'delay_ms100': ../welder.c:326: error: 'XTAL' undeclared (first use in this function) ../welder.c: In function 'main': ../welder.c:487: error: 'XTAL' undeclared (first use in this function) ../welder.c: At top level: ../welder.c:609: fatal error: opening dependency file dep/welder.o.d: No such file or directory compilation terminated. make: *** [welder.o] Error 1 Build failed with 7 errors and 3 warnings...
> -DF_CPU=147456UL ^ 1,45.. MHz Sieht mir komisch aus, 14,5... MHz wäre wahrscheinlicher oder? > ../welder.c:316: error: 'XTAL' undeclared (first use in this function) Alte Source, mittlerweile benutzt man da F_CPU und das setzt man in den Projektoptionen innerhalb der IDE (AVR Studio). Kannst du beheben mit: #define XTAL F_CPU Der Rest (die Warnungen) kann man sich in der Source ansehen, wie relevant die sind.
>> -DF_CPU=147456UL > 1,45.. MHz Sieht mir komisch aus, Ähm, korrigiere, 0,145.. MHz sieht mir noch komischer aus...
Ups, bei der Frequenz habe ich in den AVR Studio Einstellungen 2 Nullen unterschlagen. Habe jetzt nochmal daheim mit dem Notebook probiert. Leider komme ich jetzt nur soweit, das mir AVR Studio wenn ich auf Build klicke sagt.... rm -rf welder_neu.o welder_neu.elf dep/* welder_neu.hex welder_neu.eep welder_neu.lss welder_neu.map Build succeeded with 0 Warnings... make: *** No rule to make target `../../../welder_neu.c', needed by `welder_neu.o'. Stop. Build failed with 1 errors and 0 warnings... hab jetzt echt keine Ahnung was ich wieder falsch mache.... Möcht doch aus dem Code nur nen .hex machen..... boah, was fürn Akt
Hoho, hat sich was geändert... in den Options wurde das Ausgabeverzeichniss nicht übernommen. Bin jetzt nach dem Einstellen erstmal auf Projekt speichen und nun kommt folgendes.... Build started 5.12.2011 at 20:43:55 I"C:\Users\Gubbi\Desktop\Firma\Technik\Punktschweißen\dateien\neuhex\wel der_neu\..\..\..\..\..\..\..\..\..\WinAVR-20100110\avr\include" -mmcu=atmega16 -gdwarf-2 -std=gnu99 -Wall -DF_CPU=14745600UL -Os -funsigned-char -funsigned-bitfields - fpack-struct -fshort-enums -MD -MP -MT welder_neu.o -MF dep/welder_neu.o.d -c ../../../welder_neu.c /usr/bin/sh: IC:\Users\Gubbi\Desktop\Firma\Technik\Punktschweißen\dateien\neuhex\weld er_neu\..\..\..\..\..\..\..\..\..\WinAVR-20100110\avr\include: command not found make: [welder_neu.o] Error 127 (ignored) mmcu=atmega16 -Wl,-Map=welder_neu.map welder_neu.o -L"C:\WinAVR-20100110\avr\include\avr" -L"C:\WinAVR-20100110\avr\include" -o welder_neu.elf /usr/bin/sh: -Wl,-Map=welder_neu.map: command not found make: [welder_neu.elf] Error 127 (ignored) avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature welder_neu.elf welder_neu.hex avr-objcopy: 'welder_neu.elf': No such file make: *** [welder_neu.hex] Error 1 Build failed with 1 errors and 0 warnings...
Zieh vielleicht das Projekt in AVR Studio auf und benutze dessen internes Build. Dort kompiliert die Source bei mir (nach den XTAL Änderungen) problemlos.
Besten Dank erstmal, für Heute geb ich auf und geh lieber noch nen Bier trinken ;-) Hab eben in AVR Studio nochmal nen neues Projekt angelegt und noch diesen Fehler >> avr-objcopy: 'welder.elf': No such file Kein Plan was das soll, die Datei soll doch das Studio erstellen und nicht ich, oder. Naja, wenns leicht wär könnts ja jeder.. Hab auch noch nicht verstanden wie du das mit dem #define XTAL F_CPU ändern meinst. Soll ich die Zeile irgendwo in den Code einfügen ? In den Projektoptionen finde ich nichts wo ich die Zeile reinschreiben sollte. Was heißt innerhalb der IDE und wo find ich das in den Projekt Optionen ? gäähn.. bis morgen
> Hab auch noch nicht verstanden wie du das mit dem #define XTAL F_CPU > ändern meinst. Soll ich die Zeile irgendwo in den Code einfügen? Ich habe die Zeile direkt in die Hauptsource nach dem ersten #define geschrieben, also so
1 | #define debug
|
2 | // Neu:
|
3 | #define XTAL F_CPU
|
Krapao schrieb: > Ich habe die Zeile direkt in die Hauptsource nach dem ersten #define > geschrieben, also so > > #define debug > // Neu: > #define XTAL F_CPU Super, danke... Die andere Fehlermeldung liegt wohl daran das WinAVR und das Studio 4.19 etwas eigen in der Zusamnmenarbeit sind. Soweit ich es verstanden habe müsste es mit 4.18 sp3 oder einer AVR Toolchain Installation behoben sein. Werde da mal ein wenig ausprobieren...
So liebe Freunde der Programmierkunst, die letzten Tage habe ich etwas verzeifelt versucht den Code zu compelieren mit folgendem Ergebnis.. AVR-Studio 4.19 bin ich kläglich gescheitert, wahrscheinlich ein Problem mit W7 und WinAVR. Dann mit Eclipse klappte irgendwann schonmal das ein .hex ausgegeben wurde. Allerdings zig Errors und Warnungen die ich nicht wegbekam. Dann mit AVR Studio 5 und es klappte irgentwann die Errors wegzubekommen. Allerdings freute ich mich zu früh und nach dem Flashen zeigte das Display nur einen Balken. AVR gibt zwar beim Compelieren 0 Errors an, aber noch einige Warnungen! Ich geh mal davon aus das es daran liegt aber meine Kenntnisse mit Microprozessoren sind nur die der vergangenen 14 Tage, also gleich null... Was ich bei dem Code auch gar nicht verstehe ist die Header Datei "backward" Wenn ich die entpacke sind dort noch zwei andere drin.."old_sfrdefs.h" und "old_timer.h" . Im Code sind alle Headerdateien in Spitzen Klammern <xxxx> aber die backward.h in Gänsefüßchen "xxxx" Ich habe die 3 Dateien im AVR Studio mit in den Ordner gepackt, weiß aber gar nicht ob die überhaupt benötigt werden oder nur dafür sind falls man die anderen nicht hat oder wozu auch immer. Wäre toll wenn mir das jemand beantworten könnte.... Vielen Dank ------------------------------------------------------------------- Hier einmal die Ausgabe vom Built-Vorgang und die Warnungen > Compiling C: main.c avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=14745600UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./main.lst -std=gnu99 -MMD -MP -MF .dep/main.o.d main.c -o main.o C:\Users\Gubbi\Documents\AVRStudio\welder\welder\Debug\main.c(155,1): return type defaults to 'int' main.c: In function '__vector_18': C:\Users\Gubbi\Documents\AVRStudio\welder\welder\Debug\main.c(254,1): suggest parentheses around assignment used as truth value main.c: At top level: C:\Users\Gubbi\Documents\AVRStudio\welder\welder\Debug\main.c(279,1): return type defaults to 'int' main.c: In function 'init_rotcoder': C:\Users\Gubbi\Documents\AVRStudio\welder\welder\Debug\main.c(299,1): control reaches end of non-void function main.c: In function 'watchdog': C:\Users\Gubbi\Documents\AVRStudio\welder\welder\Debug\main.c(159,1): control reaches end of non-void function Linking: main.elf avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=14745600UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o -std=gnu99 -MMD -MP -MF .dep/main.elf.d main.o --output main.elf -Wl,-Map=main.map,--cref -lm Creating load file for Flash: main.hex avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock main.elf main.hex Creating load file for EEPROM: main.eep avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \ --change-section-lma .eeprom=0 --no-change-warnings -O ihex main.elf main.eep || exit 0 Creating Extended Listing: main.lss avr-objdump -h -S -z main.elf > main.lss Creating Symbol Table: main.sym avr-nm -n main.elf > main.sym Size after: AVR Memory Usage ---------------- Device: atmega16 Program: 2996 bytes (18.3% Full) (.text + .data + .bootloader) Data: 123 bytes (12.0% Full) (.data + .bss + .noinit) -------- end -------- make: Leaving directory `C:/Users/Gubbi/Desktop/Firma/Technik/Punktschwei▀en/dateien' Done executing task "RunAvrGCC". Done building target "CoreBuild" in project "main.avrgccproj". Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != ''). Target "Build" in file "C:\Program Files\Atmel\AVR Studio 5.0\Vs\Avr.common.targets" from project "C:\Users\Gubbi\Documents\AVRStudio\welder\welder\main.avrgccproj" (entry point): Done building target "Build" in project "main.avrgccproj". Done building project "main.avrgccproj". Build succeeded. ========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ========== Und hier die Warnungen > 1 return type defaults to 'int' / Line 155 und 279 2 suggest parentheses around assignment used as truth value / Line 254 3 control reaches end of non-void function / Line 159 und 299
> Allerdings freute ich mich zu früh und nach dem Flashen zeigte das > Display nur einen Balken. Typisches LCD Problem. Hätte mich gewundert, wenn es auf Anhieb funktioniert. Kontrast richtig eingestellt? LCD richtig verkabelt, d.h. Datenblatt und Sourcecode abgeglichen? LCD Controller bzgl. Timing und Commands richtig angesprochen, d.h. Datenblatt und Sourcecode abgeglichen? > 1 return type defaults to 'int' / Line 155 und 279 > 3 control reaches end of non-void function / Line 159 und 299 Diese Warnungen gehören zusammen und haben mit dem LCD Problem oben nix zu tun. Mach die beiden Funktionen void d.h. ohne Rückgabewert >> void watchdog(uint8_t onoff) >> void init_rotcoder(void) > 2 suggest parentheses around assignment used as truth value / Line 254 Diese Warnung hat mit dem LCD Problem oben auch nix zu tun. Mach das um die Warnung weg zu bekommen >> if( (x=bit_is_set(PINB,PB2)) ) ^ ^ > Ich habe die 3 Dateien (aus backward...) im AVR Studio mit in den Ordner > gepackt, weiß aber gar nicht ob die überhaupt benötigt werden oder nur > dafür sind falls man die anderen nicht hat oder wozu auch immer. Die werden benötigt, wenn du die Source an bestimmten nicht umschreiben willst. Die Dateien passen ältere Sourcecodes (d.h. die Dateien stammen aus 2002!) an neuere Toolchains an.
Krapao schrieb: > Typisches LCD Problem. Hätte mich gewundert, wenn es auf Anhieb > funktioniert. > > Kontrast richtig eingestellt? > > LCD richtig verkabelt, d.h. Datenblatt und Sourcecode abgeglichen? > > LCD Controller bzgl. Timing und Commands richtig angesprochen, d.h. > Datenblatt und Sourcecode abgeglichen? Ich habe mit dem Punktschweißgerät ja schon testweise gearbeitet, d.h. das LCD und die Schaltung funktioniert ja grundsätzlich bis auf das Problem mit der Pushfunction des Rotcoders wo ich nichtmal weiß wozu sie sein soll... Hier im Link... http://www.pittnerovi.com/jiri/hobby/electronics/welder/index.html ... ist ja das "fertige" Hexfile zu finden und ich gehe mal stark davon aus das dieses genau aus dem dort gezeigten Code generiert wurde. Brenne ich dieses Hex auf den Atmega funktioniert alles so wie beschrieben. Nehme ich jetzt den dort gezeigten Code und compeliere ihn, müsste ich also auch 1:1 genau das gleiche Hex rausbekommen... So hatte ich es halt anfänglich als totaler Newbie gesehen und verstehe nicht wirklich warum "ER" aus dem Code ein lauffähiges .hex rausbekommt und ich nicht. Habe jetzt im Code folgendes geändert, mit dem Ergebnis das die Warnungen noch genau wie zuvor vorhanden sind. void watchdog(uint8_t onoff) ; ergänzt mit void Zeile 154 void init_rotcoder(void) ; ergänzt mit void Zeile 278 if( (x=bit_is_set(PINB,PB2)) ) ; zwei Klammern hinzugefügt Zeile 253 war das so gemeint? Weil die Warnungen werden ja nicht in diesen Zeilen angezeigt sondern immer eine Zeile tiefer, also 155, 254, 279 und was bedeutet "mach die beiden Funktionen void d.h. ohne Rückgabewert" ? Ich hab jetzt wie gesagt nur das Wort void vor die vorhandenen Zeilen geschrieben. Sorry das ich nicht weiß was das bewirkt und was es mit nem Rückgabewert zu tun hat. Bin wie gesagt erst vor 14 Tagen mit dem Ganzen in Kontakt gekommen...
void http://eshca.net/books/DE/c_von_a_bis_z/005_c_basisdatentypen_018.htm > Nehme ich jetzt den dort gezeigten Code und compeliere ihn, müsste ich > also auch 1:1 genau das gleiche Hex rausbekommen... Das ist höchstunwahrscheinlich. Das klappt nur wenn du die exakt gleiche a) Toolchain und b) Projekteinstellungen und c) Sourcecode verwendest. Aus den Beiträgen oben weiss ich, dass du eine andere Toolchain verwendest und die Punkte b-c sind IMHO auch unsicher. Die Source bei deinem Link muss nicht dem Hexfile bei deinem Link entsprechen. Die häufigsten Probleme beim LCD sind ein falsches Timing (hier kommt die Toolchain ins Spiel) oder falsche Kommandos. Beides ist leider nicht 100%ig mit einfachen Messmitteln zu kontrollieren. An die Timing Sache kann man rangehen, wenn man mit den Routinen aus der Source mal versucht, eine LED exakt anzusteuern oder über RS232 Zeichen in einem exakten Zeitabstand auszugeben (1 Zeichen alle 10s usw.).
Auch im AVR Simulator kann man mit der Stopwatch die Zeitschleifen ausmessen. Weil der AVR Simulator seine Zeit zum Simulieren braucht, braucht man aber etwas Geduld dafür.
Wenn man sich dann etwas besser im Code auskennt, kann man auch das originale Hexfile in den Debugger/Disassembler laden und entsprechend durchsteppen, um Abweichungen zu finden.
> Habe jetzt im Code folgendes geändert, mit dem Ergebnis das die > Warnungen noch genau wie zuvor vorhanden sind. > void watchdog(uint8_t onoff) ; ergänzt mit void Zeile 154 > void init_rotcoder(void) ; ergänzt mit void Zeile 278 > if( (x=bit_is_set(PINB,PB2)) ) ; zwei Klammern hinzugefügt Zeile 253 Bist du sicher, dass du die geänderte Source übersetzt hast? Die Warnungen dürfen nicht mehr vorhanden sein. Die Orginalsource hat leider eine ungünstige C-Formatierung z.B. mit mehreren Anweisungen auf einer Zeile und ich würde nicht zuviel auf die exakte Zeilennummer setzen.
Krapao schrieb: > Bist du sicher, dass du die geänderte Source übersetzt hast? Die > Warnungen dürfen nicht mehr vorhanden sein. Naja, ich hab halt alles probiert was mir so einviel. Änderungen in main.c speichern Clean Solution und dann Built Solution oder Clean Main und Built Main oder nur auf compile (F7) egal was, die Warnungen sind noch da... Wozu ist überhaupt "compile" wenn bei Built das hex erstellt wird ? Da wird es doch auch compeliert, hmmmm etwas ratlos
> Änderungen in main.c speichern Ist main.c auch dein Quellcode im Projekt? Oben war der Dateiname noch peter.c Beim AVR Studio 4: # Compile übersetzt nur die aktuelle Datei im Editor # Build erstellt das Projekt, und kompiliert dazu die nur Dateien, die es nötig haben (Datum der Änderungen) # Rebuild all kompiliert alle Dateien des Projekts unabhängig vom Änderungsstatus. > Clean Solution und dann Built Solution Sagt mir nix, ist anders als in meinem AVR Studio 4.
Mal was ganz anderes: Sind die Fuses richtig eingestellt, z.B. auf externen Quarz? (Bevor man hier in hochwissenschaftliche Diskussionen abdriftet...) Gruß Dietrich
Ja, main.c steht auch im Projekt und die main.c liegt zusammen mit den anderen Dateien in einem Ordner. Ich denke schon das die Fuses richtig gesetzt sind. Ich flashe das Hex mit Ponyprog auf den Atmega und ändere auch nichts an den Fuses wenn ich das neu erstellte hex. aufgespielt habe. Sonst dürfte es mit dem alten hex doch auch nicht laufen denke ich.
So, ich habe jetzt nochmal im AVR Studio ein ganz neues Projekt angelegt und nun führt mir das Studio ein Build aus ohne Errors und Warnungen! Kann das Hexfile leider erst morgen testen ob es läuft. Im Code habe ich jetzt der Reihe nach folgendes geändert. > direkt unter #define debug Zeile #define XTAL F_CPU eingefügt > void watchdog(uint8_t onoff) ; ergänzt mit void > void init_rotcoder(void) ; ergänzt mit void > if( (x=bit_is_set(PINB,PB2)) ) ; zwei Klammern hinzugefügt > while(ms--) delay_xs(XTAL/4/1000); XTAL durch F_CPU ersetzt > while(ms--) delay_xs(XTAL/4/10000); XTAL durch F_CPU ersetzt > while(ms--) delay_xs(XTAL/4/100000);XTAL durch F_CPU ersetzt Interessieren würde mich auf jedenfall noch warum die backward.h nun nicht wie die anderen Headerdateien in spitzen Klammern steht.. bin halt neugierig Da bin ich ja dann mal gespannt ob es läuft, mehr dazu morgen, vielen Dank an und schönen Restsonntag
>>> #include <hüh> vs. #include "hott" http://eshca.net/books/DE/c_von_a_bis_z/010_c_praeprozessor_001.htm#mjf374f026d04c7badd6109bab24ff1114
Super, danke für die Erklärung und den Link. Hatte dort auch schonmal versucht es rauszufinden aber einfach falsch gesucht. Als Anfänger einer solch Komplexen Geschichte echt nicht ganz leicht, man muss auch erstmal lernen wie und wonach man richtig sucht. Eine Headerdatei stdlib.h ist zB. mit "nützliche Funktionen" beschrieben. Das hat meine Vorstellung wozu die Dateien gut sind jetzt erstmal etwas durcheinander gebracht. Nützliche Funktionen können doch hunderte und völlig verschieden sein. Jetzt wird der Inhalt, also Code dieser Datei an die Stelle in meinem Code eingefügt wo das #include steht. Also wird dann auch alles abgearbeitet was in so einer Datei drinsteht und das übersteigt dann wieder mein Verständnis. Verstehen würde ich, wenn aus diesen Header Dateien "Teile" im eingenen Code Verwendung finden die man sozusagen anhaken kann die man auch benötigt. Wahrscheinlich habe ich da etwas Grundsätzliches noch nicht verstanden :-) Ich hoffe mein jetzt 14 jähriger Sohn kann mir in 2 -3 Jahren auch ein wenig helfen. Er interessiert sich für das Thema und ich möchte ihm zu Weihnachten unter anderem Arduino Equipment zusammenstellen. Ich hoffe damit macht man nichts verkehrt und Leds bis Sensoren von unseren UAV`s Schwebeplattformen liegen auch noch genug rum womit er dann etwas spielen kann. Vielleicht bleibt er ja dabei und findet darin sein Ding...
Jörg Gubba schrieb: > Jetzt wird der Inhalt, also Code dieser Datei an die Stelle in meinem > Code eingefügt wo das #include steht. Also wird dann auch alles > abgearbeitet was in so einer Datei drinsteht und das übersteigt dann > wieder mein Verständnis. Verstehen würde ich, wenn aus diesen Header > Dateien "Teile" im eingenen Code Verwendung finden die man sozusagen > anhaken kann die man auch benötigt. Wahrscheinlich habe ich da etwas > Grundsätzliches noch nicht verstanden :-) Soweit ich das verstehe: Das #include ist eine Anweisung an den Präprozessor. Dadurch wird der Inhalt der angegebenen Datei so eingebunden, als stünde er direkt im Code. Beim weiteren Buildvorgang kommt nun aber nicht wild alles ins Kompilat, was im Quelltext steht sondern nur das, was auch tatsächlich gebraucht wird, was Du also durch einen entsprechenden Aufruf "angehakt" hast. 42m
Michael Krauth schrieb: > Beim weiteren Buildvorgang kommt nun aber nicht wild alles ins Kompilat, > was im Quelltext steht sondern nur das, was auch tatsächlich gebraucht > wird, was Du also durch einen entsprechenden Aufruf "angehakt" hast. Ja, so würde es m.E. Sinn machen. Nur erkenne ich noch nicht welche Anweisungen sozusagen die "Haken" sind die dann sagen... nimm dies oder das aus dem Inhalt der xxx.h Datei. Hoffe ich hab mich nicht zu blöd ausgedrückt. Ich habe jetzt übrigens das neu erstellte hex. getestet. Leider läuft es auch nicht, obwohl mir das AVR Studio 0 Errors und 0 Warnungen zeigt. Wenn ich das hex. was läuft mit dem neuen vergleiche, sehe ich das es insgesamt ein paar Zeilen weniger sind und auch in manchen Registern andere Werte stehen. Nur wie komme ich weiter ? Wenn keine Fehler mehr angezeigt werden, sollte es doch eigentlich laufen, oder ? Verstehe auch nicht warum in der Source éiniges von Atmega8 steht obwohl es doch für einen Atmega 16 sein soll? Das fertige hex. was Jiri Pittner auf seiner Seite angibt, gibt es für Atmega16 und Atmega32. Warum aber steht im Source immer was von Atmega8 ? Kann ich vielleicht etwas erreichen, wenn ich im Makefile die verschiedenen Optimierungsgrade durchprobiere? Weiß jetzt echt nicht mehr weiter. Die Definition vom LCD habe ich auch mit dem Schaltplan kontrolliert und es passt damit überein.
Hi >Wenn keine Fehler mehr >angezeigt werden, sollte es doch eigentlich laufen, oder ? Nein. Im übertragenen Sinn heißt das nur, das Rechtschreibung und Grammatik richtig sind. Aber nicht, das sie Sätze einen Sinn ergeben. MfG Spess
Krapao schrieb: > Nimmst du die Sache mit den LCD Timings noch in Angriff? Gern, wenn ich wüsste wie ;-) Ich habe den ganzen Tag nochmal rumprobiert und habe mir jetzt außerdem noch mit Netbeans und Programmers Notepad Hex File erstellt. Zumindest unterscheiden sie sich um ein paar KB und werde sie morgen nochmal testen. Werden hier die LCD Timings eingestellt ? Da sieht man übrigens schön was ich in einem vorrigen Post meinte das oft atmega8 dort steht. Was heist denn MCU == atmega8 , und warum nicht atmega16 ? #if (MCU == atmega8 ) sbi(DDRD,PD4); DDRC=0x3f; #else DDRC=0xff; #endif delay_xs(20000); lcd_w4bit(0,3); delay_xs(10000); lcd_w4bit(0,3); delay_xs(500); lcd_w4bit(0,3); lcd_w4bit(0,2);
Ok, habe heute nachdem keins der erstellten Hex läuft mit Jiri Pittner telefoniert. Er war sehr hilfsbereit und spricht au0erdem sehr gut Deutsch da er einige Jahre an der Humbolt Uni in Berlin gelehrt hatte. Ich habe ihm jetzt die unter Windows und AVR Studio geänderte Source geschickt und er testet mal ob er ein lauffähiges Hex rausbekommt. Er arbeitet halt nicht mit Windows und kompeliert unter Linux direkt mit gcc wenn ich das richtig verstanden habe. Warum da dann was anderes rauskommen kann habe ich halt immer noch nicht ganz verstanden weil der gcc doch auch im Studio oder in WinAVR enthalten ist. oder sehe ich das wieder zu einfach. ??? Naja, mal sehen ob da was rauskommt. Würd mir natürlich auch nur bedingt weiter helfen, wenn er es compeliert und mir dann ein Hex schickt was läuft. Möchte ja selbst verschiedene Werte ändern und testen können, naja schaun wir mal was passiert. Heute wurden erst mal die Kupferschienen fertig gestellt womit die Ableiter der Lipozellen und auch die FETs verschraubt werden. 70 qmm Kabel sind nun auch schon vorhanden. Ich überlege ernsthaft ob ich da noch irgendwie ne Absicherung reinbringen muss. Bei der Kondensatorentladung kann ja nicht so viel passieren da die Kondensatoren im Erstfall wenn was abraucht einfach sofort entladen sind. Bei Einsatz von Lipos anstatt Kondensator siehts ein wenig anders aus als Stromlieferant :-) Andererseits kann wohl auch nicht mehr passieren als das die Fets bzw. die Source Leitungen sich atomisieren und einem Kurzschluss ein Ende setzen...
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.