De Internet Controller, door CTM-R.G.Logchies

Projectbeschrijving Internet protocollen op microcontrollers.

Doel: "The ultimate connectivity"
Het realiseren van communicatiemogelijkheden, via het Internet, voor microcontrollers.
Het implementeren van een gebruikers-interface, op basis van HTML-pagina´s, naar eenvoudige besturingscontrollers.
De bediening van home-installaties of professionele apparatuur, met Internet techniek.
De hardware realisatie van een HTTP-server met als doel een low-cost 8051 met 32k ROM en 32k RAM.
Voorbeelden:

Afstandbesturing over het Internet.
Het bedienen van de verwarmingsinstallatie via de telefoon, met een WWW-browser.
Een antwoordapparaat voor email.
De service-instelling en controle van een kopieermachine, met een portable PC.
Een datalogger voor temperatuur welke een grafische weergave van de metingen geeft door het generen van een HTML pagina, te raadplegen via het Internet, Intranet of telefoon.
Een meetstation voor waterstanden dat een emailbericht genereert bij extreme meetwaarden.

Het projekt is een praktische benadering van de uitvoering van TCP/IP protocollen op kleine micro´s. De gehele uitvoering is origineel zonder gebruikmaking van bestaande software en heeft geenszins de pretentie als voorbeeld te dienen of zelfs maar praktisch en/of efficient te zijn. Al doende wordt echter ervaring opgedaan op het protocolniveau en met de eigenschappen van een "real-time" operating systeem. Kritiek wordt hogelijk gewaardeerd.

Projectstatus
Operating systeem
Implementatie
Protocollen
- ppp
- ip/icmp
- telnet/rlogin/chat
- tcp
- ftp
- dns/pop
- http
Gebruikt soort van produkt

Projectstatus:
Gekozen is voor het eerst uitvoeren van een implementatie van het PPP-protocol, temeer omdat dit een algemeen te gebruiken protocol is voor andere doeleinden.
Het project heeft zich tot nu toe gericht op het operating systeem dat is ingezet bij een toepassing waarbij 4 seriepoorten gebruikt worden met verschillende, klant-specifieke, asynchrone communicatieprotocollen. Ervaring is opgedaan met o.a. interproces-communicatie: het doorgeven van data (blokken) tussen verschillende processen en het activeren van meerdere processen met dezelfde software als device-drivers naar verschillende seriepoorten. Hierdoor is een set subroutines en macro's gevormd welke de basis vormt voor het doel van dit project. Realisatie is niet verder dan dat de controllers "gepinged" kunnen worden. De te volgen marsroute is echter duidelijker geworden en bij beschikbare tijd zal de aanval direct worden voortgezet.
Minimale uitvoering van IP en icmp: alleen de distributiefunctie van IP wordt uitgevoerd; routing is niet nodig in dit soort "host", fragmentatie kan later nog. UDP-proces genereert icmp message: protocol niet aanwezig.
Opzet van meerdere Telnet verbindingen in een "socket-pool".
De moeilijkste taak: het TCP-protocol.

Operating systeem:
De gebruiker staat op enige afstand van het operating systeem dat, normaal gesproken, transparant voor hem is. Het enige wat hij moet weten is dat het operating systeem er is om de hardware te laten functioneren en de toepassingen te ondersteunen. Voor de programmeur is het operating systeem echter de sleutel tot het hardware-systeem. Enige jaren geleden, toen het leven nog eenvoudig was, maakte iedere ontwerper zijn eigen software vanaf nul. Tegenwoordig is, door de toegenomen complexiteit van systemen, de toepassing van een operating systeem eerder aan de orde. In embedded systemen worden operating systemen vaak aangemerkt met "real-time", erop duidend dat zij: op externe gebeurtenissen of bediening reageren op een voorspelbare wijze in een virtueel onmerkbare tijd gerelateerd aan de frequentie van de gebeurtenissen.
In dit projekt is het niet noodzakelijk een operating systeem te implementeren maar om redenen van gebruiksgemak en vooral om een eenvoudige manier te hebben om de software te debuggen is een geheel origineel operating systeem gemaakt met de volgende kenmerken.
Proces-lagen.
In de geest van een "real-time" systeem is een strategie gekozen voor de strikte scheiding van tijdskritische gebeurtenissen en overige taken. Het is bijvoorbeeld bij TCP/IP belangrijker om alle data compleet te ontvangen dan om een snelle responstijd te genereren.
In volgorde van prioriteit:

interrupt gedreven datatransmissie van/naar fifo-buffers "tijds-isoleren" de communicatie.
timerinterrupt gedreven processing (met lagere prioriteit) van TCP/IP protocollen en applicaties.
background afhandeling van gebruikerscommando´s en batch files.

Het verschil met overige real-time operating systemen is de splitsing van datatransmissie in "eigen" interrupt routines die naar buffers communiceren en het verwerken van deze buffers in timer-interrupt gedreven processen. De meeste systemen gebruiken hiervoor een enkel proces. De gekozen methode is m.i. beter geschikt voor asynchrone communicatie protocollen. Met minder O.S-overhead wordt de belangrijkste taak verricht: het juist verwerken van alle informatie. Men zou in dit verband kunnen spreken van een just-in-time operating systeem.
De processen worden, bij het aflopen van een timer (tick), gerund in een frequentie afhankelijk van het procesnummer. Proces_0 wordt om de timer-tick gerund, proces_1 2x zo langzaam etc. Deze methode heeft het voordeel van geringe O.S. overhead echter praktische ervaring met het systeem leerde dat de typische interactie tussen processen vraagt om een andere benadering. Ten koste van een woord in intern geheugen per proces heeft elk proces een eigen timer. Zo kunnen processen dezelfde timerwaarde hebben en om en om runnen. Elke timer-tick verlaagt alle actieve proces-timers en het proces waarvan de timer nul is wordt gerund.
Elk proces dient de controle terug te geven aan het operating systeem en kan dus zo lang runnen als nodig. De ontwerper dient ervoor te zorgen dat elk proces zo kort mogelijk loopt en dat geen proces de micro doet hangen; dit wordt gerealiseerd door elk proces uit te voeren als eindige state-machine. Het voordeel is dat relatief weinig tijd wordt besteed aan context switchen; inter-proces communicatie wordt erg simpel: elk proces weet dat enig ander proces in een stabiele state is en kan de parameters van elk ander proces direct beinvloeden.
Databuffers.
De basis van het systeem wordt gevormd door twee soorten databuffers welke gebruikt worden voor de communicatie tussen de verschillende gebeurtenissen:

32 blokken ter grootte van 256 bytes
16 fifo´s met een instelbare lengte van n x 256 bytes

De eenheid van 256 bytes is gekozen vanwege snelheid van verwerking in een 8051. Het O.S. bevat subroutines voor de afhandeling van data van en naar de databuffers:

claim een buffer als niet reeds in gebruik (open)
geef een buffer vrij na gebruik (close)
reset de bufferpointer (rewind)
zet een databyte in het buffer (store&increment pointer)
haal een databyte uit het buffer (get&increment pointer)

Het systeem waar de software, gedurende de ontwikkeling, op wordt getest bevat 5 full-duplex seriepoorten. Elk van deze poorten kan worden geinitialiseerd met o.a. toewijzing van een in- en uitgangs fifo. Er is een proces: "edit" dat kan worden verbonden met deze fifo's en de taak heeft van een ingetoetste regel een databuffer te maken (blok) en dit door te geven, als een commando, via het scheduler-fifo aan de scheduler. Deze scheduler handelt achtereenvolgende commando's vanuit dit fifo af in de 3e proceslaag. Een scheduler-message bestaat uit het bloknummer van de commandoregel en het nummer van het fifo voor tekstuitvoer. Het is mogelijk om meerdere "kopieen" van het editproces te activeren en te verbinden met de fifo's van een andere seriepoort. Hiermee ontstaat een "multi-user" systeem.
Commando's.
In het geheugen van de micro staan commando's opgeslagen in een speciaal formaat. Een commando is in feite een stuk programma alleen is, door het te omkleden met een header waarin startadres, naam en manual etc., een module ontstaan welke, bij het initialiseren van de micro, een directory oplevert van alle aanwezige commando's. Dit vergelijkbaar met een disk-drive. Er zijn verschillende klassen van commando's; de belangrijkste zijn de "executable" en de batch-file. Via de systeemterminal(s) kunnen commando's worden uitgevoerd en batchfiles worden aangemaakt. Een batchfile wordt door de scheduler, bij uitvoering, weer gesplitst in nieuwe commando's in het schedulerfifo. Hierdoor ontstaat het eigenaardige effect dat een batchfile zichzelf kan runnen en dat daarnaast nog terminalcommando's mogelijk zijn en zelfs het runnen van andere batchfiles. Alles wordt in een wachtrij geplaatst en achtereenvolgens uitgevoerd.
Commando's hebben een belangrijke functie in de monitoring van het systeem. Als bedacht wordt dat het doelsysteem tevens ontwikkelingssysteem kan zijn dan is duidelijk dat een commando als displayram behulpzaam kan zijn bij het on-line monitoren van alle processen. Alle systeem variabelen (pointers, buffers etc.) worden namelijk in extern ram geheugen geplaatst.
Praktische ervaring heeft geleerd dat de fifo-pointers, welke in de eerste proceslaag worden gebruikt, omwille van de snelheid beter in het interne geheugen van de processor kunnen worden geplaatst. Systeemgeneratie geeft de keuze tussen intern/extern geheugen, zodat na debuggen gekozen kan worden voor optimalisatie.

Processen zijn ook opgeslagen in het speciale formaat om ze zichtbaar te maken in de geheugenruimte van de micro. De systeemterminal-input herkent het "hexload" formaat en zo kunnen processen maar ook commando's en batchfiles "bijgeladen" worden in code-ram. Processen worden geactiveerd met het commando: "proces". Dit commando geeft het O.S. te kennen welk proces geactiveerd wordt met de bijbehorende parameters: nummer en naam van het proces, de timer-waarde en verdere parameters. Elk proces krijgt een eigen, vast, geheugenblok van 256 bytes dat gebruikt kan worden voor de parameters en run-time variabelen. Dit blok heeft de functie van het interne geheugen in een "single-proces" systeem overgenomen. Ieder proces heeft bovendien een 'mailbox'; dit is een 16-bytes fifo waar andere processen berichten in kunnen zetten.(store- en getpointer a 4 bits= 1 byte in intern ram; data op vaste plaats in extern ram)
September 1996
Een belangrijke reeks commando's heeft betrekking op het instellen van de databuffers en communicatiecontrollers; hiermee kan de werking van het systeem, op elementair niveau, online, gestuurd worden. Er is een batchfile: "startup" in rom welke de configuratie instelt (start proces: "edit"; fifo's: aantal en grootte; seriepoorten: baudrate, in- en uitgangsfifo etc) en tevens de batchfile: "userstartup" runt welke in code-ram kan worden geladen voor verdere configuratie.

Implementatie
Oktober 1996

Overzicht protocollen:
Bijgaande figuur geeft een overzicht van de communicatie protocollen welke in een netwerkknooppunt, zoals in de Internet Controller, aanwezig kunnen zijn. Een belangrijk inzicht in de functie en samenhang van de TCP/IP protocollen kan worden verkregen door het volgen van de datastroom door het getekende schema. Onderaan beginnend, bij de netwerkaansluiting, is de in- en uitgaande berichtenstroom getekend. Berichten zijn, door een protocol- en een poortnummer, voorzien van een postadres met als bestemming de diverse protocollen. Elk protocol speelt zijn eigen rol in het totaal van de dienstverlening: telecommunicatie. Zo is de HDLC-laag opgesplitst in een ontvang- en een verzendproces. Het ontvangproces controleert een bericht op juistheid en verstuurt het naar een van de processen lcp, ipcp en IP. Bij het opbouwen van een PPP-verbinding (point to point: twee netwerkknooppunten aan elkaar) is eerst het lcp-proces actief met de uitwisseling van communicatieparameters tussen de beide eenheden (bijvoorbeeld de Internet Controller en een terminal-server van een Unix systeem).
Na het overeenkomen van acceptabele parameterwaarden wordt het ipcp proces actief met eenzelfde procedure voor het IP-protocol. Meerdere protocol-soorten kunnen op deze wijze een "link" tot stand brengen tussen de beide communicatieeenheden.
In het schema is het IP-protocol verder uitgewerkt.
Na het leggen van de "link" kan een berichtenstroom voor het IP-proces op gang komen. Het IP-protocol stuurt berichten door naar icmp, UDP of TCP welke elk weer een eigen set van doelprocessen heeft.
Lcp, ipcp en icmp hebben een controlefunctie in het tot stand komen van verbinding en het signaleren van communicatieproblemen. IP verzorgt het datatransport over het netwerk (routing en fragmentatie) en TCP bouwt de verbinding op en zorgt voor de betrouwbare dataoverdracht. Protocollen als http, ftp en telnet gebruiken de verbinding van TCP voor communicatie met de "tegenpartij".
De aanduiding protocol en proces worden opzettelijk door elkaar gebruikt. Dit om twee redenen. Ten eerste een praktische: voor het beter beheersbaar maken van de software wordt elk protocol uitgevoerd door een of meer processen. Daarnaast is het zo dat applicaties gebruik maken van de dienstverlening van een protocol en aldus is een protocol, meer dan een procedurebeschrijving, een deel van het operatingsysteem ofwel een dienst binnen het totaal van de applicatiesoftware.

Configuraties met de Internet Controller:

Afstandbesturing:

Verwarming:

Antwoord apparaat voor email:

Datalogger:

Alarm:

Dataformaat:

Protocollen
Het PPP-protocol:

IP/icmp
Minimale uitvoering van IP en icmp: alleen de distributiefunctie van IP wordt uitgevoerd; routing is niet nodig in dit soort "host", fragmentatie kan later nog. UDP-proces genereert icmp message: protocol niet aanwezig.

Telnet/rlogin/chat
Opzet van meerdere Telnet verbindingen in een "socket-pool".

Het TCP-protocol.