woensdag 10 juli 2024

Schakelbord (3)

 In de vorige post ging het over een DCCdecoder opgenomen in het project. Dat werkt nu. Alle 3 bytes DCC commands ontvangen door deze decoder van een andere centrale worden samengevoegd met de commands die in SchakelBord zelf worden opgewekt door het schakelen van de 64 aan te sluiten  accessoires. 

Deze 3 bytes commands zijn alle 2048 mogelijke aansturingen voor accessoires. Maar ook de aansturing voor 127 verschillende locs van rijopdrachten en het schakelen van de eerste 12 functies in de loc. Anders gezegd, de commands bedoeld voor locs met een 7 bits adres worden ook doorgeven.

Dit geeft mogelijkheden waar ik bij start van het project niet eens aan had gedacht, SchakelBord is ook als een booster te gebruiken. Met die verstande dat het alleen werkt met kort adres (7bits) locs. In uitgebreidere centrales als Ecos of CS3 kunnen ook locs met lang  adres (15bits) decoders worden gebruikt, dus 9999 verschillende adressen. Zoveel locs staan natuurlijk zelden samen op 1 modelbaan.

MFX en vergelijkbare terug- en aanmeld systemen worden door SchakelBord niet ondersteund. Ook CV boodschappen ontvangen in de decoder worden niet doorgestuurd naar de DCC uitgang. Wel zijn er plannen als er nog wat geheugen over is om SchakelBord ook vergaande functies te geven als CV programmer.

Punt van aandacht is nog wel een dubbele aansturing van een accessoire door SchakelBord en door een extern aangesloten centrale. De extern aangesloten centrale kan nooit weten wanneer SchakelBord deze accessoire omzet, dus de externe centrale toont dan de verkeerde stand van dit accessoire. Andersom zou in theorie, door het door de externe centrale gestuurde signaal te decoderen, SchakelBord dit wel kunnen weten. Maar SchakelBord heeft meerdere methoden om de aangesloten schakelaars te interpreteren. En dat kan de centrale ook niet weten. Beste om er gewoon niks mee te doen. Als gebruiker moet je je gewoon realiseren, dat als je een accessoire vanuit een externe centrale omzet, de aanduiding op SchakelBord niet meer klopt en andersom.

Volgende hoofstuk in het project is de signalering. Natuurlijk kun je voor de signalering aparte decoders op het DCC signaal zetten. 

Maar SchakelBord krijgt ook een aansluiting voor smartleds van het type WS2811. Deze chips zijn er in meerdere uitvoeringen. Losse chips voor drie leds rood, groen en blauw. Of meerdere versies 3-kleuren leds waar de chip ook bij is ingebouwd. Deze smartleds zijn dan weer los te verkrijgen of als ledstrip of als slinger van leds, vergelijkbaar met een kerstboomverlichting. Alle 64 mogelijk accessoires krijgen een pixel.(zo worden die setjes van drie rood, groen en blauw in dat wereldje genoemd) Het kleurenschema moet ik nog bedenken.

Nu volgt een technisch verhaal: Voor Arduino zijn er meerdere libraries te vinden om die smartleds aan te sturen. Bekendste is FastLed, een aanrader voor een ieder die met die World Semi chips (WS=worldsemi) wil experimenteren. Aardige lui trouwens van World Semi voor mijn eerste project 'LicHt' waar ik deze chips in gebruik, hebben ze mij  veel ondersteuning en uitleg gegeven hoe dit te doen, maar dit terzijde.

Die libraries als bv. FastLed hebben allen 1 probleem. Voor iedere pixel dient er een geheugen plekje te zijn voor drie bytes die de waarde van lichtsterkte voor de drie leds in een pixel bevat. Voor 64 pixels zijn dat dus 192 bytes. Zoveel ruimte is er dus niet meer in het geheugen van de Arduino over met SchakelBord. Nodig is dus dat de lichtsterkte per led in de pixel berekend moet worden uit de gegevens die al bekend zijn, zoals de stand van het accessoire. Maar dat kan Fastled niet. Een zelf te maken smartled encoder is dus nodig. 

De datasheet van de WS2811 leert dat er een pulstrein nodig is van ongeveer een 800khz.  Een serieel gestuurt bit  is opgedeeld in een aan-tijd direct gevolgd door een uit-tijd. De totale tijdsduur van een bit is ongeveer constant. Is het deel aan-tijd 2x langer als het deel uit-tijd dan interpreteert de WS2811 dit als een 1. Is het deel uit-tijd twee keer het deel aan-tijd dan is het een nul. Een pixel krijgt 24bits. Een pixel leest 24 bits en stuurt de rest van het signaal door naar de volgende pixel. Zonder die eerste 24bits dus.

Na experimenten is gebleken dat die chips het niet zo nauw nemen met die pulsduur. Wat belangrijk is, is die verdeling van die twee helften in tijdsduur die het onderscheid maken tussen een 1 of een 0.

Praktisch heb ik het opgelost door voor een 0 bit een minimale pulsduur mogelijk met een arduino te maken. Dat is twee keer een PINB |=(1<<0). Pin 8 van de arduino heb ik gebruikt voor de smartleds. En direct daarachter de port hard naar laag met PORTB &=~(1<<0). Hierna moet een volgend bit worden bepaald, uitvoering van die logica duurt lang genoeg om dit als een 0 bit te kunnen gebruiken.

Voor een 1 bit ligt het lastiger. Na het zetten van de pin moet deze minstens 2x langer hoog blijven als het tweede laag deel inclusief weer de tijd voor het bepalen van het volgend bit. Dit gedaan met een delay bestaande uit een aantal direct door de compiler in te voegen assembler nop instructies.

En zo waar dit werkt nu perfect.....

Maar nu  nog implementeren in de rest van het SchakelBord project......

Wordt vervolgt...





Geen opmerkingen:

Een reactie posten

RoBoot

 Tijdje niet gepost. Druk, vakantie en zo.  Laatste project SchakelBord is af, gaat mee naar de beurs en helemaal geworden wat ik ervan had ...