Hallo zusammen, habe das Forum schon durchstöpert, aber ich bekomme es nicht hin: Folgendes Problem: Habe mit AVR-Studio folgendes Programm geschrieben: /[code] #include <avr/io.h> // (1) int main (void) { // (2) DDRD = 0xFF; // (3) PORTD = 0xFF; // (4) DDRB = 0xFF; PORTB = 0xFF; DDRC = 0xFF; PORTC = 0xFF; while(1) { // (5a) /* "leere" Schleife*/ // (5b) } // (5c) /* wird nie erreicht */ return 0; // (6) } /[code] Wie kann ich eigentlich die Hex-Datei erzeugen? AVR? Win Avr? Die Hex-Datei möchte ich nun mit PonyProg 2000 übertragen. Habe bei PonyProg Atmega32 und AVR-Micro eingestellt. Des Weiteren habe ich wie folgt die Fusebits gesetzt. Benutze ein 1:1 Kabel am Notebook. Habe das Polinboard und greife über die ISP-Schnittstelle zu. Calibrationtest wird mit ok, angezeigt. Im Portsetup bei Pony habe ich serial-port angewählt mit com1. Bei Probe wird ok angezeigt, aber das Schreiben ist trotzdem fehlerhaft. Warum? Weiß nicht mehr weiter. Gruß
Angehängte Dateien:
-
Fusebits.PNG
35 KB
flocki schrieb: > Wie kann ich eigentlich die Hex-Datei erzeugen? AVR? Win Avr? > Bei Probe wird ok angezeigt, aber das Schreiben ist trotzdem fehlerhaft. Äh, ich bin jetzt etwas verunsichert. Du weißt nicht, wie Du das AVR-Studio dazu bringst, eine .hex Datei zu erstellen und wunderst Dich dann, daß Du genau diese nicht erstellte .hex nicht übertragen kannst? Welche Fehlermeldung bekommst Du denn? 42m
Sollte ja automatisch durch avr-studi geschehen wenn ich compiliere. Leider wird die HEX-Datei nicht upgedatet. Denn das Erstelldatum steht immer noch auf gestern
>Sollte ja automatisch durch avr-studi geschehen wenn ich compiliere. Das HEX-File wird nicht erstellt, wenn compiliert wird, sondern wenn "build" angefordert wird. Das sind zwei unterschiedliche Sachen. Es mag zwar sein, das "gewöhnlich" das bauen als compilieren bezeichnet wird und damit dennoch das bauen gemeint ist, aber da wir nicht wissen, wie erfahren Du bist, kann es sein, das Du da was falsch einschätzt. >Leider wird die HEX-Datei nicht upgedatet. Denn das Erstelldatum steht >immer noch auf gestern Das HEX-File wird nur dann neu erzeugt, wenn sich im Quellcode was geändert hat. Aber ich bin auch irritiert. Erst fragst Du wie das HEX-File erzeugt wird, dann aber weisst Du sogar wo es gespeichert ist, denn sonst könnte Dir das mit dem Datum ja nicht auffallen. Bitte versuche Dein Problem etwas klarer zu beschreiben.
so habe es mit der Hex geschafft, avr hatte mir die in default-Ordner abgelegt. Habe das Programm ohne Fehler übertragen. Jedoch leuchtet keine LED auf
>so habe es mit der Hex geschafft, avr hatte mir die in default-Ordner >abgelegt. Nun, letzteres ist das Standard-Verhalten. Was ist daran so verwunderlich? Und ich möchte Dich nochmal bitten Dich klar und verständlich auszudrücken. Warum erwartest Du, dass da eine LED leuchtet? Soweit ich den Code verstehe, sollte da garkeine LED leuchten.
Ok. tut mir leid wenn es gerade alles ein wenig verwirrend klingt. Sie haben Recht, das die HEX-Datei über Build erstellt wird. Hatte mich da Falsch Ausgedrückt. Arbeite das erstemal mit AVR , Pony Prog. Wie gesagt habe mir eine HEX-Datei mit folgenden Code erstellt: #include <avr/io.h> // (1) int main (void) { // (2) DDRD = 0xFF; // (3) PORTD = 0xFF; // (4) DDRB = 0xFF; PORTB = 0xFF; while(1) { // (5a) /* "leere" Schleife*/ // (5b) } // (5c) /* wird nie erreicht */ return 0; // (6) } Nach Build, wird mir eine Hex-Datei erstellt. Diese öffne ich mit PonyProg2000. Anschließend führe ich write all aus. Dann läuft der Ladebalken bis 100%. Dann erscheint die Meldung. Write OK. Aber man sieht das die LED nicht brennt. Woran könnte das liegen? Wie gesagt hatte das Pollinboard schon mal in Betrieb. Funktioniert also.
Ich setze den PortD als Ausgang, damit stehen 5V am Ausgang an. Auf der Pollinplatine ist eine LED angebracht, die genau am PIN des µC (PortD) liegt. Daher sollte nach meiner Meinung die LED angehen.
Ich werde das jetzt zum letzten Mal schreiben. Drücke Dich (wir Duzen uns hier) klar und verständlich aus. >Aber man sieht das die LED nicht brennt. >Woran könnte das liegen? Es ist immer noch unklar, warum, mit welcher Begründung Du erwartest, das da eine LED leuchtet. Zu dieser Begründung gehört eine Beschreibung des entsprechenden Programmteils in Verbindung mit dem entsprechenden Teil des Schaltplanes.
>Auf der Pollinplatine ist eine LED angebracht, die genau am PIN des µC >(PortD) liegt. Das ist schon mal ein guter Ansatz. Aber die LED hat ja zwei Anschlüsse. Wie ist der andere Anschluss belegt? Nicht nur klar schreiben bitte, sondern auch vollständig.
Der eine Pin der LED ist am µC angeschlossen. Der andere Pin ist über einen Widerstand auf Masse gezogen. Anbei der Link zur Beschreibung des Boards: http://www.pollin.de/shop/downloads/D810038B.PDF
Gut. Du hast einen Schaltplan. Schön. Wenn Du ein Messgerät hast, dann prüfe doch einfach mal nach, ob an dem Portpin 5V, herauskommen und ob an der LED 5V ankommen. Ich sehe im Moment nicht das Problem. Du hast Doch alle Informationen. Warum benutzt Du die nicht?
> Der eine Pin der LED ist am µC angeschlossen. > Der andere Pin ist über einen Widerstand auf Masse gezogen. LED falsch herum?
Guru schrieb: > Das HEX-File wird nicht erstellt, wenn compiliert wird, sondern wenn > "build" angefordert wird. Das sind zwei unterschiedliche Sachen. Es mag Es ist sogar so - zumindest beim AVR-Studio 5 - und ich bin mir fast sicher, daß es beim Studio 4 auch so ist - daß die .hex nicht mal dann erstellt wird, wenn man einen Build macht, zumindest, so lange man nicht in den 'Project Properties | Build' .hex als zu erzeugendes File angekreuzt hat. Das hat mich in den ersten Tagen auch einiges an Nerven gekostet :D 42m
Hallo, nur mal so geraden im Schaltplan sind noch Jumper eingezeichnet, sind die gesetzt ?
mach ma port auf low anstatt auf high (PORTB = 0x00) leds sind bestimmt an Vcc als auf Masse geschaltet.. wird oft gemacht, da der µC mehr Strom ziehen als liefern kann grüße benni
ok sry.. war zu faul alles zu lesen.. hab grad schaltplan gesehen.. sind auf masse ;) aber kann man sich trotzdem merken..
so habe nun mal ein bißchen was gemessen und eine alternative LED mit Vorwiderstand mal als Überprüfung hinzu genommen. Das Problem ist, dass die Platine schon von hinten leichte Korosion aufweist. Habe das mal so gut es geht entfernt. Darüber können Fehler auftreten oder? Das Problem ist, das wenn ich die Ausgänge setze, keine 5V am Pin des µC anstehen. Woran kann das liegen? Kann das durch falsche Fusebit entstehen? Beschreiben kann ich laut Pony noch den µC. Hat jemand eine Übersicht,wie man die Einstellung der Fusebit und die Einstellung für das Beschreiben des µC bein Pony einstellen muss? Möchte erst sicherstellen, das es wirklich nicht an den Einstellungen liegt. Gruß
flocki schrieb: > Kann das durch falsche Fusebit entstehen? > Beschreiben kann ich laut Pony noch den µC. > > Hat jemand eine Übersicht,wie man die Einstellung der Fusebit und die > Einstellung für das Beschreiben des µC bein Pony einstellen muss? Ich verstehe ganz ehrlich nicht, was Du mit den Fuses treibst. Ich bin noch sehr neu im µC-Bereich, aber eines habe ich sehr schnell begriffen: Fuses fasse ich nicht an. Und wenn ich sie anfassen muss, dann lasse ich es bleiben und überlege mir, wie ich es vermeiden kann, sie zu verändern. Sowas kann sehr schnell sehr eklig werden. Ich verwende zwar keinen nackten µC sondern ein Arduino-Board und programmiere den µC per ISP, aber ich vermute mal, daß man auch die nackigen Chips im Auslieferungszustand bzw. in einem Pollin-Board verwenden kann, ohne an den Fuses zu schrauben. Zumal Du irgendwie noch gar nicht erklärt hast, warum Du an die Fuses musst. Oder ich habs nicht begriffen :) 42m
Hallo Michael, erst die Fuse-Bits lassen die volle Funktionalität einen Atmel AVR 'erblühen'. Ich verwende immer den "Engbedded Atmel AVR® Fuse Calculator" http://www.engbedded.com/fusecalc/ Da ich mit avrdude und usbasp oder usbtiny meine AVRs beschreibe, kann ich direkt die Ausgabe unter "AVRDUDE arguments" nutzen. Ich denke eine PonyProg Nutzer hat nicht eine so klare Darstellung der Möglichkeiten die FuseBits zu nutzen und vertut sich da schneller. Ein Blick ins Datenblatt hilft auch eine richtige Einstellung für ein Problem zu finden. Auch schreibe ich auf fast alle AVRs einen seriellen Bootloader von Peda. Der läuft in den oberen 512 Byte des AVRs und selbst in einem kleinen atTiny85 oder atTiny45 ist das machbar ! Dann nutze ich immer die Brown-Out Funktionalität, so kann der AVR richtig resetten und auch das EEPROM ist bereit ! Versuch es mal selbst und mach die schlau !.
Uwe S. schrieb: > Hallo Michael, Hallo Uwe, > erst die Fuse-Bits lassen die volle Funktionalität einen Atmel AVR > 'erblühen'. Das glaube ich gerne, aber ich für meinen Teil bin noch gaaanz weit am Anfang, und von einem Versuch, Debug-Wire per JTAGICE-Clone zu aktivieren (ging im AVR-Studio5 ganz toll, das deaktivieren hat dann aber nur in Studio 4 funktioniert) bin ich erst mal von Fuses-Spielereien kuriert. Um eine LED leuchten oder gar blinken zu lassen sollten Fuses nicht notwendig sein. Und darum gehts dem TO IMHO. Deswegen meine Frage, was er mit den Fuses eigentlich vor hat. Für ein paar Bitmanipulationen in DDR und PORT sollte das eigentlich nicht notwendig sein, oder? Klar werden Fuses irgendwann mal interessant; aber bis ich meinen AVR in seiner Blüte defloriere ... naja, das hat noch n bisschen Zeit, bis ich weiß, wie es geht :D 42m
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.