Projectje voor na de examens, samen met afwerken van de voeding en verder werken aan realisatie van mijn GIP.
(realisatie moest niet af zijn omdat IW een theoretische richting is en enkel het dossier van belang is, heb dat de laatste maand op een wat lager pitje gezet om de theorie af te werken).
Ik zou willen wat experimenteren met seriële communicatie via µC (i²c en RS-485)
Wat ik ondertussen begrepen heb is dat I²c vooral plaatselijk is bv tussen twee µC, of Ic's op een pcb onderling en erg gevoelig is voor storing bij lange afstanden.
RS-485 zou daar minder last van hebben.
Heeft iemand meer (complete) info over deze standaarden?
Ik heb vroeger (12 jaar geleden) heel veel met het I²C protocol gewerkt en dingen ontwikkeld. I²C leent zich zeer goede voor eenvoudige communicatie tussen verschillende devices en dat hoeven niet noodzakelijk enkel ICs te zijn. De allereerste CD speler gebruiken dit protocol intern om alle onderdelen aan te sturen. Later zag je dit protocol meer en meer opduiken. Het werkt met 2 draden (klok en data). Een device is de master en genereert het klok signaal. Master en slaves kunnen verzenden en ontvangen; slaves kunnen alleen verzenden op verzoek van de master.
Met RS-485 heb ik minder ervaring, ik weet wel dat hiermee grotere afstanden overbrugd kunnen worden (lengte (m) x frequentie (Hz) < 10^8). Het verschil is dat er geen klok is en dat tijdens communicatie beide lijnen een tegengestelde spanning hebben.
Grote verschil is dat I2C niet enkel een electrische standaard is maar tevens een communicatie protocol beschrijft. RS-485 is enkel een electrische standaard en beschrijft geen protocol.
I2C is inderdaad eerder voor "kleine" afstanden. Typisch tussen IC's op dezelfde print. Snelheid is enkele Mbps. Er wordt gebruik gemaakt van een bi-directionele datalijn, een kloklijn en GND. De data en klok lijn hebben een pull-up. Omdat de stijgende flank van de pulsen dus enkel door die pull-up wordt bepaald beperkt dit de lengte en snelheid. Vandaar dat het weinig gebruikt wordt om buiten een toestel te gaan.
Bus is multimaster, dus er kunnen verschillende chips of dezelfde bus een communicatie starten. Het protocol beschrijft dan ook hoe communicatie starten, stoppen en hoe bepalen welke master er eerst op de bus mag als er veschillende tegelijk beginnen. Er zijn 7-bit adressen dus 128 elementen op een bus mogelijk. Maar de meeste chips hebben maar een beperkt aantal van de adresbits die je met bvb weerstanden kan instellen.
Zelf heb ik al verschillende keren ervaren dat I2C problemen geeft als je het gebruikt tussen verschillende printen of naar buiten een toestel brengt. Meestal loopt het fout bij de emc testen (en later typisch als er lampen aan en uit gaan). Wat er meestal gebeurt is dat een van de leden op de bus niet gezien heeft dat de transmissie gestart is of afgelopen en dan gewoon blijft hangen. Totdat de watchdog of wetware ingrijpt en de boel reset.
De standaard kan je hier vinden: www.nxp.com/documents/other/39340011.pdf (http://www.nxp.com/documents/other/39340011.pdf) Niet nagekeken of dat de laatste versie is.
RS-485 is enkel een electrische interface er is niets dat zegt hoe je daar data mee moet oversturen. Het is een verbetering van RS-422. Het is een electrisch signaal dat van een zender naar een of meerdere ontvanger(s) gaat. Hoeveel ontvangers hangt af van welke belasting de ontvangers op de bus hebben. De standaard ontvanger heeft 1 load en dan kunnen er 32 ontvangers op de bus. Er zijn echter nieuwere chips en die kunnen 1/2, 1/4 of 1/8 loead zijn. Dan kunnen er resp 64, 128 of 256 ontvangers op 1 bus.
De bus werkt met symmetrische spanning maar niet gebalanceerd!!!. Er zijn 2 uitgangen (A en B genoemd) die steeds een tegenovergesteld niveau hebben. Als de ene hoog is, is de andere laag en omgekeerd. Er is dus om goed te zijn steeds een GND verbinding nodig tussen de elementen op de bus. De ontvanger heeft echter met een verschil van 200mV genoeg om te weten of het 1 (A>B) of 0 (B>A) is. De zender stuurt echter steeds minstens 1.5V verschil uit. Er zijn dus heel lange verbindingen mogelijk. Omdat de snelheid ook hoog kan zijn (tot 40Mbps) is een impedantie gekontroleerde bus noodzakelijk. Dit is normaliter 120 Ohm (perfect voor ethernet kabel) en beide einden moeten getermineerd zijn. In goede omstandigheden is tot 1km kabel mogelijk maar dan heb je maar 100kbps meer.
Omdat RS-485 geen protocol is moet je zelf je datacommunicatie organiseren. Protocollen die van RS-485 gebruik maken zijn bvb Modbus, Profinet, IEC958
Een goed werkje: http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slla070&track=no (http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slla070&track=no) en www.ti.com/lit/an/slla272b/slla272b.pdf (http://www.ti.com/lit/an/slla272b/slla272b.pdf)
Met al die microcontrollers de laatste tijd - misschien moeten we een aparte rubriek opstarten?
Een nieuw board?
-rubrieken daarin:
-elektronica
-µC
-elektriciteit
-....
I2C en RS-485 zijn niet enkel nuttig voor microcontrollers. Misschien moeten we eerder de naam van dit draadje veranderen in "Elektronica en KISS" en de microcontrollers naar hier halen. Lijkt me trouwens ook eerder waar je het zou zoeken.
Ik vrees dat KISS zo goed als dood is? Of niet?
KISS is wat mij betreft nog lang niet dood ??? Lang leve de `eenvoudige`elektriekerij :D
Gerolf, Rian en Johan hebben wel een punt met de idee om over microcontrollers een nieuwe rubriek te starten 8)
Dan mogen zeker draadjes rond verschillende communicatie-types en protocols niet ontbreken !
Citaat van: conducteur op 30 mei 2013, 21:03:53 PM
...realisatie moest niet af zijn omdat IW een theoretische richting is en enkel het dossier van belang is...
Rian, al een idee voor volgend schooljaar?
[Edit] ondertussen volop met I2C bezig voor een project(je)...
Elektronica in Oostende, starten met professionele bachelor, daarna plan ik om nog een schakeljaar te doen, en een masterjaar in de elektronica als ik het nog zie zitten.
Citaat van: conducteur op 31 mei 2013, 20:16:11 PM
Elektronica in Oostende, starten met professionele bachelor, daarna plan ik om nog een schakeljaar te doen, en een masterjaar in de elektronica als ik het nog zie zitten.
Over hoeveel jaren spreek je dan? Ik ben al lang niet meer mee met de tegenwoordige opleidingen...
In elk geval veel succes!
CiteerKISS is wat mij betreft nog lang niet dood Lang leve de `eenvoudige`elektriekerij
Ik heb het over KISS als een rubriek in MSM. Geen idee wat het ooit moest worden maar het begin leek veelbelovend. Spijtig genoeg ergens blijven steken. (ik begrijp het heus wel)
Het gaat me er een beetje over dat het KISS gebeuren doorgaat mede ivm modelspoorders welke dat idee aanspreekt, Johan.
Er zullen altijd modelspoorders zijn, die bezig zijn met goed uitgewerkte scenery etc. welke gebruik maken van zeer geavanceerde technieken maar problemen hebben met eenvoudige electronica.
Kijk eens op vooraanstaande fora aan de andere kant van de grote plas...Schitterend voorbeeld `niet zo ver weg, u moet wel even met de boot...'is het Pendon museum. High St, Long Wittenham, Abingdon OX14 4QD
Er zijn er ook welke nog altijd staalkabeltjes gebruiken om wissels om te zetten......Daarbij,
Het KISS idee komt uiteindelijk voort uit het MSM, en bij de gratie van MSM bestaat dit forum!
Hoewel het allemaal mijn belangstelling heeft, gaat het toch om modelbouw. De mate waarin men electronica wil gebruiken en de manier waarop is voor iedereen verschillend zo lijkt mij.
Vandaar mijn gedachte ;)
Citaat van: PeterC op 31 mei 2013, 20:18:55 PM
Citaat van: conducteur op 31 mei 2013, 20:16:11 PM
Elektronica in Oostende, starten met professionele bachelor, daarna plan ik om nog een schakeljaar te doen, en een masterjaar in de elektronica als ik het nog zie zitten.
Over hoeveel jaren spreek je dan? Ik ben al lang niet meer mee met de tegenwoordige opleidingen...
In elk geval veel succes!
In een notendop:
Professionele bachelor (3j) = graduaat van vroeger
Academische bach (3j) + master (1j) = ing van vroeger
Prof bach (3j) + schakeljaar (1j) + Master (1j) = graduaat die schakeljaar doet en zo ing wordt
Rian, waarom ga je niet direct voor ing als je toch IW gedaan hebt ? Je hebt alleszinds een geweldige interesse in elektronica en je bent bijzonder goed bezig.
Zelf heb ik ook in Oostende gestudeerd voor ing, wel EM. Eerste drie semesters waren algemeen voor iedereen (bouw, em, eo, ...) en deze vond ik persoonlijk ook het minst interessant, maar vanaf dat we een studierichting gekozen hadden viel het wel mee. Indien je graduaat eo met schakeljaar doet heb je wel het voordeel dat je een paar buisvakken kan overslaan die je bij ing eo anders wel hebt in het derde semester (sterkteleer, thermodynamica en fluïdummech). Indien je graduaat eo doet met schakeljaar sla je deze over wat bij sommigen eerder als oneerlijk overkwam...
Bovenstaande was alleszinds zo toen ik er zat (2006-2010), ik weet niet of er tot nu toe al veel veranderd is.
Weet je eigenlijk hoelang ze eigenlijk nog in Oostende blijven ? Toen ik in mijn eerste jaar zat in 2006 zeiden ze dat ze vanaf 2008 in Brugge zouden zitten ;D :o
Voila, topic is verplaatst naar een nieuwe specifieke microcontroller-rubriek
Ik dacht dat ik al geantwoord heb, maar moet bij ongeluk vergeten hebben om op 'verzenden' te duwen. Dus nog één keer
Waarom ik geen acad. bachelor doe vragen ze mij ook altijd op infodagen op hogescholen als ik info vraag voor prof. bachelor.
Ik doe een prof. bachelor voor een aantal redenen
-Op aanraden van school, blijkbaar zijn er weinig iw'ers die direct slagen.
-Prof. bachelor is meer elektronica-gericht: geen chemie en andere vakken die mij veel minder interesseren...
-Ik denk dat het voor mij beter is om niet direct met het moeilijkste te starten, maar dan liever een jaartje meer te doen
-In Oostende zijn de grote meerderheid van de masters in elektronica... zij die een schakeljaar gedaan hebben en via professionele dat bereikt hebben.
En nu terug naar i²c, rs485, can, ....
Citaat van: conducteur op 01 juni 2013, 10:14:46 AM
...
-Prof. bachelor is meer elektronica-gericht: geen chemie en andere vakken die mij veel minder interesseren...
Klopt als een bus, maar de wiskunde, chemie, fysica ed geven een serieus grotere basis waar je wel eens (onrechtstreeks) kunt mee te maken krijgen. En ja, dit zijn ook wel de vakken die het wat moeilijker maken, maar dit is enkel in de eerste 2 jaren, als dit nog is als voeger...
Geert
Citaat van: Havoc op 30 mei 2013, 21:50:12 PM
...
RS-485 is enkel een electrische interface er is niets dat zegt hoe je daar data mee moet oversturen. Het is een verbetering van RS-422. Het is een electrisch signaal dat van een zender naar een of meerdere ontvanger(s) gaat. Hoeveel ontvangers hangt af van welke belasting de ontvangers op de bus hebben. De standaard ontvanger heeft 1 load en dan kunnen er 32 ontvangers op de bus. Er zijn echter nieuwere chips en die kunnen 1/2, 1/4 of 1/8 loead zijn. Dan kunnen er resp 64, 128 of 256 ontvangers op 1 bus.
De bus werkt met symmetrische spanning maar niet gebalanceerd!!!. Er zijn 2 uitgangen (A en B genoemd) die steeds een tegenovergesteld niveau hebben. Als de ene hoog is, is de andere laag en omgekeerd. Er is dus om goed te zijn steeds een GND verbinding nodig tussen de elementen op de bus. De ontvanger heeft echter met een verschil van 200mV genoeg om te weten of het 1 (A>B) of 0 (B>A) is. De zender stuurt echter steeds minstens 1.5V verschil uit. Er zijn dus heel lange verbindingen mogelijk. Omdat de snelheid ook hoog kan zijn (tot 40Mbps) is een impedantie gekontroleerde bus noodzakelijk. Dit is normaliter 120 Ohm (perfect voor ethernet kabel) en beide einden moeten getermineerd zijn. In goede omstandigheden is tot 1km kabel mogelijk maar dan heb je maar 100kbps meer.
...
In mijn electronica-verleden ooit nog eens een domoticasysteem ontwikkeld voor een klant (hw, firmware & pc-sw) met een 8051-afgeleide controller.
Communicatie gebeurde via RS-485 met 256 ontvangers op de bus aan een snelheid van 345kb/s.
Op die snelheid hebben we testen gedaan en we raakten makkelijk 4km ver, wel met goede twisted pair kabel. In praktijk werd een limiet van 1km aangeraden door ons.
Door de symmetrische spanning en de twisted pair kabel is RS-485 redelijk bestand door storingen van buitenaf...
Nadeel aan RS-485 is dat je best niet in ster werkt maar doorlust,
Geert
Ik kan Geert enkel gelijk geven: die vakken zijn misschien minder aantrekkelijk en moeilijk maar wat je er later uithaalt is niet te onderschatten. Als je in de elektronica zit krijg je zeker te maken met chemie (corrosie, compatibiliteit van materialen), sterkteleer (je gaat die dingen moeten inbouwen), fysica (elke grootheid die je wil meten) etc. En wat nog veel erger is: klanten die in die vakgebieden bezig zijn. Op dat moment kunnen meepraten, op zijn minst elementair begrijpen waar het over gaat is echt waardevol.
Ik ben zelf vanuit de natuurkunde bij elektronica terechtgekomen. Klanten apprecieren het als ze niet eerst een dag je moeten uitleggen wat hun toestel nu eigenlijk doet/meet/moet besturen. Of als je vanuit zo'n standpunt een probleem kan zien aankomen. Trek je niet teveel aan van "men zegt dat er niet veel slagen". Toen ik vroeg of het niet beter was om eerst een extra jaar voorbereidende wiskunde te gaan volgen voor ik naar natuurkunde ging heb ik 2x het antwoord gekregen dat de beste voorbereiding op het eerste jaar natuurkunde het eerste jaar natuurkunde was. Ik heb ze gelijk moeten geven...
En die sterkteleer kan je echt wel gebruiken! Kan je berekenen hoeveel hout en staal je onder je baan moet steken om te voorkomen dat ze meer dan 0.58mm doorbuigt als jij er op gaat staan met een boormachine in de hand :D
Heb je nog vragen over i2c or rs-485?
Zelfde mening !
Je bouwt nú je kennis-basis op.
En er zijn er al zó velen, die in die "moeilijke" vakken geslaagd zijn.
Waarom zou het bij jou niet lukken, als je je er voor inzet ?
Kunnen we nu verder gaan over seriële communicatie technieken?
Wat ik al bijgeleerd heb.
Bij I²C heb je dus twee datalijnen, die hoog gehouden worden door twee pull-up weerstanden. Hierdoor is de communicatieafstand vrij 'beperkt'. Hier is de communicatie ook strikt geregeld. Johan had in reactie 2 een link geplaatst maar die blijkt dood te zijn. Data verzenden begint en eindigt met een start- en stopbit. Na elke verzonden byte zend de ontvanger een soort bevestiging.
RS 485 werkt ook met twee draden, waarbij het signaal op de ene draad het inverse is van de andere. Lange afstanden overbruggen is geen probleem. De communicatie moet je min of meer zelf 'uitvissen'. Er bestaan wel 'protocollen' die van rs-485 gebruik maken.
Het grootse probleem is dat dit nog geen programma oplevert....
Je hebt gelijk ivm die link. http://www.google.com/url?sa=t&rct=j&q=i2c+standard&source=web&cd=1&ved=0CCwQFjAA&url=http%3A%2F%2Fwww.nxp.com%2Fdocuments%2Fother%2F39340011.pdf&ei=QniqUY7JMYHsO67_gbAK&usg=AFQjCNEuAwuGNjurPtsdvjIdq3OlNQMI7A (http://www.google.com/url?sa=t&rct=j&q=i2c+standard&source=web&cd=1&ved=0CCwQFjAA&url=http%3A%2F%2Fwww.nxp.com%2Fdocuments%2Fother%2F39340011.pdf&ei=QniqUY7JMYHsO67_gbAK&usg=AFQjCNEuAwuGNjurPtsdvjIdq3OlNQMI7A) zou moeten werken. Sorry, ik had ze niet getest.
CiteerRS 485 werkt ook met twee draden, waarbij het signaal op de ene draad het inverse is van de andere.
Dat is niet echt correct. Elke verbinding van RS-232 gebruikt 2 draden. Dus als je een protocol uitdenkt dat bvb clock en data nodig heeft, dan heb je bij RS-485 VIER draden nodig. Twee voor klok en twee voor data. Eigenlijk vijf draden want je hebt ook nog massa nodig. Een voorbeeld is als je SPI wil gebruiken over lange afstand en daarvoor RS-485 gebruikt. Dan heb je eigenlijk 7 draden nodig: 2x klok, 2x MOSI, 2s MISO en GND.
Je kan zonder problemen een UART uitgang met RS-485 verbinden ipv RS-232. Als je de eenvoudigste versie zonder klok en handshake gebruikt heb je enkel RX en TX. Dan zet je RX en TX om naar RS-485 signalen ipv RS-232 signalen en je kan honderden meters ver gaan ipv enkele tientallen meters.
CiteerHet grootse probleem is dat dit nog geen programma oplevert....
Inderdaad...
Je doelt met het verschil tussen 485 en 232 op signaalniveaus, vermoed ik.
Ik dacht dat RS485 bedoeld was om met meer dan twee te communiceren (één master, verschillende slaves),
en dat je met RS232 alleen tussen twee entiteiten communiceert.
Die IPS in je vorige post, bedoel je daar ISP mee?
Elke module in RS 485 kan data zenden en ontvangen;
Citaat van: conducteur op 02 juni 2013, 09:46:38 AM
Elke module in RS 485 kan data zenden en ontvangen;
Ja, natuurlijk. "slave" wil niet zeggen "alleen luisteren", maar: spreken als je mag van de "master" ;)
Voor zover ik me herinner gaat de master het rijtje slaves af, vraagt of ze iets te zeggen hebben, en geeft dan eventueel toestemming.
Citaat van: Gerolf op 02 juni 2013, 10:02:39 AM
Citaat van: conducteur op 02 juni 2013, 09:46:38 AM
Elke module in RS 485 kan data zenden en ontvangen;
Ja, natuurlijk. "slave" wil niet zeggen "alleen luisteren", maar: spreken als je mag van de "master" ;)
Voor zover ik me herinner gaat de master het rijtje slaves af, vraagt of ze iets te zeggen hebben, en geeft dan eventueel toestemming.
Je bent goed thuis in dergelijke zaken, Gerolf... ::)
;D ;D Ieder zijn hobby ;D :-X
CiteerVoor zover ik me herinner gaat de master het rijtje slaves af, vraagt of ze iets te zeggen hebben, en geeft dan eventueel toestemming.
Dat heeft strikt gezien niets met RS-485 te maken. RS-485 beschrijft enkel het signaal niveau, de manier van de bus organiseren etc. Hoe data gecommuniceerd wordt tussen de verschillende elementen (het protocol) daar zegt RS-485 niets over. Ook niet welke connectoren je moet gebruiken bvb.
Wat Gerolf beschrijft is een systeem master-slave met polling: er is een master die vraagt (polt) of er iemand iets te zeggen heeft, dan beslist de master wie er iets te zeggen heeft, en de master laat dan de slave zijn data sturen (of haalt ze zelf op). Modbus bvb werkt zo.
CiteerElke module in RS 485 kan data zenden en ontvangen;
Dat kan, maar dat hoeft niet. Het is perfect mogelijk om gewoon 1 zender te hebben en verschillende ontvangers die nooit iets terugsturen. Bvb denk aan een nummerdisplay bij de beenhouwer. Een centrale cpu die alles regelt en enkele domme displays die gewoon een nieuw nummer binnenkrijgen.
RS-485 zegt ook niets of het enkel master-slave is, multi-master, of de lijnen bi-directioneel zijn of niet. Het is enkel hoe electrisch een en ander werkt en hoe het moet werken om compatibel te zijn. Electrisch compatibel, want als je een Modbus toestel op een Profibus hangt dan is dat electrisch misschien in orde maar van datacommunicatie gaat er niet veel in huis komen.
CiteerDie IPS in je vorige post, bedoel je daar ISP mee?
Ik zie nergens IPS of ISP staan, enkel SPI. SPI is een eenvoudig protocol dat net als I2C gebruikt wordt voor communicatie tussen chips. Tegenwoordig iets minder maar het wordt nog wel gebruikt als het sneller dan I2C moet gaan. Een toepassing is bvb configuratie eeproms en DAC/ADC. Dan kan je tot 80MHz en hogere klok gebruiken.
Bij SPI is er steeds 1 master. De master controleert de klok en chip select. Als een slave geselecteerd wordt, dan klokt de master de data naar buiten op de MOSI lijn (master-out, slave-in) en tegelijk klokt de slave zijn data buiten op MISO (master-in, slave-out). Er is een variant waarbij er maar 1 datalijn is waarove eerste de master zijn data stuurt en daarna de slave zijn stuk. Als er maar in 1 richting data moet gaan en er is niet echt behoefte aan een protocol, een simpel shift register is dan genoeg.
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.
Men moet dan minstens de zelf uitgestuurde data controleren of je die zelf terug correct ontvangt, zoniet wil het zeggen dat een andere module ook net was beginnen zenden. Beiden moeten dan een random tijd van de bus gaan en opnieuw proberen.
In single master is dit heel wat simpeler: een module antwoord pas op vraag van de master, wat niet wil zeggen dat niet eender welke module 'vragen' kan stellen aan eender welke andere module, de master moet dan iedere module, via een commando, iedere module even toelating geven om iets op de bus te gooien.
Hangt er van af wat je nodig hebt natuurlijk...
Eerste wat je best maakt als je met 485 begint is wat wij vroeger 'de luistervink' noemden. Dit is een module die luistert naar alle andere modules maar nooit zelf zend. De data die deze module ziet kun je dan zichtbaar maken op eoa terminal. Ideaal om te zien welk gebabbel er allemaal op de bus gebeurd...;D
Geert
Citaat van: MickeyMouse op 02 juni 2013, 14:47:01 PM
Men moet dan minstens de zelf uitgestuurde data controleren of je die zelf terug correct ontvangt, zoniet wil het zeggen dat een andere module ook net was beginnen zenden. Beiden moeten dan een random tijd van de bus gaan en opnieuw proberen.
Dat is precies de werkwijze van Loconet.
CiteerInderdaad!! 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.
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 ;D
Geert
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)
Citaat van: Havoc op 02 juni 2013, 18:49:41 PM
... 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... :o :o :o
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... 8) 8) 8)
Terug on topic...
Al heel wat opgestoken uit dit draadje. Mijn 'babbelsoftware' (en hardware) kennis is beperkt tot RS232 en I2C.
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 ...
Citaat van: Steam.N op 02 juni 2013, 19:31:43 PM
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.
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).
Oh ja, mensen die bvb een RaspberryPI gebruiken of zoiets kunnen gewoon ethernet gebruiken. Alles ingebouwd.
Citaat van: Havoc op 02 juni 2013, 20:44:48 PM
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
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.
Citaat van: Havoc op 02 juni 2013, 18:49:41 PM
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
Citaat van: Havoc op 02 juni 2013, 21:06:16 PM
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!! ;D ;D
Geert
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 :D
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.
CiteerIk 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 :D
(*) het zeven-lagen-model van OSI, store and forward, routing etc
Niet als reclame bedoeld maar als je met seriële communicatie wil 'spelen' bestaat er goeie (lees betaalbare) tool: de Bus-Pirate (http://dangerousprototypes.com/docs/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).
I²C en RS485 zitten blijkbaar al in mijn PIC ingebakken die ik gebruik (16f887). Voor dit projectje zal ik wat programmeertalen moeten leren, want mijn Flowcode is maar zeer beperkt met deze communicatietechnieken.
Het voornaamste wat ik dus mis om hiermee aan de slag te gaan zijn de commando's... Op school hebben we nu al een zeer beperkte basis van C gezien (3 lessen), dus als ik daar mee verder zou kunnen doen is die basis al bruikbaar en moet ik niet van 0 te beginnen.
Tenzij er natuurlijke een andere high-level programmeertaal bestaat die wat eenvoudiger zelfstandig aan te leren is en ook voldoende functionaliteiten heeft.
Ik zal toch eens moeten kijken voor de aankoop van een programmer, want mijn huidige is van school geleend en moet ik dus zeer binnenkort teruggeven.
Rian, als je met PIC werkt, vind je bij Velleman een goeie programmer (K8076) .
Citaat van: Steam.N op 02 juni 2013, 22:43:32 PM
Rian, als je met PIC werkt, vind je bij Velleman een goeie programmer (K8076) .
Helaas wel één probleem:
BELANGRIJK
niet compatibel met een USB naar seriële poort (RS232) omvormer! (http://www.velleman.eu/products/view/?country=be&lang=nl&id=364426)
Ik heb geen PC meer met een 'echte' seriële poort...
De PicStartPlus (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010020&redirects=picstart) werkt wel met een USB-Seriëel omzetter maar is dan wel een heel pak duurder...
Antwoord verplaatst naar http://forum.modelspoormagazine.be/index.php/topic,17593.msg210911.html#msg210911
Ik heb al eens PIC's geprogrammeerd voor seriële communicatie in assembler. Maar ik raad je aan dit te doen in een iets hogere programmeertaal, C of JAL. Je zit met een enorme hoeveelheid databytes, en probeer dat maar eens in assembler bij te houden en te verwerken...
Geert
Assembler begin ik (voorlopig) niet aan. Ga eens Peter zijn JAL-pagina bekijken, of eens zoeken naar wat C-info.
C is goed bruikbaar hiervoor (eigenlijk voor alles bruikbaar). Enig nadeel van C is dat het je handje niet vasthoudt. Je kan alles programeren, ook dat wat je beter niet zou doen... Vermits daar bij een vorige werkgever modems en router in geprogrameerd werden moet het zeker werken.
Hoe bedoel je met 'wat je beter niet zou programmeren?'
C laat je toe te doen wat je wil en doet dat ook. Dus als je meer geheugen toekent dan je hebt dan is dat geen probleem. C controleert weinig, arrays zijn pointers, als het ene type in het andere past is het ok of jij dat nu een char, boolean of integer noemt is eender. Je kan dan ook veel doen. Maar evenveel misdoen. Moderne compilers en ide's gaan wel helpen. Maar bvb als je geheugen toekent moet je het ook zelf terug vrijgeven. Bij C gaat dat niet automatisch. Het vegeeft geen fouten.
Daarom is C code ook veel efficiënter dan de zogenoemde 4de en 5de generatie programmeertalen. Je moet verdomd goed beseffen wat je doet of je gaat gegarandeerd de mist in. Hoe dichter een taal dichter bij de menselijke taal komt, des te inefficienter ze wordt; maar hoe meer 'controles' er ingebouwd worden (declaratieve types). Ze wordt wel steeds gemakkelijker om te gebruiken.
Bij mij is het als volgt: op m'n werk Java. Voor m'n hobby projecten C, C++ en assembler. Assembler vooral als de timing precies goed moet zitten, zoniet C/C++.
Op mijn Spectrum gebruik ik nog altijd Fortran, op mijn C128 gaat het beter mer Cobol. 8)
Fortran en Cobol... nu laat je ook je leeftijd zien Hugo! Voor mijn eindwerk heb ik ook nog Fortran gebruikt. Fantastisch als je integralen van 2-de orde gemodificeerde Besselfuncties moet berekenen. Voor controllertoepassingen echter zijn er betere keuzes te maken.
C is een goede keuze en eigenlijk niet moeilijk. De basis is snel te begrijpen. Er zijn ook veel libraries beschikbaar dus tenzij je echt het onderste uit de kan wil moet je niet elke keer het wiel uitvinden. Maar je moet er je hoofd bijhouden. Eenmaal je ingewikkelde datatypes begint op te zetten wordt het gauw complexer. Ik ben er onlangs mee herbegonnen na 20 jaar en het begint stilaan terug te komen. (maar ik ben er nog lang niet)
Tja, ik programmeerde dan ook al toepassingen, voor buitengewoon onderwijs, toen de meeste hier aanwezigen nog een glinstering in hun papa's oog waren. En toen moest je roeien met de riemen die je had. Pascal!Commodore Super Basic! Qbasic! And finally...C.
Citaat van: Huugooke op 06 juni 2013, 20:24:55 PM
Pascal!Commodore Super Basic! Qbasic! And finally...C.
Been there, done that! Waar is die tijd gebleven? De peek's en de poke's van m'n goeie ouwe C64 (heb 'm nog altijd).
Onze 8051-achtige toestanden waren in het begin volledig in assembler. Je was wel verplicht van eerst eens goed na te denken en dan pas te beginnen programmeren/testen.
Daarna werd het een combinatie van C en Assembler, was al heel wat eenvoudiger om een betere structuur aan te houden in de sw.
Tijdskritische en/of lowlevel-zaken (timer interrupts, seriele interups, ...) werden wel bijna steeds in assembler geschreven. Op 8051's was dit nu eenmaal stukken efficienter dan C. Ook nog een paar toepassingen in PLM geschreven op die dingen.
Geert
Ja mannen, dat begint hier op een meeting van de gepensioneerden te lijken, we gaan de jeugd nog op slecht ideën brengen :D
Die mogen gerust eens weten dat zij het niet uitgevonden hebben!
Citaat van: Havoc op 07 juni 2013, 20:56:45 PM
Ja mannen, dat begint hier op een meeting van de gepensioneerden te lijken, we gaan de jeugd nog op slecht ideën brengen :D
Wie weet ;D ;D
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]
Citaat van: Steam.N op 08 juni 2013, 13:47:48 PM
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...
Citaat van: Steam.N op 08 juni 2013, 13:47:48 PM
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.
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
Citaat van: Gerolf op 08 juni 2013, 15:59:15 PM
Citaat van: Steam.N op 08 juni 2013, 13:47:48 PM
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.
Citaat van: MickeyMouse op 08 juni 2013, 16:58:39 PM
...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.
CiteerWat 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.
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.
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.
Ik heb hier snel eens in enkele boeken gekeken maar zoiets vind ik inderdaad niet direct terug.
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?
Ik zou eens in Wickipedia of iets dergelijks snuffelen naar RS232 en RS485 protocols, en meteen ook naar I2C, 1-wire, ...
Citaat van: Gerolf op 12 juni 2013, 09:34:41 AM
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.
CiteerBegrijp 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.
CiteerMaar 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.
CiteerRS232 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.
Thanks, Johan.
Ik ben er nog niet, maar stilaan komt er een heel klein beetje licht. ;)
Gezien dit communicatie-aspect voor mijn project nog niet dringend is, heb ik nog wat tijd om wat lectuur en datasheets door te nemen.
Eens ik wat verder sta, kom ik je nog eens lastig vallen !
@Rian (Conducteur) en @Jean (steam.N) en andere ....
de volgende link geeft wat meer uitleg hoe de UESART van PIC 16F887 werkt, ik weet dat jullie deze o.a. gebruiken ...
http://www.mikroe.com/chapters/view/16/chapter-3-pic16f887-microcontroller/#c3v8
Geert
Dank je wel Geert.
Ga ik asap doornemen !!!
Even dit draadje wakker maken ;)
Ik ben volop op zoek naar communicatieprotocols tussen microcontrollers.
1Wire lijkt me een aantal voordelen te hebben. Heeft er iemand ervaring mee ?
Echt ervaring met 1Wire, neen; ervaring met seriële communicatie over één draad (als je de massa niet meetelt) wel.
Hangt een beetje van de power van je µC af en hoeveel klokcycli je nog 'over' hebt. Het lastige zit 'm in de timing, net zoals met DCC signalen; je dient een interrupt te gebruiken om elke level wijziging van het signaal te detecteren en een timer om na te gaan hoeveel tijd er ongeveer tussen zat. Op zich niet zo moeilijk om te programmeren, maar het kost wel klokclycli en als je er daar al te kort hebt, ben je zo goed als verloren. Voor de µC met een hogere klokfrequentie mag dit echter geen probleem zijn.
Maxim heeft een hele product-range gebaseerd op de 1Wire, ook een aantal µC's hebben software libraries hiervoor.
Best wel een interessante bus...
1Wire "masteren" lijkt niet zo'n probleem binnen Bascom en zo. Slave is lastiger.
Ik ga eens snuffelen in het gamma van Maxim, Patrick. Bedankt voor de tip :D
Na wat googelen heb ik zelf van een Atmega8 een eenvoudige 1Wire-slave gemaakt.
Ik gebruik hem momenteel om informatie door te geven aan een Atmega8 1Wire-master, die 8 slaves kan bevragen
De verzamelde informatie geeft hij door via RS232 aan een bovenste "trap", ook een Atmega8
Die kan op zijn beurt tot 8 "tussenstappen" bevragen, en zelf via I2C bevraagd worden.
(http://meb.gerolf.be/sturing/bm/schaduw/BlokbezetStapel.jpg)
In het prototype is de onderste trap (hier de onderste printplaat) een 16-kanaals bezetmelder (stroomsensoren)
Later kunnen dat eenvoudiger zaken worden, bvb voor druktoetsen op het synoptisch bord, of wisselterugmeldingen, ...
Even rekenen: 16 kanalen onderaan x 8 1Wire's x 8 RS232 = maximaal 1024 bits, of 128 bytes. Lijkt me genoeg 8)
Voor de die-hards: een scoop-view van een 1Wire communicatie: actief=laag.
Master stuurt een reset, slave een acknowledge, en daarna de 16 databits.
De laatste bits zijn afwijkend, want op ingang 5, 6 en 8 werd de stroomsensor geactiveerd.
(http://meb.gerolf.be/sturing/bm/schaduw/BlokBezet1wireScoop.jpg)
Totale tijd voor één overdracht: 2.4ms. Dus 8 1Wires duren ongeveer 20ms.
De RS232 zal asynchroon communiceren, dat kan dus even snel (en ruim snel genoeg, dunkt me)
Voor mij was een totale refreshtijd van 1/4 seconde al genoeg geweest. Ik heb dus nog wat ruimte...
Stap 1 is gezet, nu de bovenste stap van de sandwich proberen ...
Misschien domme opmerking van mij: Heb je al eens naar arduino gekeken Gerolf?
Arduino is zeker geen slecht platform, maar het is een platform. Centrale module, aan te sluiten andere modules, ...
Ik ga liever voor de basis: een stapje lager, meer werk, maar resultaat op maat, minder kosten.
Eens je enkele toepassingen hebt ontworpen (prints en software) wordt het steeds makkelijker.
Wel, ik doe er alvast mijn hoedje voor af Gerolf :D
Ik ben zeer content dat er nog mensen zijn die zelf zulke elektronica in elkaar steken, ondanks alles wat er al op de markt is. ;)
Vooral blijven doorgaan!
Succes & groeten
Steven
Bedankt, Steven ;)
Na wat volgende knoei- en zoekwerk stap 2 kunnen nemen:
De verzamelde 1Wire-informatie kan via RS232 op verzoek van een master "hogerop" doorgestuurd worden:
(http://meb.gerolf.be/sturing/bm/schaduw/BlokBezet1wireRS232.jpg)
Bovenaan 32 bytes via RS232, onderaan een reeks 1Wire-datastromen. Die worden vergaard wanneer RS232 niet aktief is.
Nu is dat nog tijdens een programma-pauze, maar later kan dat terwijl de RS232-master elders gegevens opvraagt.
Op deze manier zou ik de maximale 1024 bits kunnen vergaren op 120 milliseconden. Ben ik content mee :)
Dat is het hé, communicatie moet je stap voor stap implementeren (= programmeren), zeker de eerste keren.
Later kun je dan uiteindelijk terugvallen op een bibliotheek van (low-level) routines en evt verder uitbouwen...
Suc6 Gerof,
Geert
Indrukwekkend, Gerolf !!!
Al en grote stap gezet, voor je nieuwe communicatie.
Ik blijf duimen voor een totaal succes ;)
Bedankt voor de aanmoediging, mensen.
Ditzelfde principe zou ook andersom moeten kunnen werken:
- Een andere RS232-master komt te weten hoe "alle" uitgangen zouden moeten zijn
- en geeft die info door aan wissels, seinen, leds op het besturingspaneel, ...
De belangrijkste tussenstap (de beslissingen) is een andere boterham, maar hoort niet bij dit topic.
Ik blaas even nieuw leven hierin. In de treinclub zijn we bezig met een nieuwe modulebaan. Ik speel met het idee om onder elke bak een microcontroller te plaatsen die via een soort busnetwerk met elkaar kunnen communiceren.
Bv een trein wordt op een sectie op bak 1 gedetecteerd met stroomdetectie, en dan moet informatie verzonden worden naar de node op bak 3 om daar het sein/wissel te verzetten. Ook een baanbedieningspaneeltje kan op dit netwerk aangesloten zijn.
Ondertussen hier al enkele mogelijkheden gelezen. Zelf al wat ervaring met RS232 voor de verbinding tussen de schaduwstationssturing en de bediening ervoor, maar dat is slechts tussen twee nodes.
CAN? RS485? Welke is het makkelijkst te implementeren, het betrouwbaarst? Als ik goed gekeken heb bestaat er alleszins een JAL bibliotheek voor CAN.
RS485 is bedoeld voor industriële omgevingen, en kan tot enkele kilometers overbruggen in een "ruige" omgeving
CAN komt uit de automobielsector, dus storingsgevoeligheid zal ook wel prima zijn. Afstanden? Zal je moeten Googlen
Ik weet dat er bij de AVR's heel wat microcontrollers zijn met "CAN" in de hardware
RS485 vereist speciale chips (van Maxim bijvoorbeeld) voor de niveau-aanpassing
Maar het gaat niet alleen over de elektrische eigenschappen bij een bussysteem.
Het protocol en de opbouw (master-slave of Multi-master) bepalen vooral hoe alles werkt.
Ik heb intussen ook TWI (I2C) in gebruik, maar dat is alleen betrouwbaar over relatief korte afstanden (max 80cm, dacht ik)
Het voordeel van CAN is dat de basis van het protocol reeds in de CAN-controller aanwezig is (bvb prioriteit op de bus wordt bepaald door het adres). CAN gaat ook over een 'differentiele' lijn waardoor het ook stoorongevoeliger is net als rs485. RS485 staat voor een wijze van overdracht, een protocol zit daar niet in vervat, ook in rs232 niet.
CAN is ideaal om veel kleine berichten door te sturen met een minimum aan vertraging, zoals in een auto.
Geert
RS-485 is enkel een electrische standaard, het beschrijft hoe de spanningen moeten zijn. CAN is een protocol, beschrijft ook hoe de berichten moeten zijn.
Op het werk hebben we een systeem en dat is CAN met een RS-485 interface. Haalt tot 1000m maar dan moet de bedrading wel volgens de regels zijn. Dus geen aftakkingen maar in lus van de ene naar de andere module. Bij de meeste van die interfaces hangt de maximale snelheid van de bus af van de lengte (en dus ook omgekeerd).
I2C kan véél verder dan 80cm gaan. Typisch is I2C enkel voor tussen IC's op een printplaat. De limiet wordt bepaald door de capacitieve load van 400pF. (voor standaard I2C) Maar er bestaan I2C buffers waarmee veel meer mogelijk is en je tot 100m over ethernetkabel kan gaan. Philips (nu NXP, maar het is al zo oud dat er nog Philips op de slides staat) heeft een presentatie waar het probleem wordt uitgelegd en ook hoe die buffers dat omzeilen. 100m is dan de nieuwe limiet enkel door de rondgaande vertraging. Ben het systeem voor mijn baan dan ook op die basis aan het uitwerken.
Langs de andere kant blijf ik me afvragen waarom men altijd een netwerk van microcontrollers wil opzetten.
bij ons zijn de can draden altijd getwist en in een auto heb je dus veel storende elementen.
maar hoe ver je der mee kan gaan ??? toch altijd een meter of 10
wij werken met highspeed can en mid speed can
dan is er nog lin en dat is weer iets anders en zo is er dan weer high en low lin bus systeem
dan nog iets met audio welk de audio apparaten in de wagen met elkaar laat babbelen.
gelukkig ben ik op 31 december van die ellende vanaf
gr raf
Citaat van: conducteur op 30 maart 2014, 00:05:55 AM
...In de treinclub zijn we bezig met een nieuwe modulebaan. Ik speel met het idee om onder elke bak een microcontroller te plaatsen die via een soort busnetwerk met elkaar kunnen communiceren.
Bv een trein wordt op een sectie op bak 1 gedetecteerd met stroomdetectie, en dan moet informatie verzonden worden naar de node op bak 3 om daar het sein/wissel te verzetten. Ook een baanbedieningspaneeltje kan op dit netwerk aangesloten zijn...
Loconet? Bestaat, is degelijk en er zijn commerciële zaken genoeg verkrijgbaar.
Zelfbouw? Het is een 'gesloten' protocol maar hier (http://www.digitrax.com/static/apps/cms/media/documents/loconet/loconetpersonaledition.pdf) vind je de vrijgegeven standaard (Loconet personal edition) en hier (http://www.scuba.net/wiki/images/1/18/LoconetProtoboard-1.0-schematic.png) een eenvoudige controller interface.
Er zijn genoeg softwareoplossingen op het net te vinden (meestal in C maar gemakkelijk om te zetten naar een andere taal).
Succes!
Citaat van: conducteur op 30 maart 2014, 00:05:55 AM
Ik blaas even nieuw leven hierin. In de treinclub zijn we bezig met een nieuwe modulebaan. Ik speel met het idee om onder elke bak een microcontroller te plaatsen die via een soort busnetwerk met elkaar kunnen communiceren.
Bv een trein wordt op een sectie op bak 1 gedetecteerd met stroomdetectie, en dan moet informatie verzonden worden naar de node op bak 3 om daar het sein/wissel te verzetten. Ook een baanbedieningspaneeltje kan op dit netwerk aangesloten zijn.
quote]
Ik weet niet hoe ver jullie staan in de systeemopzet maar persoonlijk zou ik zeker eerst de systeemarchitectuur/opzet volledig op punt zetten. Een systeemconcept met gedecentraliseerde intelligentie is niet zo eenvoudig, zeker niet als modules kennis moeten hebben van wat onderling mogelijk is. Dit beperkt de flexibiliteit en het is een nachtmerrie om de software te onderhouden.
De keuze van CAN of welke oplossing ook om te communiceren is eigenlijk een beslissing die nog veel later genomen kan worden.
mvg,
Patrick Smout