seriële communicatie.

[Havoc]

Inderdaad!! Het is gewoon softwarematig redelijk wat ingewikkelder om multimaster te implementeren op RS-485 gezien er geen aparte RX- en TX-lijn is en dus niet kan verzenden en ontvangen tegelijkertijd.

Waarom zou er geen aparte TX en RX zijn? Of bedoel je dat multi-master moeilijker te implementeren is dan simpel zender -> ontvanger(s)? Dat eerste kan je oplossen door je hardware interface keuze, het tweede door protocol keuze.

Als je een multi-master wil doen en RS-485 gebruiken, dan kan je bvb elk element een tranceiver (transmitter en receiver) maken die je default in luisteren zet. Als een element de bus op wil dan moet hij:
- wachten tot er geen communicatie meer is
- zijn zender inschakelen
- communicatie starten en zelf luisteren
- als er een conflict is (2 zenders tegelijk) dan zender van de bus halen
- random tijd wachten en opnieuw proberen.

Dat is een basis ALOHA protocol. Een van de simpelere multi-masters. Je gaat andere protocollen vinden als CSMA/CD of CSMA/CA Carrier Sense Multiple Access/ Collision Detection/Avoidance. Carrier Sense is kijken of de kust veilig is, Multiple Access omdat er meerdere starters van data zijn en Collision Detection of Avoidance spreekt voor zich. Gebruikt in ethernet.

Andere methode is bvb Token Ring. Dat is kablage technisch moeilijker en ook meer cpu nodig. Je verbindt elk element met elkaar in 1 richting TX naar RX. Nu stuurt er 1 "master" een pakketje met een token. Die geeft aan of er data achter het token mag gezet worden en voor wie die bestemd is. Elke node krijgt nu op zijn beurt dat pakketje binnen. De node kijkt nu naar het token en als die vrij staat en de node niets te zeggen heeft wordt het pakketje gewoon doorgestuurd naar de volgende. Als de node wel iets te zeggen heeft kijkt die eerst of het token "vrij" staat. Als het token vrij is, zet die node het token op "bezet", voegt zijn data en bestemming toe en stuurt het naar de volgende. Als het token op "bezet" staat kijkt de node of de data voor hem is. Indien niet gewoon doorsturen, indien wel, data inlezen, token op "vrij" zetten en doorsturen.

Je kan het bekijken als een envelop die van hand to hand gaat. Als je iets te verzenden hebt steek je de brief erin en zet het adres erop. Doorgeven naar de volgende. Als het voor jou is haal je de brief eruit en verwijder je je adres, doorgeven.

Probleem hier is als 1 van je nodes down gaat alles stilvalt. Daarom zijn er uitbreidingen en hardware aanpassingen die dat omzeilen.

[MickeyMouse]

Klopt Havoc, maar denk dat het toch vooral RS-485 tweedraads is die meest wordt toegepast. Vandaar mijn verhaal...

Verder een perfecte uitleg van Havoc!!
Precies ook nog veel met babbelsoftware bezig geweest


Geert

[Havoc]

Neen, nooit met software, enkel met hardware. Maar die mannen van software geloven nooit dat de rommel die ze kribbelen niet werkt. Dus moet je goed weten wat er eigenlijk allemaal moet gebeuren om ze met hun neus op de feiten de duwen.

Hoeveel-draads je gebruikt hangt enkel af van wat je moet verbinden. Ik kan begrijpen dat in domotica je zo weinig mogelijk draad wil gebruiken. Als je 2 toestellen aan elkaar wil hangen is dat soms minder belangrijk. Kijk bvb eens naar een volledige RS-232 of RS-530. Voor wat ik zelf voor mijn treinen wil maken zal het SPI over RS-485 zijn: 1x klok en 1x bi-directionele data. Als ik ooit eens de tijd heb om eraan te beginnen... Ik vrees dat ik hier afscheid ga moeten nemen tot in september. Er moeten hier verbouwingen starten en er gaat geen tijd zijn om de pc op te zetten. En op het werk riskeer ik het me niet (het zijn daar niet de plezantste mannen om mee te werken. Vooral de vrouwen niet)

[PeterC]

... En op het werk riskeer ik het me niet (het zijn daar niet de plezantste mannen om mee te werken. Vooral de vrouwen niet)...

Volledig off-topic: leuke werksfeer...   

Wij hebben zo een gang die we spottend de 'Scenegang' noemen: als het de vrouwen weer eens wat teveel wordt of ze hebben hun moment-van-de-maand, worden daar wel eens luide en emotionele scenes opgevoerd...   

Terug on topic...

Al heel wat opgestoken uit dit draadje.  Mijn 'babbelsoftware' (en hardware) kennis is beperkt tot RS232 en I2C.

[Steam.N]

Ik volg dit ook met argusogen !!!
Ooit hoop ik hier de nodige informatie te verzamelen om een netwerkje op te zetten, waar elke node naar gelijk welke andere node berichtjes kan sturen ...

[conducteur]

Ik volg dit ook met argusogen !!!
Ooit hoop ik hier de nodige informatie te verzamelen om een netwerkje op te zetten, waar elke node naar gelijk welke andere node berichtjes kan sturen ...

Dat is wat ik ook wil doen eigenlijk. Noem het een soort 'eigen' loconet systeem.

[Havoc]

Als je van elke node naar elke node een boodschap wil kunnen sturen, dan zijn er verschillende mogelijkheden:
- 1 master die de toestand van het systeem overziet. De slaves zenden hun boodschap naar hem en de master zorgt dat de toestand "in orde komt". De slaves moeten dan niet onderling communiceren, enkel een status doorgeven. (dit is wat ik denk te doen, met als master een pc en "domme" slaves. Pc rekenpower is goedkoop, slave rekenpower is beperkt tot absoluut minimum)
- multi-master omgeving. Dan moet je eerst een adressering uitwerken (elke node moet een uniek adres krijgen) en moet je de berichten uitwerken. Ook ga je moeten weten of verschillende nodes enkel iets moeten doorgeven aan elkaar (bvb trein XYZ heeft nu mijn blok verlaten) of dat ze ook iets moeten kunnen vragen aan elkaar (bvb is er een trein in jouw blok?). Andere zaak om weten is of je met vaste berichten werkt of berichten met veranderlijke lengte (en inhoud). Ga je een checksum inbouwen of eerder met acknowledge werken?

Voor beide systemen kan je dan nog synchroon (een klok die samen met de data wordt gestuurd) of asynchroon werken (geen apart klok, klok wordt uit de data gehaald). Dan kan je nog werken met een globale klok (die van "ergens" komt), de klok die door de zender mee gestuurd wordt of de klok die door de ontvanger gestuurd wordt.
- ga je werken met aparte "controlelijnen"? Bij RS-232 heb je zeker CTS en RTS. Daar kan je een handshake mee opbouwen. RTS = Request To Send (mag ik iets verzenden?) en CTS = Clear To Send (OK om te verzenden). Ook RI = Ring Indicator (er komt een bericht binnen), CD = carrier detect (verbinding is klaar voor gebruik) etc. Je zou bvb een 2 signalen kunnen gebruiken. Een CTS en RTS die naar alle nodes gaan: RTS heeft een pull-up en alle nodes kunnen die laag maken om te vragen of ze iets mogen sturen. Die lijn is ook de CD want je moet eerst kijken of de lijn vrij is (anders krijg je een collision, zie hierboven). CTS heeft ook een pull-up, maar iedereen trekt die laag (met een open-collector) om aan te duiden dat het niet ok is om te zenden. Dus de zender ziet dat CD hoog is en trekt die laag om de anderen te laten weten dat hij iets wil zenden. De zender laat ook zijn CTS los. Als nu alle andere nodes hun CTS losgelaten hebben komt die hoog en kan het bericht beginnen. Als het gedaan is gaat RTS weer hoog. en iedereen trekt CTS weer laag.

Als er tijdens transmissie een node een probleem heeft kan die CTS terug laag trekken. Iedereen weet dan dat er een probleem is en men kan herbeginnen.

Redelijk simpel maar niet echt effcient. Maar je kan wel een hoop leren waar het fout kan gaan bij transmissie en hoe zoiets synchroniseren tussen verschillende nodes.

De rest gaat meestal vastliggen door wat je cpu ter beschikking stelt. Als je een gewone UART hebt, dan heb je zeker TX, RX en kan je asynchroon werken (RS-232 of RS-485 (eigenlijk gebruik je dan een deel van een RS-530A)). Als je een wat meer communicatiegerichte cpu hebt dan zijn synchrone interfaces ook mogelijk. Heb je SPI dan kan je de klok meesturen (moet eigenlijk).

[Havoc]

Oh ja, mensen die bvb een RaspberryPI gebruiken of zoiets kunnen gewoon ethernet gebruiken. Alles ingebouwd.

[MickeyMouse]

Als je van elke node naar elke node een boodschap wil kunnen sturen, dan zijn er verschillende mogelijkheden:
- 1 master die de toestand van het systeem overziet. De slaves zenden hun boodschap naar hem en de master zorgt dat de toestand "in orde komt". De slaves moeten dan niet onderling communiceren, enkel een status doorgeven. (dit is wat ik denk te doen, met als master een pc en "domme" slaves. Pc rekenpower is goedkoop, slave rekenpower is beperkt tot absoluut minimum)

Is ook wat wij in het geval van dat domoticasysteem deden, de modules waren idd domme slaves. Ze kregen van de master één voor één de nodige info (bvb toestand van leds, tekst op lcd, ...) en antwoorden terug met bvb welke toetsen waren ingedrukt, info van temp.sensor, ... Daarna was de volgende slave aan de beurt. De beslissingslogica zat in de master, wat steeds kon zorgen voor uitbreiding van de functionaliteit zonder de slaves te moeten upgraden.

Voor andere toepassingen werd het dan weer net wat anders gedaan.


Geert

[Havoc]

Dat systeem heeft zowel voor- als nadelen. Gelijk elk systeem natuurlijk.

+ de rekenkracht van het centraal systeem kan voorkomen dat de nodes onnodig krachtig moeten worden. Als je anders bvb de gehele status in elke node moet bijhouden of beslissingen moet nemen op basis van de inhoud van verschillende nodes dan zou je in sommige gevallen nogal krachtige nodes nodig hebben. Ook als je protocol robuust moet zijn ga je nogal veel aandacht eraan moeten besteden.
+ upgrade in rekenkracht is er enkel voor die ene centrale node, niet voor alle nodes.
- als die ene supernode het begeeft sta je daar... je creëert een single point of failure. Zonder die node werkt er niets. Dit maakt ook dat als je later iets wil veranderen werkt er niets zolang die supernode niet perfect werkt.

DCC is eigenlijk van dit soort: de centrale is een supernode, elke loc controller een node. Enkel gaat er maar data in 1 richting.

[MickeyMouse]

Neen, nooit met software, enkel met hardware. Maar die mannen van software geloven nooit dat de rommel die ze kribbelen niet werkt. Dus moet je goed weten wat er eigenlijk allemaal moet gebeuren om ze met hun neus op de feiten de duwen.

Ik zat het met het (luxe ?)probleem dat ik zowel de hw als de sw deed.
Kon dus enkel met mezelf overhoop liggen, wat dan ook wel eens gebeurde 

Geert

[MickeyMouse]

Dat systeem heeft zowel voor- als nadelen. Gelijk elk systeem natuurlijk.

+ de rekenkracht van het centraal systeem kan voorkomen dat de nodes onnodig krachtig moeten worden. Als je anders bvb de gehele status in elke node moet bijhouden of beslissingen moet nemen op basis van de inhoud van verschillende nodes dan zou je in sommige gevallen nogal krachtige nodes nodig hebben. Ook als je protocol robuust moet zijn ga je nogal veel aandacht eraan moeten besteden.
+ upgrade in rekenkracht is er enkel voor die ene centrale node, niet voor alle nodes.
- als die ene supernode het begeeft sta je daar... je creëert een single point of failure. Zonder die node werkt er niets. Dit maakt ook dat als je later iets wil veranderen werkt er niets zolang die supernode niet perfect werkt.

DCC is eigenlijk van dit soort: de centrale is een supernode, elke loc controller een node. Enkel gaat er maar data in 1 richting.

Klopt als een (485)bus!!   

Geert

[conducteur]

.....

Klopt als een (485)bus!!   

Geert

Vind ik leuk! +1


Het wordt hier zeer leerrijk!

[Havoc]

Heb je al iets bijgeleerd Rian, of zie je door het bos de bomen niet meer? Op tijd reageren voor we hier aan de punten-en-komma-n**kerij (*) beginnen

Zonder zever, stel maar gerust vragen hoor. Momenteel zit ik hier maar wat in het rond te schieten zonder doel. Is leuk als je een overzicht wil hebben maar niet echt constructief als dat je probleem niet is.

Ik zat het met het (luxe ?)probleem dat ik zowel de hw als de sw deed.
Kon dus enkel met mezelf overhoop liggen, wat dan ook wel eens gebeurde

Langs de ene kant een luxe want je kan zelf beslissen hoe je het probleem oplost. Maar als je enkel de hardware doet en je ziet dat jouw deel binnen spec zit en de software maakt er een zootje van maar jij moet het oplossen dan gaat er bij soms een en ander in het rood. Maar jij kan natuurlijk niemand de schuld geven en het over de haag gooien. Pech

(*) het zeven-lagen-model van OSI, store and forward, routing etc

[PeterC]

Niet als reclame bedoeld maar als je met seriële communicatie wil 'spelen' bestaat er goeie (lees betaalbare) tool: de Bus-Pirate van Dangerous Prototypes.  USB kabel erin en een terminalprogramma op je PC en volledige communicatie met je seriële bus (ook 'sniffen').

Al heel wat ontdekt op mijn experimentele I2C bus (ook al problemen mee opgelost).