Hallo, ich hätte mal eine Frage: Ich bin echt gerade am verzweifeln: Habe ein Board nach folgenden Vorgaben aufgebaut [http://www.linuxfocus.org/Deutsch/March2002/article231.shtml] und unter Linux versucht das Ding zu programmieren. Ich habe jetzt schon stundenlang versucht den Fehler (ein fehlener Draht oder falsche Pinbelegung??) zu finden, aber kein Erfolg. Die Schaltung und das Kabel sind 100%ig richtig. Deswegen vermute ich den Fehler beim AVR selbst. Ich meine mich zu errinern, dass es bei den Motorola MC68HC11-Controllern einen Pin "E" gab, an dem die Clock anlag und man ganz banal mit einem Multimeter testen konnte ob die MCU überhaupt läuft. (Multimeter zeigt bei laufendem Chip ca 1/2 VCC an) Ich habe leider kein Oszi zur Hand und kann somit auch schlecht mit einem Oszi testen. Das Programm was ich verwende (avrprog) meldet mir halt immer das kein Gerät gefunden wäre und dass die Signature-Bytes alle jeweils ff sind und nicht wie für den verwendeten MC: 0x01 0x92 0x03 Hier ist die Ausgabe von avrprog: Befehl: avrprog -d AT90S4433 -p 0x378 -v -w < avrledtest.hex Chip signature bytes: 0xff 0xff 0xff 0xff Warning: chip autodetection not done due to '-d' option. Chip identification: AT90S4433 - 4096 bytes program; 256 bytes eeprom Writing program memory offset reclen success 0x0000 0x08 -fail- 0x0008 0x08 -fail- 0x0010 0x08 -fail- 0x0018 0x08 -fail- 0x0020 0x08 -fail- 0x0028 0x08 -fail- 0x0030 0x08 -fail- 0x0038 0x08 -fail- 0x0040 0x06 -fail- ERROR: Writing failure. Abschließend zur Info: Ja, ich habe schreib/leserechte für das parport-device (alle Versuche geschahen als root) Habe es auch alternativ noch einmal mit PonyProg versucht, aber dass kann auch keinen angeschlossenen Controller finden. Zusammenfassed: Ich suche eine Methode messtechnisch zu ermitteln ob der Controller überhaupt läuft. Danke für eure Hilfe. Nico
Vorschlag von mir : nimm doch mal den uisp (www.openavr.org) und tipp dann in der Shell : uisp -dprog=dapa Als Ausgabe sollte sowas kommen wie AT90S4433 found. Danach dann beschreiben probieren. Wenn Fehlermeldung : Spannungsversorgung OK ?, Quarz OK?,( Oszilloskop vorhanden nachmessen) Wenn alles nichts fruchtet : Meldung von uisp hier posten.
Okay, danke erst einmal für den Hinweis. Habe es mal ausprobiert, wie du es vorgeschlagen hast. Uisp meldet, dass /dev/parport0 nicht da ist, ooooookay, ist ein Grund. ;-) Ich glaube ich habe fälschlicherweise immer nach /dev/lp0 geschaut, aber das ist ja ein anderes Paar Stiefel. Werde mich ersteinmal darum kümmern, dass das Parport-Device funktioniert. Ausserdem habe ich mal alle Programme deaktiviert, die in irgendeinem Zusammenhang mit dem Paralellport stehen (cups, lpr etc.) Ich melde mich nochmal, sobald ich was neues rausgefunden habe, aber das hat mir jetzt immerhin schonmal gemeldet, dass etwas schon mit dem Paralellport net stimmt. Trotzdem suche ich allgemein mal nach einer Möglichkeit, den Chip OHNE Oszi zu testen. Ein Gedanke von mir war vielleicht die Stromaufnahme, aber ob das aussagekräftig genug ist, um mir zu sagen, das der Quarz auch schwingt? Fragen über fragen, danke für eure Hilfe! Gruß Nico
Bei der Stromaufnahme dürftestDu nichts rausfinden. Hast Du die Module parport_pc und ppdev geladen ?
Hi am Pin2 des AVR (XTAL2) solltest du mit einem hochohmigen Spannungsmessgerät (Digitalmultimeter) etwa Ub/2 messen können. Ist es nicht hochohmig bleibt wahrscheinlich der Oszillator stehen und du mist 0V oder Ub. Matthias
@Dominic: Ja, die Module sind geladen, ich werde es heute abend nochmal in aller Ruhe kontrollieren. Aber trotzdem danke für den Hinweis. @Matthias: Genau das wäre der Hinweis, den ich erwartet hatte, werde auch dies heute Abend noch mal in Ruhe eruieren. Vielen Dank!
Fogender Zwischenstand hat sich ergeben: Die Module sind alle geladen. Ich habe in der Zwischenzeit ein wenig nach dem Problem gegoogelt und herausgefunden, dass man das Problem mit dem Fehlenden parport0-Device so lösen kann: Als root "mknod /dev/parport0 c 99 0" uisp meldet nun folgendes: ------------ Befehl: uisp -dprog=dapa An error has occurred during the AVR initialization. * Target status: Vendor Code = 0xff, Part Family = 0xff, Part Number = 0xff Probably the wiring is incorrect or target might be `damaged'. -------------- Ich fand ausserdem noch heraus, dass unter Debian parport0 = par0 ist, der Befehl uisp -dprog=dapa -dlpt=/dev/par0 brachte mir die gleiche Fehlermeldung wie oben genannt. Nun kann es wohl nur noch am System selber liegen. (Wenn man der Fehlermeldung Glauben schenken darf!) Hat es eigentlich einen Einfluss, wie der Paralellport im BIOS konfiguriert ist? Als EPP, EPC, SPP oder whatever? Naja, es ist jetzt spät, ich mache morgen weiter, vielleicht nochmal die 1/2 Ub- an-XTAL2-Messung durchführen. Gähn Vielleicht hat hier ja noch jemand ne Idee. Gruß Nico
Ergänzung: Gelegentlich bekomme ioctl PPCLAIM: Invalid argument ------- Befehl: uisp -dprog=dapa -dplt=/dev/par0 Failed to claim ppdev. ich bei der Verwendung von /dev/par0 auch das hier: ---------- Also noch was zum Grübeln ;-)
Hi, was für eine Kernel-Version hast Du? ppdev gibts erst ab Kernel 2.4.x <Zitat aus uisp/INSTALL> Parallel port access should still work if you have the Linux ppdev driver (patch for 2.2.17 is in the kernel directory, ppdev is standard in 2.4 kernels). Please lobby Alan Cox to include this tiny little driver in 2.2.x too :) </Zitat> Ähm, das mit Alan Cox ist nur ein Witz :-) Ultimativer Test: Drucker an lpt1: und "echo Testing >/dev/lp0" in der Console eingeben, wenn was rauskommt sollte es gehen. Cya Tom
Hey Tom! Danke für deinen Hinweis. Ich habe einen 2.4.20-k6 Kernel. Die Testidee mit dem Drucker ist mir auch noch gekommen, nur habe ich gerade keinen Drucker zur Hand, den ich mal eben dranklemmen könnte. Meine Frage wäre allerdings: Ist /dev/lp0 nicht ein spezielles Drucker-Device, dass irgendwie über den lpd bearbeitet wird und nur zum Ansprechen von Druckern verwendet wird und parport0 bzw. par0 die eigentliche Schnittstelle? Ich meine damit: Wenn ein Drucker über ein spezielles Druckerdevice funktioniert sagt mir das zwar, ob ich mit der Schnittstelle drucken kann, aber doch noch nicht, ob ich mit uisp direkt auf die Schnittstelle zugreifen kann, oder sehe ich das falsch..? Naja, werd mal noch ein bischen weiterfummeln. Vielleicht ergit sich ja noch was aus den Manpages oder so. Ist halt immer das tolle an Linux, man will nur mal eben was ausprobieren und schon muss man sich damit auseinandersetzen, was das Betriebssystem im innersten zusammenhält. Gruß Nico
Hi Nico, NP. Ich hab noch ne Idee. Mach mal "lsdev", dann solltest Du sehen auf welche I/O-Ports parport0 verweist. Alternativ (Wenn Du "lsdev" nicht hast) kannst Du auch "cat /proc/ioports" verwenden. Sollte so aussehen: ... keyboard 1 0060-006f parport0 0378-037a PCI 0cf8-0cff ... Wenn nicht, dann ZUERST "modprobe parport_pc", dann "modprobe parport". Dann nochmal guggen. btw: parport0 hält Linux nicht zusammen :-) Cya Tom
Hey Tom! Hier das Resultat meine all-abendlichen Bastelei: Bin nach deinem Posting vorgegangen: --------- Ausgabe von cat /proc/ioports ---------- ... 02f8-02ff : serial(set) 0376-0376 : ide1 0378-037a : parport0 037b-037f : parport0 03c0-03df : vga+ 03f6-03f6 : ide0 ... ---------------------------------- Okay, soweit sogut! Aber warum 2 mal parport0? verwundertsei Ich habe immer mehr den Eindruck, dass es mehr ein Hardware-Defekt an meinem AVR-Board ist, ich glaube auf Sofware-Ebene auf meinem Linux-System scheint mir alles im grünen Bereich zu sein. Also doch nochmal testen. Ich melde mich bei Erfolg. Werde diesen ganzen Krempel der hier jetzt schon zum Thema Linux und AVR gepostet wurde wohl mal als FAQ zusammenfassen und ein Mini-Howto für Debian schreiben. Gibt sicher noch andere, die diese oder ähnliche Probleme haben. Greetz Nico
Nachtrag für heute: Eben dachte ich, ich hätte es: Fand beim genauen überprüfen der Platine noch eine Nicht-Verbindung zwischen GND vom AVR und des Parport-Steckers. Aber war leider nicht ausschlaggebend für den weiteren Verlauf. XTAL2 gibt überigens bei Ub=5V ca. 2,4V ab, sollte wohl soweit auch stimmen. An RESET liegen 5V an, somit ist der AVR wohl nicht in einem Dauer-Reset, wie ich anfangs mal vermutete. Also weitersuchen....
Hi, Du hast nur einen parport0, weil 37f - 378 = 8 Byte :-) Von der Linux-Seite aus scheint es ok zu sein. Ich denke das Problem muss woanders liegen. Halt mich bitte auf dem laufenden, wenns geht, würd mich interessieren. Cya Tom
Servus! Ich mach einfach mal kurzen Prozess. Kleiner Ausflug in die Windows-Welt. Werde heute das Board mal bei einem bekannten an den PC hängen und dann testen ob es da programmierbar ist. Der Bekannte hat auch glaube ich ein Osziloskop da, was die Diagnostik wohl ein bischen einfacher gestalten sollte. Vielleicht brutzel ich hier ja auch schon eine Woche lang mit einem defektem Chip rum... Gruß Nico
Servus! Wollte blos bescheid geben, dass sich das Problem von selber gelöst hat: Das Board geht und das erste Testprogramm, dass eine LED am Port D blinken lässt funktioniert! blinkblink Messungen mit Oszi ergaben, dass alles so funktioniert wie es soll. Habe eine Lötstelle nochmal erneuert und TADA, es ging!!!! Trotzdem vielen Dank an alle die mir hier geholfen haben. Ich werde das angesammelte Wissen zum Thema Linux und AVR mal wenn ich Zeit habe zu einem HowTo zusammenschreiben. Viele Grüße und nochmal Danke Nico
>>Die Schaltung und das Kabel >>sind 100%ig richtig. Deswegen vermute ich den Fehler beim AVR selbst. Hmmm, da fällt mir nur eines ein. Sauber arbeiten sollte man schon.
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.