Uppdatering SerialNet 06/11/2016

Har gått ett antal veckor nu och det har gått framåt med SerialNet projektet. Bakgrunden är idén att en busskopplad 2-tråds serielänk som ger TCP/IP koppling är önkvärd och kan vara en bra lösning i vissa situationer. Se tidigare poster för detaljerna.
Störst nytta med denna länk gäller sammankoppling av små system, typiskt Embedded Linux eller MCU baserade system. Med de senaste årens framsteg inom Embedded Linux är det nog en hyfsad andel som är tillräckligt billiga för att detta ska spela roll. Men även MCUs kan dra nytta av TCP/IP uppkoppling billigt, främst för att underlätta integration uppåt.

Så vad har hänt? Några highlights:

  • Första testsystem med RS232 signaler, kopplade som en 'wired or' gemensam buss uppsatt tillsammans med USB<->serie adaptrar.
  • Skapat en Linux-utility i C++14 som kopplar samman ett TAP interface från Linux TCP/IP stack till serieporten där USB<->serieadaptern sitter. Innehåller allt stöd för hantering av serieportar, addresshantering och möjlighet att starta en master som organiserar trafiken.
  • Adaptiv hantering av vem som får skicka. Aktiva (well behaved) klienter får prioritet framför enheter som inte snabbt returnerar token.
  • Första test där en ssh session skedde från 1 dator till en annan över serielinan.
  • Lyckats kompilera utility till ARMv7 (RaspberryPi2) och gjort inloggning till RaspberryPi via ssh.
  • Publicerat koden till serialnet på github under GPLv3 licens. Tanken är att låta folk prova ut, ge feedback och utnyttja serialnet i open source sammanhang. Vill man hacka vidare själv går det att klona repot och fortsätta utvecklingen under GPLv3 licensen. Jag har fortfarande full copyright på källkoden så vill man använda detta i en kommersiell miljö så går det att ordna.
  • Första test med 3 enheter. (Stationär dator / laptop / RaspberryPI2) Gick att parallellt starta ssh sessioner från stationär dator till laptop och RaspberryPI:n. I samband med detta var det en förbättrad kabel som tydligt visar att det är 2 trådar som används.
  • Tittat lite djupare på olika scenarios där detta kan vara användbart. Destillerat fram 3-4 scenarios som verkar vara bra för denna kommunikation. Börjat på presentationsmaterial kring dessa.

Det som ligger närmast i 'roadmap':

  • Behöver kunna visa upp ett demo. Trol. 3 enheter, en enhet med Wifiaccess och i denna sker en level-2 bryggning mellan Wifi och serialnet enheten. Sedan delas IP adresser ut via DHCP-servern i Wifiroutern till alla enheter.
  • Testa av riktig RS485. Finns HW, borde fungera, men ska testas.
  • Formalisera byggprocessen. Vore trevligt att kunna installera serialnet genom 'apt-get install ...'

Sedan finns det några lite mer långsiktiga mål:

  • Port till MCUs. (Trol. C implementation, client only)
  • Dynamisk addressallokering av lokala adressen. Automatisk konfiguration vid anslutning/urkoppling. (IP adress kan hanteras av DHCP)
  • HW adaptrar som tillåter signaler + matning över samma ledare.

Portning till MCU

Detta känns som en viktig del i projektet. Det är till stor del MCU:s som kan dra nytta av billig installation av kommunikation. Det finns ett behov att enkelt kunna ge TCP/IP koppling till små billiga enheter.
Målbilden är t.ex. STM32 MCU med FreeRTOS + bundlad TCP server. Kopplat till detta är en enkel serieportsdrivrutin samt serialnet som kopplar ihop serieporten till TCP/IP stacken. För demonstration bör t.ex. COAP protokollet kunna passa. Det gör att man kan exponera ett REST liknande API till sensorer/aktuatorer på MCU:n som sedan kan accessas via t.ex. Firefox.
Kostnadsmässigt är dessa enheter billiga, ofta mindre än $1. I det ljuset är anslutning en relativt stor del av kostnaden. Samtidigt har dessa MCU:s mycket minne jämfört med förr.
Absolut enklaste inkoppling mellan MCU:s kan vara en enkel kopparledare på ett kretskort. Internt kopplas GPIO pinnen för TX som 'open drain' och en MCU aktiverar pull-up resistor. Med denna setup kan flera MCU:s på samma kort fullt ut delta i TCP/IP kommunikation.

Dynamisk adressallokering

En viktigt egenskap i slutändan är enkelhet i installation samt konfiguration. Det ska räcka att koppla in en enhet till kabeln för att den ska upptäckas på nätet, registreras och rätt konfiguration ska sättas. Det mesta av detta sker på högre nivåer. Det som rör serialnet är upptäckt och lokal adressallokering. IP adressen hanteras via DHCP när väl ethernetpaketen kan börja skickas.

Några ord om autokonfigureringen. Detta är den enda gång hittills då timing mellan paket spelar roll i normal kommunikation. En enhet som ansluts har ingen address och har ingen anledning att bli anropad av mastern. Dessutom kan flera enheter ligga på bussen och vänta på address (t.ex. efter power-on av hela bussen) Den lösning som är vald är att ha ett paket för adressallokering med en relativt lång timeout efter frågan. Sedan används random backoff och 'collision-detect' för att en enhet i taget ska få sin address. Varje enhet behöver någon form av unik identifierare för att detta ska fungera. Det är dock fullt lösbart.

Sedan behövs någon form av hantering av addressens livstid. När väl addressen är tilldelad är det relativt lätt att få till ett protokoll för att kontrollera hur länge adressen är giltig. Med mastern som har kontroll på alla adresserna så får man automatiskt en koll på vilka enheter som lever och som har varit borta. Så mastern får gratis en 'heartbeat' tjänst via adresshanteringen och tokenskickning.

HW adaptrar med power supply

Bör finnas en hel del installationer där ett antal små enheter sitter inom 10 meter från varandra. Längre än så så börjar kabelkostnaden dra iväg och trådlöst börjar bli den naturliga lösningen. Hybrider kommer troligtvis bli vanliga (lokala grupper kopplas med kabel och trådlöst för de längre avstånden mellan grupper.) Notera för hybrider, med bryggkoppling av nätverksinterface upplevs hela nätet som ett ethernetnätverk så överliggande lager behöver inte se övergångarna mellan medier, annat än i fördröjningar i paketen.

Det kabeln tillför är att en grupp kan dela på infrastruktur. En enhet har kraftförsörjning, ev. backupbatteri och sedan skickas matning och kommunikation ut lokalt. Om en microkontroller kostar $1 så är man inte alltid intresserad av en 230V adapter till var och en.
Ska man nu dedikera bussen till matning så bör den klara det bra. Skissar på adaptrar som kopplar till en buss med 8V-20V systemspänning. Tillåter att hyfsad effekt förs över utan att kabeln ökar i storlek. Varje enhet har en 'step-down' spänningskonverter som tar ner spänningen till 5V/3.3V eller vad som behövs. Med detta kan man vara rätt så frikostig med hur kraften genereras.
T. ex. direkt inkoppling av 12V accumulatorer eller standard 19V laptopladdare. En adapter kan koppla till bussen på ena sidan och ge GND, serial RX/TX samt +3.3V på andra. Med detta kan det vara lätt att integrera mot existerade konstruktioner. Jag kan tänka mig ett par 3 olika sätt att utforma bussen medan gränsnittet mot MCUn är samma. T.ex. RS485 + kraft, open drain serial eller Powerline communication över kraftkabeln. Det hela kommer ned till kostnad i det enskilda fallet.

En viktigt egenskap är mekanisk inkoppling. Helst ska man kunna montera på en enhet på en existerande kabel utan att behöva klippa den. Har tittat på IDC kontakter (insulation dispacement contacts) som  ett alternativ men inte hittat något klockrent än. Kan dock vänta med att lösa detta för stunden.

Sammanfattning

Det går framåt, inga större hinder än (än tid). Jag tror fortfarande att detta kan göra nytta. Är det någon därute som kan se användningsområden och är intresserad av att komma vidare så hör gärna av er. Annars finns koden på Github att titta på.