Hallo Leute, folgendes Problem lässt sich auch nach stundenlangem Googeln nicht lösen: Serielles Bit-Bangig eines ATtiny13 über USB-RS232-Wandler-Kabel (Typ: PL2303) mittels avrdude auf openSUSE-Linux 11.2 ab Kommandozeile mit folgendem Aufruf: avrdude -p t13 -P /dev/ttyUSB0 -c rafaprog -i 10 -U flash:w:/home/rafa/bin init.hex:i liefert folgendes Ergebnis: avrdude: AVR device not responding avrdude: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check. avrdude done. Thank you. Auf dem selben System ist WinXP in einer Sun-Box installiert. Mit dem darauf laufenden AVR-Studio lässt sich die init.hex problemlos auf den ATtiny13 übertragen (Dauer ca 1-2 min). Wodurch klar ist, dass es nicht an der Hardware liegen kann. Der Programmer "rafaprog" ist in der avrdude.conf definiert und sieht so aus: #etwas Kommentar: # 4/DTR -> PB0/MOSI # 8/CTS -> PB1/MISO # 3/TXD -> PB2/SCK # Einen programmierbaren Reset gibt es nicht, der Pin-9 ist nicht belegt und fungiert als Phantomangabe programmer id = "rafaprog"; desc = "design rafa, serial-bitbanging"; type = serbb; reset = 9; sck = 3; mosi = 4; miso = 8; ; Mit diesem "Programmer" lässt sich der ATtiny13 auf einem Laptop über ein rein serielles Bit-Banging (ohne USB) ebenfalls unter Linux 11.2 mit avrdude (gleicher Aufruf wie oben) zumindest zum Signaturcheck überreden. Das Übertragen der init.hex funktioniert da zwar auch nicht, aber das spielt zunächst keine Rolle. Mir geht es hauptsächlich darum, den Signaturcheck auch mit dem USB-Seriell-Adapterkabel auf dem Desktop zu realisieren. Weitere Info: Auf dem Desktop ist auch eine Arduino-IDE installiert. Deren Datenübertragung zum ATmega328p basiert ebenfalls auf avrdude, läuft über USB und funktioniert ebenfalls. D.h. auch eine fehlerbehaftete USB-Treiber-Installation (lsusb) kann ausgeschlossen werden. Ebenfalls habe ich sichergestellt, dass während des Versuches den ATtiny zu kontaktieren, keine andere Anwendung auf den USB0 zugreift. Was ich mich selbst frage ist: Denke ich richtig hinsichtlich der Angabe des seriellen bit-banging-Programmers ? Oder muss der Programmer ganz anders aussehen weil ich ja wegen des USB-Seriell-Umsetzers nicht wirklich auf einen RS232-Port zugreife, sondern auf einen USB-Port. Sollte hier der Hase im Pfeffer liegen, wie müsste dann ein "USB-Seriell-AdapterKompatiblerProgrammer" konfiguriert werden (in avrdude.conf ?) Hat jemand den Hammer zum Knacken dieser für mich zu harten Nuss ? Danke vorab und Grüsse ans Forum, Ralf
Ralf K. schrieb: > Serielles Bit-Bangig eines ATtiny13 über USB-RS232-Wandler-Kabel Das wird nichts. Kauf dir einen USB-Programmer. AVR In System Programmer: USB Beachte, dass einige von den Bausätzen da selbst auch erst einmal programmiert werden müssen. Andreas
Hallo Andreas, Danke für die Antwort. Einen Programmer zu bestellen ist kein Problem. Nur wüsste ich trotzdem gerne, warum es unter Windows funktioniert, unter Linux jedoch nicht. Und vor allen Dingen, warum es über die rein-serielle Kommunikation auf dem Laptop unter sonst gleichen Bedingungen auch mit avrdude funktioniert, über den USB-Konverter jedoch nicht. Dafür muss es eine Erklärung geben. Geht nit.. gibts nit ! Oder bin ich für sowas schon zu konservativ ? Gruss, Ralf
Ralf K. schrieb: > Auf dem selben System ist WinXP in einer Sun-Box installiert. Mit dem > darauf laufenden AVR-Studio lässt sich die init.hex problemlos auf den > ATtiny13 übertragen (Dauer ca 1-2 min). Moment mal: AVR Studio kann aber mit einem Bitbanger absolut nicht umgehen, das kann nur mit Atmel-eigenen Tools arbeiten. Irgendwas ist da faul... Ich würde nicht behaupten, dass Bitbanging mit einem USB-RS-232- Wandler überhaupt nicht gehen kann, aber viel Geduld wirst du dafür mitbringen müssen. Jede Taktflanke braucht 1 ms... Lohnt sich bestenfalls, um vielleicht einen Bootloader initial zu flashen, mit dem man dann später arbeiten will.
Sorry Jörg, es handelt sich um das Lernprogramm von Franzis... LPMikro. Das dürfte aber an das AVR-Studio angelehnt sein.. zumindest glaube ich mich zu erinnern etwas derartiges gelesen zu haben. Wenn es, wie Du sagst, gehen müsste, was muss ich denn dann tun, um es, meinetwegen auch im ms-Takt, zu bewerkstelligen ? (unter den gegeben Voraussetzungen). Der Vorgang mit dem LPMikro ist erwartungsgemäss auch nicht gerade schnell... der Upload der init.hex auf den Tiny13 dauert eher gute 2-3 Minuten, als 1-2. Übrigens: Bald bin ich (hoffentlich) stolzer Besitzer eines AVRISPmkII. Die Bestellung ist schon raus. TROTZDEM würde ich gerne wissen was mit dem avrdude konkret zu tun ist, um die spartanische Lösung zu fahren. Danke, Grüsse, Ralf
> Übrigens: Bald bin ich (hoffentlich) stolzer Besitzer eines AVRISPmkII. > Die Bestellung ist schon raus. Glückwunsch! :-) > TROTZDEM würde ich gerne wissen was mit dem avrdude konkret zu tun ist, > um die spartanische Lösung zu fahren. Zuallerserst /RESET verbinden wie "drüben" im anderen Fred schon angesprochen. Und dann hoffen. Bitbanging über USB-Seriell-Wandler ist grundsätzlich eher Glücksache. Hierzuworkstation (Linux/64) z.B. funktionieren nur manche Wandler (respektive bestimmte Chipsätze) im Bitbanging-Betrieb, andere liefern nur Übertragungsfehler. Jene die funktionieren laufen dafür zuverlässig - aber langsam. Bei anderen Leuten funktionieren jeweils genau 'die anderen' (nicht). HTH
Hallo g457, dann gibt es also an meiner Befehelszeile für den avrdude-Aufruf eigentlich nichts zu korrigieren ? Was Du mit "/RESET" anschließen meinst, war mir schon im alten Thread nicht klar. Freie Pins für Reset habe ich nicht und muss von daher immer zu GND resetten. Die einzigen freien Pins (siehe avrdude.conf-rafaprog) sind alle für den Datenaustausch in Richtung Steuerrechner. Für die andere Richtung ist nichts frei. Oder verstehe ich Dich völlig falsch.. dann bitte nochnmal für maschinenbauende Halbidioten zum Mitschreiben :-) Gruss, Ralf
> Was Du mit "/RESET" anschließen meinst, war mir schon im alten Thread > nicht klar. Den Reset-Pin (PIN 1 am tiny13) verdrahten, und zwar nicht fest auf GND sondern so, dass der avrdude ihn steuern kann. > Freie Pins für Reset habe ich nicht und muss von daher immer > zu GND resetten. Die einzigen freien Pins (siehe avrdude.conf-rafaprog) > sind alle für den Datenaustausch in Richtung Steuerrechner. > # 4/DTR -> PB0/MOSI > # 8/CTS -> PB1/MISO > # 3/TXD -> PB2/SCK Wenn ich das richtig sehe, dann müsste 7/RTS noch frei sein. Das muss dann aber immernoch nicht heissen, dass es mit einem (diesem) USB-Seriell-Wandler tun will. Aber die Chancen an der 'echten' Seriellen steigen. Mit etwas Glück zumindest ;-) HTH
Hi g457, also der 7er ist nicht frei, der geht schaltplantechnisch.... über eine Diode zum Spannungsregler.... mhhh.... Dann ist das also keine Signalleitung, sondern die Spannungsversorgung fürs Brettchen. Wenn ich die abklemme, für den Reset verwende und stattdessen eine externe Spannungsversorgung nehme... Das wird ausprobiert, mehr als schief gehen kann es nicht. Hab ja noch ein Reservebrettchen :-) Zusammenfassung: Die Resetfunktionalität aktivieren wäre also eine Lösung das "schwer vorhersagbare" Verhalten am USB bei Bit-Banging zu verbessern. Und daß es mit der einen Software funktioniert und mit der anderen nicht liegt dann eben auch "ein wenig" an der softwarespezifischen Zugriffsroutine an sich und nicht an der Parametrierung des avrdude-Befehls. Verstehe ich das so richtig ? Dann wäre ich ja eigentlich schon zufrieden :-) Erneut vielen Dank... jetzt gebe ich Ruhe und melde mich wieder wenn es mit dem neuen Programmer Probleme gibt :-) Gruss, Ralf
> also der 7er ist nicht frei, der geht schaltplantechnisch.... über eine > Diode zum Spannungsregler.... mhhh.... > > Dann ist das also keine Signalleitung, sondern die Spannungsversorgung > fürs Brettchen. Falls Du eh die externe Spannungsversorung nimmst, dann kannst Du die vom Brett ganz entfernen. Allerdings - das solltest Du mal austesten, bevor Du zum Lötkolben greifst - ist es denkbar, dass das Programmieren mit der Originalsoftware dann nicht mehr klappt (Hintergrund: auch jener muss in bestimmen Situationen einen 'neuen' Reset auslösen, und da /RESET nicht angeschlossen ist, vielleicht über die Spannungsversorung? Dann wäre ein Entfernen selbiger der Todesstoß. Oder verlässt sich jene Software darauf, dass sowas nienienie erforderlich sein wird?) > Das wird ausprobiert, mehr als schief gehen kann es nicht. Hab ja noch > ein Reservebrettchen :-) Sofern Du mechanisch nichts zerstörst sollte sich das auch zurücklöten lassen. > Zusammenfassung: Die Resetfunktionalität aktivieren wäre also eine > Lösung das "schwer vorhersagbare" Verhalten am USB bei Bit-Banging zu > verbessern. Jain. Oder eher nein, eigentlich nicht. Wahrscheinlich nicht. Aber Gewissheit bringt da nur das Ausprobieren. In Anbetracht des hoffentlich baldigen Eintreffens des neuen Programmieradapters würde ich mir das aber ehrlich gesagt genau überlegen, ob es das wert ist, da nachzuforschen. > Und daß es mit der einen Software funktioniert und mit der anderen nicht > liegt dann eben auch "ein wenig" an der softwarespezifischen > Zugriffsroutine an sich und nicht an der Parametrierung des > avrdude-Befehls. Verstehe ich das so richtig ? Ja, da liegt der Hund begraben. > Erneut vielen Dank... jetzt gebe ich Ruhe und melde mich wieder wenn es > mit dem neuen Programmer Probleme gibt :-) Viel Spaß mit selbigem!
Ralf K. schrieb: > Zusammenfassung: Die Resetfunktionalität aktivieren wäre also eine > Lösung das "schwer vorhersagbare" Verhalten am USB bei Bit-Banging zu > verbessern. Das USB spielt dabei keine Geige (unter der Voraussetzung, dass dein USB-RS-232-Adapter auch wirklich alle Steuerleitungen bedient), das wäre an einer Hardware-RS-232 auch nicht gegangen dann, nur schneller. ;-) Kann schon sein, dass das damit zusammen hängt, dass AVRDUDE aus historischen Gründen nach einem chip erase den ISP-Modus verlassen und neu aktivieren will, dafür muss es die /RESET-Leitung des Prozessors bedienen können. Diese Prozedur ist da drin, weil sie für ganz alte AVRs mal vorgeschrieben war. Wenn dem so ist, müsstest du in der Lage sein, den Chip zu programmieren, indem du dem AVRDUDE mal sagst, dass er ihn nicht vorher löschen soll (Option -D). Die zweite Sache ist, dass AVRDUDE keine Vorkehrungen besitzt, den Ziel-AVR auch noch über die serielle Schnittstelle mit Spannung zu versorgen. Diese Methode ist sowieso reichlich zweifelhaft, da meiner Erinnerung nach nur ein entnehmbarer Strom im Bereich 1 mA bei RS-232 garantiert wird; davon bekommst du kaum einen AVR betrieben. Bei externer Versorgung wiederum musst du sehen, dass die Pegel dann auch passen. Wenn du den AVR mit 5 V versorgst, aber der Adapter nur einen high-Pegel von 3,5 V erzeugt (was für RS-232 zulässig wäre), dann funktioniert das Signalspiel nicht.
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.