Waar zijn we nu mee bezig ? Microcontrollers

[dani]

dat is inderdaad heel ruim, ja..... 

[Steam.N]

Onvoorstelbare luxe !
Maar je loopt natuurlijk het gevaar té groots te starten, zodanig dat je het nooit afgewerkt krijgt ...
Dat risico is bij mij een heel stuk kleiner 

[Geert]

Onvoorstelbare luxe !
Maar je loopt natuurlijk het gevaar té groots te starten, zodanig dat je het nooit afgewerkt krijgt ...
Dat risico is bij mij een heel stuk kleiner 

Ik weet het veel luxe. Maar hou deze ruimte is vorstvrij en redelijk droog (vochtgehalte). Maar ook stofvrij! Ik denk er zelfs over na deze ruimte de halveren...

Ik heb ook wat gelogen over deze ruimte, er staat ook een trap in die 2vierkante meter eraf neemt...


Geert

[dani]

zoals ons vadere altijd zei (en hij kon het weten...) :   

"Zoon, ge kunt in 't leven niet alles hebben....  een dikke vrouw en veel plaats in uw beddeke !!"

Soms moet je keuzes maken.

[Sattrickske]

Effe een LCD'ke met touchscreen besteld.
http://www.aliexpress.com/item/Freeshipping-2-8-TFT-SPI-LCD-module-Touch-screen-with-PCB-board-SD-card-driver-for/820314575.html
Gaat dienen om de CAN-bus controller te debuggen en op te volgen.  Wordt via SPI op de microcontroller aangesloten.  Elke CAN-bus controller in m'n ontwerp wordt uitgerust met 8 seriële devices waarvan er één specialeke: het LCD-scherm met touchscreen...

[Gerolf]

Klinkt leuk, Patrick. Ik ben benieuwd wat je er visueel en bedien-technisch mee gaat uitspoken 

[Sattrickske]

Alles gaat over CAN-bus gaan op m'n baan.  Binnenkort ga ik ook de interne CAN-bus van de Marklin CSII hacken en mergen/samenvoegen met mijn CAN-bus.  2 mogelijkheden hiervoor: via de CSII ethernet verbinding, of ding opengooien en intern de CAN-bus afpitsen.
Elke moduleplaat van m'n baan krijgt één CAN-controller en die kan op zijn beurt 8 tot 16 seriële sub-controllers aan (wissel sturingen via servo, accessory decoders, bezetmelders, ...).  Eén van de seriële sub-controllers zal dat LCD'tje worden dat ik op elke van de CAN-nodes kan inpluggen wanneer nodig.
Er worden ook 2 speciale CAN-node/controllers voorzien: een CAN-to-ethernet voor de PC sturing en één CAN-to-S88 (terugmelders).  Bedoeling is dat elk van de nodes self-learning is en kan achterhalen welke sub-controllers er precies aanhangen.  't Leuke is dat het bijlange niet zo moeilijk is en dat de microcontrollers waarvan ik er nu heel wat ga nodig hebben ook bijna niets kosten.

Ik ga volgend jaar ook bouwen en ga zelf m'n domotica in mekaar steken (en ja, ook via CAN-bus) en dan komt dat LCD wel meer dan eens van pas.  Nu eerst eentje aangeschaft om te testen.  Ik ga eerst proberen om dat ding volledig serieel aan te sturen over de SPI van de µC, maar ik vrees een beetje voor de snelheid.  Ik heb al uitgerekend dat ik om alle pixels aan te spreken ong. 1.2 seconde ga nodig hebben.  Desnoods schakel ik over naar 8 of 16 bit parallelle interface met een extra microcontroller; dat LCD'tje heeft 't gelukkig allemaal...

[Havoc]

SPI daar kan je nochtans heel wat doorpompen. Op een project dat ding ooit aan 100MHz laten draaien, dan wel enkel over een 30-tal cm over de pcb. CAN is 1 Mbps of zoiets en dan moet je nog opletten op de round-trip (als ik me goed herinner van een project met rolbruggen).

Na een hele hoop nadenken en theoretiseren ga ik toch voor en zelfgebrouwen oplossing. In november een processorkaartje in elkaar flansen en eens leren code schrijven.

[Sattrickske]

SPI is inderdaad een zeer snel protocol en de snelheid kan je heel hoog opdrijven.  Maar... inderdaad roundtrip (of reflectie) komt roet in het eten gooien (en zowel bij CAN als bij SPI).  De brute regel bij transimissielijnen is dat de golflengte mag nooit hoger zijn dan 10x de lengte van je kabel.  Dus om jouw geval aan te halen: 100Mhz geeft een golflengte van 3 meter (snelheid van het licht / frequentie), dus max. lengte van je kabel 30cm.  Om deze reflecties te vermijden moet je transmissie kabel steeds voldoen aan bovenstaande formule.  Protocols die werken met error correctie kunnen de snelheid opdrijven, omdat kleine foutjes weggefilterd kunnen worden door deze correctie.  Daar ligt het grote verschil tussen SPI en CAN.

Dus om alles op te lossen met SPI gaan we iets te kort door de bocht vrees ik; dit protocol is duidelijk voorzien op communicatie tussen microcontrollers of seriële devices binnen hetzelfde apparaat of op zeer korte afstand.  Stel dat we de frequentie laten zaken tot 10Mhz, komen we op 3 meter; en bij 1 Mhz zitten we op 30 meter.  Bovendien heb je 4 draden (zelfs best 5, CLK, MISO, MOSI, !CS en GND) nodig.  Je kan wel een soort van daisy chain ontwikkelen om zo de lengte op te drijven: elke node heeft 2 SPI transmitters/receivers.  Maar dit genereert gigantisch veel overhead op elke node (alle traffiek passeert over alle nodes en moet verwerkt en terug doorgestuurd worden).

CAN-bus heeft meer voordelen: bij versie 2.0B haal je 1MHz over 40 meter met 2 draden (versie CAN-FD zelfs 8MHz).   De afstand van de CAN-node tot de transmissiekabel mag echter nooit meer dan 30cm bedragen.  De transmissie over CAN is veel minder gevoelig voor storingen omdat je signaal steeds in tegenfase zit.  Bovendien is de bekabeling een simpele twisted pair.  Het is bovendien een industriële standaard (zit in de meeste recente autos) en je kan er heel wat hardware/software voor vinden.  Het verschil met CAN en SPI is dat CAN niet zomaar een serieel protocol is, maar het bevat ook elementen voor timing en fysieke beperkingen.  Dit is voor mij genoeg om voor CAN te kiezen over langere afstanden (>1m) en SPI over korte afstanden (ong. 10 à 20 cm).  Hetgeen ik wil bekomen staat hier al wat beschreven: http://forum.modelspoormagazine.be/index.php/topic,17335.msg230179.html#msg230179

Eender welk protocol je ook kiest, je zal zowiezo redelijk zuinig moeten omspringen met de data die je ermee verstuurt.  Al deze data moet immers genoeg tijd hebben om serieel over de lijn gejaagd te worden.

Post maar wat gegevens van wat je exact wil doen, het interesseert me ten zeerste...

[Havoc]

De brute regel bij transimissielijnen is dat de golflengte mag nooit hoger zijn dan 10x de lengte van je kabel.  Dus om jouw geval aan te halen: 100Mhz geeft een golflengte van 3 meter (snelheid van het licht / frequentie), dus max. lengte van je kabel 30cm.  Om deze reflecties te vermijden moet je transmissie kabel steeds voldoen aan bovenstaande formule.  Protocols die werken met error correctie kunnen de snelheid opdrijven, omdat kleine foutjes weggefilterd kunnen worden door deze correctie.  Daar ligt het grote verschil tussen SPI en CAN.

Euh...denk dat je 2 dingen door elkaar haalt. Eenmaal een kabel/pcb-trace langer is dan 1/10 de golflengte is het een transmissielijn. Korter dan 1/10 golflengte is het een stub. Maar reflecties heb je enkel als de impedantie niet aangepast is. Je kan prima 100MHz door een kabel van tientallen meters sturen zonder reflecties als je impedantie van zender en ontvanger aan de impedantie van de kabel aangepast zijn. Ethernet stuurt 125 MHz over 100m kabel zonder enig probleem. Als je parallel gaat werken bij hogere snelheden komen er nog looptijden bij om de boel moeilijker te maken.

SPI is enkel een "protocol", het beschrijft geen fysische interface. Dus SPI over een RS-485 elektrische interface is prima en haalt zonder problemen grote afstanden met behoorlijke debieten. RS-485 gaat tot 35Mbps tot 10m dus dat is ruim voldoende voor de gemiddelde treinbaan denk ik. Enig probleem is dat ik meer dan de standaard 32 tranceivers op de bus wil en de 1/8 load 3V3 tranceivers zijn niet zo snel.

Ik ga ook geen SPI gebruiken om de klok niet te hoeven mee te sturen. Dat is een probleem van SPI, je hebt die klok nodig. Op een pcb waar je in ttl kan blijven is dat geen ramp, dat is een track meer. Maar als je tussen pcb's wil gaan moet je iets robuster gebruiken. En dan is die klok er teveel aan. Direct dubbel zoveel tranceivers en ook 2 draden meer, 2 pinnen in de connector extra.

Opzet is redelijk eenvoudig:
- pc draait stuurprogramma, hangt een usb interface bordje aan (DiMax Sub20)
- gebruik het 9-bit serieel protocol en zet om naar RS-485 voor transport. Alles in 1/8 load voor max 256 elementen op de bus. Snelheidsbeperking is de processor/pc interface.
- enkele extra lijnen voor de borden te resetten, te weten of ze allemaal klaar staan, irq etc.
- seriële bus vertrekt aan de pc interface, gaat alle borden af, laatste bord sluit de lus af.
- processorbord op basis van de Atmel ATxmega128A1U
- processorbord plugt in een interfacebord dat de IO doet. Zeker een versie is pwm. Misschien ook een servo bord. Geen idee of ik enkel in, uit of gemengd IO ga doen.
- 5 seriële bussen: schaduwstation, baan, bedieningsbord, accesoires, spare. Mogelijk gaan de accesoires in de rest op en komt er een apart bedieningsbord voor schaduwstation en baan.

Gaat niet volgend jaar klaar zijn denk ik... Ook nog de onderbouw beginnen, die 3.5" live steam afmaken, de tekeningen voor de 5" beginnen en die spoor 1 die hier al zeker 5 jaar op het forum rondwaart verder afwerken.

[Sattrickske]

Inderdaad was effe met 2 dingen tegelijk bezig en niet goed opgelet (ben m'n bibliotheken naar KiCad aan 't omzetten)...  Je hebt gelijk >1/10 golflengte = transmissie.  Ook de impedantie was ik effe vergeten te vermelden, bij de CAN bus is dat ook zo (120 ohm aan beide zijden voor de langere lijn, korte hoeft niks).

Maar ik gebruik SPI wel tussen m'n PCBs, maar op korte afstand (max 20cm), en dat gaat perfect.  Gewoon een stukje CAT5 kabel op een 6pin header (GND, VDD, MISO, MOSI, SCK en !CS).  Momenteel draait die bij mij op 20MHz.  GND en VDD geef ik ook mee omdat ik m'n microcontrollers apart voed, de regulator staat op de CAN-node en kan gerust de 8-16 slave controllers aan.  Op elke slave controller zit er een aparte regulator (los van de µC) voor de 'periferie'.

Aan RS-485 heb ik ook een tijdje gedacht, maar laten varen wegens teveel werk.  CAN is trager, maar geeft meer ondersteuning: protocol, bibliotheken, hardware ed...

[Havoc]

CAN is trager, maar geeft meer ondersteuning: protocol, bibliotheken, hardware ed...

Goed punt dat je daar aanhaalt. Vermijden om het wiel nog eens uit te vinden is belangrijk.

Mijn keuze voor 9-bit serieel over RS-485 is gekomen om een en ander te vermijden:
- asynchroon serieel maakt dat een klok niet nodig is
- RS-485 geeft lange verbindingen zonder veel problemen
- 9-bit omdat zowel de pc-interface dit ondersteunt als de controller. De controller heeft bovendien hardware ondersteuning voor de adresherkenning.

Nadeel is dat de snelheid beperkt wordt tot 2 Mbps. Maar langs de andere kant is DCC en S88 veel trager. Dus kan ik best wat inefficientie in mijn code verdragen.

Mijn bedoeling is om de RS-485 via de "bus" te voeden. De controller krijgt zijn eigen voeding. Maar als die voeding er niet is krijgt de pc geen "ready" signaal dus weet die dat er iets mis is (en ik dus ook). Alles gaat op 12V draaien denk ik. Voor Z is dat direct als rijstroom bruikbaar en met een SMPS is het geen probleem om daar 3.3V van te maken. Dat beperkt de stroom wat en met een PC voeding mag dat ook geen probleem zijn, die leveren gemakkelijk enkele Ampères voor weinig geld.

[Sattrickske]

Je voornaamste keuzes die je gemaakt hebt, komen in CAN ook voor dus op dat vlak zijn de violen gelijkgestemd (enkel de 9-bit is niet van toepassing bij CAN).

Ik denk dat we uiteindelijk wel hetzelfde gaan bekomen, enkel met een ander protocol.  Je gaat wel meer werk hebben met die RS-485, maar je bent nergens aan gebonden, je doet wat je wil en dat kan ook een groot voordeel zijn.  Met CAN moet je de specs volgen, anders is het geen CAN meer en verlies je meteen alle voordelen ervan.  Een beetje give and take denk ik.

Ben ondertussen de specs van CAN-FD aan 't uitpluizen, deze werkt met variabele bitrates: 'nego' & 'ack' nog steeds aan max. 1MBit, maar data transfer onbeperkt (fysische beperking).  Maar ik heb al nagegeken dat je met 1Mbit CAN al meer dan genoeg hebt voor een modelbaan (zelfs met de CAN overhead). Dus jouw 2Mbit zal zeker ook lukken, want jouw protocol zal zelfs nog minder overhead hebben vermoed ik.  We moeten gewoon slim omspringen met de beschikbare ruimte; bv. de bezetmelders dienen enkel toestandswijzigingen door te geven in normaal bedrijf, vele efficiënter dan altijd alles door te sturen.

En wat noem je ineffiëntie?  De overhead voor bv. de CRC .  Maar je hebt gelijk de bestaande protocollen van de modelbaan zijn zo traag, dat we heel wat ruimte hebben....

[PeterC]

...Maar je hebt gelijk de bestaande protocollen van de modelbaan zijn zo traag, dat we heel wat ruimte hebben....

Juist daarom vraag ik mij af waarom jullie zelf een protocol willen uitvinden?  Wat is er mis met een bestaand?  Weliswaar niet zo snel (16.6 kb) maar algemeen en eenvoudig in gebruik: Loconet!

[Sattrickske]

CAN bus is sneller en beter dan Loconet.  Deze bus wordt intern in de Marklin CSII gebruikt (heb er een ganse handleiding van), door Zimo en waarschijnlijk nog anderen.
En waarom -al was het maar voor de sport- geen eigen protocol ontwikkelen als je daar de tijd voor hebt.  Wie weet kom je wel met een vernieuwend idee...