avr fuse bits
Simone Winkler
Vor einiger Zeit hab ich meinen AVR geschossen, indem ich seine fuse
bits auf externen takt gesetzt habe (jaaa, ich weiß, das passiert hier
öfter....)
ENDLICH hab ich einen neuen - das hat ca. 1/2 Jahr gedauret, weil
derjenige, dem das Board gehört, den nach fehlgeschlagenen
funktionsgeneratorversuchen nicht einfach ersetzen wollte sondern
zuerst mal versuchen wollte, den wieder per jtag-programmierung zu
aktivieren. als das auch nichts half, gabs dann einen neuen.
so - und den hab ich jetzt: habe zuerst mit dem internen gewerkt, weil
ich riesig großen respekt vor den fuse bits gewonne habe - da hat der
takt aber irgendwie auch nicht gepaßt - eine led, die im sekundentakt
blinken sollte, tat das etwa im 15s-takt (sehr genau ist diese angabe
aber nicht).
naja, und dann hab ich mich doch getraut, den externen quarz
einzustellen per fuse bits. und....ES GEHT NICHT MEHR!! ich hab
wirklich 10000000x mal kontrolliert, ob die bits richtig sind, und
auch 0=programmiert und 1=unprogrmamiert beachtet. ich benutze
ponyprog, und ich hab auf hinweise hin auch vorher ein Read
durchgeführt.
Nach dem schreiben der configuration bits wollte Ponyprog (v.2.06c)
die security bits schreiben - dabei hat es dann den AVR schon gar
nicht mehr gekannt.
Was soll ich nur machen? Ich bin mir echt ziemlich sicher, daß ich
richtig eingestellt habe, bins vorher mit einem kollegen extra
mehrmals durchgegangen. Habe auch slowly rising power eingestellt. Was
kann denn da noch schiefgehen? und v.a. was kann man machen?????
*verzweifel*
Wenn ich jetzt wieder mit dem demolierten AVR ankomme...das möcht ich
mir gar nicht vorstellen.
Device: ATmega128L (3.3V)
Quarz: 8Mhz Crystal
Software: PonyProg V2.06c
Programmer: AVRISP
Ich hoffe, es ist noch irgendwas möglich...
Danke,
Simone
Olaf Kaluza
>naja, und dann hab ich mich doch getraut, den externen quarz
>einzustellen per fuse bits. und....ES GEHT NICHT MEHR!! ich hab
Tja das leben kann so hart sein. :-)
Mir ist mit dem Ponyprog und einem Mega8 genau dasselbe passiert. Das
liegt daran das er die Bits invertiert. DAdurch steht er auf externen
Takt. War aber bei mir kein Proplem ein Taktsignal anzulegen und das
Teil wieder zu benutzen.
Olaf
--
D.i.e.s.S. (K.)
Michael Eggert
wrote:
Hi!
>Mir ist mit dem Ponyprog und einem Mega8 genau dasselbe passiert. Das
>liegt daran das er die Bits invertiert.
Ich seh das Problem eher noch ne Stufe tiefer, nämlich daß schon im
Datenblatt des AVR "gesetzt" = 0 und "nicht gesetzt" = 1 ist. Insofern
würde ich bei Ponyprog nicht von "invertiert" sprechen, sondern eher
davon, ob [X] jetzt als "1" oder als "gesetzt" zu interpretieren ist.
An Simone:
Wenns Dir hilft, kann ich Dir Montag von der Arbeit ein screenshot
mailen, wie ich unter Ponyprog die fuses des Mega8 für externen Quartz
(nur Quartz, nicht Quarztoszillator) setze. Den screenshot hatte ich
nämlich gleich gemacht, nachdem ichs zum laufen gebracht hatte -
sicher ist sicher. :-)
Gruß,
Michael.
Joerg Wunsch
>Mir ist mit dem Ponyprog und einem Mega8 genau dasselbe passiert.
Wobei man sich den ATmega8 damit wirklich schrotten kann, wenn man
sich das /RESET totklemmt. Einen m128 kann man damit allein nicht
wirklich totbekommen.
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ß...
Ich hatte übrigens neulich einen Kollegen mit frisch gekauften (bei
Reichelt) AT90S2343, die sich allesamt nicht programmieren ließen.
Aus irgendwelchen Gründen hat Atmel diese Serie mit abgeschaltetem
RC-Oszillator ausgeliefert (obwohl das Datenblatt diese Möglichkeit
nirgends erwähnt). Externer 1 MHz Takt hat dann geholfen (nachdem wir
schon fast am Aufgeben waren).
--
J"org Wunsch Unix support engineer
joerg_...@interface-systems.de http://www.interface-systems.de/~j/
Joerg Wunsch
>Ich seh das Problem eher noch ne Stufe tiefer, nämlich daß schon im
>Datenblatt des AVR "gesetzt" = 0 und "nicht gesetzt" = 1 ist.
EPROM-Logik halt. Ein gelöschter EPROM besteht aus 1-Bits.
Olaf Kaluza
>Ich seh das Problem eher noch ne Stufe tiefer, nämlich daß schon im
>Datenblatt des AVR "gesetzt" = 0 und "nicht gesetzt" = 1 ist. Insofern
>würde ich bei Ponyprog nicht von "invertiert" sprechen, sondern eher
>davon, ob [X] jetzt als "1" oder als "gesetzt" zu interpretieren ist.
Sagen wir mal so, die Bits die ich mit Ponyprog gebrannt habe sind
genau anders rum als wenn ich sie mit meinem Galep-3 auslese.
Ich bin mir da uebrigens nicht ganz sicher, aber meine das Problem
trat nur auf wenn alle bits 1 oder 0 waren. Wuerde ich aber jetzt
nicht drauf schwoeren.
Olaf
--
D.i.e.s.S. (K.)
Daniel Schramm
> Olaf Kaluza <ol...@criseis.ruhr.de> wrote:
> Ich hatte übrigens neulich einen Kollegen mit frisch gekauften (bei
> Reichelt) AT90S2343, die sich allesamt nicht programmieren ließen.
> Aus irgendwelchen Gründen hat Atmel diese Serie mit abgeschaltetem
> RC-Oszillator ausgeliefert (obwohl das Datenblatt diese Möglichkeit
> nirgends erwähnt). Externer 1 MHz Takt hat dann geholfen (nachdem wir
> schon fast am Aufgeben waren).
Hallo Olaf,
passiert sowas bei Atmel öfters?
Ich habe hier momentan 2 Mega128, die sich ueberhaupt nicht per SPI
programmieren lassen wollen, per JTAG aber einwandfrei. FuseBit fuer SPI
ist aber richtig gesetzt.
Serie: ATMEGA128 16AI 0335
Bye Daniel
--
.~. Daniel Schramm Phone: +49 231 6108112 Mail:daniel....@gmx.de
/V\ Bruehlweg 36 Mobile:+49 178 8839848 ICQ: 35816985
// \\ 44379 Dortmund Fax: +49 231 96989961 WWW: pinguin.sauerland.de
/( )\ Germany
^`~'^
Simone Winkler
> >liegt daran das er die Bits invertiert.
>
> Ich seh das Problem eher noch ne Stufe tiefer, nämlich daß schon im
> Datenblatt des AVR "gesetzt" = 0 und "nicht gesetzt" = 1 ist. Insofern
> würde ich bei Ponyprog nicht von "invertiert" sprechen, sondern eher
> davon, ob [X] jetzt als "1" oder als "gesetzt" zu interpretieren ist.
Das hab ich ja beachtet!!! Denn das letzte Mal hatte ich es nicht
beachtet, und da war er dann auf externen Takt gestellt. Ließ sich
aber leider mit Funktionsgenerator auch nicht mehr retten.
> An Simone:
> Wenns Dir hilft, kann ich Dir Montag von der Arbeit ein screenshot
> mailen, wie ich unter Ponyprog die fuses des Mega8 für externen Quartz
> (nur Quartz, nicht Quarztoszillator) setze. Den screenshot hatte ich
> nämlich gleich gemacht, nachdem ichs zum laufen gebracht hatte -
> sicher ist sicher. :-)
Habe CLKSEL3:0 nicht markiert, SUT1:0 auch nicht (slowly rising
power).
Es steht im progrmamierfenster extra, was markiert und unmarkiert
bedeutet, das hab ich ziemlich sicher richtig gemacht.
Ich bin mittlerweile ins Grübeln gekommen - es könnte sein, daß der
AVR den 8MHz Quarz einfach nicht verträgt.
Die Variante, die ich hier hab, ist ATmega128 18AI, der ist für 3.3V
gar nicht spezifiziert, glaub ich. (ich hab die Hardware nicht
zusammengestellt, bitte nicht schimpfen ;-)). Deshalb könnte es sein,
daß er dne 8Mhz Quarz nicht mag.
Nämlich als ich davor mit der werksseitigen Einstellung von 1Mhz
intern gearbeitet hab, war das auch um ca. faktor 15 daneben (eine led
sollte 1s blinken, tat es aber alle 15s). Vielleicht meint der AVR, er
hat 5V anliegen und der interne Oszillator läuft um diesen Teil
langsamer, da ja die R's und C's für 5V ausgelegt sind?
Und dasselbe gilt ja dann tw. auch für einen externen Quarz - der 8MHz
Quarz kann also vielleicht gar nicht loslaufen.
Was meint ihr?
Kann es vielliecht mit 4Mhz gehen?
Meine jetzige Fuse-Einstellung würde von 3Mhz-8Mhz erlauben. Ich bin
mir ziemlich sicher, daß die Einstellung stimmt.
Vielen Dank,
Simone
Simone Winkler
Es handelt sich um einen ATmega128 16AI 0348 (das steht auf dem Chip).
simone
Stefan Heinzmann
[...]
> Ich bin mittlerweile ins Grübeln gekommen - es könnte sein, daß der
> AVR den 8MHz Quarz einfach nicht verträgt.
> Die Variante, die ich hier hab, ist ATmega128 18AI, der ist für 3.3V
> gar nicht spezifiziert, glaub ich. (ich hab die Hardware nicht
> zusammengestellt, bitte nicht schimpfen ;-)). Deshalb könnte es sein,
> daß er dne 8Mhz Quarz nicht mag.
Das sollte wohl ATmega128-16AI heißen, oder?
Der verträgt nicht den Quarz nicht, sondern die 3.3V. Er will mindestens
4.5V. Mit 4.5V sollte auch der 8MHz Quarz gehen.
Für 3.3V muß es der ATmega128L-8AI sein. Falls Du wirklich mit 3.3V
arbeitest hat der Zusammensteller der Hardware 'nen Rüffel verdient.
> Kann es vielliecht mit 4Mhz gehen?
unwahrscheinlich
--
Cheers
Stefan
Henning Paul
> Device: ATmega128L (3.3V)
> Quarz: 8Mhz Crystal
> Software: PonyProg V2.06c
> Programmer: AVRISP
Also ich hab' mit PonyProg überhaupt keine Probleme, ATmegas zu
programmieren. PonyProg2000 in der neuesten Version für Linux, ATmega128
Datecode 0317, serieller Programmer. Eigentlich nur deshalb PonyProg. Ich
will unter Linux nicht auf dem Parallelport herumpfuschen, außerdem hab'
ich Angst um mein Notebook und denke, daß die serielle da robuster ist. Ist
übrigens eine voll standardkonforme serielle, und der Dongle ("passiv",
Z-Dioden + Rs + 1 BC546) funktioniert sogar an 5m RS232-Verlängerung
problemlos. Schon einiges damit programmiert, AT90S2333, AT90S2313,
AT90S1200 und halt der ATmega128 (auf Lochraster-Adapterplatine). Den
AT90S8515 aus meinem FUMP2 (www.fump.de.vu) hab' ich noch nicht probiert,
das war damals noch mit SP12 unter Win95 auf einem K6.
Mein Notebook ist übrigens ein ASUS L2400D. Schwer, laut, heiß, aber dafür
voll ausgerüstet. So wie ich's mag... ;-)
Gruß
Henning
--
henning paul home: http://www.geocities.com/hennichodernich
PM: henni...@gmx.de , ICQ: 111044613
Colin
Ich hatte mal ein ähnliches Problem mit einem AT90S8535 der mit einem
8 MHz Quarz nicht schwingen wollte, mit 4 allerdings schon. Den konnte
man reanimieren indem man mit eine MultiMeter oder einem Widerstand
einen OSC Pin mit Masse verbunden hat. Ich hab das allerdings nicht
weiter verfolgt, war nicht mein Board :).
Schon mal versucht mit dem Bascom Programer die Fusebits zu setzen?
Dort braucht man sich nicht um '1' oder '0' zu kümmern sondern es
steht textuell dran was gesetzt ist, a lá '8 MHz internal Osc'.
Mfg,
Colin
Ulrich Prinz
Das ist IMHO nicht richtig. Alle ATmegas arbeiten mit 3V..6V. (6V AMR!)
Dabei gilt, dass 3V bis 8MHz und 5V bis 16MHz funktionieren und dies
wird durch selektrion der Bauteile nach der Herstellung festgelegt.
Man kann also einen megaL mit 5V betreiben, hat aber keine Garantie,
dass er oberhalb von 8MHz funktioniert und man kann einen mega (ohne L)
auch mit 3.3V betreiben, wenn man <8MHz bleibt. Da Simone wohl bei 1MHz
herumgeistert ist das alles unkritisch.
Also da keinen kopf machen.
Wie die Klassifizierung bei den LV Typen aussieht ( 1.xV) kann ich nicht
sagen.
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. Bitte
schaltet doch zu den beiden Quarz-Pinnen jeweils einen Kondensator im
bereich 12..22pF nach Masse. Dann sollte das auch alles funktionieren.
Generell ist es unerheblich, ob man den ARV auf externen Takt oder
externen Quarz betreibt, bei externem Takt muss man nur den richtigen
Pin der beiden erwischen.
>> Kann es vielliecht mit 4Mhz gehen?
>
>
> unwahrscheinlich
>
Nein, wahrscheinlich. Wenn der Chip mit niedriger Versorgung betrieben
wird, sind langsamere Frequenzen sinnvoll für einen
Wiederbelebungsversuch. Aber bitte auch hier beachten, dass ein nackter
Quarz nur dann funktioniert, wenn er die zwei kleinen Kondensatoren hat.
Gruß,
Ulrich
Ulrich Prinz
Das ist ein 5V Typ mit 16MHz max. Frequenz. ( Hergestellt KW48 in 2003)
Also entweder mit 3V und <8MHz oder mit 5V bei >8MHz betreiben.
Und zwei Kondensatoren 12.22pF zwischen die Quarzpinne nach Masse
schalten, sonst schwingt er garnicht oder irgendwo, aber nicht bei der
engegeben Frequenz.
Gruß,
Ulrich
Olaf Kaluza
>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.
Von daher wuerde ich mir nicht zuviel sorgen machen.
>Bitte
>schaltet doch zu den beiden Quarz-Pinnen jeweils einen Kondensator im
>bereich 12..22pF nach Masse. Dann sollte das auch alles funktionieren.
Das sehe ich genauso.
Olaf
--
D.i.e.s.S. (K.)
Aguja
>sich das /RESET totklemmt. Einen m128 kann man damit allein nicht
Dafür habe ich einen Adapter gebaut um den AtMega8 parallel zu pro-
grammieren...
>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...
>Reichelt) AT90S2343, die sich allesamt nicht programmieren ließen.
Den setze ich gar nicht mehr ein, zu seltsam sind dessen Verhaltensweisen,
nicht nur was ISP angeht...
cu,
Aguja
::Update:: www.PROuC.de ==> Free AVR-, PIC- & 8051-Programmers, Apps & Tips
Aguja
>Software: PonyProg V2.06c
>Programmer: AVRISP
PonyProg sofort löschen...
>Ich hoffe, es ist noch irgendwas möglich...
JTAG-Programmer versuchen? Wir hatten erst vor kurzem einen Thread darüber.
Michael Eggert
Hi Simone!
> Ich seh das Problem eher noch ne Stufe tiefer, nämlich daß schon im
> Datenblatt des AVR "gesetzt" = 0 und "nicht gesetzt" = 1 ist. Insofern
> würde ich bei Ponyprog nicht von "invertiert" sprechen, sondern eher
> davon, ob [X] jetzt als "1" oder als "gesetzt" zu interpretieren ist.
Und so sieht das aus, wenn ich den Mega8 für 16MHz Quartz unter
Ponyprog programmiere. Dabei ging ich so vor, daß ich die fuses
erstmal _gelesen_
hab, und dann geschaut, was ich gegenüber den defaults _ändern_ will.
[ ] alle Bootlock und Lock
[ ] RSTDISBL
[ ] WDTON
[X] CKOPT
[ ] EESAVE
[X] BOOTSZ1
[X] BOOTSZ0
[ ] BOOTRST
[X] BODLEVEL
[X] BODEN
[X] SUT1
[ ] SUT0
[ ] CKSEL3
[ ] CKSEL2
[ ] CKSEL1
[ ] CKSEL0
Gruß,
Michael.
Henning Paul
>>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?
Henning Paul
> Und so sieht das aus, wenn ich den Mega8 für 16MHz Quartz unter
> Ponyprog programmiere. Dabei ging ich so vor, daß ich die fuses
> erstmal _gelesen_
> hab, und dann geschaut, was ich gegenüber den defaults _ändern_ will.
Das ist auch die einzig sinnvolle Vorgehensweise.
Michael Baeuerle
>
> 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
> 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
Joerg Wunsch
> 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
Henning Paul
> 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.
Jan Reucker
> 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
>
> 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!
Henning Paul
> 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.
Henning Paul
> 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.
Henning Paul
>> 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.
Joerg Wunsch
> 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. ;-)
Henning Paul
>> 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.
Joerg Wunsch
(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.
Michael Baeuerle
>
> 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
Joerg Wunsch
> 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?)
Ulrich Prinz
> Ulrich Prinz <ulr....@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
Ulrich Prinz
> Henning Paul <henni...@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
>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
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
> Joerg Wunsch wrote:
>
>> Henning Paul <henni...@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
> 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?
Joerg Wunsch
> Was bleibt denn jetzt als brauchbarer serieller AVR-Programmer?
Irgendwas, was STK500 Protokoll spricht. ;-)
Leider gibt's davon m. W. keine freien Clones. Da das Atmel AVR ISP
für um die EUR 50 zu haben ist (Segor 54, Reichelt 48), lohnt
wahrscheinlich der Aufwand für das Re-engineeren auch nicht so sehr
wie beim JTAG ICE.
Jan Reucker
> Brrr ... Also so kompliziert ist ein AVR910 doch auch wieder nicht zu
> bauen als dass man so murksen muss, oder?
Er hat als Nachteil allerdings das Henne<-->Ei-Problem. Man
muss einen 2313 programmieren, um den Programmer zu bauen.
Also muss man sich ohnehin erstmal einen no-parts-Programmer
bauen, quasi als "Starthilfe". Und viele bleiben dann wohl
gleich dabei, weil es eben schon funktioniert.