arm Cortex M0+ ueber USB

[Hans P. (helios_one)]

Hallo,

ich wollte die letzten Tage ein bisschen programmieren, da ich mit ARM 
Proyessoren noch nicht wirklich vertraut bin.
Ich moechte einen arm Cortex M0+ so programmieren, sodass ich diesen per 
COM PORT (HTerm) ansteuern kann.
Was ich bis jetzt gemacht habe: USB-Architektur und Datenblatt vom 
uController angeschaut. So richtig schlau wurde ich damit leider nicht.
Ausserdem habe ich versucht ein Beispiel-Programm zu nehmen und es zu 
veraendern...finde aber keine passendes.

Frage:
1)Ich moechte von euch keine feretige Loesung, sondern benoetige nur 
einen Denkanstoss. Wie wuerdet ihr vorgehen?
2)Im Datenblatt sind zwei Register die ich nicht so ganz verstehe:
2.1)Buffer descriptor format? Was macht das genau? Eine Art Flag 
Register?
2.2)Im welchen Register werden die Daten gesendet/empfangen? 
Endpointregister? Wenn ja, wo genau? Laut Datenblatt ist kein einziges 
Bit das dafuer zustaendig ist.

Vielen Dank fuer eure Hilfe!

Mit freundlichen Gruessen Helios_one

[Jim M. (turboj)]

Welchen Controller benutzt Du denn genau? Die USB Ansteuerung ist bei 
jedem Hersteller anders. Wenn der Controller USB unterstützt, sollte der 
Hersteller aber ein CDC Beispiel anbieten, das einen COM-Port über USB 
implementiert. Suche also besser nochmal gründlich.

[W.S. (Gast)]

Jim Meba schrieb:
> sollte der
> Hersteller aber ein CDC Beispiel anbieten

DAS kannst du aber glatt vergessen. Keiner der üblichen Hersteller hat 
das bis auf den heutigen Tag gemacht. Stattdessen gibt es von einigen 
(von Nuvoton selbst, von NXP nur über Keil) nur ganz universell 
gehaltene USB-Rümpfe, wo man tonnenweise eigene Handler per Pointer 
einbinden muß, damit sich überhaupt was bewegt.

Hans Peter schrieb:
> 1)Ich moechte von euch keine feretige Loesung, sondern benoetige nur
> einen Denkanstoss.

Na denne:
1. Die Hardware auffsetzen, das sollte selbstverständlich sein.
2. Einen Interrupthandler schreiben, der sämtliches USB-Geschäft 
erledigt.
3. Ringpuffer für Sende- und Empfangsdaten einrichten und die 
anwendungsseitigen Routinen dazu schreiben (CharAvailable(), GetChar(), 
CharOut(..), usw.)

Das eigentliche USB-Geschehen ist leicht umrissen:
- Der Host schickt dem Device öfters mal ein Setup-Paket, wo drinsteht, 
was er vom Device will. Zumeist fordert er diverse Descriptoren an, die 
man ihm dann auch schicken sollte. Die Descriptoren sind salopp gesagt 
statische Byte-Folgen, die man im Code unterbringt. Es gibt aber noch 
nen ganzen Sack anderer Wünsche seitens des Hostes, da mußt du dich 
belesen.

Ein Device besteht logisch gesehen erstmal aus einem Control-Port 
(physisch aus 2 Controlports: Control-In und Control-Out), der den 
obigen Wünschen des Hosts nachkommt. Die eigentlichen Daten werden von 
zwei anderen Ports durch die Gegend geschleudert: Bulk-In und Bulk-Out. 
Dazu gibt's - sofern man es braucht - noch nen Interrupt-Port und 
Isochron-In und Isochron-Out, aber die sind bei nem CDC nicht nötig. 
Physisch ist ein Port bzw. Endpunkt nur ein Adressbyte in der 
Übertragung.

Der USB-Core erledigt eigentlich ALLEN hardwarebezogenen Kram, ohne dich 
zu belästigen. Interrupt's gibt es nur für quasi "höheres", also wenn 
ein Setup-Paket empfangen wurde und nun drauf reagiert werden muß, oder 
wenn Der Core seine Sende- oder Empfangs-Arbeit erledigt hat und nun 
bereit ist, wieder neue Sendedaten abzukriegen oder seinen 
Empfangspuffer voll hat und die Daten loswerden will. Um sowas wie CRC, 
Handshake und so weiter mußt du dich nur bedingt kümmern, zumeist nur 
als Reaktion auf ein Setup-Paket einen leeren Block als ACK senden oder 
bei Sachen, die du nicht beantworten willst ein NAK senden.


Tja, wie du nun mit dem USB-Core deines µC konkret umgehst, mußt du dir 
im HW-Manual anlesen - und probieren. Ich hatte beim LPC2478 grobe 
Fehler im Manual feststellen müssen, beim LPC1343 durch Probieren 
herausgefunden, daß man die Interrupts auf 2 Weisen löschen muß 
(SIE-Command UND Int-Register) und so weiter. Denke bloß nicht, du 
kämest da mit nem Debugger zurecht. Der USB ist auch zeitbegrenzt und 
der Host erwartet, daß das Device nach ner angemssenen Zeit richtig 
reagiert - wenn nicht, gibt's nen Reset des USB-Cores.

W.S.

[Kurt (Gast)]

Hans Peter schrieb:
> ich wollte die letzten Tage ein bisschen programmieren, da ich mit ARM
> Proyessoren noch nicht wirklich vertraut bin.

Hans Peter schrieb:
> Wie wuerdet ihr vorgehen?

Zuerst mal eine LED zum blinken bringen, dann sehen wir weiter.

[Hans P. (helios_one)]

@ W.S.
W.S. schrieb:
> wo man tonnenweise eigene Handler per Pointer
> einbinden muß, damit sich überhaupt was bewegt
Genau das war einer meiner Probleme...
Vielen Dank fuer die Hilfe jetzt weiss wenigstens wo ich anfangen soll.

@Kurt

Sehr konstruktive Antwort. Natuerliche habe ich erst die LED blinken 
lassen und ganz nebenbei habe ich auch schon die SPI und UART 
Kommunikation mit einem anderen MCU programmiert.

Mit freundlichen Grussen

.

[Lothar (Gast)]

Jim Meba schrieb:
> Wenn der Controller USB unterstützt, sollte der
> Hersteller aber ein CDC Beispiel anbieten, das einen COM-Port über USB
> implementiert.

NXP bietet bei LPC11U00 Cortex M0 sogar den kompletten CDC-Stack im ROM 
an, man muss also nicht viel mehr tun als:

void USBIRQ_IRQHandler()
{
  (*rom)->pUSBD->isr();
}

(*rom)->pUSBD->init_clk_pins();
(*rom)->pUSBD->init(&DeviceInfo);
(*rom)->pUSBD->connect(TRUE);

Dann gibt es In/Out-Puffer die entsprechend geschrieben bzw. gelesen 
werden müssen.

[Kurt (Gast)]

Hans Peter schrieb:
> Sehr konstruktive Antwort.

Danke.

Hans Peter schrieb:
> Ich moechte einen arm Cortex M0+ so programmieren, sodass ich diesen per
> COM PORT (HTerm) ansteuern kann.
> Was ich bis jetzt gemacht habe: USB-Architektur und Datenblatt vom
> uController angeschaut. So richtig schlau wurde ich damit leider nicht.
> Ausserdem habe ich versucht ein Beispiel-Programm zu nehmen und es zu
> veraendern...finde aber keine passendes.

Aufgrund deines ersten Posts war ich tatsächlich der Meinung, dass Du am 
besten mit der LED anfängst.