AVR Dragon
Frank Buss
dem ich gleich hoffentlich den Microcontroller auf meinem Board wieder zum
Leben erwecke. Anleitung war nicht dabei, Kabel auch keins. Anleitung gibt
es zumindest Online. Also erstmal AVR Studio installiert und dann mal die
Pinbelegung angeschaut:
und versucht, den VTG-Pin mit Spannung zu beaufschlagen und im AVR Studio
ein Voltage Read durchzuführen. Klappte natürlich nicht. Was haben die
Anleitungsschreiber sich nur dabei gedacht, die schematische Zeichnung des
ISP-Headers 180° gedreht zum abgebildeten Foto zu zeichnen? Kann man nur
irgendwie raten, daß MISO der Pin 1 ist, weil rechteckig, und daher auf dem
Foto nicht links oben, sondern rechts unten ist und Pin 2 dann VTG ist, wo
man die Referenzspannung anlegen soll. Ist aber vielleicht auch für
Vollbluteletroniker selbstverständlich und mein gemeckere nicht
gerechtfertigt. Mal sehen wie es weitergeht.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Joerg Wunsch
> Was haben die Anleitungsschreiber sich nur dabei gedacht, die
> schematische Zeichnung des ISP-Headers 180° gedreht zum abgebildeten
> Foto zu zeichnen? Kann man nur irgendwie raten, daß MISO der Pin 1
> ist, weil rechteckig, und daher auf dem Foto nicht links oben,
> sondern rechts unten ist und Pin 2 dann VTG ist, wo man die
> Referenzspannung anlegen soll.
Vielleicht hättest du dir dafür die Anleitung sparen können und
einfach den Dragon angeguckt. Pin 1 ist deutlich gekennzeichnet, und
die ganzen Standard-Pinouts sind auf der Unterseite aufgedruckt. ;-)
Wofür man die Anleitung dann einzig braucht (dafür geht's aber
wirklich nicht mehr "nach Nase") ist HV-Programmierung. Da habe ich
dann aber eigentlich noch nie Sorgen gehabt, dass die Anleitung in
dieser Hinsicht missverständlich wäre.
Das Einzige, worüber ich mich dabei ärgere ist, dass der ganze Mift
nur zusammen mit AVR Studio erhältlich ist und daher zwingend noch
Geld für Billyboy fällig wird (für die Windows-Lizenz), obwohl man
eigentlich nur die Anleitung haben will und das ganze AVR Studio gar
nicht braucht. Aber das dürfte vermutlich dein Problem nicht sein.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Frank Buss
> Vielleicht hättest du dir dafür die Anleitung sparen können und
> einfach den Dragon angeguckt. Pin 1 ist deutlich gekennzeichnet, und
> die ganzen Standard-Pinouts sind auf der Unterseite aufgedruckt. ;-)
Stimmt, jetzt wo du es sagst :-) Ist aber dennoch blöd, wenn man es oben
einsteckt und dann erstmal schön brav die Anleitung liest und nicht so
genau auf die Platine schaut.
> Das Einzige, worüber ich mich dabei ärgere ist, dass der ganze Mift
> nur zusammen mit AVR Studio erhältlich ist und daher zwingend noch
> Geld für Billyboy fällig wird (für die Windows-Lizenz), obwohl man
> eigentlich nur die Anleitung haben will und das ganze AVR Studio gar
> nicht braucht. Aber das dürfte vermutlich dein Problem nicht sein.
Eine Google-Suche liefert einiges für AVR Dragon und Linux, sollte also
nicht nötig sein. Ich muß aber sagen, daß mir Programmer-Interface gut
gefällt. Man kann die Fuse-Bits, Chip Kennung usw. einzeln auslesen und
HEX-Files programmieren, vergleichen usw., also alles was man so braucht,
wenn mal was schief gegangen ist.
Ich glaube bei mir waren die Fuse Bits das Problem: Da war die HWBE Fuse
eingeschaltet. Ich vermute mal, daß der Bootlader beim ersten Booten, wo
ich das letztens über USB geflasht hatte, noch den Bootloader gestartet
hatte, weil noch nie was geflasht wurde. Als dann einmal ein Programm
geflasht war, startete dann der Bootloader dieses direkt. Nachdem ich dann
BOOTRST eingeschaltet hatte (die Fuse-Bits umstellen ging allerdings erst
nach einem Erase Flash und Neuaufspielen des Bootloaders), startete nach
einem Reset wieder der Bootloader und ich kann wieder problemlos per USB
mein Programm starten und neu flashen, ganz ohne AVR Dragon.
Joerg Wunsch
> Eine Google-Suche liefert einiges für AVR Dragon und Linux, sollte
> also nicht nötig sein.
Das Problem ist nicht die Software, sondern die Dokumentation. Die
gibt's nur als Bestandteil von AVR Studio. Wenn man HV programmieren
will, braucht man sie aber schon, das kann man nicht mehr einfach
erraten.
Dass du "Linux" implizierst, berührt dann schon gleich die nächste
Marotte, unter der alle möglichen Hersteller leiden: kein Windows zu
benutzen bedeutet automatisch, dass man Linux-Nutzer wäre...
Frank Buss
> Das Problem ist nicht die Software, sondern die Dokumentation. Die
> gibt's nur als Bestandteil von AVR Studio. Wenn man HV programmieren
> will, braucht man sie aber schon, das kann man nicht mehr einfach
> erraten.
Müsste das nicht alles im Datenblatt dokumentiert sein?
> Dass du "Linux" implizierst, berührt dann schon gleich die nächste
> Marotte, unter der alle möglichen Hersteller leiden: kein Windows zu
> benutzen bedeutet automatisch, dass man Linux-Nutzer wäre...
BSD ist ja auch nur eine Art Linux :-)
Falk Willberg
> Joerg Wunsch wrote:
>> Dass du "Linux" implizierst, berührt dann schon gleich die nächste
>> Marotte, unter der alle möglichen Hersteller leiden: kein Windows zu
>> benutzen bedeutet automatisch, dass man Linux-Nutzer wäre...
Kenne ich eher so: Kein Windows? Dann muß es ein MAC sein.
Oder man hat gar keinen Computer. Aber dann ist man auch Linux- oder
MacOs-User.
> BSD ist ja auch nur eine Art Linux :-)
In der guten alten Zeit wurde man schon für weniger gevierteilt :-)
Schließlich ist ein BMW nicht "auch nur eine Art Mercedes"...
Falk
P.S.: Noch'n Linux:
http://www.mikrocontroller.net/articles/PHILIPS_VP5500_VoIP_Telefon
Joerg Wunsch
>Müsste das nicht alles im Datenblatt dokumentiert sein?
Im was? ;-)
Das beste, was du als "Datenblatt" dafür halt bekommst, ist die
.chm-Datei, die bei AVR Studio dabei ist.
Allerdings sehe ich gerade, dass sie diese Teile wenigstens
mittlerweile mal online auf einem Webserver verteilen:
http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon.htm
OK, damit hat sich meine Kritik zumindest dahingehend erübrigt,
dass es mittlerweile wenigstens /einen/ Weg außerhalb von AVR
Studio gibt.
Hergen Lehmann
> Das Problem ist nicht die Software, sondern die Dokumentation. Die
> gibt's nur als Bestandteil von AVR Studio. Wenn man HV programmieren
> will, braucht man sie aber schon, das kann man nicht mehr einfach
> erraten.
AVR Studio läuft auch unter WINE. Nicht vollständig bis in die letzten
Winkel, aber zumindest bis zur Doku kommt man problemlos.
Hergen
Joerg Wunsch
> AVR Studio läuft auch unter WINE.
War zumindest früher ein Krampf, es bis dahin zu bekommen, ob der
massiven Abhängigkeiten von diversen Explodierern und andererer
Ungetüme. Hab's seither nicht wieder probiert.
<nitpick>Hilft auch nicht bei Architekturen jenseits i386 oder amd64.
Von einer Dokumentation erwarte ich, dass sie komplett system- und
maschinenunabhängig ist. PDF wurde bereits vor geraumer Zeit dafür
erfunden und funktioniert für den Zweck brauchbar.</nitpick>
Aber s. o., mit dem Online-Angebot der Doku hat sich mein Gejammer
bezüglich der Doku erledigt, bleibt noch das bezüglich der
Firmwareupgrades.
Frank Buss
> Kenne ich eher so: Kein Windows? Dann muß es ein MAC sein.
>
> Oder man hat gar keinen Computer. Aber dann ist man auch Linux- oder
> MacOs-User.
Mac ist ja auch größtenteil BSD, kann man also nicht falsch liegen :-)
> P.S.: Noch'n Linux:
> http://www.mikrocontroller.net/articles/PHILIPS_VP5500_VoIP_Telefon
Sieht nett aus, scheint aber nicht mehr hergestellt zu werden? Für
Bastelprojekte aber nicht schlecht.
Frank Buss
> Frank Buss <f...@frank-buss.de> wrote:
>
>>Müsste das nicht alles im Datenblatt dokumentiert sein?
>
> Im was? ;-)
>
> Das beste, was du als "Datenblatt" dafür halt bekommst, ist die
> .chm-Datei, die bei AVR Studio dabei ist.
Stimmt, scheint einiges nicht dokumentiert zu sein. Z.B. das DebugWIRE
Interface, zumindest laut dieser Webseite:
http://www.mikrocontroller.net/articles/DebugWIRE
Verstehe ich nicht, warum Atmel das als Firmengeheimnis betrachtet.
Habe übrigens eben gedacht, jetzt den Microcontroller endgültig verloren zu
haben: Hatte das DebugWIRE-Interface eingeschaltet und konnte danach dann
weder über USB, noch über die SPI-Schnittstelle mehr auf den Chip
zugreifen. Bis ich dann im Internet darauf gestoßen bin, daß man den
DebugWIRE-Modus irgendwo tief im Debug/Options Menü wieder ausschalten
kann, allerdings nur temporär. Aufrufen konnte man die Option allerdings
erst, wenn man eine Debug-Session gestartet hat, was ich durch Neuanlegen
eines Projektes und Laden einer HEX-Datei im AVR Studio geschafft habe. SPI
lief dann wieder, sodaß ich dann die Fuses wieder permanent umstellen
konnte.
Zum Glück habe ich noch nicht von Quarz auf externen Clock umgeschaltet, da
ich dann wohl um einige Lötaktionen nicht drumherumgekommen wäre, um einen
externen Signalgenerator dann als Herzschrittmacher zu verwenden.
Ich kenne ja einige Microcontroller, aber Atmel macht es einem wirklich
leicht, sich ins Knie zu schießen :-)
Joerg Wunsch
> Bis ich dann im Internet darauf gesto�en bin, da� man den
> DebugWIRE-Modus irgendwo tief im Debug/Options Men� wieder ausschalten
> kann, allerdings nur tempor�r.
Das Problem dabei ist, dass AVR Studio alles sch�n GUI-m��ig "wir
machen das schon f�r Sie" verstecken m�chte. Soll ja alles im
normalen Ablauf "ganz von allein" gehen, aber wehe, du verl�sst mal
den vorgedachten Trampelpfad...
Ich hatte damals auch eine Weile gebraucht, bis ich verstanden habe,
wie die internen Abl�ufe bei debugWIRE sind, sodass ich dann alles ins
AVRDUDE implementieren konnte. Da sie den /RESET-Pin f�r die
debugWIRE-Kommunikation umdefinieren, existiert danach nat�rlich keine
M�glichkeit mehr, einen externen Reset auszul�sen. Damit funktioniert
auch ISP nicht mehr, denn bei ISP wirkt der Reset-Pin ja als eine Art
SPI-Chipselect (zusammen mit einer an MOSI zu schreibenden Signatur).
Andererseits ist debugWIRE eigentlich weiter nichts als eine Art
Monitorprogramm, das in der CPU selbst abl�uft. Dadurch kommt es nur
an die Ressourcen heran, an die man auch vom Programm aus gelangen
k�nnte. Fusebits geh�ren (aus gutem Grund) /nicht/ zu diesem Kreis,
dadurch kann debugWIRE sich nicht selbst wieder abschalten. Um nun
den Knoten aufzul�sen, gibt es daher ein debugWIRE-Kommando, mit dem
man den debugWIRE-Modus tempor�r wieder verlassen kann (bis zum
n�chsten Power-On-Reset), um auf diese Weise das /RESET-Pin wieder
seiner gewohnten Funktionalit�t zuzuf�hren. Auf diese Weise kann man
danach dann wieder normales ISP abwickeln und kommt an die Fuses ran.
Die Firmware im ICE bzw. Dragon m�chte danach aber neu gegr��t werden,
d. h. man muss sich einmal komplett verabschieden und neu verbinden
(was eine komplette Abmeldung und Wiederanmeldung vom/zum USB
bedeutet, einschlie�lich aller damit verbundener Aktivit�ten des
Betriebssystems).
Meines Wissens ist die einzige M�glichkeit, die AVR Studio an dieser
Stelle bietet, das Abschalten der DWEN-Fuse, das verbirgt sich hinter
dem von dir genannten H�kchen. Danach kann man den Chip wieder ganz
normal benutzen.
In AVRDUDE bin ich einen anderen Weg gegangen. Man kann dort ein ganz
normales ISP-Kommando starten, das aber auf Grund des noch aktive
debugWIRE-Modes nicht funktionieren wird. In dem Moment versucht
AVRDUDE noch, das tempor�re Abschalten von debugWIRE einzuleiten,
bevor es sich vom JTAG ICE oder AVR Dragon abmeldet. Sollte dies
gelingen, kann man das gleiche ISP-Kommando nochmal aufrufen (nachdem
das OS das ICE oder den Dragon am USB wieder angemeldet hat), und das
ISP-Kommando funktioniert ganz normal. Die Wahl des ISP-Kommandos ist
dabei komplett dem Nutzer �berlassen; der AVR befindet sich jetzt bis
zum n�chsten power cycle im Zustand "debugWIRE tempor�r abgeschaltet".
Man kann nun ein ISP-Kommando absetzen, das DWEN wieder entsch�rft,
man kann aber auch einfach nur eine neue Firmware schreiben, und nach
dem power cycle die Debugsitzung (mit der immer noch aktiven
DWEN-Fuse) fortsetzen.
Das alles ist leider kaum dokumentiert, das musste ich mir seinerzeit
vom Atmel-Support erl�utern lassen.
F�r mich bleibt dabei als Hauptnachteil von debugWIRE (das ich
ansonsten mittlerweile gar nicht mal so schlecht finde, online-
Debuggen ist schon was feines), dass man sich direkt neben dem zu
debuggenden Controller befinden muss, um ggf. den power cycle zu
initiieren. Bei JTAG dagegen kann man praktisch alles von der Ferne
aus machen.
Frank Buss
> Das Problem dabei ist, dass AVR Studio alles schön GUI-mäßig "wir
> machen das schon für Sie" verstecken möchte. Soll ja alles im
> normalen Ablauf "ganz von allein" gehen, aber wehe, du verlässt mal
> den vorgedachten Trampelpfad...
Solange das funktioniert und bedienbar ist, stört mich das nicht. Wäre zwar
schön, wenn es alles dokumentiert wäre, aber vielleicht will Atmel es sich
leichter machen, um bei Änderungen des Protokolls keinen Supportaufwand zu
haben, und es vielleicht daher nicht offenlegen, oder die wollen ihre
Programmer verkaufen, die aber scheinbar auch gut kopiert werden, was man
so liest.
Ich finde das Fuse-Bit Konzept aber dennoch unsinnig. Warum sollte eine
Software nicht alle Register selber setzen können? Der Microcontroller hat
einen internen RC Oscillator, könnte also in einem sicheren Modus starten
und den Rest macht die Software. Kommt man sich ja vor wie früher, wo
Computer noch große Tafeln mit vielen Schaltern und Lämpchen waren :-)
Zumindest bei meinem Board läuft jetzt übrigens auch endlich USB. Ich habe
die LUFA-Library ausprobiert und die funktioniert gut. Ist aber recht
ähnlich zur Atmel-Library aufgebaut, verwendet also auch eine
Endlosschleife im Hauptprogramm, statt alles interruptgesteuert zu
erledigen. Ist aber bei USB ja sowieso kein Problem, die paar Milliampere
mehr Stromverbrauch machen da nichts aus. Wenn das Gerät allerdings USB und
nicht USB-Betrieb können sollte, müsste man sich noch was einfallen lassen.
Ansonsten gefällt mir die AT90USB-Serie gut. Sind ein paar gut durchdachte
Dinge drin, wie z.B. das man ein Port-Pin einzeln ändern kann, ohne wie
beim PIC befürchten zu müssen, daß ein auf anderer auf Ausgang geschalteter
Pin beim Lesen dennoch gemessen wird. Oder der 16 Bit Timer: Ein 1 kHz
Interrupt lässt sich einfach so generieren:
void initTimer(void)
{
TCCR1B = (_BV(WGM12) | _BV(CS11));
OCR1A = 1000;
TIMSK1 = _BV(OCIE1A);
}
Dann einfach sowas hier:
ISR(TIMER1_COMPA_vect)
{
timerInterrupt();
}
und schon wird die timerInterrupt C Funktion in meiner Application-Ebene
(die hardwareunabhängig ist) regelmäßig aufgerufen. Bei vielen kleineren
PICs gibt es so ein Compare und automatisches Zähler-Rücksetzen gar nicht,
und bei ein einigen größeren Modellen ist es umständlicher zu
programmieren.
WinAVR scheint auch gut optimierten Code zu generieren, der schnell
abgearbeitet wird, da die meisten Befehle in einem Takt durch sind, wobei
der Instruction Clock die volle Geschwindigkeit hat, nicht 1/4 wie beim
PIC.
Joerg Wunsch
> Ich finde das Fuse-Bit Konzept aber dennoch unsinnig. Warum sollte
> eine Software nicht alle Register selber setzen können?
Weil das für bestimmte Features aus Gründen der Zuverlässigkeit nicht
wünschenswert ist, beispielsweise kannst du mit den Fuses
sicherstellen, dass sich Brownout-Überwachung oder Watchdog nicht
durch fehlerhafte Software abstellen lassen.
> Der Microcontroller hat einen internen RC Oscillator, könnte also in
> einem sicheren Modus starten und den Rest macht die Software.
Das Umschalten der Taktquelle ist bei den Xmegas in der Tat dynamisch
möglich, auch die AT90USB162 können das. Hier sind die Fuses wohl
eher historisches Überbleibsel aus der Zeit der ersten AVRs, die noch
nicht alle mit einem internen RC-Oszillator ausgestattet waren.
> Ansonsten gefällt mir die AT90USB-Serie gut. Sind ein paar gut
> durchdachte Dinge drin, wie z.B. das man ein Port-Pin einzeln ändern
> kann, ohne wie beim PIC befürchten zu müssen, daß ein auf anderer
> auf Ausgang geschalteter Pin beim Lesen dennoch gemessen wird.
Das trifft praktisch auf alle AVRs zu, was du da schreibst, nicht nur
auf die USB-Derivate.
Frank Buss
> Weil das für bestimmte Features aus Gründen der Zuverlässigkeit nicht
> wünschenswert ist, beispielsweise kannst du mit den Fuses
> sicherstellen, dass sich Brownout-Überwachung oder Watchdog nicht
> durch fehlerhafte Software abstellen lassen.
Macht für mich auch keinen Sinn. Klar, Watchdog wäre vielleicht schon
sinnvoll, da der ja gerade fehlerhaftes Verhalten absichern soll. Aber da
könnte man beim Setzen von Fuse-Bits auch leicht so ein Konzept wie beim
Umschalten der Interrupt-Bank einbauen, also erst ein Spezialbit setzen,
dann den Wert setzen und dann das Sepzialbit innerhalb von x Takten
zurücksetzen, was dann sehr unwahrscheinlich von fehlerhafter Software
unbeabsichtigt überschrieben werden kann. Damit könnte man auch den
Speicherschutz programmieren (also erst testet die Software die Bits und
wenn der Schutz noch nicht drin ist, werden die programmiert).
Man bräuchte dann keinen speziellen Programmer mehr (außer vielleicht zum
kompletten Löschen des Flashs und der Fuse-Bits, was man aber auch per
Signal an einem Pin machen könnte) und es wäre alles in der Software
enthalten und von dort änderbar, was für einige Anwendungsfälle bestimmt
sinnvoll wäre.
Die LUFA-Library belegt übrigens ca. 50% von den 8 kByte Flash vom
AT90USB82, und zusammen mit meiner Anwendung ca. 70% (ein paar Sensorwerte
abfragen und als HID-Device am PC angeschlossen übertragen). Dazu braucht
man also doch noch einen Programmer, da der USB-Bootloader nicht mehr
reinpasst, aber sonst läuft der Chip recht gut und schnell.
Nur das SPI-Modul will irgendwie noch nicht so richtig, ich kann aber
zumindest per Bitbanging arbeiten. Hat vielleicht einer eine Idee? Ich habe
mich da an das Beispiel aus dem Datenblatt gehalten:
void spiInit(void)
{
/* Set MOSI and SCK output, all others input */
DDRB |= _BV(DD_MOSI) | _BV(DD_SCK);
/* Enable SPI, Master, set clock rate fck/16 */
SPCR = _BV(SPE) | _BV(MSTR) | _BV(SPR0);
}
uint8_t spiTransfer(uint8_t data)
{
/* Start transmission */
SPDR = data;
/* Wait for transmission complete */
while (!(SPSR & _BV(SPIF))) {}
return SPDR;
}
Es werden keine Daten gesendet und bei der Warteschleife bleibt das
Programm hängen (_BV(x) ist in den WinAVR Headern als 1<<x definiert).
Bernd Klier
> Nur das SPI-Modul will irgendwie noch nicht so richtig, ich kann aber
> zumindest per Bitbanging arbeiten. Hat vielleicht einer eine Idee? Ich habe
> mich da an das Beispiel aus dem Datenblatt gehalten:
>
> void spiInit(void)
> {
> /* Set MOSI and SCK output, all others input */
> DDRB |= _BV(DD_MOSI) | _BV(DD_SCK);
>
> /* Enable SPI, Master, set clock rate fck/16 */
> SPCR = _BV(SPE) | _BV(MSTR) | _BV(SPR0);
> }
IIRC muss man SS als Ausgang setzen, zumindest ist das bei den AVRs so,
die ich kenn. Das Datenblatt zu deinem allerdings sagt: If SS is
configured as an input, it must be held high to ensure Master SPI operation.
HTH,
Bernd
Joerg Wunsch
> Aber da könnte man beim Setzen von Fuse-Bits auch leicht so ein
> Konzept wie beim Umschalten der Interrupt-Bank einbauen, also erst
> ein Spezialbit setzen, dann den Wert setzen und dann das Sepzialbit
> innerhalb von x Takten zurücksetzen, was dann sehr unwahrscheinlich
> von fehlerhafter Software unbeabsichtigt überschrieben werden kann.
Könnte man, hat man aber nicht.
Ähnlich gelagert ist die Konfiguration der Totzeiten beim Anlauf nach
Reset oder Sleep: dort kann die Firmware noch nicht eingreifen, und
die Konfiguration hängt von der externen Beschaltung ab. Ist sie
falsch, hast du keinen sauberen Takt zum Anlaufen, und rennst in
undefinierte Zustände.
Gut, in diesem Falle wäre ist nicht ganz so tragisch, der Software das
Beschreiben der entsprechenden EEPROM-Zellen zu gestatten. Wenn sich
die Software damit aber erstmal vertan hat, musst du ohnehin wieder
mit einem externen Programmer 'ran.
> Man bräuchte dann keinen speziellen Programmer mehr
Nur bei deinem AT90USBxxx. Alle anderen AVRs kommen ohnehin nicht mit
einem Bootloader daher, oder (wie man's nimmt) der Bootloader geht
halt über eine besondere Pinkonfiguration (wie beim Xmega), sodass du
doch wieder eine spezielle Programmierhardware brauchst. Die
Programmer kannst du aber im Zweifelsfalle so billig bauen, dass das
kein wirkliches Thema ist. Gerade in der Anfangszeit der AVRs war es
gang und gäbe, dass man den AVR einfach passend an den Parallelport
geklemmt hat. Dass man das heute nicht mehr so einfach kann, haben
wir der Computerindustrie und dem Weglassen der Parallelports zu
verdanken, nicht Atmel. ;-)
Dirk Ruth
Nö. Der Parallelport ist zwar weg, den seriellen (über USB) gibt es
aber immer noch. Andere Controller-Hersteller, wie Renesas, NXP (ARM)
und vermutlich noch andere, schaffen es problemlos damit ihre
Controller zu programmieren.
Aber wenn diese Eigenschaften kein Kritierium beim Kauf sind, dann
kann man dem Käufer auch nicht weiterhelfen...
Dirk
Frank Buss
> IIRC muss man SS als Ausgang setzen, zumindest ist das bei den AVRs so,
> die ich kenn. Das Datenblatt zu deinem allerdings sagt: If SS is
> configured as an input, it must be held high to ensure Master SPI operation.
Stimmt, hatte ich übersehen, danke. Ist aber erstmal überraschend sowas und
finde ich nicht sehr sinnvoll, da ich speziell in meinem Fall drei
Bausteine am SPI-Bus hängen habe und daher den Chipselect sowieso manuell
schalte. Zum Glück ist PB0 noch nicht angeschlossen in meiner Schaltung,
sodaß ich den auf Ausgang schalten kann. Werde ich bei Gelegenheit mal
ausprobieren.
Joerg Wunsch
> Stimmt, hatte ich übersehen, danke. Ist aber erstmal überraschend
> sowas und finde ich nicht sehr sinnvoll, ...
Doch, wenn du weiterliest schon: es gestattet die Möglichkeit, sowohl
master als auch slave zu sein. Wenn /SS als Eingang definiert ist
*und* der SPI-Block als master konfiguriert ist, dann wird mit dem
Pegel an /SS entschieden, ob er master oder slave ist.
> ... da ich speziell in meinem Fall drei Bausteine am SPI-Bus hängen
> habe und daher den Chipselect sowieso manuell schalte.
Das ist bei SPI *immer* so. Daher ist es einfach für einen
"gewöhnlichen master" die erste Wahl, dass man den /SS-Pin als select
zum (ersten) slave schaltet, da man ihn auf diese Weise immer als
Ausgang konfiguriert (der Pin hat nur als Eingang eine
Sonderbedeutung, als Ausgang ist er ein gewöhnlicher GPIO). Den muss
man trotzdem "mit der Hand" schalten, der SPI-Block hat keine Kennung
(und kann keine haben), aus wie vielen 8-bit-Transfers sich eine
SPI-Operation gegenüber dem slave zusammensetzt.
Joerg Wunsch
> Nö. Der Parallelport ist zwar weg, den seriellen (über USB) gibt es
> aber immer noch.
Den kann man aber nur miserabel zum Bit-Banging missbrauchen. 1 ms
pro "bang", da kannst du zwischendrin Kaffee kochen gehen. Reicht
vielleicht gerade mal dazu, dass man damit einen Bootloader nach Wahl
(der dann auf die konkrete Hardware und deren IO-Pins zugeschnitten
ist) programmiert.
Nicht jeder Controller in einer Zielschaltung will schließlich die
UART-Pins immer als UART benutzen, und gerade bei den ganz kleinen
werden die Pins schnell knapp sonst (außerdem haben die kleinsten gar
keine UART).
Aber Programmierhardware für einen AVR bekommst du inzwischen wirklich
an jeder Straßenecke für'n Appel und 'n Ei, das ist nicht mehr
wirklich ein Thema.
Andreas Graebe
> Aber Programmierhardware für einen AVR bekommst du inzwischen wirklich
> an jeder Straßenecke für'n Appel und 'n Ei, das ist nicht mehr
> wirklich ein Thema.
Wenn sie denn funktioniert. Ich hatte gerade ein Problem mit einem gekauften
USB-Programmer. Hübsches Gerät, klein und mit Gehäuse, und endlich mal eins
mit dem 6-poligen Steckverbinder. Das Dumme war nur, er konnte nicht mit
dem (zugegeben schon recht alten) Zielprozessor kommunizieren. Ein
modernerer, pinkompatibler Prozessor in derselben Hardware lief. (zum Glück
DIL auf Fassung) Gegentest mit einem no-cost-Selbstbauteil über den
Parallelport: beides geht. Service des Verkäufers hat keine Idee, woran es
liegt. Bei ihnen geht es. Ich soll ihnen die ganze Hardware zuschicken,
darf ich aber nicht.
Lösung des Problems: Chef sagt "Parallelkarte kaufen, alten Programmer
benutzen." - schade.
--
Mit freundlichen Grüßen Andreas Graebe
--. .-. .- . -... . .--.-. - ..-. .... -....- -... . .-. .-.. .. -. .-.-.- -.. .
Dirk Ruth
"
>Dirk Ruth <d.r...@itecnet.de> schrieb:
>
>> Nö. Der Parallelport ist zwar weg, den seriellen (über USB) gibt es
>> aber immer noch.
>
>Den kann man aber nur miserabel zum Bit-Banging missbrauchen. 1 ms
>pro "bang", da kannst du zwischendrin Kaffee kochen gehen. Reicht
>vielleicht gerade mal dazu, dass man damit einen Bootloader nach Wahl
>(der dann auf die konkrete Hardware und deren IO-Pins zugeschnitten
>ist) programmiert.
>
Für Bit-Banging über USB-Seriell sind m.W. die FT245 von FTDI besser
geeignet.
Allgemein bin ich aber von einem Controller mit Bootloader
ausgegangen. Der kann nicht nur die verschiedenen internen
Spezialitäten abbilden, mit dem kann man dann auch debuggen. Bei
Renesas z.B. haben das m.W. selbst die kleinsten Controller.
>Nicht jeder Controller in einer Zielschaltung will schließlich die
>UART-Pins immer als UART benutzen, und gerade bei den ganz kleinen
>werden die Pins schnell knapp sonst (außerdem haben die kleinsten gar
>keine UART).
>
UART braucht zwei Pins. Wer die aus Kostengründen sparen muss, um
dafür den noch kleineren Controller zu verwenden, wird wohl Produkte
entwickeln, die mal in sehr großen Stückzahlen vom Band laufen.
Derjenige wird dann sicher auch einen richtigen Emulator für ein paar
tausend Euros anschaffen.
>Aber Programmierhardware für einen AVR bekommst du inzwischen wirklich
>an jeder Straßenecke für'n Appel und 'n Ei, das ist nicht mehr
>wirklich ein Thema.
Ärgerlich ist, dass man für jede Serie dieses Hersteller einen neuen
Emulator bräuchte. Das hat mich bisher vom Einsatz dieser Controller
abgehalten, da ein Up- oder Downgrade immer umfangreichere Änderungen
nach sich zieht.
Dirk
Andreas Graebe
> Joerg Wunschschrieb:
> "
>>Dirk Ruth <d.r...@itecnet.de> schrieb:
>>
>>> Nö. Der Parallelport ist zwar weg, den seriellen (über USB) gibt es
>>> aber immer noch.
>>
>>Den kann man aber nur miserabel zum Bit-Banging missbrauchen. 1 ms
>>pro "bang", da kannst du zwischendrin Kaffee kochen gehen. Reicht
>>vielleicht gerade mal dazu, dass man damit einen Bootloader nach Wahl
>>(der dann auf die konkrete Hardware und deren IO-Pins zugeschnitten
>>ist) programmiert.
>>
>
> Für Bit-Banging über USB-Seriell sind m.W. die FT245 von FTDI besser
> geeignet.
> Allgemein bin ich aber von einem Controller mit Bootloader
> ausgegangen. Der kann nicht nur die verschiedenen internen
> Spezialitäten abbilden, mit dem kann man dann auch debuggen. Bei
> Renesas z.B. haben das m.W. selbst die kleinsten Controller.
Bei den meisten AVRs kann man einen Bootloader installieren, hierfür kann
man per Fusebits dessen Speicherbereich vor dem Überschreiben schützen.
Braucht dann aber um die 500 Byte; wenn der Platz knapp ist, muß man eben
wieder den Programmer nehmen.
>>Nicht jeder Controller in einer Zielschaltung will schließlich die
>>UART-Pins immer als UART benutzen, und gerade bei den ganz kleinen
>>werden die Pins schnell knapp sonst (außerdem haben die kleinsten gar
>>keine UART).
>>
>
> UART braucht zwei Pins. Wer die aus Kostengründen sparen muss, um
> dafür den noch kleineren Controller zu verwenden, wird wohl Produkte
> entwickeln, die mal in sehr großen Stückzahlen vom Band laufen.
> Derjenige wird dann sicher auch einen richtigen Emulator für ein paar
> tausend Euros anschaffen.
Ist mMn nicht nötig. Hier ist von Programmern die Rede, und diese haben bei
bislang *allen* von mir verwendeten AVRs (Tiny13 bis Mega2561) dieselben
Anschlüsse. Das einzige, was sich hier geändert hat, ist der verwendete
Steckverbinder. Früher war das meist ein 10poliger Pfostenstecker, heute
wird ein 6poliger empfohlen.
>>Aber Programmierhardware für einen AVR bekommst du inzwischen wirklich
>>an jeder Straßenecke für'n Appel und 'n Ei, das ist nicht mehr
>>wirklich ein Thema.
>
> Ärgerlich ist, dass man für jede Serie dieses Hersteller einen neuen
> Emulator bräuchte. Das hat mich bisher vom Einsatz dieser Controller
> abgehalten, da ein Up- oder Downgrade immer umfangreichere Änderungen
> nach sich zieht.
>
> Dirk
Das ist, wie gesagt, nicht korrekt. Ab und an ändern sich mal die
Algorithmen, mit denen die Kommunikation läuft. Ist auch nicht
verwunderlich, die Derivate vermehren sich wie die Karnickel, und als die
Verfahren einst entwickelt wurden, konnte man wohl noch nicht erahnen, wie
erfolgreich diese Serie wird. Wenn man ein gut gepflegtes Programmiertool
wie den AVRDUDE einsetzt, muß man sich darüber jedenfalls keine Gedanken
machen.
Der ist netterweise auch noch konfigurierbar, sodaß man auch exotische oder
selbstgebaute Programmer nutzen kann. Einen Emulator habe ich bislang noch
nie gebraucht. AVRGCC übersetzt schon recht ordentlich.
Joerg Wunsch
> Für Bit-Banging über USB-Seriell sind m.W. die FT245 von FTDI besser
> geeignet.
Nö, wenn schon, dann FT2232. Damit kann man auch einen AVR
programmieren, ja, und das geht recht flink.
Sei's wie es sei, wenn du einen Controller via USB programmieren
willst, brauchst du halt (mit Ausnahme der direkt USB-fähigen
Controller, die aus ebendiesem Grund auch einen entsprechenden
Bootloader vorgeladen haben) immer noch *irgendein* Stück
Programmierhardware. Auch deinen USB-RS-232-Wandler bekommst du
schließlich nicht kostenlos.
Beim Parallelport (und nur bei diesem) genügte als Adapter ein
DB-25-Stecker mit ein paar Drähten. Allerdings war das auch nur die
"lowest cost"-Variante, bei der man schon ein paar Abstriche an der
Zuverlässigkeit machen musste.
> Derjenige wird dann sicher auch einen richtigen Emulator für ein
> paar tausend Euros anschaffen.
Gibt's beim AVR nicht (mehr). Der Standard-Emulator (das JTAG ICE
mkII) kostet offiziell wohl USD 300 oder so, die Lowcost-Variante (AVR
Dragon, back to the subject ;-) kommt für knapp EUR 70 zum Endkunden
(mit Märchensteuer). Der kann nicht nur so gut wie alle AVRs mit so
gut wie allen Methoden programmieren, sondern auch gleich noch
debuggen.
> Ärgerlich ist, dass man für jede Serie dieses Hersteller einen neuen
> Emulator bräuchte.
Woher auch immer du das hast. Andreas schrieb dir ja schon, dass das
so nicht stimmt.
Frank Buss
> Doch, wenn du weiterliest schon: es gestattet die Möglichkeit, sowohl
> master als auch slave zu sein. Wenn /SS als Eingang definiert ist
> *und* der SPI-Block als master konfiguriert ist, dann wird mit dem
> Pegel an /SS entschieden, ob er master oder slave ist.
Ja, das hatte ich gelesen und genau das finde ich nicht sinnvoll. Wieso
soll die Richtung und der Pegel von einem Port-Pin darüber entscheiden, ob
SPI nun läuft oder nicht? Beim AD7718 z.B. kann man SPI ohne Chipselect
betreiben (indem man 32 Clocks mit DIN high zur Synchronisierung sendet),
sodaß ich also rein theoretisch alle anderen Anschlüsse als Eingang
schalten könnte, wenn die andere Aufgaben hätten. Ein kleines zusätzlichens
Bit irgendwo im SPI-Modul wäre dann sinnvoll, um es dennoch immer als
Master laufen zu lassen, egal was an anderen Pins anliegt. Zugegeben, ein
wenig konstruiert der Fall :-)
Dirk Ruth
"
>Dirk Ruth <d.r...@itecnet.de> schrieb:
>
>> Für Bit-Banging über USB-Seriell sind m.W. die FT245 von FTDI besser
>> geeignet.
>
>Nö, wenn schon, dann FT2232. Damit kann man auch einen AVR
>programmieren, ja, und das geht recht flink.
>
Ja genau den meinte ich.
>Sei's wie es sei, wenn du einen Controller via USB programmieren
>willst, brauchst du halt (mit Ausnahme der direkt USB-fähigen
>Controller, die aus ebendiesem Grund auch einen entsprechenden
>Bootloader vorgeladen haben) immer noch *irgendein* Stück
>Programmierhardware. Auch deinen USB-RS-232-Wandler bekommst du
>schließlich nicht kostenlos.
Die USB nach RS232 Wandler gibt es bei Ebay für 2 EUR incl. Versand.
Wenn man den aufmacht, die Kondensatoren für den Spannungswandler am
MAX213 entfernt und entsp. zwei Brücken mit Fädeldraht einlötet, dann
hat man einen Wandler von USB auf RS232 mit 5V Pegeln. Den kann man
immer gebrauchen, wenn man mit Mikrocontrollern arbeitet,und sei es
nur, man will nur mal ein Terminal an den Controller hängen.
>
>Beim Parallelport (und nur bei diesem) genügte als Adapter ein
>DB-25-Stecker mit ein paar Drähten. Allerdings war das auch nur die
>"lowest cost"-Variante, bei der man schon ein paar Abstriche an der
>Zuverlässigkeit machen musste.
>
>> Derjenige wird dann sicher auch einen richtigen Emulator für ein
>> paar tausend Euros anschaffen.
>
>Gibt's beim AVR nicht (mehr). Der Standard-Emulator (das JTAG ICE
>mkII) kostet offiziell wohl USD 300 oder so, die Lowcost-Variante (AVR
>Dragon, back to the subject ;-) kommt für knapp EUR 70 zum Endkunden
>(mit Märchensteuer). Der kann nicht nur so gut wie alle AVRs mit so
>gut wie allen Methoden programmieren, sondern auch gleich noch
>debuggen.
>
>> Ärgerlich ist, dass man für jede Serie dieses Hersteller einen neuen
>> Emulator bräuchte.
>
>Woher auch immer du das hast. Andreas schrieb dir ja schon, dass das
>so nicht stimmt.
Da bin ich noch anderer Meinung.
Ich erinnere mich noch an etwas wie einen STK500 + 501 + 502, AVRISP,
AVRJTAG mkII usw. Dazwischen gab es möglicherweise noch andere
Versionen - ich hab das nicht weiter verfolgt. Die C51er Serie kann
man damit aber gar nicht programmieren, bei der C51er Serie mir ISP
weiß ich es nicht. Und den Emulator ATICE50 scheint es auch noch zu
geben.
Das alles scheint mir etwas verwirrend. Aus heutiger Sicht mag der
mkII oder der Dragon das alles erschlagen, wenn man aber schon ein
paar Jahre bei Atmel ist, dann hat man die ganzen anderen Programmer
auch im Schrank stehen.
Nur für die o.g. Programmer kommt man auf ca. 670,- EUR. Dafür kann
man schon eine Menge Controller kaufen.
Mal zum Vergleich, bei Renesas kann man vom kleinsten bis zum größten
Controller (R8C, M16C, M32C, R32C ..) alles mit dem E8 (vergleichbar
mit dem mkII) programmieren und debuggen. Geht m.W. sogar mit einigen
H8, die Hitachi mit zu Renesas gebracht hat.
Programmieren und debuggen kann man R8C, M16C, M32C auch
ausschließlich über die UART. Damit liegt die Investition für den
Einsteiger bei genau 2,- EUR.
Aber sei's drum. Bei Microchip scheint es noch mehr verschiedene
Programmer zu geben.
Mal schauen, wie lange der Drache lebt.
Dirk
Joerg Wunsch
>Ja, das hatte ich gelesen und genau das finde ich nicht sinnvoll.
Dann beschreibe mal, wie du es implementieren würdest, dass der
gleiche SPI-Block am gleichen Bus sowohl als Master als auch als Slave
betrieben werden kann. Irgendein Entscheidungskriterium brauchst du
dafür (auch wenn diese Kombination in der Praxis wahrscheinlich
wirklich eher selten benötigt wird), und es liegt in der Natur der
Sache, dass dieses Kriterium vom Master (also aus Sicht deines AVR von
außen) kommen muss.
Gut, ein Bit mehr im Steuerregister hätte es auch getan, aber die
waren alle schon belegt. (Später hat man dann aber trotzdem noch eins
mehr gebraucht, SP2X, das hat man dann ins Statusregister gelegt.)
Wenn dich das so sehr stört, kannst du ja immer noch die USART im
SPI-Modus betreiben, die kann dann nur den Master-Modus. ;-)
> Wieso
>soll die Richtung und der Pegel von einem Port-Pin darüber entscheiden, ob
>SPI nun läuft oder nicht?
Der SPI läuft ja in beiden Fällen. In deinem Fall hat er nur auf den Takt
vom Master gewartet...
> Beim AD7718 z.B. kann man SPI ohne Chipselect
>betreiben (indem man 32 Clocks mit DIN high zur Synchronisierung sendet),
Das ist aber eine ziemliche Ausnahme, die meisten SPI-Chips brauchen
ein Select-Signal, weil das auch zur Synchronisation des SPI-Moduls
benötigt wird.
>Zugegeben, ein
>wenig konstruiert der Fall :-)
Ja, erscheint mir noch mehr konstruiert als der Fall, dass man
wirklich mal master und slave an einem Bus sein möchte. ;-)
Joerg Wunsch
>Ich erinnere mich noch an etwas wie einen STK500 + 501 + 502, AVRISP,
>AVRJTAG mkII usw. Dazwischen gab es m�glicherweise noch andere
>Versionen - ich hab das nicht weiter verfolgt. Die C51er Serie kann
>man damit aber gar nicht programmieren, bei der C51er Serie mir ISP
>wei� ich es nicht. Und den Emulator ATICE50 scheint es auch noch zu
>geben.
Du schmei�t hier gerade komplett das gesamte Programm an Tools in
einen Haufen: Programmer, Emulatoren, Entwicklungsboards.
Der STK500 ist ein Entwicklungsboard mit Fassungen f�r den schnellen
Prototypenbau, noch dazu ein paar LEDs und ein paar Taster drauf. Er
enth�lt au�erdem noch einen Programmer, aber das ist nicht der
Hauptverwendungszweck. Die STK5xx sind Aufsteckboards, die den STK500
f�r AVRs erweitert haben, die ins Grundger�t mechanisch nicht mehr
gepasst haben. (Mittlerweile gibt's von alldem einen Nachfolger
namens STK600.)
So ein Ding kann ganz hilfreich sein (man kann sich mit ein paar
Flachbandkabeln innerhalb weniger Minuten eine Demo-Applikation
zusammenst�pseln), und gerade der Preis des STK500 hat ihn selbst bis
in den Hobbybereich attraktiv gemacht, aber wenn man nur programmieren
will, ist es komplett �bers Ziel hinaus geschossen.
Als reinen Programmer hat Atmel immer nur den AVRISP vermarktet, der
war noch mit RS-232 (aber nicht im Bitbang-Modus, d. h. er geht auch
hinter einem USB-Adapter), sp�ter abgel�st durch AVRISPmkII mit USB.
Die Dinger sind vergleichsweise preiswert, wenn auch nicht unbedingt
f�rs Hobbybudget. Dort haben sich stattdessen diverse Eigenbauten
eingeb�rgert, die es auch nach wie vor tun, wenn man will.
JTAG ICE nannte sich der Emulator f�r die gr��eren ATmegas, die mit
JTAG daher kommen und als erste AVRs on-chip debuggt werden k�nnen.
Das Ding wurde schnell zu klein und daher durch ein JTAG ICE mkII
abgel�st, das nun au�er via JTAG auch noch mit debuWIRE die kleineren
neuen AVRs on-chip debuggen kann. Da es relativ teuer war f�r
Wenignutzer (zwar nicht im Vergleich zu einem "richtigen" ICE), wurde
dann als lowcost-Variante der AVR Dragon aufgelegt. Der kann im
Gro�en und Ganzen dasselbe, ist nur billiger aufgebaut (kein Geh�use,
Kabel muss man sich selbst machen, einfachere Schutzschaltung an den
Pins).
Das ICE50 war nur was f�r Leute mit einem dicken Geldbeutel, da es die
gesamte Hardware in einem FPGA implementiert hat, damit man die CPU
online debuggen kann. Nachdem das Debuggen �ber JTAG so
vergleichsweise simpel und praktikabel geworden ist, gab es f�r dieses
teure Teil (das vermutlich nur wenige Kunden gekauft haben werden, bei
denen der damit erreichbare Produkitivit�tsgewinn tats�chlich den
Preis wieder rausgeholt hat) keine Berechtigung mehr, sodass es nicht
mehr gebaut worden ist.
>Das alles scheint mir etwas verwirrend. Aus heutiger Sicht mag der
>mkII oder der Dragon das alles erschlagen, wenn man aber schon ein
>paar Jahre bei Atmel ist, dann hat man die ganzen anderen Programmer
>auch im Schrank stehen.
Ich glaube, das teuerste, was du danvon noch �brig h�ttest, w�re ein
altes JTAG ICE. Das war aber vergleichsweise wenig verbreitet,
au�erdem war es leicht zu clonen. Die Clones gab's lange noch im
Hobbybereich, aber das ist mittlerweile vom Dragon verdr�ngt worden.
Den STK500 kannst du heute nach wie vor genauso einsetzen, wenn du vor
8 Jahren einen gekauft hast, und selbst die alten AVRISPs m�ssten noch
gehen (die sind praktisch dasselbe wie der Programmierteil des
STK500).
>Mal schauen, wie lange der Drache lebt.
Mittlerweile auch schon einige Jahre.
Heiko Lechner
Zusätzlich noch zu Joerg Wunschs Antwort:
> Die C51er Serie kann
> man damit aber gar nicht programmieren, bei der C51er Serie mir ISP
> weiß ich es nicht.
C51 ist nicht AVR.
Joerg Wunsch
> C51 ist nicht AVR.
Wobei wohl der STK500 aus hysterischen Gründen noch in der Lage war,
AT89C2051 und AT89C4051 zu programmieren, aber diese Sonderlösung
wurde später dann nicht mehr verfolgt.