mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SAM3x8E nativen USB Port als COM-Port nutzen


Autor: Hanns-Jürgen M. (yogy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

nachdem ich nun viele meiner AVR-Routinen auf dem SAM (Hardware Arduino 
DUE) erfolgreich portiert habe, will ich den nativen USB Port auch zum 
Spielen bringen. Als erstes will ich ihn als Slave ("Device") zu 
konfigurieren, daß er dem PC gegenüber als COM-Port erscheint und dann 
(später) als solcher nutzbar ist. Eine passende INF-Datei für Windoof 
werde ich mir schon zusammenfrickeln.

Nur ich komme nicht weiter.

Ich nutze Atmel Studio 7 in Standard C und ohne ASF.

Wie bekomme ich den Port zum Spielen bzw. richtig konfiguriert?

Hier gibt es ein hervorragendes Tutorial, das mir verständnismäßig schon 
weiter geholfen hat, aber es ist für den STM32 und damit nicht ohne 
weiteres auf den ATMEL übertragbar. Zumindest habe ich es nicht 
geschafft, auch nur die ersten Register richtig setzen zu können.

Bei Github habe ich auch zwei Sachen gefunden, eine von "Erlkönig", 
leider in CPP, und einen von "emagli", durch die ich nicht durchsteige.

Ist hier jemand, der sich mit dem SAM3X8 auskennt und mir Links zu 
entsprechenden Tutorials oder Examples geben könnte? Wäre toll. Meine 
Googelei führen mich immer nur im Kreis.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, du bist mir aber einer....
Also du musst dich schon mit dem in deinem Chip vorhandenen USB-Core 
befassen, sonst wird das nix. Ich habe im Laufe der Zeit hier schon ein 
paar USB CDC Quellen gepostet, die prinzipielle Logik ist immer 
dieselbe, aber die Handhabung des Codes ist eben unterschiedlich.

Also nimm dir die Quelle für nen LPC (deren SIE ist noch am 
erträglichsten)  und schreibe die für deinen Chip um.

W.S.

Autor: STM Apprentice (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Wie bekomme ich den Port zum Spielen bzw. richtig konfiguriert?

Ein einfacher Port wie ein UART wird das nie sein. Du brauchst
ein gehöriges Paket an Software dafür.

Irgendwo in den Tiefen des Arduino Board Packages für den SAM3X8E
wirst du eine Sourcen-Sammlung finden (in C++ natürlich) die es
dir ermöglichen mag daraus einen eigenständigen Treiber in C zu
extrahieren.

Aber einfach ist das nicht. Da haben es die STMler etwas leichter.
Und für die STM32-Controller gibt es dermassen viele fertige und
bessere Boards dass die einem den Arduino Due schnell vergessen
lassen.

Ein K.O. Kriterium für mich war dass es beim Arduino Due keine
durchgehenden 8 Bit breite Ports an den Board-Schnittstellen
gibt. Wie kann man nur so etwas designen .....

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM Apprentice schrieb:
> Wie kann man nur so etwas designen .....

Genial ist auch, dass man das Parallelinterface so designt hat, dass 
eine der Adressleitungen mit einer Steuerleitung verbunden ist. Damit 
sind parallele Displays nur per Bitbanging ansteuerbar. Idioten. BTDT.

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Ich nutze Atmel Studio 7 in Standard C und ohne ASF.

Freunde Dich schon mal mit ASF an, denn damit läuft das 
Herstellerbeispiel (Appnote) von Atmel/Microchip.

Bei USB sollte man zuerst versuchen den Hersteller Beispiel Code zum 
Laufen zu bekommen, denn da muss eine ganze Menge Zeugs richtig gemacht 
werden.
Anderenfalls gibt das nur ein häßliches Ausrufezeichen im Gerätemanager, 
das dem Anfänger auch nicht wirklich weiter hilft...

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Eine passende INF-Datei für Windoof
> werde ich mir schon zusammenfrickeln.
Braucht man nicht, ist seit Windows 8 integriert.

Hanns-Jürgen M. schrieb:
> leider in CPP
Ausrede! Und der Code ist im Tutorial doch detailliert erläutert...

Jim M. schrieb:
> Anderenfalls gibt das nur ein häßliches Ausrufezeichen im Gerätemanager,
> das dem Anfänger auch nicht wirklich weiter hilft...
Linux hilft hier, denn der Kernel gibt relativ gute Fehlermeldungen aus.

Virtuelle COM Ports ("VCP"), ob per CDC-ACM oder anders, sind auch nur 
eine Krücke. Wenn du Kontrolle über das PC-Programm hast, definiere dein 
eigenes USB-Protokoll und greife direkt per libusb zu. So hast du mehr 
Flexibilität, Performance und Kontrolle, und vermeidest diverse 
Probleme.

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Ich nutze Atmel Studio 7 in Standard C und ohne ASF.

Was wir gemacht haben: das Beispiel mit ASF zusammenstöpseln lassen,
dann den relevanten Core-Code von ASF rausgepopelt und bei uns
reingesteckt.  Alles andere ringsum ist unser eigener Code.  (Ist
hier ein SAM4E16E, USB-Core dürfte sich von deinem kaum unterscheiden.)

Autor: Hanns-Jürgen M. (yogy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, danke für die vielen Antworten und Hinweise.

Da ich aktuell nur "spiele" und kein produktives System plane, ist der 
DUE für mich der Richtige, insb, da ich einen auf dem Tisch habe.

Und ja, das besagte, wirklich sehr gute Tutorial, ist schon sehr 
hilfreich, ohne hätte ich die USB-Idee gar nicht erst aufgegriffen. Dank 
an Erlkönig!


CPP: Nun, ich habe in einer anderen Geschichte CPP Routinen in K&R C 
umgesetzt. Machbar wäre das auch hier, notfalls..

Ach ja: Ich nutze auf meinen PCs Win XP und Win 7. Updaten auf 
irgendeinen Kachelmist (Win 8 oder gar 10) werde ich nicht. Definitiv. 
Mit Linux habe ich mich vor 15 Jahren mal intensiver beschäftigt, vlt. 
werde ich irgendwann wieder mit Linux anfangen.

Daher:

Niklas G. schrieb:
> Hanns-Jürgen M. schrieb:
>> Eine passende INF-Datei für Windoof
>> werde ich mir schon zusammenfrickeln.
> Braucht man nicht, ist seit Windows 8 integriert.
>
nicht zutreffend, a.o.

> Virtuelle COM Ports ("VCP"), ob per CDC-ACM oder anders, sind auch nur
> eine Krücke. Wenn du Kontrolle über das PC-Programm hast, definiere dein
> eigenes USB-Protokoll und greife direkt per libusb zu. So hast du mehr
> Flexibilität, Performance und Kontrolle, und vermeidest diverse
> Probleme.

Ja, mag sein. Die COM-Geschichte sehe ich zunächst als Einstieg. Ob und 
inwieweit ich "später" weitergehe, kann ich heute noch nicht sagen. Ich 
denke aber, daß ich dann eine Kommunikation eher über Ethernet nutzen 
werde

ASF will ich nicht. Ich will mein System möglichst selber kontrollieren 
und damit auch verstehen. Daß das Ganze dann länger dauert ist für mich 
irrelevant....

Jörg W. schrieb:
> Hanns-Jürgen M. schrieb:
>> Ich nutze Atmel Studio 7 in Standard C und ohne ASF.
>
> Was wir gemacht haben: das Beispiel mit ASF zusammenstöpseln lassen,
> dann den relevanten Core-Code von ASF rausgepopelt und bei uns
> reingesteckt.  Alles andere ringsum ist unser eigener Code.  (Ist
> hier ein SAM4E16E, USB-Core dürfte sich von deinem kaum unterscheiden.)

 Wenn alle Strick reißen, werde das wohl versuchen

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> CPP: Nun, ich habe in einer anderen Geschichte CPP Routinen in K&R C
> umgesetzt. Machbar wäre das auch hier, notfalls..

C++ läuft auch auf SAM3x8E Mikrocontrollern... Und auch C11. Es muss 
nicht K&R C sein...

Hanns-Jürgen M. schrieb:
> Ach ja: Ich nutze auf meinen PCs Win XP und Win 7. Updaten auf
> irgendeinen Kachelmist (Win 8 oder gar 10) werde ich nicht. Definitiv.
Unter Windows 10 kann man die Kacheln komplett abschalten und das 
Startmenü klassisch nutzen. Unter Windows 7 kann man über den 
Geräte-Manager manuell die usbser.sys laden und kann sich auch da die 
.inf Datei sparen... Unter XP - keine Ahnung, wer sich das antut ist 
selber schuld :-)

Hanns-Jürgen M. schrieb:
> Mit Linux habe ich mich vor 15 Jahren mal intensiver beschäftigt, vlt.
> werde ich irgendwann wieder mit Linux anfangen.
Da ist das eh alles einfacher - keine .inf -Datei, keine manuelle 
Treiber-Zuweisung, kein Laden von ggf. WinUSB, bessere Fehlermeldungen, 
Kompilieren mit libusb. Man muss eigentlich nur die Berechtigungen der 
/dev -Datei beachten mithilfe einer udev-Rule.

Hanns-Jürgen M. schrieb:
> Ja, mag sein. Die COM-Geschichte sehe ich zunächst als Einstieg.
CDC / VCP ist aber komplizierter zum Laufen zu bringen, als erstmal 
"nacktes" USB...

Hanns-Jürgen M. schrieb:
> Ich
> denke aber, daß ich dann eine Kommunikation eher über Ethernet nutzen
> werde
Dann mach das doch direkt, ist eh einfacher als USB.

: Bearbeitet durch User
Autor: Hanns-Jürgen M. (yogy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun ja...

Niklas G. schrieb:
> Hanns-Jürgen M. schrieb:
>> CPP: Nun, ich habe in einer anderen Geschichte CPP Routinen in K&R C
>> umgesetzt. Machbar wäre das auch hier, notfalls..
>
> C++ läuft auch auf SAM3x8E Mikrocontrollern... Und auch C11. Es muss
> nicht K&R C sein...

Ich selber beherrsche CPP nicht, daher nehme ich nur nur K&R C

> Hanns-Jürgen M. schrieb:
>> Ach ja: Ich nutze auf meinen PCs Win XP und Win 7. Updaten auf
>> irgendeinen Kachelmist (Win 8 oder gar 10) werde ich nicht. Definitiv.
> Unter Windows 10 kann man die Kacheln komplett abschalten und das
> Startmenü klassisch nutzen. Unter Windows 7 kann man über den
> Geräte-Manager manuell die usbser.sys laden und kann sich auch da die
> .inf Datei sparen... Unter XP - keine Ahnung, wer sich das antut ist
> selber schuld :-)

Nun, Windof ist Mist, so oder so. Irgendwann, so um 2008, habe ich mir 
einen ersten Rechner mit XP aufgebaut und der Win 2k Rechner aufs 
Altenteil geschickt. Das funzte/funzt ganz gut. Nach knapp 5 Jahren hat 
sich dann das (ASUS-) MB verabschiedet. Ich konnte ein gebrauchtes 
erwerben, das aber nur ein knappes jahr hielt. Also baute ich mir einen 
komplett neuen Rechner und beging den Kardinalfehler, dort Win 7 zu 
installieren. Win 7 hat zwar Vorteile gegenüber XP, aaaaber: Keinen 
Druckertreiber für meinen Drucker mehr verfügbar, kein Treiber bzw,. SW 
für mein Progranmuiergeröt, kein NETBEUI für die Vewrbinung zu meinem 
DOS-Rechner (TCP schluckt zuviel RAM), 2 meiner 3 
Videso-Schnittprogramme liefen nicht mehr und einiges andere auch nicht 
mehr. Auch der XP-Emulator half nicht, ebensowenig wie eine VMWare 
Installation. Alles nur Gemurkse. Schließlich baute ich mit einem 
"neuen" gebrauchten, zum alten fast kompatiblen MB wieder einen 
-zusätzlichen(!)- XP-Rechner...

Das Ganze will und werde ich nicht ein weiteres Mal durchführen. Daher 
wird es auch kein "modernes" Windoof geben. Ach ja: XP und 7 laufen 
absolut stabil bei mir. Ich "nutze" ja auch kein MS Office

>
> Hanns-Jürgen M. schrieb:
>> Mit Linux habe ich mich vor 15 Jahren mal intensiver beschäftigt, vlt.
>> werde ich irgendwann wieder mit Linux anfangen.
> Da ist das eh alles einfacher - keine .inf -Datei, keine manuelle
> Treiber-Zuweisung, kein Laden von ggf. WinUSB, bessere Fehlermeldungen,
> Kompilieren mit libusb. Man muss eigentlich nur die Berechtigungen der
> /dev -Datei beachten mithilfe einer udev-Rule.

Dem ist nichts hinzuzufügen. Ich muß wohl meinen alten Linux-Rechner, 
der damals aös Web- und Fileserver diente, aus dem Abstellraum 
zurückholen. Ob der noch läuft? Wird wohl was für die langen 
Winterabende

>
> Hanns-Jürgen M. schrieb:
>> Ja, mag sein. Die COM-Geschichte sehe ich zunächst als Einstieg.
> CDC / VCP ist aber komplizierter zum Laufen zu bringen, als erstmal
> "nacktes" USB...

Das sehe ich auch so, was ich da gerade durchgehe ist absolut 
unübersichtlich.

>
> Hanns-Jürgen M. schrieb:
>> Ich
>> denke aber, daß ich dann eine Kommunikation eher über Ethernet nutzen
>> werde
> Dann mach das doch direkt, ist eh einfacher als USB.

Klar, Ethernet hatte ich mit dem AVR schon lauffähig

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
>> CDC / VCP ist aber komplizierter zum Laufen zu bringen, als erstmal
>> "nacktes" USB...
>
> Das sehe ich auch so, was ich da gerade durchgehe ist absolut
> unübersichtlich.

Naja, sooo schlimm ist es nun auch wieder nicht.  Man sollte einen gut
getesteten Satz von Descriptors benutzen, verschiedene Betriebssysteme
reagieren allergisch auf verschiedene Feinheiten in dem, was das Device
über sich so behauptet.

Vorteilhaft an CDC ist, dass du am Ende irgendein einfaches
Kommandozeilen-Interface auf deinem Controller zimmern kannst, welches
du mit einem üblichen (Seriell-)Terminalemultor auf dem Host bedienen
kannst.  Wenn es einmal läuft, ist der wesentliche Nachteil halt, dass
Windows <= 7 dafür noch so'n blödes .inf-File braucht.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Ich selber beherrsche CPP nicht, daher nehme ich nur nur K&R C

Das heißt C++, denn CPP ist der C PreProcessor... Wirklich K&R C? Das 
von 1978? Nicht mal ANSI-C? Uff.
Man kann übrigens auch C++ Code in C Projekte einbinden...

Hanns-Jürgen M. schrieb:
> Keinen
> Druckertreiber für meinen Drucker mehr verfügbar,
Linux hat Treiber für ein paar Drucker, für die es nach WinXP keine mehr 
gibt...

Hanns-Jürgen M. schrieb:
> Ich muß wohl meinen alten Linux-Rechner,
> der damals aös Web- und Fileserver diente, aus dem Abstellraum
> zurückholen. Ob der noch läuft? Wird wohl was für die langen
> Winterabende
Oder parallel zu Windows installieren ("dual-boot"). Dauert je nach 
Glück mit den Treibern 1-2h.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Ich selber beherrsche CPP nicht, daher nehme ich nur nur K&R C

Als K&R-C wird der C-Standard vor 1989 bezeichnet, der noch keine 
Funktionsprototypen kannte und damit praktisch überhaupt keine 
Typprüfungen durchführen konnte.

Bist Du Dir sicher, daß Du dieses Fossil meinst?

Autor: Hanns-Jürgen M. (yogy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oops, da habe ich mich falsch/unklar ausgedrückt bzw. die fslschen 
Begriffe benutzt:

Mit CPP meinte ich natürlich C++

und mit K&R C das "Standard C" (ANSI C?). Ursprünglich habe ich "damals" 
bei meinen ersten C-Versuchen 1985 ein Buch von K&R benutzt, später dann 
das Buch von Claus Schirmar mit ANSI C (1992). Also sagen wir mal:

#define K&R  ANSI  :-)

Noch eine Anmerkung zum Dual Boot: Ich hatte einen Dual Rechner (Win 98 
/ LUNIX SUSE 8), aber der ist längst verschrottet. Dual Boot dauert mir 
heute zu lange (Runterfahren, Hochfahren), da ist ein weiterer PC ggf. 
über KVM-Switch gemuxt eher die Wahl.


Ach ja: Druckertreiber: Es ging um den Treiber für den HP LJ 3100...Ob 
da Linux was zu bieten hat bzw. HP einen beigetsuert hat, weiß ich 
nicht. Ich werfe nunmal ungern Sachen weg, die noch funktionieren (oder 
reparabel sind), nur, weil es keine Treiber mehr gibt.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Ach ja: Druckertreiber: Es ging um den Treiber für den HP LJ 3100...Ob
> da Linux was zu bieten hat bzw. HP einen beigetsuert hat, weiß ich nicht

Laut HP ja:

https://developers.hp.com/hp-linux-imaging-and-printing/models/laserjet/hp_laserjet_3100

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Vorteilhaft an CDC ist, dass du am Ende irgendein einfaches
> Kommandozeilen-Interface auf deinem Controller zimmern kannst, welches
> du mit einem üblichen (Seriell-)Terminalemultor auf dem Host bedienen
> kannst.

exakt DEN Satz solltest du ungefragt in goldenen Lettern in jeden 
Thread kopieren, wo einer anfängt, über USB aud seinem µC zu schreiben.

Wie man das von der Pike auf für diverse µC hinbekommt, habe ich hier 
zur Genüge gepostet, wer es also tatsächlich an seinen µC adaptieren 
will, darf die Suchfunktion benutzen.

W.S.

Autor: Hanns-Jürgen M. (yogy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich möchte meine (frustrierten) Zwischenstand abgeben, nachdem ich 
letzte mich Woche 30 Stunden  mit dem Thema "USB" befaßt habe.

Aber zunächet: Ich habe hier im Forum nach dem Hinseis von W.S. (das 
vorhergehende Posting" nach dessen Postings gesucht. Aber weder einen 
Suche nach w.S., noch nach CDC oder USB brachte Erfolg. Nun, auch egal.

Ich hatte bei meiner Suche auch einen SEHR interesanten Artikel 
bezüglich USB (allerdings als Host betrieben) auf einem SAM3X8E 
gefunden. Ich möchte euch das hier nicht vorenthalten:

https://www.codeproject.com/Articles/876161/Getting-video-stream-from-USB-web-camera-on-Ardu

Zunächst habe ich muir die Startroutinen (Init) bei ihm angesehen.

Dann habe ich mir so gedacht, ich nehme das Projekt von emagii auf 
Github
https://github.com/emagii/at91sam3s
und portiere das zum SAM3X8.

Das war sehr zäh, immerhin waren über 20 Files (H und C) einzubinden und 
zu portieren und meiner Nomenklatur entsprechend anzupassen. Als ich 
zuletzt das USB-HAL.c File anpassen wollte, habe ich aufgegeben. Grund:

Der SAM3S kann im Gegensatz zum SAM3X nur den USB-Device Mode. Mir ist 
es daher nicht gelungen, die Register entsprechend "umzudenken"

Mein Ansatz bestand/besteht halt darin, ein Fremd-Projekt zum Spielen zu 
bringen und es dann zu analysieren. So habe ich es beispielsweise bei 
"FAT32 auf Speicherkarte" gemacht (AVR).

Da mir das Beisipiel von erlkönig auf dem STM32 trotz des dort 
vorhandene USB2GO Ports noch zu umständlich in der Portierung (C++ und 
zudem ein anderer Prozessor) erscheint, habe ich nun, wie hier auch 
vorgeschklagen wurde, ein nacktes ASF Projekt angefangen, das ich nun 
als erstes mit meinen Umgebung (Display etc) verbinden werde.

Ich melde mich wieder, allerdings habe ich nur noch 2..3 tage Zeit, 
danach muß ich mich für 3..4 Wochen um wichtigere Dinge kümmern.

VG Yogy

Der dort verwendete

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Der SAM3S kann im Gegensatz zum SAM3X nur den USB-Device Mode. Mir ist
> es daher nicht gelungen, die Register entsprechend "umzudenken"

Wo ist das Problem? Du wolltest doch ein USB-Device bauen?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Wo ist das Problem?

Dass er offenbar versucht hat, einen für OTG geschriebenen Code als
Device-Code umzubauen.

Das dürfte nicht nur wegen anderer Registernamen kaum praktikabel sein,
sondern das Verhalten als USB Host ist ein völlig anderes als das als
USB Device.  Selbst, wenn eine Hardware beides kann, ist die dahinter
liegende Software für beide Betriebsarten komplett anders gestrickt.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Die COM-Geschichte sehe ich zunächst als Einstieg.

Mach doch erstmal was simpleres wie HID. Hast Du schon das Buch "USB 
Complete"? Das ist Pflichtlektüre.

Autor: Hanns-Jürgen M. (yogy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, einen nicht mehr so frustrierten Zwischenbericht.
HEUREKA! Es funzt "im Prinzip"
Am und Mo habe ich ein ASF-Projekt begonnen und dann die ASF Files mit 
meinm SW-Grundgerüst verknotet. ASF hat noch mehr Files einzubinden als 
die amagii-Geschichte. Gestsrn, DI habe ich das dann soweit zum Spielen 
gebracht, daß ich im Windoof Gerätemanager den USB-Port ohnen 
Fehlermeldung sehen konnte. Heute habe ich dann damit "rumgespielt", so 
daß ich jetzt mittekls des termainal programms Zeichen senden und 
empfangen kann. Nun, ein erster aber sehr wichtiger Schritt.

So bald ich wieder zeit habe, werde die ASF Dateien entmüllen und meiner 
Nomenklatura anpassen.

Was mir noch fehlt, sind der Zeichenempfang und das Zeichensenden 
mittels Interrupt, damit es kompatibel zu meinen anderen 
Communikationsroutinen wird.

Diese funktionieren, wie wohl allgemein üblich, folgendermaßen:

Durch den Empfang eines Zeichens wird ein IRQ ausgelöst, in dem das 
zeichen in  einen Buffer geschrieben wird. Zugleich wird ein Eventflag 
gesetzt. In der Hauptprogrammschleife werden dann alle bis dahin 
empfangenen Zeichen ausgewertet.

Soll ein Zeichen geschrieben werden, wird es in einen anderen Buffer 
geschrieben und der Sende-IRQ freigegeben. In der Sende-IRQ Routine 
werden dann nach und nach elle Zeichen im Buffer ausgesendet, und nach 
dem letzten Zeichen wird der IRQ gesperrt.

Bei USB-Systemen scheinen ja Buffer defaultmäßig vorhanden zu sein, so 
daß ich zumindest den Sende-IRQ nicht benötige. Aber einen Empfangs-IRQ 
brauche ich zum EventFlag-setzen. Pollen ist halt blöd. Ich denke "so 
mal eben auf die Schnelle", daß dazu der IRQ den Endpoints-0 verwendbar 
ist, oder?

So, jetzt muß ich mich (leider) erst einmal um wichtige Dinge kümmern.

Bis bald

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Bei USB-Systemen scheinen ja Buffer defaultmäßig vorhanden zu sein, so
> daß ich zumindest den Sende-IRQ nicht benötige.

Jein.  Dafür solltest du dir sendeseitig Gedanken machen, ab welchem
Füllstand des Puffers bzw. bei welche(m|n) Zeichen du das Senden
anwirfst.  Gesendet wird ja immer in ganzen Paketen, und wenn du worst
case jedes Zeichen einzeln in einem USB-Paket verpackst, dann geht die
Datenrate in den Keller.

> Aber einen Empfangs-IRQ
> brauche ich zum EventFlag-setzen. Pollen ist halt blöd. Ich denke "so
> mal eben auf die Schnelle", daß dazu der IRQ den Endpoints-0 verwendbar
> ist, oder?

Wenn du den HAL aus ASF benutzt, dann gibt es eine Funktion 
HAL_UsbRead(), bei der ein Callback für das Ende des Transfers angegeben 
werden kann.  Wir starten ein solches HAL_UsbRead(), danach läuft das 
Programm im Vordergrund weiter.  Wenn der ankommende Transfer bereits 
zum Abholen ist, wird der Callback gerufen.  Der verarbeitet das, was 
eingetrudelt ist, und startet danach ein neues HAL_UsbRead().

Gewissermaßen startet man mit jedem HAL_UsbRead() einen separaten 
Thread, der so lange schläft, bis auf dem USB wieder „was passiert“ ist.

: Bearbeitet durch Moderator
Autor: Hanns-Jürgen M. (yogy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, danke für die Antwort. Werde ich mir dann genauer ansehen.

Autor: Hanns-Jürgen M. (yogy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, das Thema ISB ist jetzt ersteinmal erledigt. In den vergangenen 
Tagen habe ich einen teil des ASF Überbaus entfernt, den rest mache ich 
irgendwann, wenn es ernst wird.

Die Kommunkation habe ich nun laufen. Lesen aus dem UOTGHS erfolgt per 
Interrupt nach einem empfangene Zeichen, es werden dann alle bis dahin 
abrufbaren Zeichen abgeholt.

Rücksendung erfolgt entweder als Einzelzeichen oder, falls möglich, 
blockweise aus einem Array. Große Datenblöcke hat meine 
Kommunkationsstruktur allerdings keine, maximal 240 byte,

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Die Kommunkation habe ich nun laufen.

Schön!

Bei uns ist nun gerade der SAM4E durch einen SAME70 ersetzt worden. Der 
hat Highspeed-USB statt nur Fullspeed … da wird sicher noch einiges an 
Umbau nötig werden.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.