avr fuse bits

[Michael Baeuerle]

Henning Paul wrote:

Mal eine ernsthafte Frage: Wie programmiere ich dann über die serielle
Schnittstelle? Ein Open Source-UNIX-Tool, das /dev/ttyS0 nutzt und keinen
Direktzugriff auf die Hardware wagt. Wie ist das eigentlich bei avrdude und
uisp? Nutzen die parport.o oder greifen die direkt zu?

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

 

[Jan-Hinnerk Reichert]

Henning Paul wrote:

Aguja schrieb:

Aber daß Simone nicht aus dem ersten Mißgeschick gelernt hat, daß
man Ponyprog vielleicht doch besser in die Ecke schmeißt und es
wieder damit versuchen muß...

Vielleicht schaffen wir's ja mit kollektiver Überzeugungsarbeit...

Mal eine ernsthafte Frage: Wie programmiere ich dann über die
serielle Schnittstelle? Ein Open Source-UNIX-Tool, das /dev/ttyS0
nutzt und keinen Direktzugriff auf die Hardware wagt. Wie ist das
eigentlich bei avrdude und uisp? Nutzen die parport.o oder greifen
die direkt zu?

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.

/Jan-Hinnerk

PS: email-Adresse ist gültig

 

[Henning Paul]

Michael Baeuerle schrieb:

Kein Mensch greift direkt auf die Hardware zu (das ist boese!).

Gibt genügend Win32-Soft, die das macht.

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).

Ja, aber einen unixoiden Programmer außer PonyProg, der über die serielle
funzt, hab' ich noch nicht gefunden. Und das ist mir halt wichtig.

Gruß
Henning
--
henning paul home: http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613

 

[Joerg Wunsch]

Jan-Hinnerk Reichert <hinni@despammed.com> schrieb:

TIOCMxxx sehen ganz vielversprechend aus.

Ja, das sind die zugehörigen.

Habe aber aus dem Kernelsource (drivers/char/serial.c) noch keine
Dokumentation gesehen. Falls Du was rausfindest, würde mich das auch
interessieren.

Das Include-File sollte als Doku genügen , ggf. noch in Kermit
oder sowas gucken. Hab' gerade mal in einem Linux nachgeguckt:

/usr/include/asm/termios.h:#define TIOCM_DSR 0x100

usw. usf. Beim FreeBSD sind die Bitwerte andere, aber die Namen
dieselben.

Allerdings ist das vermutlich noch ein wenig langsamer als die
parport/ppi Geschichte.
--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
Kristian Köhntopp, de.comp.os.unix.misc

 

[Jan Reucker]

Am Tue, 10 Feb 2004 17:41:32 +0100 schrieb Henning Paul:

Ja, aber einen unixoiden Programmer außer PonyProg, der über die serielle
funzt, hab' ich noch nicht gefunden. Und das ist mir halt wichtig.

Warum nicht einfach ein AN910-Programmer mit uisp? Damit
programmiere ich meine AVRs unter Linux problemlos.

MfG
Jan

--
Jan Reucker
email: jan dot reucker at web dot de
web: http://www.reucker-online.de

 

[Michael Baeuerle]

Henning Paul wrote:

Michael Baeuerle schrieb:

Kein Mensch greift direkt auf die Hardware zu (das ist boese!).

Gibt genügend Win32-Soft, die das macht.

Bleibt trotzdem Pfusch. Hat auch den Nachteil, dass das AFAIK nur "root"
machen darf.

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).

Ja, aber einen unixoiden Programmer außer PonyProg, der über die serielle
funzt, hab' ich noch nicht gefunden. Und das ist mir halt wichtig.

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

 

[Henning Paul]

Jan Reucker schrieb:

Am Tue, 10 Feb 2004 17:41:32 +0100 schrieb Henning Paul:

Ja, aber einen unixoiden Programmer außer PonyProg, der über die serielle
funzt, hab' ich noch nicht gefunden. Und das ist mir halt wichtig.

Warum nicht einfach ein AN910-Programmer mit uisp? Damit
programmiere ich meine AVRs unter Linux problemlos.

Muß ich mir mal angucken. Läuft aber wohl nicht auf no-parts hinaus,
befürchte ich.

Gruß
Henning
--
henning paul home: http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613

 

[Henning Paul]

Michael Baeuerle schrieb:

Was verstehst du unter "Programmer" - Die Hardware oder die Software?

Software, die mit einem no-parts-Dongle funktioniert.

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!

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

 

[Henning Paul]

Henning Paul schrieb:

Warum nicht einfach ein AN910-Programmer mit uisp? Damit
programmiere ich meine AVRs unter Linux problemlos.

Muß ich mir mal angucken. Läuft aber wohl nicht auf no-parts hinaus,
befürchte ich.

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

 

[Henning Paul]

Joerg Wunsch schrieb:

Und ich "brauche" halt die Hotplugfähigkeit der seriellen
Schnittstelle.

Was ist daran "hotplugfähiger" als an der parallelen?

Naja, auf dem Papier soll es ja noch Kurzschlußstrombegrenzung etc geben.

Und der Vorteil: Über 5m RS232-Verlängerung funktioniert noch alles
einwandfrei.

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).

Die AN910 sieht ja ganz ok aus.

Gruß
Henning
--
henning paul home: http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613

 

[Joerg Wunsch]

Henning Paul <henningpaul@gmx.de> schrieb:

Und ich "brauche" halt die Hotplugfähigkeit der seriellen
Schnittstelle.

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

 

[Joerg Wunsch]

Henning Paul <henningpaul@gmx.de> schrieb:

(AVR910 Programmer)

Muß ich mir mal angucken. Läuft aber wohl nicht auf no-parts
hinaus, befürchte ich.

Jo, sieht ganz gut aus, müsste wohl auch mit einem
USB-Seriell-Konverter funktionieren.

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

 

[Michael Baeuerle]

Henning Paul wrote:

Michael Baeuerle schrieb:

Was verstehst du unter "Programmer" - Die Hardware oder die Software?

Software, die mit einem no-parts-Dongle funktioniert.

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!

Aber wenn das herumpfuschen an Parport-Steuerleitungen auch böse ist,
kommt's darauf doch auch nicht mehr an. ;-)

Ack. Aber es geht ja auch anders ...

PonyProg benutzt TxD für Reset,
DSR/RTS gebrückt für SCK, DTR für MOSI, CTS für MISO.

Brrr ... Also so kompliziert ist ein AVR910 doch auch wieder nicht zu
bauen als dass man so murksen muss, oder?

Und ich "brauche" halt die Hotplugfähigkeit der seriellen Schnittstelle.

Die hat ja jede RS-232 Hardware.


Micha
--
Wer sagte das doch noch mal: Er koenne garnicht so viel essen, wie er
kotzen koenne?
Horst-D Winzler in de.sci.electronics

 

[Ulrich Prinz]

Olaf Kaluza wrote:

Ulrich Prinz <ulr.prinz@t-online.de> wrote:

Was mich eher stutzig macht ist, dass hier einfach Quarze an den Chip
geschaltet werden, um einen externen Takt zu schaffen. Das ist nur bei
ausgessuchten Quarzen möglich, da andere leicht auf irgenwelchen
Oberwellen schwingen und nicht auf der angegeben Frequenz.

Hast du das schonmal erlebt? Ich habe in meinem ganzen Leben noch nie
ein Problem damit gehabt einen Quarz an einen Controller zu klemmen.

Die einzige Ausnahme war ein Videotextdecoder wo der Quarz gerade eben
auf der dritten Oberwelle schwingen sollte.

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.

Gruß

Ulrich

 

[Joerg Wunsch]

Henning Paul <henningpaul@gmx.de> schrieb:

Und der Vorteil: Über 5m RS232-Verlängerung funktioniert noch alles
einwandfrei.

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

 

[Ulrich Prinz]

Joerg Wunsch wrote:

Henning Paul <henningpaul@gmx.de> schrieb:

(AVR910 Programmer)


Muß ich mir mal angucken. Läuft aber wohl nicht auf no-parts
hinaus, befürchte ich.


Jo, sieht ganz gut aus, müsste wohl auch mit einem
USB-Seriell-Konverter funktionieren.


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.

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.

Gruß,

Ulrich

 

[Olaf Kaluza]

Ulrich Prinz <ulr.prinz@t-online.de> wrote:

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.

Ach so..das man die beiden Kondensatoren verwendet die der Hersteller
schliesslich in jedem Datenblatt mit einzeichnet habe ich einfach mal
vorrausgesetzt.

Olaf


--
D.i.e.s.S. (K.)

 

[Ulrich Prinz]

Olaf Kaluza wrote:

Ulrich Prinz <ulr.prinz@t-online.de> wrote:

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.

Ach so..das man die beiden Kondensatoren verwendet die der Hersteller
schliesslich in jedem Datenblatt mit einzeichnet habe ich einfach mal
vorrausgesetzt.

Olaf


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'.

Gruß,

Ulrich

 

[Jan-Hinnerk Reichert]

Ulrich Prinz wrote:

Joerg Wunsch wrote:

Henning Paul <henningpaul@gmx.de> schrieb:

Jo, sieht ganz gut aus, müsste wohl auch mit einem
USB-Seriell-Konverter funktionieren.


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.

Oh, welch niederschmetternde Beurteilung. Und dann auch noch daneben
gegriffen:

Glaub' mir: Jörg weiß, wovon er redet...

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.

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.

Wenn es etwas gibt, was schlechter ist als das Protokoll, dann ist es
sicherlich die Implementierung von Atmel ;-(

Viel Spaß beim Lesen
Jan-Hinnerk

 

[Henning Paul]

Jan-Hinnerk Reichert schrieb:

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