Hallo, ich benutze einen LPT-ISP (nicht hauen) und habe mir das Testboard wie im AVR-Tutorial beschrieben aufgebaut. Mit avrdude (im WinAVR-Paket) kann ich mein Testprogramm ohne Probleme auf den AVR überspielen (siehe http://pastie.org/223486 für sourcecode + avrdude output). Doch nun tut sich einfach nichts am AVR. Ich habe eine LED and Pin B0 angeschlossen (VCC->Widerstand->LED->AVR), die nun blinken sollte. Doch das geschieht nicht, die LED bleibt aus. Gleiches habe ich in einer testweise zusammengebastelten UART-Umgebung (MAX232 etc.) erfahren - keine Fehler beim Kompilieren oder sonstwo, aber das Programm läuft nicht. An der Taktfrequenz liegt es nicht, der angeschlossene Quarzoszi funktioniert (d.h. wenn man ihn während des programmierens abzieht, hagelt es Fehler).... Hat jemand eine Idee? Gruß Jonas
Polung ist ja richtig denke ich mal. Aber man sollte sich vorher mal die delay.h ansehen: >The macro F_CPU is supposed to be defined to a >constant defining the CPU clock frequency (in Hertz). >The maximal possible delay is 262.14 ms / F_CPU in MHz. Bei 16MHz sind das also nur 16ms. Das ist verdammt schnell und du dürftest nur ein glimmen sehen.
nix gegen parallelport-isps ^^ 50% helligkeit der led sieht man auch. das geht also wirklich ned. ich vermute den fehler irgendwo anders. verschiedene massen? kein pullup am reset? usw... das mag zwar für den fall jetzt mit kanonen auf spatzen geschossen sein, aber es lohnt sich doch ein simulationstool - mindestens für später. ich empfehl da immer gern proteus: das tool erlaubt dir, mikrocontroller einzubinden und ein externes .hex-file zu laden. sprich: dein simulierter atmel am pc läuft mit genau dem programm, das du geschrieben hast. dazu natürlich noch der restlichen scherze genug: oszi, dmm, fkt-generatur, usw... http://www.labcenter.co.uk/download/prodemo_download.cfm#professional da gibts ne gratis-demo und JA, ich weiß, das is übertrieben...
Also am reset hab ich ein 10kOhm nach VCC hängen. Und durch das Proteus steig ich überhaupt net durch. Gibts da irgendo ein tutorial für?
Hi Und warum nimmst du nicht den normalen Simulator MfG Spess
Timmo H. wrote: > Bei 16MHz sind das also nur 16ms. Das ist verdammt schnell und du > dürftest nur ein glimmen sehen. Duhu, dann musst du aber auch weiterlesen, gell? Zitat: >Perform a delay of __ms milliseconds, using _delay_loop_2(). > >The macro F_CPU is supposed to be defined to a constant defining the CPU >clock frequency (in Hertz). > >The maximal possible delay is 262.14 ms / F_CPU in MHz. > >When the user request delay which exceed the maximum possible one, >_delay_ms() provides a decreased resolution functionality. In this mode >_delay_ms() will work with a resolution of 1/10 ms, providing delays up to >6.5535 seconds (independent from CPU frequency). The user will not be >informed about decreased resolution.
Kann sein, das der reset ständig auf low/high (µC immer im ResetModus) ist?
ich hätt noch nen ganz genialen fehler: dein file heißt: main.c > "make.exe" program > avrdude -p atmega16 -P lpt1 -c stk200 -U flash:w:led.hex ^^^^^^^^^ kann es sein, dass du das falsche .hex file brennst? =)
[SOOOOOOOOOOOOOOOLVED] das problem war beim LPT-Progger zu suchen: zieht man ihn nach dem brennen vom board ab, funktioniert das programm. Liegt wohl am Reset-Pin. Gruß Jonas
Michael H* wrote:
> nix gegen parallelport-isps ^^
Once again. Der Fehler war der Parallelport-Programmer ;)
kann gar net sein =) ich tipp ja auf ne kalte lötstelle, die kontakt kriegt, wenn man den isp abzieht - ganz ehrlich. natürlich schweißt sich die dann fest und bricht erst beim anstecken wieder - klare angelegenheit =)
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.