ATmega und USB, suche Tutorial

realisieren.

Schon mal unter mikrocontroller.Net geschaut????

Werk waren.

--
ich heiße wirklich Björn, und mein Nachname tut nichts zur Sache
beitragen... Danke

C ist nunmal für Pascal-Verwöhnte ein nur mühsam lesbares Kauderwelsch, das geht mit ganz genauso.

Aber ich denke mal, daß das garnicht dein Hauptproblem ist. Das wird wohl eher die Tatsache sein, daß man USB verstanden haben muß, um die Implementierung eines USB-Treibers wirklich verstehen zu können. Und gegen dieses Problem hilft halt nur, die USB-Specs zu lesen, Kommentare im Quelltext der Implementierung können das einfach nicht ersetzen, dazu ist die Sache viel zu komplex.

Der Quelltext von obdev.at jedenfall ist für C-Verhältnisse durchaus ordentlich und lesbar geschrieben. Wenn man weiß, wie USB funktioniert und grundlegende C-Kenntnisse hat, kann man den gut verstehen. Ich konnte es zumindest.

Na ja, was mich generell stört, nicht nur an C-Programmbeispielen, das gibt es auch bei Pascal, ist, dass manche Leute offenbar zeigen wollen, was für tolle Tricks die drauf haben.

So findet man bei obdev.at z.B. bei einem Delphiprogramm eine inline asm Funktion um ein Byte in einzelne Bits zu zerlegen und damit 8 Checkboxen zu markieren. Dazu dann noch einige andere unsinnige Spielereien, die mit der eigentlichen USB-Funktionalität nichts zu tun haben.

ICh hab mir das nicht durchgelesen, aber wenn ich das richtig sehe dann geht das ganze doch sowieso auf den Russen zurueck der vor Jahren mal die Sourceimplementation geschrieben habe und der spaeter von Atmel eingekauft und zur Applikation umgewurstet wurde. Daran fand ich eigentlich nichts schlecht dokumentiert. Aber wie schon jemand sagte man muss erstmal die ganzen Grundlagen zu USB gelesen haben.

Klar, sowas gibt es. Aber du hast es hier mit einer Softwareimplemenation von USB zutun. Da kommt es teilweise auf jede Mikrosekunde an. Da kann man nicht immer allerfeinsten Code erwarten.

BTW: Da du ja ueberlegt hast Geld fuer die USB-Sache rauszuruecken geht es wohl um ein kommerzielles Project oder? Mir waer dann so eine Softwaresache zu heiss. Zumal da noch die Frage aufkommt ob das so zertifizierungsfaehig ist damit du den USB-Babberl auf deine Kiste kleben kannst. Ich wuerde jedenfalls eher einen Microcontroller mit integriertem USB verwenden. Sowas ist ja heute auch kein Problem mehr.

Olaf

Hallo Björn!

Schonmal unter

geschaut?

Gruß Thorsten

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

Hallo Stefan!

Wie sieht denn deine Hardware aus? AVR mit onChip USB, oder externer FTDI-Chip? Für ersteres solltest du dir mal das LUFA-Framework ansehen, das ist deutlich besser als das Zeug von Atmel.

Gruß Thorsten

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

Stefan Brröring schrieb:

Komisch, dasselbe habe ich gedacht, als ich Atmels Referenzimplementierung für einen I²C-Host in C gesehen hab und sie ob ihrer kruden Hässlichkeit -- bereits im Sourcecode -- kurzerhand auf Assembler umgeschrieben habe. Der Assemblercode ist simpler, kleiner, schneller und dabei noch einfacher zu verstehen.

C ist einfach nix im µC-Bereich. Auch wenn's irgendwie doch geht.

Mit freundlichem Gruß

Jan

Am 21.12.2010 20:59, schrieb Jan Kandziora:

...

Es geht sogar sehr gut. Man muß sich nicht um den Befehlssatz kümmern, um Stacks etc....

Die Peripherie kostet bei einem Wechsel schon genug Zeit. Manchmal ist selbst ein UART nicht trivial.

Dann kann man komplzierte Sachen bequem auf dem PC austesten, Vieles ohne Änderung auf eine neue Plattform bringen und performant ist C-Code in aller Regel auch.

Ich finde selbst schlecht kommentierten C-Code leichter zu lesen als

8051-Assembler. Da stehen einem nämlich mindestens der Befehlssatz und die Register-breite/-namen im Weg.

Falk P.S.: Die Forth-Fraktion hat das Wort ;-)

Am 21.12.2010 20:55, schrieb Thorsten Ostermann:

Danke. Es ist schon angenehm, wenn man nicht der Einzige ist, der meckert ;-)

Falk

Waer es nicht langsam mal wieder an der Zeit das mal wieder jemand eine ganz neue Spracher erfindet? Oder geht das nicht mehr weil zuviel abgeschrieben wird?

Olaf

Falk Willberg schrieb:

Wenn bei deinen Programmen die Algorithmen das wesentliche sind, mag das stimmen. Ich würde auch nicht unbedingt damit anfangen, einen digitalen Regelkreis in Assembler zu implementieren (obwohl sich das später als Optimierung doch wieder lohnt).

Das meiste was ich in einen µC reinstopfe *ist* Peripheriecode und irgendwelche Interruptroutinen. Das ist in C fast unumgänglich umständlich, weil man ohnehin nur Bits setzt, löscht und durch die Gegend schiebt.

Vielleicht waren meine Projekte bisher auch immer zu simpel? Aber ich hatte eigentlich noch nie Bedarf irgendwas komplizierteres als einen SPS-Ersatz, vielleicht noch mit dem einen oder anderen integrierten Bonbon, in einen µC zu stopfen. Sobald es komplizierter wird locken die ARM-Boards mit Linux drauf, da ist die gesamte Umgebung deutlich hochsprachenfreundlicher.

8051 und all diese alten Schlurren waren nie angenehm in Assembler zu programmieren. Aber Kommentare sind allerdings alles, auch in Assembler. Und Modularisierung des Codes. Man kann sowohl in Assembler als auch in C Spaghetti machen.

Ich mag Forth, noch vom Apple II. Allerdings suche ich immer noch nach einem Anwendungsfall, den ich anders nicht gleichwertig oder leichter hinbekommen würde. Vielleicht ist der eingangs erwähnte digitale Regelkreis ja sowas.

Mit freundlichem Gruß

Jan

Das Abschreiben ist unvermeidlich. Alle guten Ideen scheint schon mal jemand gehabt zu haben:

X'SCNR'L

Jan Kandzioraschrieb: "

... vermutlich weil du noch nie an Projekten gearbeitet hast, wo mehrere Leute dran mitarbeiten. Gerade Stefans Beispiel mit den 8 Checkboxen zeigt doch, das eben genau sowas nicht gewünscht ist. Und zu was anderem als genau das ist ASM nicht sinnvoller als C.

Dirk

Dirk Ruth schrieb:

Ich glaube ich wiederhole mich, aber dennoch: Man kann in Assembler wie auch in C hervorragend Spaghetticode erzeugen. Wenn mehrere Leute an einer Sache arbeiten hilft nur Modularisierung und gute Dokumentation.

Andererseits kann ich mir auch nur sehr wenige µC-Projekte vorstellen, bei denen es auf der Softwareseite so viel zu tun gibt, dass mehr als einer gleichzeitig damit beschäftigt wäre. Hunderte von kB Quellcode in einen µC zu schieben kann sich nur bei sehr hohem Kostendruck, also extremer Stückzahl, lohnen. Vor allem wenn auch noch mehrere Leute daran arbeiten sollen.

Mit freundlichem Gruß

Jan

Ich vermute mal: beides nicht, sondern bitbang-USB. Wie schon geschrieben wurde, ist das für ein kommerzielles Produkt, auf das man sich verlassen muss, zu heiss. Es kratzt an den Grenzen jeglicher Specs und funktioniert IIRC nur auf übertakteten ATmegas im Rahmen derselben.

Wir haben mal einen Prototypen gebaut, der einfach nur Tastendrücke an einen PC weiterreichen sollte. Also USB-HID-Klasse emuliert und gut, das hat zwar absolut zuverlässig funktioniert, aber ein USB-Logo bekäme es nie. Und so war der Prototyp halt ein Gerät, das u.U. auch zum Betrieb an USB-Schnittstellen geeignet ist. Im gegebenen Umfeld war das akzeptabel, aber wodie Gefahr besteht, dass mal jemand genau nachfragt, geht es natürlich nicht.

Nö, und auch kein Interesse daran...

--
ich heiße wirklich Björn, und mein Nachname tut nichts zur Sache
beitragen... Danke

Es gibt einige neue Sprachen. Interessant z.B. Fortress, mit der man besser lesbaren Code schreiben können soll, der aber dennoch zu sehr schnellen Programmen compiliert wird. Daneben scheint mir GO! auch interessant zu sein:

Außerdem gibt es natürlich noch einige gute ältere Sprachen, die man zumindest mal kurz ausprobiert haben sollte:

Und natürlich die Klassiker wie Common Lisp, Forth, Smalltalk, Haskell oder Prolog. Wenn du die alle durch hast und dir dann noch Features für eine neue Sprache einfallen, dann kannst du gerne nochmal die Frage nach einer neuen Programmiersprache stellen :-)

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Am Tue, 21 Dec 2010 16:20:38 +0100 schrieb Stefan Brröring:

Ich fand das dort sehr brauch- und lesbar:

HTH, Marc

Am 21.12.2010 23:27, schrieb Jan Kandziora:

Es gibt ja auch Sachen, die möchte man nach x Jahren noch einmal bauen oder muss sie "reparieren" und da gibt es dann den früher benutzten Controller nicht mehr. Es ist dann vorteilhaft wenn man nur ein paar Funktionen ändern muss, die direkt mit den "Controller- Interna" herum hantieren (Interface). Setzt natürlich voraus, dass man das auch schon beim Schreiben der Software bedenkt und es macht die Sache halt etwas langsamer.