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ß
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.
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?
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
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
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
Fusebits.PNG
(35 KB)
