Hallo, nachdem ich diese Woche die ersten AT90USB1287 im TQFP-64 Gehäuse bekommen habe, hab ich mich gleich mal drangesetzt und eine kleine Schaltung aufzubauen. Gottseidank hatte ich noch eine Adapterplatine für den TQFP-64, so daß die Kontaktierung einfach war. Leider gibt es ein paar Unterschiede zum Datenblatt und zur Beschreibung des Bootloaders von ATMEL. Ausgeliefert wird der Controller mit installiertem Bootloader ab 0xF000. Allerdings sind nicht die Lockbits LB1, LB2 und BLB11 gesetzt, so daß ein Auslesen des Controllers über die SPI-Schnittstelle problemblos möglich ist. Also Achtung, wenn Ihr nicht wollt, daß Eure Firmware in falsche Hände gerät, immer erst die Lockbits setzen, das geht per SPI oder auch per SPM-Befehl von der Firmware aus (hab ich jedoch noch nicht getestet). Ansonsten war der Upload der Firmware über den DFU-Bootloader recht problemlos. Ich habe jedoch nicht Atmels FLIP benutzt, sondern meinen eigenen modifizierten Cypress-Treiber und mein Upload-Tool vom 89C5131, das ich für den AT90USB umgeschrieben habe. Es sind noch ein paar Fehler drin, sobald die beseitigt sind, werde ich das Teil zum Download freigeben. Jedoch werde ich in Zukunft wohl lieber den LIBUSB-Treiber benutzen, der bei ersten Versuchen einen recht guten Eindruck hinterlies und hoffentlich im Bulk-Modus schneller ist, als der Cypress-Treiber (aber soweit bin ich noch nicht). Da ich davon ausgegangen bin, daß der Controller mit internem 8MHz getaktet wird, habe ich erstmal den Quarz weggelassen. Aber da kam auch schon der nächste Unterschied zum Datenblatt zum Vorschein. Die Oszillator-Fuses sind 1110 gesetzt, daß heißt Quarz 8..16MHz. Also, 8 MHz Quarz drangelötet, USB drangesteckt, der PC hat den Bootloader sofort erkannt. Wer schon den AT89C5131 kennt, wird beim AT90USB-Bootloader die Fuses vermissen. Es gibt kein "Software Security Byte" mit dem man einstellen kann, ob der Controller über den Bootloader ausgelesen werden kann. Der Controller ist nämlich grundsätzlich gesichert, ein Auslesen des Speichers ist erst möglich, wenn der Erase-Befehl benutzt wurde. Jetzt kann programmiert werden und ein Verify durchgeführt werden. Aber nur so lange, bis der Bootloader verlassen wird, also die Firmware gestartet wird. Ab sofort ist der Controller dann gegen auslesen geschützt. Bei der Entwicklung der Firmware hat dies natürlich einen großen Nachteil, es muß der Flash-Speicher jedes mal komplett gelöscht werden, was ein paar Sekunden dauert. Ein einfaches Seitenweises überschreiben des Speichers ohne Erase wie beim 89C5131 ist nicht möglich. Wer also in der Entwicklungsphase häufig den Speicher umprogrammieren muß, sollte den Controller besser per SPI- oder Jtag-Schnittstelle programmieren, das geht schneller und ist Flash-schonender. Da es außer dem Datenblatt und den paar HID-Anwendungen (leider Passwort geschützt) keine weiteren Informationen üner die Programmierung des Controllers gibt, entwickelt sich die erste Kontaktaufnahme mit dem Controller relativ schwierig. Vielleicht gibt es ja hier den Einen oder Anderen, der schon ein paar USB-Routinen geschrieben hat mit dem man Informationen austauschen kann. Soviel für Heute, sobald ich mehr über den Controller herausgefunden habe, werde ich das hier wieder posten. Erwin
Hinzuzufügen ist nocht, daß bei einem Erase per USB-DFU-Bootloader der EEPROM-Bereich nicht gelöscht wird. Hat bei der Entwicklung natürlich den Vorteil, daß man den Bereich nicht jedes mal neu schreiben muß, stellt aber im Produktionsstatus ein Sicherheitsmangel dar, falls hier wichtige Daten stehen. Der Atmel-Bootloader ist tatsächlich nur etwas für die Entwicklung. Für die Serienfertigung würde ich den Bootloader auf jeden Fall löschen (also den Controller per SPI programmieren) und einen eigenen Bootloader installieren (falls benötigt). Erwin
Meine ersten Versuche mit dem inzwischen lieferbaren AT90USB1287 waren durchweg positiv. Mit dem WinAVR-Compiler habe ich die kompletten Routinen zur Enumeration geschrieben. Die Anmeldung an den PC funktioniert schon einwandfrei. Als Treiber dient mir der freie LIBUSB für Windows. Als nächstes kommen die ersten Routinen zur Datenübertragung über den Control-Endpoint 0 dran.
Fein, fein. Ich bin soooo kurz davor bei Dir so ein Teil zu bestellen ;-) Wird LIBUSB-Win32 überhaupt weiterentwickelt? Laut Homepage ist der letzte Stand ein Port von 0.1.8.0 (Anfang 2004). Vermißt man da aktuell nichts? Wirst Du weiter Deine Ergebnisse (z.B. Quellcodes g) im Forum posten? Ich bin sozusagen USB-Anfänger und genau das hält mich momentan noch etwas zurück. Grüße, Freakazoid
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.