AT90USB HID Beispiel?

Ich habe eben mal den AVR USB Key ausprobiert, der einen AT90USB1287 drauf hat und noch anderes Spielzeug. Per WinAVR konnte ich das "USB Generic HID Implementation" Beispiel per make recht leicht compilieren (nachdem ich das Target in der config.h geändert hatte). Habe mir dann noch ein Script für FLIP geschrieben:

"C:\Program Files\Atmel\Flip 3.4.1\bin\batchisp.exe" -device AT90USB1287

-hardware USB -operation MEMORY FLASH LOADBUFFER USBKEY_STK525-series6-hidio.hex ERASE F PROGRAM VERIFY

(alles in einer Zeile), sodaß das Flashen jetzt auch nicht mehr allzu viel Schmerzen bereitet. Mit der Windows Beispielanwendung kann ich jetzt die LEDs ein- und ausschalten und Joystickbewegungen des USB Keys werden im Fenster angezeigt.

Aber das Atmel Beispiel ist recht resourcenfressend: Die haben da tatsächlich einen (sehr simplen) Scheduler implementiert, der meist nichts anderes zu tun hat, als wie jeck zu pollen, ob es für USB was zu tun gibt, was per Interrupt signalisiert wird. Wenn Stromverbrauch kein Problem ist und man auch sonst nichts zeitkritisches nebenbei laufen lässt, ist das kein Problem (also wahrscheinlich auch nicht für mein aktuelles Projekt), aber gibt es nicht was besseres fertiges? Ist LUFA besser und hat damit schon einer Erfahrung?

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss
Loading thread data ...

Hallo Frank!

Der Test vom Lufa-Stack steht ziemlich weit oben auf meiner ToDo-Liste. Das will ich in den nächsten Wochen erledigt haben. Der Atmel-Stack scheint mir an einigen Stellen nicht so ganz sauber programmiert zu sein. Wenn Du bei AVR-Freaks fragt, da setzen alle auf Lufa.

Bei den Atmel USB-Controllern gibt es aber noch andere Merkwürdigkeiten. Sobald man die HID-Demo geringfügig abändert, läuft die Demo nicht mehr für die AT90USB64x. Mit dem originalen Code oder auf dem AT90USB128x geht es dagegen ohne Probleme.

Gruß Thorsten

--
Wir bewegen Ihre Ideen!
Intelligente Lösungen mit elektrischen Antrieben:
http://www.mechapro.de
Reply to
Thorsten Ostermann

Ja, scheint nicht so gut programmiert worden zu sein. Ein wenig so, als hätte da ein High-Level PC Programmierer versucht, was für einen Microcontroller zu schreiben, was man schon an dem merkwürdigen Scheduler sieht :-)

Ich habe jetzt auch noch ein anderes Problem: Auf meinem selbst entwickelten Board mit einem AT90USB82 wollte ich das HID-Beispiel aufspielen, was auf dem USB Key (mit einem AT90USB1287) problemlos ging. Habe also die Prozessordefinitionen geändert und einige Stellen im Source Code geändert (gibt z.B. scheinbar keine VBus Erkennung) und dann mit Flip aufgespielt. Flip erkannte den Prozessor auch und ich konnte es mehrmals flashen. Als ich dann allerdings ein START Kommando eingebaut hatte, um mein Programm zu starten, also so hier:

"C:\Program Files\Atmel\Flip 3.4.1\bin\batchisp.exe" -device AT90USB82

-hardware USB -operation MEMORY FLASH LOADBUFFER USBKEY_STK525-series6-hidio.hex ERASE F PROGRAM VERIFY START 0

Wurde es zwar wieder geflasht, aber nach dem Start sagte Windows, es hätte das USB-Gerät nicht erkannt. Ein Reset danach erkennt jetzt leider auch den Bootloader nicht mehr. Irgendeine Idee, was schief gelaufen sein könnte? Kann Flip die Fuse-Bits über den seriellen Port irgendwie geändert haben, also z.B. die HWB-Logik aktiviert habe (die Werkseinstellung ist ja, daß der Bootloader gestartet wird)? Oder den Bootloader überschrieben haben?

Ansonsten warte ich jetzt erstmal auf die Bestellung des ISP-Programmers, um das Board vielleicht noch mit den ISP-Pins wieder zum Leben erwecken zu können, ohne den QFN-Chip auslöten zu müssen.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Am 11.04.2010 14:39, schrieb Frank Buss:

Ich habe schon öfters von Fehlern in Atmels Bibliotheken gehört. Auch schon von jemanden, der Atmel darauf angeschrieben hat (mit Fehlerberichtigung) und keine Antwort bekam- der Fehler soll immer noch nicht berichtigt worden sein.

Reply to
Heiko Lechner

Die haben eigentlich eine gute Supportseite, wo ich bisher immer Antwort bekommen habe. Ist ein wenig versteckt:

formatting link

Bisher habe ich auch noch keine ernsthaften Probleme gehabt, nur Ungenauigkeiten im Datenblatt, z.B. daß bei den fetteren CPUs das SSC-Interface laut Datenblatt zwar bis zu Masterclock/2 betrieben werden kann, aber im Anhang in Tabellen versteckt die maximale Frequenz nochmal eingeschränkt wird, sodaß ich das dann doch nicht mit 50 MHz, sondern nur mit 25 MHz stabil laufen lassen konnte.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Am 11.04.2010 23:04, schrieb Frank Buss:

Wenn Du die SPI-Schnittstelle meinst - wenn ich mich recht erinnnere läuft dieschon bis Masterclock/2, nurhat man sehr wenig Zeit das nächste Datenbyte nachzuladen. Wenn man das schon vor dem Interrupt in ein Register schreibt aus dem man es in das Senderegister schreibt sollte es gehn.

Gerald

Reply to
Gerald Oppen

Am 11.04.2010 23:04, schrieb Frank Buss:

Danke, ich reiche das mal weiter.

Reply to
Heiko Lechner

Nein, war schon die SSC-Schnittstelle. Hat z.B. der at91sam9g20. In dem Dokument hier:

formatting link

ist das auf Seite 519 beschrieben. Auf Seite 789 gibt es dann 7 Timingdiagramme und dazu 14 Parameter mit min/max Werten. Ich bin daraus nicht schlau geworden, aber der Supportmann sagte mir dann, er hätte das ausgerechnet und könne nur 25 MHz garantieren. Für SPI gibt es auch ähnliche Timingdiagramme und Tabellen, aber die Schnittstelle brauche ich nicht so schnell in meiner Anwendung.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

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.