seriële communicatie.

[Huugooke]

Die mogen gerust eens weten dat zij het niet uitgevonden hebben!

[MickeyMouse]

Ja mannen, dat begint hier op een meeting van de gepensioneerden te lijken, we gaan de jeugd nog op slecht ideën brengen

Wie weet

[Steam.N]

En ik blijf wat op mijn honger ...

Wat voor signalisatie moet je opzetten, om de "bus" te mogen nemen,, het bericht te sturen, te chechen of je geen collision voor hebt, enz ...

De structuur van berichten is een andere zaak, die ik kan uitwerken (source en destination adres, bericht type en lengte, enz), maar het "voorspel" ... dat is voor mij nog erg duister.
Voor mij s het d bedoeling dat gelijk welke node naar gelijk welk andere kan sturen, op de moment dat die dat noodzakelijk is.
Mogelijks krijgt een node een grotere verantwoordelijkheid, maar niet in de zin van een "netwerk master"

(Sorry om de nostalgische draad wat te doorbreken, maar het ging toch om "communicatie", hé  )

[Edit: typootje verbeterd]

[conducteur]

En ik blijf wat op mijn honger ...

Wat voor signalisatie moet je opzetten, om de "bus" te mogen nemen,, het bericht te sturen, te chechen of je geen collision voor hebt, enz ...

De structuur van berichten is een andere zaak, die ik kan uitwerken (source en destination adres, bericht type en lengte, enz), maar het "voorspel" ... dat is voor mij nog erg duiste.
Voor mij s het d bedoeling dat gelijk welke node naar gelijk welk andere kan sturen, op de moment dat die dat noodzakelijk is.
Mogelijks krijgt een node een grotere verantwoordelijkheid, maar niet in de zin van een "netwerk master"

(Sorry om de nostalgische draad wat te doorbreken, maar het ging toch om "communicatie", hé  )

Idem hier, ik ben nog altijd niet echt wijzer geworden welke code ik na de examen moet schrijven...

[Gerolf]

Voor mij is het de bedoeling dat gelijk welke node naar gelijk welk andere kan sturen, op de moment dat die dat noodzakelijk vindt. Mogelijks krijgt een node een grotere verantwoordelijkheid, maar niet in de zin van een "netwerk master"

Dan zijn er twee mogelijkheden:
- een web, waarbij elke node met elke (zinvolle) andere is verbonden (veel UART's)
- allemaal in een lijn / op dezelfde kabel, maar dan moet je toch een soort "master" hebben die de communicatie beheert.
     Als een "slave" iets aan een andere "slave" wil zeggen, moet hij daar ook toestemming voor krijgen.

[MickeyMouse]

Methode hangt een beetje van de hw-implementatie af, en of het rs232,rs485, i2c, ... is.
Met een uart, al dan niet ingebouwd in de controller, grofweg:
- bericht opbouwen in een array, starten met het adres van de bestemmeling, evt achteraan een checksum
- om versturen te starten: eerste karakter van de array in de tx-buffer zetten
- indien nodig een vlag (of commando) geven aan de uart om verzenden te starten
- indien er opnieuw plaats is in de tx-buffer komt een interrupt (toch als de hw zo gemaakt is)
- volgende karaketer in de tx-buffer plaatsen. Om te bepalen of alle karakters verzonden zijn kan met werken met een 'terminator' als laatste karakter en daar op controleren in de routine die het volgende karaketer in de buffer plaatst. Alternatief kan men ook het aantal te versturen karakters in het bercht plaatsen en daarop controleren.
Sommige uarts hebben slechts 1 plaats in de buffer, andere hebben er 4, 16 of meer.

Let wel, bovenstaande is zeer grof geschetst wat een mogelijke manier kan zijn. Alles hangt af van de hw, de gebruikte microcontroller, de uart, het soort communicatie, ...

Om te leren zou ik starten met communicatie op rs232 aan lage snelheid (is evt nog een beetje te volgen op een scoop). En dan best beginnen met enkel versturen in 1 richting van 'leesbare data' naar een terminal (kan een pc zijn).

Geert

[PeterC]

Voor mij is het de bedoeling dat gelijk welke node naar gelijk welk andere kan sturen, op de moment dat die dat noodzakelijk vindt. Mogelijks krijgt een node een grotere verantwoordelijkheid, maar niet in de zin van een "netwerk master"

Dan zijn er twee mogelijkheden:
- een web, waarbij elke node met elke (zinvolle) andere is verbonden (veel UART's)
- allemaal in een lijn / op dezelfde kabel, maar dan moet je toch een soort "master" hebben die de communicatie beheert.
     Als een "slave" iets aan een andere "slave" wil zeggen, moet hij daar ook toestemming voor krijgen.

Multi-Master.  Maar ik vraag me af of je slaves zo veel aan elkaar te vertellen hebben?  Het doet me een beetje denken aan een forum zonder moderator met als gevolg dat iedereen door elkaar en met elkaar praat maar dat er weinig zinvolle communicatie gebeurd en dat er ten slotte veel te veel communicatie is om een bepaald doel te bereiken...

Ik baseer me nu op I2C omdat ik daar enkele meters mee kan overbruggen, omdat ik dat protocol ken en dat het in veel controllers en programmeertalen ingebakken zit.  I2C heeft naast de data en de kloklijn ook nog de mogelijkheid om interruptlijnen te gebruiken.  Laat van de belangrijkste slaves een interruptlijn naar de master lopen.  Die master polt regelmatig die lijnen (of werkt interruptgestuurd) en als hij ziet dat een slave iets nuttig te zeggen heeft, neemt de master wel contact op met die slave (als het hem past).  Is dat bericht ook belangrijk voor andere slaves dan stuurt de master dat naar die slaves door.  In het bericht van de eerste slave kan zelfs staan naar welke andere slaves het bericht moet worden doorgestuurd.
Ook broadcast is in het protocol geïmplementeerd en Multi-Master is ook toegelaten (op het ene moment master, op het andere moment slave).  Gemengde spanningen in de communicatielijnen (een deel op 5V en een ander deel op 3V3) is met slechts twee Fet's op te lossen.
Ik heb de indruk dat I2C een tijdje op een laag pitje heeft gestaan, maar als ik kijk naar recente componenten zijn er toch veel bij met een I2C interface.

...Om te leren zou ik starten met communicatie op rs232 aan lage snelheid (is evt nog een beetje te volgen op een scoop). En dan best beginnen met enkel versturen in 1 richting van 'leesbare data' naar een terminal (kan een pc zijn)...

Dat is volgens mij de enige manier om je zaak op te bouwen, steeds je communicatie testen: eerst iedere node afzonderlijk tot die doet wat hij moet doen en dan tussen de nodes onderling.
RS232 is hierbij het eenvoudigste omdat dat op iedere PC mogelijk is (eventueel via een USB omzetter) en terminalprogrramma's zijn er in overvloed.  Voor andere protocollen zijn er ook interfaces die via een RS232 interface kunnen werken en kunnen communiceren met een terminal.

[Havoc]

Wat voor signalisatie moet je opzetten, om de "bus" te mogen nemen,, het bericht te sturen, te chechen of je geen collision voor hebt, enz ...

De structuur van berichten is een andere zaak, die ik kan uitwerken (source en destination adres, bericht type en lengte, enz), maar het "voorspel" ... dat is voor mij nog erg duister.
Voor mij s het d bedoeling dat gelijk welke node naar gelijk welk andere kan sturen, op de moment dat die dat noodzakelijk is.
Mogelijks krijgt een node een grotere verantwoordelijkheid, maar niet in de zin van een "netwerk master"

Hangt een beetje af van hoe snel het moet gaan, hoeveel er te versturen is en wat je hardware allemaal ter beschikking heeft. Voor i2c heeft Peter hier al een idee gegeven.

Als je een uart gebruikt op de eenvoudigste manier (punt-tot-punt) met rx verbonden aan tx in elke richting dan hoef je niet veel te doen. De zender vult de buffer en zegt de uart van de boel op te sturen. De ontvanger krijgt dit in zijn buffer geschoven door de uart en die geeft een interrupt aan de processor. Of het allemaal zonder fouten verloopt en of je cpu kan volgen en op tijd de buffer leegmaken is aan de intelligente programmeur om uit te vissen. Vandaar dat je een pakketje met wat extra info en checksum en zo gaat meesturen zodat de ontvanger kan nakijken of alles er is en eventueel retransmissie vragen.

RS-232 heeft buiten RX en TX nog een heel aantal controle lijnen. Niet iedere processor heeft die beschikbaar maar meestal zijn CTS en RTS wel beschikbaar. CTS staat voor Clear To Send en RTS voor Request To Send. Als je die met een input aan de andere kant verbindt dan kan je flow-control doen. Wie iets wil zeggen steekt zijn vinger op: maakt RTS aktief en wacht tot hij iets mag zeggen: de andere maakt CTS aktief. Dan stuur je alles over en maakt de lijnen weer niet-aktief. RTS kan je ook gebruiken om bij RS-485 de ontvanger om te schakelen naar zenden.

[Steam.N]

Peter, Johan, bedankt voor de info.

Stel inderdaad dat ik RTS en CTS zou gebruiken (en ik denk nog altijd "zonder master", kwestie van moeilijk te doen):
Een node wil iets sturen, en set RTS actief: wié set dan de CTS (of is dat net wat de master zou doen?)?
Of zet de node pas RTS actief op een moment dat CTS actief is?

Scenario kan zijn:
- CTS is actief
- dus kan node RTS actief maken
- na X ms, als CTS nog steeds actief is, wordt bericht verstuurd
  (indien tijdens Xms een andere node beslist voorrang te hebben, zet die CTS inactief, zodanig dat de eerste aanvrager geblokt wordt?

Indien CTS inactief is, mag niemand RTS actief maken

Ik vermoed dat ook bij gebruik van RTS en CTS lijnen, een clock-signaal nodig is, zodanig dat iedereen op de maat zit?

Schiet maar als ik hier absurditeiten vertel, of aspecten over het hoofd gezien zijn.
Waarschijnlijk vind ik het warm water terug uit, maar nergens heb ik tot nu toe beschrijvingen gevonden van dit niveau van communicatieprotocols.

[Havoc]

Ik heb hier al eens zo'n scenario uit de doeken gedaan. Kort opnieuw:
- 2 nodes, elk met RTS en CTS (RTS1,CTS1 en RTS2,CTS2) en een ingang waarop ze RTS en CTS bekijken
- RTS1/2 en CTS1/2 zijn op een ogenblik niet aktief.
- node1 wil zenden zet RTS1 aktief
- node2 pollt RTS1 op een ingang (of irq gestuurd)
- node2 ziet dat RTS1 aktief is en doet verder tot hij tijd heeft en zet dan CTS2 aktief
- node1 wacht ondertussen (of doet andere nuttige dingen) totdat hij ziet dat CTS2 aktief is.
- beide nodes weten nu dat ze alle 2 klaar zijn om data te sturen. Hoe dat verder gaat hangt dan weer af van hoe je dat afgesproken hebt.

Afhankelijk van hoe je hardware werkt kan je rts en cts kruisen. Sommige processoren laten toe van ingangen tegelijk als uitgang te gebruiken en toch de waarde op de pin te lezen. Als je dan over open collector uitgangen beschikt kan je functies combineren. Maar dat is zo specifiek dat je daar niet op een algemene manier kan dieper op ingaan.

Je kan ook een scenario uitwerken waarin cts aktief de rusttoestand is. Dat kan bvb als de node die moet ontvangen weinig anders te doen heeft dan te wachten tot er nieuwe data binnenkomt, zoals een wisselsturing. Een mogelijkheid is dan bvb:
- cts1 aktief, node1 wacht op nieuwe data
- rts2 is niet aktief, node2 is bezig nieuwe data te "maken"
- node2 heeft nieuwe data klaar, check of cts1 aktief is, indien ja dan maakt hij rts2 aktief
- node1 ziet rts2 aktief worden en neemt nieuwe data binnen
- node1 zet cts1 niet aktief terwijl hij de data verwerkt, node2 zet rts2 terug niet aktief als bevestiging
- als node1 gedaan heeft zet hij cts1 terug aktief

Nadeel hier is dat je bvb node1 niet in slaap kan zetten omdat hij al aangegeven heeft klaar te zijn om data te ontvangen. Als alle signalen vanuit een niet aktief toestand vertrekken kan je dat gebruiken om "wakker" te worden.

Op de manier dat het hierboven staat zijn op het moment van communicatie beide processoren ook met niks anders bezig dan datacom. Dat kan natuurlijk ook niet altijd. Je gaat dat moeten inpassen, of als interrupts uitwerken. Veel gaat ook afhangen van je hardware. Als je uart cts en rts ondersteund, dan gaat de afhandeling grotendeels gebeuren zonder dat je processor zich er iets moet van aantrekken. Enkel de buffer leegmaken als de uart zegt dat er iets instaat.

Voor rts en cts zijn geen kloklijnen nodig. Dit komt allemaal uit de wereld van RS-232 en in zijn eenvoudigste vorm is dat asynchrone communicatie. De data kan soms een klok gebruiken maar de stuur signalen nooit.

[Havoc]

Ik heb hier snel eens in enkele boeken gekeken maar zoiets vind ik inderdaad niet direct terug.

[Steam.N]

Begrijp ik het correct dat UARTs "zelfstandig", zonder belasting van de mC, de communicatie verzorgen, en dat je alleen moet zorgen voor aanvoer en uitlezen van data?
Geen zorgen om RTS, CTS, parity bits, enz?

Maar de UART verzorgt communicatie slechts tussen twee vaste nodes, en je doet dan geen broadcasting ?
Communicatie tussen een nest nodes: elke node stuurt naar master, en master stuurt naar bestemmeling?

[Gerolf]

Ik zou eens in Wickipedia of iets dergelijks snuffelen naar RS232 en RS485 protocols, en meteen ook naar I2C, 1-wire, ...

[Klaas Zondervan]

Ik zou eens in Wickipedia of iets dergelijks snuffelen naar RS232 en RS485 protocols, ...

RS232 en RS485 beschrijven geen protocollen.
RS232 beschrijft de elektrische eigenschappen van het signaal, de te gebruiken stekkerverbinding en de functie van elke pin in die stekkers.
RS485 is nog magerder, die beschrijft alleen de elektrische eigenschappen op de verbindingslijn.

[Havoc]

Begrijp ik het correct dat UARTs "zelfstandig", zonder belasting van de mC, de communicatie verzorgen, en dat je alleen moet zorgen voor aanvoer en uitlezen van data?
Geen zorgen om RTS, CTS, parity bits, enz?

Hangt af van de processor, maar meestal is dat de bedoeling van een uart. Je moet waarschijnlijk wel eerst een aantal instellingen doen maar normaliter verloopt het dan redelijk automatisch.

Verder moet je zelf een protocol "uitvinden" of een bestaand protocol implementeren (of aanpassen aan je hardware/behoeften). Een eerste plaats om te gaan kijken lijkt me de documentatie van de microcontroller die je wil gebruiken. Vaak hebben fabrikanten voorbeeld software voor zoiets. Maar het hangt af va de fabrikant en chip uiteraard.

Maar de UART verzorgt communicatie slechts tussen twee vaste nodes, en je doet dan geen broadcasting ?
Communicatie tussen een nest nodes: elke node stuurt naar master, en master stuurt naar bestemmeling?

Een UART op zich doet niet meer dan een aantal controle signalen zetten (als zo geprogrameerd) en vervolgens zijn buffer buiten shiften. Eventueel worden controle karakters of start-stop bits of parity toegevoegd. In de omgekeerde richting neemt hij logische (ttl, cmos, lvds,etc) signalen binnen, interpreteert die volgens zijn programatie (als start, stop, parity etc), plaatst het resultaat in een buffer (samen met eventueel flags of de communicatie correct verlopen is, of parity correct is) en zegt (met interrupt of flag) dat er data is. Een uart handelt een deel van je communicatie af, niet alles. Je moet echt lezen wat de processor die jij gekozen hebt kan.

Of je node master of slave is, of het een master-multi-slave of multi-master netwerk is, daar heeft de UART totaal geen weet van. Dat is aan de applicatie om dat te organiseren. De uart weet ook niet of het transport verder gaat via rs-232, RS-485, TTL, IRDA of nog iets anders.

Je voorstel om alle nodes naar een master te laten sturen en die te laten verder sturen is een optie. Maar dat veronderstelt dat een node een transmissie kan starten of ten minste aanvragen. Dus eigenlijk is het al een beetje een master.

RS232 en RS485 beschrijven geen protocollen.
RS232 beschrijft de elektrische eigenschappen van het signaal, de te gebruiken stekkerverbinding en de functie van elke pin in die stekkers.
RS485 is nog magerder, die beschrijft alleen de elektrische eigenschappen op de verbindingslijn.

Absoluut gelijk heb je Klaas. Enkel zijn er weinig zaken te vinden op het net waar dat onderscheid gemaakt wordt.