Wollte nur mal ein wenig meckern. Habe jetzt den AVR Dragon Programmer, mit 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:
formatting link
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, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
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. ;-)
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.
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.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
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...
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
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:
formatting link
OK, damit hat sich meine Kritik zumindest dahingehend erübrigt, dass es mittlerweile wenigstens /einen/ Weg außerhalb von AVR Studio gibt.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
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.
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.
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.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Stimmt, scheint einiges nicht dokumentiert zu sein. Z.B. das DebugWIRE Interface, zumindest laut dieser Webseite:
formatting link
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 :-)
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
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.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
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:
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.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
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.
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.
Das trifft praktisch auf alle AVRs zu, was du da schreibst, nicht nur auf die USB-Derivate.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
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);
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.
Ä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.
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. ;-)
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
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...
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.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
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.
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.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.