Hallo,

kennt jemand von euch einen TCP/IP-Stack für den M16C der kein RTOS
braucht?

Ich habe den Flexgate-Stack gefunden, den müsste ich aber portieren.

Einen TCP/IP Stack zu portieren, sollte nicht so schlimm sein.
Die sind meistens rein in C geschrieben und recht hardwareunabhängig.
Soweit ich weiss, wurde UIP schon öfters für M16C benutzt.
Das größere Problem ist die Hardwareanbindung.
Je nachdem, welchen Netzwerkchip Du nimmst, muss dort einiges angepasst
werden. Das ist die meiste Arbeit.

Joachim

uIP von Adam Dunkels sollte gehen
Der Stack ist extra so geschrieben, dass er auf (8 Bit und) 16 Bit auch
läuft. Und RTOS braucht das nicht.
Es gibt dort auch eine Mailing-list von usern - solltest du dich
anmelden, wenn du das benutzen willst, sowie eine Sammlung von bereits
benutzen Projekten (Beispielen). An manchen Stellen in Internet ist von
"ein Meisterbeispiel an Lesbarkeit" zu höhren - vielleicht liegt es
daran, dass ich mich nicht so gut auskenne - kann dem aber nicht
zustimmen (in der Doku sind keine Grafiken oder ähnliches, im Code
selber zum Teil in "tieferen Stellen" goto-Befehle - und in den
Beispielapplikationen heißen Variablen, Pointer und Strukturen (sehr
verschachtelt) oft "s", "p" oder so). Auf der anderen Seite ist ja eben
Beispiel-Application dabei - und es gibt genug Beispiele im Internet.
Ist aber alles in allem nicht schlecht und vor allem kostenlos.
Wenn du etwas mehr Speicher zur Verfügung hast, kannst du dir auch lwIP
anschauen - auch von Adam Dunkels (Swedish Institute of Computer
Science) geschrieben (und auch kostenlos). Das ist etwas größer, verfügt
aber über die volle TCP/IP-Funktionalität (uIP an einigen Stellen etwas
eingeschränkt, z.B. bei ICMP (nur Ping - glaube ich)).
Wenn du Geld hinlegen willst, gibt es allerdings auch einige andere
Lösungen... (die weiß ich aber grad nicht auswenig, hab mir die aber
irgendwo aufgeschrieben - falls es dich interessiert, kann ich ja
nachschauen :-)).
Ich versuch mich grad an uIP - ärgere mich da zwar immer wieder ;-) (hab
aber auch noch nicht so die Erfahrung) - kann das aber trotzdem
empfehlen. uIP gibt es jetzt in der 10 Version - allerdings hat der
Autor keine Zeit, die Software zu pflegen (weil kostenlos) - wird darum
ein Wikibook (auf seiner Seite) und ein Source-Force-Projekt
(gemeinsames Weiterentwickeln)
(http://sourceforge.net/projects/uip-stack) grade gestartet. Sollte also
auch zukunftsicher sein.
Und als ich mal ne Frage hatte, hat mir in der Mailinglist einer aus
Polen, England und Australien geantwortet ;-).

Der Link ist: (http://www.sics.se/~adam/uip/index.php/Main_Page).

> Das größere Problem ist die Hardwareanbindung.

und genau die ist beim flexgate in Assembler geschrieben.

Um zu verstehen, wie die Funktionen arbeiten müsste ich mich dann in
8051 Assembler einarbeiten.

Der uIP-Stack scheint da eine alternative zu sein, obwohl der auf den
ersten Blick ziemlich umfangreich ist.

Markus

@Sebastian S.
> verfügt aber über die volle TCP/IP-Funktionalität (uIP an einigen >Stellen etwas
eingeschränkt, z.B. bei ICMP (nur Ping - glaube ich)).

das sollte nicht stören, ich werde vermutlich irgendein eigenes
Protokoll basteln, das auf tcp oder udp aufsetzt.


> Wenn du Geld hinlegen willst, gibt es allerdings auch einige andere
> Lösungen... (die weiß ich aber grad nicht auswenig, hab mir die aber
> irgendwo aufgeschrieben - falls es dich interessiert, kann ich ja
> nachschauen :-)).
Ja, das wäre nett, evtl kommt das billiger, als den uIP-Stack auf meine
HW anzupassen

> Ich versuch mich grad an uIP - ärgere mich da zwar immer wieder ;-) (hab
welcher Prozessor? welcher Ethernetcontroller?

Markus

> Ja, das wäre nett, evtl kommt das billiger, als den uIP-Stack auf meine
> HW anzupassen

Also: in der uIP-Mailingliste hat einer mal geschrieben:

"However, if you are looking for something more robust and supportable,
then give Micrium’s uC/TCP-IP a chance. It has a free 45 day evaluation
and you can download the code from the website. It does require a much
larger foot print though and you will need to use uC/OS-II as well (both
downloadable, but neither are free)."

Auch habe ich schon von CMX gehört, dass das ganz gut sein soll - aber
auch recht teuer (na ja - gehört halt).

Aber soviel musst du bei uIP gar nicht machen: wenn du die files da hast
(bei mir waren das (eigene Anwenderschicht) uip.c, arp.c, arp.h, uip.h,
uip_popt.h, uipconf.h, uip_arch.h, socket.c, socket.h und pt.h). Dann
musst du die Headerfiles anpassen: (va.) uip_popt.h (Einstellungen
vornehmen), und dann noch in uipconf.h n bisschen was. Wichtig ist halt
die application-Funktion, die immer bei einem Ereignis aufgerufen wird.
Die mainloop kannst du aus der Doku "Mainloop with arp" fast 1-1 nehmen.
Und da ist auch der Knackpunkt bei der "auf die eigene Hardware
portieren" - n paar mal übergibst du deinem Hardwaretreiber einen Buffer
(bzw. Pointer drauf) und die Länge. Na ja - brauchst halt ne Funktion,
wo du deinem Hardwaretreiber Daten übergeben kannst. Und einen
Hardwaretreiber wirst du leider wohl für alle Varianten schreiben
müssen.
Der größte Nachteil seh ich halt darin, dass die Doku ausschließlich mit
Doyigen gemacht ist (d.h. keine Flussdiagramme, Bilder, Tabellen und
so), dass einige Stabilitätsprobleme haben (bei anderen läuft das
jahrelang stabil).

> welcher Prozessor? welcher Ethernetcontroller?
Als Prozessor habe ich nen ARM7 ohne Ethernet-on-chip (im Moment), als
Ethernetcontroller den DM9000 von Davicom  (kann auch an 8-Bit oder
16-Bit Datenbus angeschlossen werden, ist recht schnell und denke
verhältnismäsig einfach zu verstehen - außerdem sind in der application
note Programmzeilen in c. Nachteil: nur 1 Steuerleitung (d.h. erst
Adresse, dann Daten), event. kleines externes EEPROM  benötigt (MAC,
andere default-Einstellungen etc). Vorteil: Datenregister, die sich
selbst inkrementieren, 2  Sendebuffer (wärend Nr.1 sendet, kann in 2.
geschrieben werden), verhältnismäsig einfach zu verstehen, gute Doku).

Na ja - wenn du dich für ne andere Lösung, als uIP entscheidest, würde
ich mich freuen, wenn du mir deine Erfahrung damit mitteilen könntest
:-) Wäre klasse, würde mich freuen :-)

Korrigiert mich, wenn ich falsch liege, aber ich sehe erstmal euer
Problem nicht.

Ich habe den uIP Stack heruntergeladen, zusammen mit dem
"Hardware-Treiber" meiner Netzwerkkarte und der main() kompiliert und es
lief schon (fast). Benutzen tue ich einen Mega644 mit 20MHz Takt und
einer ISA-Netzwerkkarte.

An dem Stack selber ist NICHTS aber auch GARNICHTS an die Hardware
anzupassen. Das einzige, was man anpassen KANN sind zum Beispiel
Checksummen-generier-Funktionen und sowas. (Addierfunktion war glaube
ich auch noch dabei).

Sprich: Man nimmt die Dateien vom TCP/IP Stack, mischt das mit der
main-Funktion (Die enthält eine Schleife, die die Netzwerkkarte auf neue
Pakete überprüft und diese dem Stack übergibt. Anschließend wird bei
Bedarf vom Stack ein neues Paket generiert, was man dann wieder
rausschickt. ARP packt man vor dem Paketprocessing auch noch in die
Schleife.) Und das wars schon fast.

Das heißt: Die einzige Stelle, wo auf die Hardware zugegriffen wird, ist
in der main() while-Schleife. Und die wird ja von dir geschrieben, da
hat der TCP/IP Stack nichts mit am Hut. Der nimmt nur die Pakete
entgegen und generiert bei Bedarf neue.

So war zumindest mein Eindruck - und so hab ichs auch ans Laufen
bekommen.

PS: Für den uIP Stack muss man auch noch eine "Anwendung" programmieren,
die oben auf dem Stack aufbaut.

Na ja - Problem nicht direkt :-) Hab an keiner Stelle gesagt, dass uIP
selber angefasst werden muss. Lediglich die Einstellungen in uipopt.h
(und ne Kleinigkeit in der uip_conf.h) müssen halt vorgenommen werden
und die Main und Anwendefunktion geschrieben werden.

Wie schon gesagt: die nötige Mainloop kannst du fast 1-1 aus der Doku
übernehmen. Dort gibt es 3-4 Stellen, wo der Hardwaretreiber aufgerufen
wird, sprich dem Hardwaretreiber Daten und die Länge übergeben werden
(und nen Hardwaretreiber brauchst du immer).

Du kriegst recht schnell je eine Funktion für TCP und UDP, die bei jedem
Ereignis aufgerufen werden. Dort kannst du deine Application
aufsetzen...

Sebastian S. wrote:
> Na ja - Problem nicht direkt :-) Hab an keiner Stelle gesagt, dass uIP
> selber angefasst werden muss. Lediglich die Einstellungen in uipopt.h
> (und ne Kleinigkeit in der uip_conf.h) müssen halt vorgenommen werden
> und die Main und Anwendefunktion geschrieben werden.

Jau, stimmt. Ein paar Optionen legt man ja auch noch fest.


> Wie schon gesagt: die nötige Mainloop kannst du fast 1-1 aus der Doku
> übernehmen. Dort gibt es 3-4 Stellen, wo der Hardwaretreiber aufgerufen
> wird, sprich dem Hardwaretreiber Daten und die Länge übergeben werden
> (und nen Hardwaretreiber brauchst du immer).

Jau, konnte ich auch (fast).


> Du kriegst recht schnell je eine Funktion für TCP und UDP, die bei jedem
> Ereignis aufgerufen werden. Dort kannst du deine Application
> aufsetzen...

Jup, eigentlich ganz gut gemacht. Man kann dann nachher noch nach Ports
unterscheiden und so verschiedene selbstgebaute Daemons aufrufen, die
das Paket handlen.

PS: Ich sehe grad die neue Wiki, die Adam da angelegt hat. Supi -
hoffentlich sammeln sich da über die Zeit wertvolle Infos.

@Sebastian S.:

> "However, if you are looking for something more robust and supportable,
> then give Micrium’s uC/TCP-IP a chance. It has a free 45 day evaluation

das kommt (erstmal) aus Lizenzgründen nicht in Frage:
µC/TCP-IP is licensed on a per-end-product basis. Each different product
that embeds µC/TCP-IP requires a different license.


> Wichtig ist halt die application-Funktion, die immer bei einem Ereignis >
aufgerufen wird.
Das könnte man doch sicherlich Interruptgesteuert machen, oder wie seht
ihr das? Gibt's irgendwas, was dagegen spricht?


Markus

Hallo,

schau doch mal bei:

http://www.renesasrulz.com/downloads/m16c

da gibt es ein Projekt. Habe es selbst nicht genutzt oder angeschaut!
Steht aber in der Kurzbeschreibung das auch eine Non Rtos Version dabei
sei.

Übrigens findet man dort so einige andere interessante Programme (z.B.
Fat File System)

>> Wichtig ist halt die application-Funktion, die immer bei einem Ereignis >
aufgerufen wird.
> Das könnte man doch sicherlich Interruptgesteuert machen, oder wie seht
> ihr das? Gibt's irgendwas, was dagegen spricht?

ne, hat nix mit Interrupt zu tun. uIP sieht eine Funktion vor, die es
immer dann aufruft, wenn ein Ereignis eintritt (ohne Interrupt). Diese
wird ganz einfach mit ner #define festgelegt (#define uip_appcall
eigeneFunktion, für TCP, sowas gibt es dann auch für UDP). Solltest du
http wollen, legst du halt "(#define uip_appcall httpd_appcall" fest,
die es schon gibt.
Wenn du ne eigene Application willst, nimmst du halt eigene Funktionen.
In denen musst du schauen, warum die Funktion aufgerufen wurde (mit ein
paar wenigen Funktionen, z.B. newdata(), conected() und so). Aber wie
das genau in der eigenen Application läuft, kann ich dir noch nicht
sagen, da häng ich ja selber noch ;-)

ich habe mal das OpenTCP für M16C gefunden. Vielleicht gefällt dir das
besser

und hier die Doku

Andy wrote:
> und hier die Doku

Der kommt auf jeden Fall in die engere Auswahl (zusammen mit uIP und
Flexgate).

@Sebastian S. :

falls du noch an einem Erfahrungsbericht interessiert bist, sende mir
einfach deine EMail-Adresse. Es wird aber einige Wochen (oder Monate)
dauern, bis ich mich intensiv damit befassen kann.

Markus

Da ich mich auch grad mit der Problematik beschäftige hier mal noch eine
Frage dazu. Die ARM Kerne können ja auch 32-bit, gibt das
Performanceverluste, wenn ich einen Stack benutze, der nur 16 kann, oder
ist das als Bandbreite ausreichend? Gibt es vielleicht kleine
TCP/IP-Stacks mit 32-bit?
Hendi

Dacht ich auch erst (hab selber wenig Erfahung) ... als ich da
nachgefragt habe, hab ich die Antwort gekriegt, dass ich den Compiler
mal nicht unterschätzen soll und dass das nicht unbedingt einen
Geschwindigkeitsverlust bedeutet... hängt mit den Optimierungsroutinen
im Compiler zusammen...