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
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.