Microchip WLAN Modul & TCP/IP Stack

[Flipp (Gast)]

Halli Hallo,

wie bereits in einem anderen Thema erwähnt bin ich gerade dabei an einem 
Modul zu bauen, welches in der Lage ist CAN Daten über WLAN an den 
Computer zu übertragen.

Im ersten Wurfe will ich dazu ein Eval-Kit benutzen, welches bereits 
einen CAN-Transceiver sowie einen PIC Microcontroller trägt.

Um nun die Daten über WLAN zu versenden habe ich mir bei Microchip auch 
schon mal die WLAN-Module angesehen und dazu hätte ich folgende Fragen:

MRF24WB0MA

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en548014

Dieses Modul bietet keinen integrierten TCP/IP Stack. Jedoch gibt es für 
PIC uC diesen bereits von Microchip als Download
-> http://ww1.microchip.com/downloads/en/appnotes/00833b.pdf

Was mir nicht ganz klar ist, ist z.B. diese Zeile aus dem Datenblatt

"To be able to meet this
requirement and still stay relatively independent of the
main application using its services, the Microchip
TCP/IP Stack uses a widely known technique called
cooperative multitasking."

Mir ist prinzipiell schon klar warum das nötig ist - allerdings muss ich 
laut Datenblatt diese Technik auch für meine Implementierung nutzen. Was 
bedeutet dass für mich? Der Begriff ist mir neu und wie ich meine 
Software passend dazu entwickel ist mir vollkommen ein Rätsel.


Eine Alternative wäre noch z.B.

RN171

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en558370

Dieses Modul hat bereits einen TCP/IP Stack implementiert. Heisst dass, 
das ich lediglich die Befehle und Nachrichten über SPI an das Modul 
schicke und dann mich um gar nichts mehr kümmern muss, also nicht mal 
mehr um oben genanntes "cooperative multitasking" ?


Welches Modul wäre also für einen mehr oder minder großen Neuling eher 
zu empfehlen?

Vielen Dank und viele Grüße

Flipp

[Programmierer (Gast)]

Kooperativ bedeutet, dass deine Applikation regelmässig Rechenzeit 
abgeben muss. Oft gibt es eine einzelne Funktion dafür; da steht sicher 
Genaueres dazu in den Appnotes oder Programmbeispielen.

[Marco M. (marco_m)]

Flipp schrieb:

> Was mir nicht ganz klar ist, ist z.B. diese Zeile aus dem Datenblatt
>
> "To be able to meet this
> requirement and still stay relatively independent of the
> main application using its services, the Microchip
> TCP/IP Stack uses a widely known technique called
> cooperative multitasking."
>
> Mir ist prinzipiell schon klar warum das nötig ist - allerdings muss ich
> laut Datenblatt diese Technik auch für meine Implementierung nutzen. Was
> bedeutet dass für mich? Der Begriff ist mir neu und wie ich meine
> Software passend dazu entwickel ist mir vollkommen ein Rätsel.
>

Cooperatives Multitasking kennt man noch aus Windows 3.11 Zeiten. Jeder 
Vorgang wurde dort durch ein Event eingeleitet und wenn man etwas 
abarbeiten wollte, dann musste man regelmäßig den Arbeitsstatus 
speichern und zum Event-Dispatcher zurückkehren, sonst wäre alles 
eingefroren.

Wenn ich die Codebeispiele zum PIC Stack so sehe, dann soll man wohl 
sowas machen:

Statt:

void meine_aufgabe() 
{
 for(;;) {
 mache_a(); 
 mache b(); 
 mache c();
 }
}

Da hier:

int status=0; 
void meine_aufgabe_cm() 
{
 switch(status)
 {
 case 0:
  mache_a(); 
  status=1; 
  return; 
 case 1:
  mache_b(); 
  status=2; 
  return; 
 case 2:
  mache_c(); 
  status=0; 
  return; 
 }
}

Eine Funktion des TCP Stacks ruft dann meine_aufgabe_cm() regelmäßig 
(neben anderen "Tasks") auf, so daß mache_a,b,c da reingemultiplext 
werden.

[Flipp (Gast)]

Hey,

vielen Dank für die Antworten.

Also nur dass ich das jetzt richtig verstehe:

Ich lasse also mein eigentliches Programm über eine Funktion des PIC 
Stacks laufen, welcher dann von Zeit zu Zeit meine Funktionen aufruft.

Diese Funktionen muss ich (je nach Größ) in verschiedene Teilaufgaben 
unterteilen (siehe bei deinem Beispiel mache_a, mache_b und mache_c) ?
Würde ich also z.B. die Funktion  meine_aufgabe_cm so rechenintensiv 
implementieren, dass eine Gewisse Laufzeit überschritten würde, würde 
das cooperative multitasking nicht mehr funktionieren?


Aber am Rande hätte ich dann noch die Frage ob es dann nicht 
einfacher/geeigniter ist das Modul mit bereits integriertem TCP/IP Stack 
zu verwenden?

[Frank K. (fchk)]

Flipp schrieb:

> Ich lasse also mein eigentliches Programm über eine Funktion des PIC
> Stacks laufen, welcher dann von Zeit zu Zeit meine Funktionen aufruft.

> Diese Funktionen muss ich (je nach Größ) in verschiedene Teilaufgaben
> unterteilen (siehe bei deinem Beispiel mache_a, mache_b und mache_c) ?
> Würde ich also z.B. die Funktion  meine_aufgabe_cm so rechenintensiv
> implementieren, dass eine Gewisse Laufzeit überschritten würde, würde
> das cooperative multitasking nicht mehr funktionieren?

Richtig. Der PIC würde zwar nicht abstürzen, aber er würde auf nichts 
mehr reagieren - keine Pings, keine HTTP-Requests,...

> Aber am Rande hätte ich dann noch die Frage ob es dann nicht
> einfacher/geeigniter ist das Modul mit bereits integriertem TCP/IP Stack
> zu verwenden?

Im Prinzip hast Du dort das gleiche Problem. Alles, was das Modul selber 
machen könnte, wie ICMP etc, würde zwar noch laufen, aber Deine 
Weboberfläche würde nicht mehr reagieren. Unter Windows ist es genauso. 
Wenn Du in einem Windows GUI-Programm Deine Window Messages nicht 
schnell genug verarbeitest, hängt Dein Programm auch, und das ist für 
den Benutzer sehr nervig.

Du musst lernen, fundamental anders zu programmieren. Nicht Du bist es, 
der den Programmablauf bestimmt, sondern der Benutzer ist es.

So ging es früher:

PRINT "Vorname eingeben:"
INPUT vor$
PRINT "Nachname eingeben:"
INPUT nach$

Jetzt bestimmt der Benutzer, welches Feld er in welcher Reihenfolge 
ausfüllt. Du bekommst nur noch eine Nachricht "Benutzer hat Feld 'nach' 
ausgefüllt" und musst darauf reagieren, indem Du beispielsweise das 
entsprechende Edit Control ausliest.

Genauso ist es mit einem Netzwerkgerät. Du bekommst Callbacks vom 
TCP-Stack, das eine bestimmte Webseite angefordert wurde und musst 
beispielsweise Variablen einfügen oder ein Formular auswerten oder oder 
oder, und damit auf das Nutzerverhalten REAGIEREN. Du agierst nicht 
mehr.

Dieses Paradigma wirst Du verinnerlichen müssen. Das Stichwort ist 
"ereignisgesteuert" oder "event-driven". Der Microchip-Stack hat den 
Vorteil, dass Du dort an die Hand genommen wirst und jemand anders schon 
die konzeptionelle Arbeit getan hat. Falsche Designentscheidungen wirst 
Du damit kaum treffen können bzw es sehr schnell merken.

fchk

[Flipp (Gast)]

Hey,

vielen Dank für die ausführliche Antwort!!! Das Umdenken zu einer mehr 
Eventbasierten Programmierphilosophie fällt mir an und für sich nicht so 
schwer, da ich schon mit C# etwas GUI Programmierung gemacht habe, 
darunter auch mit Netzwerkkommunikation.

Mein Problem ist dabei dass Umdenken in den Embedded Bereich. Während 
ich unter Linux oder Windows Betriebssystemen relativ einfach Programme 
mit mehreren Threads realisieren kann, ist mir das ganze auf einem 
Mikrocontroller leider noch nicht so ganz klar.

Da ich auf einem nackten uC ja keine Threadverwaltung habe und das auch 
ungern selbst implementieren würde (und wohl auch gar nicht könnte) ist 
mir die Umsetzung leider nicht ganz klar.

Ich hätte es mir jetzt so vorgestellt, dass ich bei der Variante mit dem 
Stack auf meinem Microcontroller, ich es wohl durch die bereits 
vorgeschlagene Methode realisieren muss. D.h. ich lasse den eigentlichen 
Hauptthread im Code von dem TCP Stack laufen und von dort werden dann 
meine Funktionen aufgerufen.

Bei der anderen Variante (also Stack auf dem Modul) würde ich erwarten 
dass der Controller auf diesem externen Modul quasi in seinem eigenen 
Thread arbeitet und mir dann über den SPI erst Bescheid gibt wenn 
irgendwas zu tun ist...?