Hallo, nun bräuchte ich wieder eure Hilfe. Ich möchte natürlich nicht das Rad neuerfinden und auf die Erfahrungen anderer aufbauen. Ich hab nen ATmega16 und den ENC28J60. Nun will ich lediglich TCP-Pakete senden und empfangen mit einem eigenen Protokoll. Also ich bräuchte einen sehr minimalistischen TCP-Stack. Ich hab mir jetzt schon uIP angesehen, aber ICMP und ARP und so brauche ich eigentlich nicht oder?
Da verwendest du am Besten den lwIP Stack: http://savannah.nongnu.org/projects/lwip/ der ist für den Einsatz mit FreeRTOS gedacht, kann aber auch ohne ein Betriebsystem bzw. ohne Multithreading eingesetzt werden. http://lwip.wikia.com/wiki/LwIP_with_or_without_an_operating_system lg Peter
Mathias O. schrieb: > nun bräuchte ich wieder eure Hilfe. Ich möchte natürlich nicht das Rad > neuerfinden und auf die Erfahrungen anderer aufbauen. > Ich hab nen ATmega16 und den ENC28J60. Nun will ich lediglich TCP-Pakete > senden und empfangen mit einem eigenen Protokoll. Ja, was denn nun? Eigenes Protokoll oder TCP? Oder eigenes Protokoll, was auf TCP aufsetzt? > Also ich bräuchte > einen sehr minimalistischen TCP-Stack. Ich hab mir jetzt schon uIP > angesehen, aber ICMP und ARP und so brauche ich eigentlich nicht oder? Wenn du TCP willst, brauchst du im Minumum auch IP. ARP ebenfalls, oder ersatzweise manuell erstellte konstante ARP-Tabellen. ICMP hingegen ist mehr oder weniger verzichtbar. Das ist mehr sowas wie ein Protokoll zur Fehlerdiagnose. Ein µC kann in aller Regel mit den darüber gelieferten Infos eh' nicht viel nützliches anfangen. Allenfalls die Auswertung von REDIRECT-Nachrichten ist manchmal nützlich. Aber im Vergleich zu TCP selber sind die anderen Protokolle vom Aufwand her sowieso eher gering einzuschätzen. Die Gretchenfrage ist also eigentlich, ob du TCP wirklich benötigst oder ob es nicht sinnvoller wäre, dein eigenes Protokoll direkt auf Ethernet aufzusetzen und damit gleich den ganzen teuren TCP/IP-Stack überflüssig zu machen... Wenn es nur um solche Sachen geht wie etwa eine einfache Kommunikation mit Sensoren oder Aktoren innerhalb eines Netzwerksegmentes, dann braucht man das ganze IP-Geraffel nämlich eigentlich überhaupt nicht, gelgentlich wirkt es sogar eher störend.
Wenn du das Rad nicht neu erfinden willst solltest du noch 20€ in ein leistungsfähiges board investieren. Dann kannst du fertige Programme verwenden. uip ist so schon Quälerei. Das noch abzuspecken ist schwierig, weil man es dafür verstehen muss. Ohne Arp wird das sowieso nichts. ICMP fällt nicht ins Gewicht.
Ich hab mich wahrscheinlich ein wenig undeutlich ausgedrückt. Es soll ein Protokoll werden wie Modbus auch eins ist. So soll es dann natürlich auf IP und TCP aufbauen.
Mathias O. schrieb: > Ich hab mich wahrscheinlich ein wenig undeutlich ausgedrückt. Es > soll > ein Protokoll werden wie Modbus auch eins ist. So soll es dann natürlich > auf IP und TCP aufbauen. Und warum dann nicht gleich auch Modbus nehmen, wenn du schon so auf universelle Standardprotokolle abfährst, daß dir ein Aufbauen auf TCP/IP als völlig natürlich erscheint? Das wäre dann wenigstens konsequent.
Modbus ist dann wieder zuviel für mein Vorhaben. Es sollen nur ein paar Bytes übertragen werden. Maximal 10 Bytes Nutzdaten. Das ganze dann also alles im 5-7 Layer vom OSI, wenn mich nicht alles täuscht.
Mathias O. schrieb: > Modbus ist dann wieder zuviel für mein Vorhaben. Es sollen nur ein paar > Bytes übertragen werden. Maximal 10 Bytes Nutzdaten. Das ganze dann also > alles im 5-7 Layer vom OSI, wenn mich nicht alles täuscht. Das ist doch Murks. Bei solch kleinen Paketgrößen ist Ethernet extrem ineffizient, weil es eine minimale Paketlänge von 64 Bytes hat. CAN würde sich dafür eher anbieten: kleine Paketgröße von 8 Bytes Nutzdaten, völlig deterministisches Timing, viel geringerer Stromverbrauch. fchk
Frank K. schrieb: > Mathias O. schrieb: >> Modbus ist dann wieder zuviel für mein Vorhaben. Es sollen nur ein paar >> Bytes übertragen werden. Maximal 10 Bytes Nutzdaten. Das ganze dann also >> alles im 5-7 Layer vom OSI, wenn mich nicht alles täuscht. > > Das ist doch Murks. Bei solch kleinen Paketgrößen ist Ethernet extrem > ineffizient, weil es eine minimale Paketlänge von 64 Bytes hat. Und? Wenn's schnell genug ist, um alle Daten zu übertragen, ist das doch wurscht. > CAN würde sich dafür eher anbieten: kleine Paketgröße von 8 Bytes > Nutzdaten, völlig deterministisches Timing, viel geringerer > Stromverbrauch. Das Timing von CAN ist nicht deterministisch.
Mathias O. schrieb: > Modbus ist dann wieder zuviel für mein Vorhaben. Es sollen nur ein > paar > Bytes übertragen werden. Maximal 10 Bytes Nutzdaten. Naja, und woraus leitest du die Anforderung ab, daß du IP und insbesondere auch noch TCP brauchst? IP kann man ja noch verstehen, damit kann man die Grenzen des lokalen Netzwerksegments überschreiten und außerdem macht es (wie schon weiter oben von jemand anderem erwähnt) die Kommunikation mit Windows einfacher bzw. überhaupt erst möglich. Aber TCP ist vergleichweise sehr fett, da sollte man genau überlegen, ob man dessen Features wirklich braucht. Ich würde mal vermuten, daß es UDP in deiner Anwendung auch tun würde und das ist viel schlanker. Obendrein ermöglicht es auch Broadcasts, was für manche Anwendungen ziemlich nützlich ist.
c-hater schrieb: > Aber TCP ist vergleichweise sehr fett, da sollte man genau überlegen, ob > man dessen Features wirklich braucht. Ich würde mal vermuten, daß es UDP > in deiner Anwendung auch tun würde und das ist viel schlanker. Obendrein > ermöglicht es auch Broadcasts, was für manche Anwendungen ziemlich > nützlich ist. Je nach Anwendungsfall ist es auch besser geeignet, da es bei Übertragungsfehlern nicht das Senden neuer Werte blockiert, bis die bereits veralteten nochmal gesendet wurden.
Also um ein wenig Licht ins Dunkle zu bringen. Es geht um eine Heizung. Diese hat eine CAN-Schnittstelle. Nun möchte ich gerne mit Hilfe einer App vom Tablet aus die Heizung bedienen. [Ironie] Nun hab ich schon überall geguckt, hab aber keine Tablet gefunden mit WCAN(Wireless CAN)[/Ironie]. Also muss ein Converter her. Da dachte ich mir dann natürlich auf Ethernet. Und eine App die dann per TCP die Daten sendet und empfängt ist am einfachsten zu schreiben.
Ich bastle gerade an so einer Lösung. Ich habe eine Kombination aus Atmega328, MCP2515 und ENC28J60. Pakete vom CAN-Bus schicke ich per UDP-Broadcast ins Ethernet und umgekehrt. Prinzipiell funktioniert das schon. ARP und Ping habe ich spaßeshalber auch realisiert. Ist allerdings alles selbst gestrikter Assembler-Code.
Mathias O. schrieb: > eine App die dann per > TCP die Daten sendet und empfängt ist am einfachsten zu schreiben. Was soll daran einfacher zu schreiben sein als eine App, die die per Bytes Daten per UDP versendet? Wenn man blocking calls verwendet, sind die beiden Programme bis auf die Parameter zur Socket-Erstellung doch absolut gleich...
Wenn ich Modbus nehme mach ich es über TCP und wenn ich ein einfaches Protokoll nehme, mach ich es über UDP. Mal schauen.
Nanu. Wenn ich das richtig überblicke, brauchst du noch ein WLAN-Ethernet Kästchen. Oder sehe ich da was falsch? Wieso dann nicht gleich eine Linux-Platine mit WLAN-Stick und Webserver nehmen? Wozu dann die ganze Arbeit mit der zu kleinen Hardware und der App auf dem Tablett?
WLAN würde ich nur machen wenn keine Kabel möglich sind und ein WLAN Accesspoint ist wahrscheinlich sowieso vorhanden. Egal ob CAN oder MODBUS, da werden immer nur Paketchen geschnürt, die sich locker in einem einzigen UDP-Frame unterbringen lassen. TCP wäre da Overkill und Controllerseitig wesentlich schwieriger zu implementieren. Und UDP ist für's Tablet auch eher einfacher als TCP, zumindest nicht schwieriger.
Wozu hat man denn einen Router mit WLAN. Man glaubt es nicht, es gibt sogar Router mit LAN-Ports. Was soll man sonst mit einem Tablet. Ich denke dan auch, dass ich UDP werden nehme. Das kann meine SPS auch. Also werde ich dann ARP, ICMP (da ich auch pingen will), IP, UDP und am Ende mein Protokoll implementieren. Beim Tablet ist es egal, ob TCP oder UDP. Das ist beides ziemlich einfach.
Soo ich hab jetzt IP, ICMP, ARP und UDP. Läuft alles super. Er antwortet auch schön auf ARP- und Ping-Requests. Weiß jemand warum die mindest Paketgröße 60 Bytes ist, also warum der ENC den Rest auffühlt, wenn es nicht 60 Bytes sind?
Weil Ethernetpakete mindestens 64 Bytes lang sein müssen (und vier Bytes für die CRC draufgehen). Diese Vorschrift ist ein Relikt aus halbduplex-Zeiten, um größere Kabellängen zu ermöglichen. Wenn die Datenpakete auf dem Kabel kürzer sind als das Kabel selbst, kann es an einer Stelle eine Kollision geben, die woanders nicht erkannt wird. Das Ethernet-Protkoll verläßt sich aber darauf, daß alle Teilnehmer mitbekommen, wenn es eine Kollision gegeben hat. Also ist die erlaubte Kabellänge durch die Länge des kleinsten erlaubten Paketes begrenzt. Ist heutzutage bei vollduplex auf twisted-pair-Kabeln natürlich egal. Wobei: der ENC kann ja nur 10Mbit, dann kann er wahrscheinlich auch keine fast link pulses, also keine Autonegotiation, also muß er halbduplex machen, oder?
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.