Kein Mensch greift direkt auf die Hardware zu (das ist boese!). Mit RS-232 hat man unter keinem UNIX ein Problem. Fuer IEEE-1284 benutzt man unter Linux die "/dev/parportX" devices fuer die der ppdev Kerneltreiber zustaendig ist (der wiederum parport benutzt).
Micha
--
Liebes GMX-Mitglied,
Ihre aktuelle Mailboxgroesse betraegt jetzt 21841 von 20480 KByte.
[...]
Message vom GMX System nach MS-Wurm overflow
Unter Linux öffnet avrdude /dev/parport und benutzt ioctl() für die Zugriffe. Geht also ohne Schweinkram. Ebenso unter FreeBSD, nur heißt das device da anders.
Die Windows-Variante ist da nicht so zimperlich. Da wird über giveio.sys der Zugriff auf die I/O-Register freigeschaltet.
Serielle no-parts-programmer unterstützt avrdude nicht. Ist aber auch mal 'ne Idee für ein neues Feature ;-)
Serielle Leitungen sollten eigentlich auch über ioctl() gehen. Eine Liste aller ioctls gibt es mit # man ioctl_list
TIOCMxxx sehen ganz vielversprechend aus. Habe aber aus dem Kernelsource (drivers/char/serial.c) noch keine Dokumentation gesehen. Falls Du was rausfindest, würde mich das auch interessieren.
Bleibt trotzdem Pfusch. Hat auch den Nachteil, dass das AFAIK nur "root" machen darf.
tzt
rielle
Was verstehst du unter "Programmer" - Die Hardware oder die Software?
Das mit dem IEEE-1284 ist ja meistens nur deswegen ein Problem, weil die Hardware nicht spezifikationsgemaess arbeitet und irgendwelche Stteuerleitungen zweckentfremdet zur Datenuebertragung missbraucht werden (wie beim STK200/300).
RS-232 Programmer (die Hardware) wie AVR910 oder STK500 arbeiten normalerweise konform und koennen daher unter UNIX schoen und platformunabhaengig per POSIX termios + file I/O angeprochen werden. Natuerlich koennte man da auch die Steuerleitungen vergewaltigen ... aber das waere auch boese!
Micha
--
Liebes GMX-Mitglied,
Ihre aktuelle Mailboxgroesse betraegt jetzt 21841 von 20480 KByte.
[...]
Message vom GMX System nach MS-Wurm overflow
Software, die mit einem no-parts-Dongle funktioniert. :-)
Aber wenn das herumpfuschen an Parport-Steuerleitungen auch böse ist, kommt's darauf doch auch nicht mehr an. ;-) PonyProg benutzt TxD für Reset, DSR/RTS gebrückt für SCK, DTR für MOSI, CTS für MISO. Und ich "brauche" halt die Hotplugfähigkeit der seriellen Schnittstelle.
Gruß Henning
--
henning paul home: http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613
Jo, sieht ganz gut aus, müsste wohl auch mit einem USB-Seriell-Konverter funktionieren. Müsste ich allerdings meine ISP-Header mit Vcc auf Pin 2 versehen, um den Programmer zu versorgen. Und ich habe gerade keinen unverbastelten 2313 im Hause (habe mir gleich die erweiterte Version angeguckt), keinen passenden Quarz. Und um das Programm entsprechend umzuschreiben müsste ich mir noch den AVRASM ziehen, der avr-as braucht ja eine andere Syntax. Nehm ich mir mal vor, wenn ich Zeit und Lust habe.
Gruß Henning
--
henning paul home: http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613
Was ist daran "hotplugfähiger" als an der parallelen?
Beide Schnittstellen kannst Du schrotten, wenn Du an Deinem Target Müll machst. OK, wenn Du bei der seriellen Glück hast, wechselst Du auf Deinem Mainboard ,,nur'' einen GD75232. :-)
Deine Forderung nach `no parts programmer' beißt sich ein wenig mit der nach maximaler Sicherheit. Je mehr Bauteile zwischen Target und Rechner liegen, um so größer wird die Wahrscheinlichkeit, daß diese dazwischenliegenden Bauteile als Sicherung wirken, wenn Dir mal die
+30 V Leitung auf das Target fällt oder sowas. Ein Parallelportprogrammer mit 'nem 74367 ist simpel und wirksam, für mehr Sicherheit halt ein AVR910 (bei dem man aber aufgrund des dummen Protokolls möglichst den UART-FIFO abschalten sollte).
Jörg, der *toi toi toi* bislang seinen Toshiba Libretto noch nicht mit geschrottet hat auf diese Weise. ;-)
--
Jörg Wunsch
"Verwende Perl. Shell will man können, dann aber nicht verwenden."
Kristian Köhntopp, de.comp.os.unix.misc
Eher gruselig. AVR910 ist ein dummes request-response Protokoll, das schon durch UART-FIFOs in der Performance einbricht. Mit einem paketorientierten Netzwerkprotokoll wie USB verträgt sich das ganz schlecht.
--
Jörg Wunsch
"Verwende Perl. Shell will man können, dann aber nicht verwenden."
Kristian Köhntopp, de.comp.os.unix.misc
Eher Zufall. Wenn Du die Portpins für dasselbe bit-banging mißbrauchst, wie das sonst am Parallelport gemacht wird, brauchst Du bei langen Leitungen auch kein besseres Verhalten zu erwarten. (Anders gesagt: dreh' das Parallelport-Bitbanging genauso langsam, und es sollte über ähnlich lange Leitungen gehen. ;-) OK, RS-232 hat leicht höhere Pegel, aber Du benutzt die Pegel ja ohnehin nicht RS-232 konform. IIRC, selbst V.24 war nur auf 5 m garantiert (bei 9600 Bd?) ;-)
--
Jörg Wunsch
"Verwende Perl. Shell will man können, dann aber nicht verwenden."
Kristian Köhntopp, de.comp.os.unix.misc
Ja, mehrfach. Auf einigen Schaltungen wollte der Quarz erst schwingen, wenn sein Gehäuse mit GND verlötet war, auf anderen musste mind. ein Kondensator an einen Pin angeschlossen werden. Daher habe ich die beiden Kondensatoren jetzt immer mit im Design. Damit brauche ich das Gehäuse auch nicht mehr mit GND zu verlöten.
Das mit der Oberwelle ist aber oft auch schon das Problem. Wenn der Quarz am AVR auf seiner 3. Oberwelle schwingt, dann ist die frequenz zu hoch für den AVR und der überschlägt sich dann, oder bekommt nix mehr mit.
Man kann auch einen der Kondensatoren als Drehko auslegen und damit die Frequenz in engem Raum ziehen. Das ist besonders bei Uhren zum Abgleich interessant.
Leztendlich kann man das ganze nur damit umgehen, dass man Q-Oszillatoren einsetzt. Die sind aber teurer, oder als Nicht-SMD recht groß. Ich bevorzuge sie trotzdem.
Oh, welch niederschmetternde Beurteilung. Und dann auch noch daneben gegriffen: Der Ziel-uC kann aufgrund der Flash-Technik nur byte- oder blockweise Daten schreiben. Dazwischen ist immer wieder Pause. Der ganze Transfer ist also in seiner Mindestdauer unveränderlich. Da beim AN910 Programmer schon das letzte bisschen Speed herausgeholt wird, in dem er kontinuierlich die Freigabe für das nächste Byte abpollt, ist da in sachen Speed wirklich nichts mehr zu machen. Wenn AN910 nun ( ich habe mir die Sourcen noch nicht angesehen) schon wärend des Pollens das nächste Byte oder den nächsten Block über die Serielle anfodert, dann ist auch das Optimum in der Übertragung ausgereitzt. Dass der USB diese Daten anstelle mit 115200 auch xmal so schnell übertragen könnte spielt dabei keine Rolle, da die Daten nicht schneller verarbeitet werden können. Ein Auto wird nun mal nicht schneller, wenn ich seinen Tank vergrößere.
Das Einfachste wäre nun, den AN910 Programmer mit einem FTDI FT232BM zu versehen und dann kann man das Teilchen auch direkt am USB betreiben. Fertig. Für Leute die sich das Ding selber löten dürften die 9EUR für den FTDI billiger sein, als 20-50EUR für einen Adapter.
Ach so..das man die beiden Kondensatoren verwendet die der Hersteller schliesslich in jedem Datenblatt mit einzeichnet habe ich einfach mal vorrausgesetzt.
Normal schon. Ich lese aber hier öfter bei dem 'Externen Taktproblem' dass ein Quarz angeklemmt wurde um den AVR wieder programmieren zu können. Wenn der dann nicht anschwingt, kommt es zu den Problemen mit 'geht nicht'.
Das Problem ist, daß beim AVR910 jeweils nur 1-2 (selten auch 3) Bytes aufmal übertragen werden. Damit es weiter geht, muß erst eine Bestätigung zurückkommen.
Man muß damit rechnen, daß sowohl der PC als auch der USB-Seriell-Konverter, das Packet nicht sofort losschicken, da ja so wenig drinsteht.
Selbst wenn man die beiden durch Konfiguration überredet kriegt, hat USB eine Beschränkung bezüglich der Frequenz, mit der Packete gesendet werden dürfen. Wenn ich mich richtig erinnere, war das alle
10ms ein Packet.
Auch bei der seriellen Schnittstelle gibt es große Probleme mit Latenzzeiten, da nach Empfang der Bestätigung nicht sofort ein Interrupt auf dem PC ausgelöst wird. Erst wenn man den Empfangs-FIFO umkonfiguriert, ergeben sich Zeiten in der Nähe des theoretischen Minimums.
BTW: Unter Linux ergeben sich noch weitere Verzögerungen, die sich aber auch wegkonfigurieren lassen.
Wenn es etwas gibt, was schlechter ist als das Protokoll, dann ist es sicherlich die Implementierung von Atmel ;-(
Es gibt eine erweiterte Version für einen AT90S2313, die den Hardware-UART nutzt, gleich als ersten oder zweiten Treffer, wenn man nach "AN910" googelt. Ich weiß ja nicht, wie's damit aussieht.
Was bleibt denn jetzt als brauchbarer serieller AVR-Programmer?
Gruß Henning
--
henning paul home: http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.