zondag 31 mei 2020

De wielen - Low cost opfrisbeurt

De wielen die onder de Eend zaten zijn zo slecht nog niet. Dus nieuwe zijn niet nodig. Het is - zeker op korte termijn - niet de bedoeling dat er van die mooie Burton-sportvelgen onder komen. Natuurlijk zijn de velgen niet roestvrij, maar welke 2cv-velgen zijn dat wel. Volgens mij roesten die al als ze nog in het magazijn liggen. Nu kan ik ze professioneel laten stralen en poedercoaten, of zelf opfrissen. Ik heb nog een bijna volle pot Epifanes staan, de lak die aan de binnenkant van de bodydelen zit. Dat treft, want ik wil zwarte velgen. En dan met van die chromen ringen en doppen erop. Dus om de kosten enigszins te drukken (kan dat nog dan...) ga ik zelf aan de slag.

Eerst maar eens de hogedrukspuit erop. Vervolgens met een Brillo-sponsje aan de slag en als laatste een schuurpapiertje voor de laatste roestplekjes. En dan even goed laten drogen in de blakende zon.


De velgen zijn schoon.

De velgen hadden onder de Eend ook al van die glimmende doppen. De rand waar de dop op de velg zit is goed te zien. Als ik weer velgdoppen gebruik moet ik hier wel iets op bedenken. Anders gaan de velgen weer van die typische roestranden krijgen.

Aan de binnenkant van de velg zit vaak roest op de plek waar het binnenste deel van de velg aan het buitenste deel gelast zit. Daar zit een spleet waar water tussen kan komen met dikke korsten roest als gevolg. Je komt daar natuurlijk niet tussen om het roest te verwijderen, dus ik ga experimenteren met RX5. Normaliter smeer of spuit je namelijk op RX5 alleen RX10, maar andere synthetische verf moet ook kunnen (volgens de leverancier). RX10 als afwerklaag voor de velgen vind ik niet strak genoeg, dus ik ga afwerken met de aangebroken pot Epifanes. Gewoon met een kwast. Ik ben benieuwd wat het resultaat op korte en lange termijn gaat zijn.

Ik heb zelf niet de apparatuur om de band te verwijderen, dus die heb ik leeg laten lopen. Ik heb wat kartonnetjes geknipt en die tussen velg en band gestoken zodat de band niet geschilderd wordt. Achteraf niet de beste keuze omdat die kartonnetjes papier achterlaten bij het verwijderen. Gelukkig heb ik eerst de binnenkant behandeld. Aan de zichtzijde heb ik stukjes plastic gebruikt. Dat werkt beter bij het verwijderen.

RX5 op de velg

Na twee lagen RX5, waarbij het spul ruimschoots in de genoemde spleet gemotiveerd is, hebben de velgen de tijd gekregen om goed te drogen. Met het mooie weer van de laatste dagen geen enkel probleem. Hierna is er Epifanes op gekwast. Dat spul vloeit best goed uit. Tussen de lagen door steeds licht opgeschuurd met een scotch brite.


Licht opgeschuurd.

Uiteindelijk waren er twee lagen zwart aan de binnenkant, en drie lagen zwart aan de buitenkant nodig. Die kant was natuurlijk wit. Met de twee lagen RX5 in totaal (binnen en buitenkant opgeteld) negen keer gelakt. Pfff, poedercoaten is sneller...


Resultaat binnenkant


Resultaat buitenkant

Vandaag in het zonlicht de velgen bekeken en ik ben nog niet helemaal tevreden. Dus ik denk dat er aan de zichtzijde (buitenkant) nog een laagje bij moet. En zo gaat dat nou elke keer. Geen wonder dat het bouwen zo lang duurt ;-).

vrijdag 22 mei 2020

De uitlaat - Onzichtbaar bling-bling

Na enkele berichten over software wordt het weer eens tijd voor een stukje hardware. Anders loop ik het risico dat ik helemaal geen lezers meer overhoud. De uitlaat is gemonteerd. Er was al eerder aan gewerkt, maar nu hangt hij "definitief". Niets is definitief, al helemaal niet aan een hobby-auto, maar vooruit dan maar, ik ga er nu even niets meer aan veranderen.

De uitlaat begint bij de motor als onderdeel van de "spin", ofwel het inlaat-/uitlaatspruitstuk. Vanuit beide cilinders zitten hier twee korte uitlaatbochtjes die aan weerszijde verbonden zijn met de warmtewisselaars (of verwarmingspotten). De uitlaat verwarmt hier de koellucht die van de motor vandaan komt nog een beetje extra op zodat het binnen in de Burton lekker warm kan worden. Ben benieuwd of ik dat echt ooit een keer nodig heb...

Eerste demper.


De twee verwarmingspotten zitten verbonden met de éérste demper - tevens balanspot - die onder de versnellingsbak hangt. Deze heeft aan de linkerzijde één uitgang van waaruit de uitlaat enkelvoudig naar achteren loopt. Beginnend met een speciaal Burton-bochtje dat tussen de body en de voorste as door gefriemeld zit - tenminste, ik denk dat dit bochtje niet gelijk is aan die van de Eend. Ik kan ze niet meer vergelijken want die van de Eend is al lange tijd geleden naar het oud-ijzer verdwenen.


De uitlaat gaat enkelvoudig naar achteren, beginnend met deze bocht.

Zoals de meeste Burton-bouwers heb ik gekozen voor een RVS-uitlaat. Met een beetje geluk hoef ik die nooit meer te vervangen. Alleen jammer dat je van dat blinkende spul aan de buitenkant nauwelijks iets ziet.

Past net!

Het volgende deel van de uitlaat is de tweede- of einddemper. Deze wordt aan de voorkant met een standaard uitlaatklem aan bovenstaand bochtje bevestigd. Maar nu nog niet vast, eerst moet het achterste deel gepast worden.

Op deze foto zit de klem al vast.


Aan de achterkant zit de demper met een rubberen bevestiging aan de body gemonteerd. Voor de zekerheid heb ik op deze plek een plaatje aluminium tegen de body geplakt (met Sikafex, what else) met een slopgat 90 graden gedraaid t.o.v. het slopgat in het speciale stripje van de uitlaatklem.


Hier moet nog het rubberen tonnetje tussen.

De uitlaat zit nu in het midden vast.

Nu komt de achterste pijp, die op bovenstaande foto al vast zit aan de einddemper. Nu lijkt het net alsof de uitlaat van voor naar achter chronologisch gemonteerd wordt. Maar da's toch echt niet zo. Ik denk dat ik de demper en eindpijp er wel tien keer onderuit heb gehaald om weer een beetje bij te buigen en te passen. Vooral de bocht die om de achterste veerpoot heen meandert is een - laat ik het netjes zeggen - uitdaging. 

De uitdaging: de veerpoot mag de uitlaat niet raken bij volledig uitveren.

De uitlaat meandert onder de veerpoot door.

Sowieso kan de veerpoot linksachter niet volledig "uitveren" zonder dat deze tegen de uitlaat aan komt. Meneer RDW vindt dit niet fijn. Iets waar trouwens meerdere bouwers mee geworsteld hebben, dus ik was voorbereid. De oplossing is het enigszins beperken van de uiterste stand van de veerpoot. Wat extra ringen/moeren bij de aanslagnok en het probleem is verholpen.

Past net.

Detailfoto.

Bij de Eend wordt de eindpijp op een andere plek opgehangen dan bij de Burton. Bij de Burton zit hij helemaal aan het eind vast met weer zo'n rubber tonnetje. Bij de Eend zit de bevestiging wat meer naar voren en hangt hij daar wat te bengelen. Dit bevestigingspunt is aanwezig bij mijn chassis en ik heb ervoor gekozen om de uitlaat ook hier nog te bevestigen zodat deze wat beter gefixeerd wordt. De tijd gaat leren of dit verstandig is.


Extra bevestiging op het "oude" ophangpunt.



De eindophanging.


Uiteindelijk heb ik eerst de eindpijp aan de einddemper bevestigd (met uitlaatpasta), deze vervolgens op de juiste plek gehangen terwijl de demper nog los in de voorste bocht kon bewegen. Pas toen ik tevreden was met de ophanging achter en midden onder de body, heb ik de verbinding tussen demper en voorste bocht vast gemaakt (ook weer met uitlaatpasta).

De voorste bocht heeft al die tijd wel vast gezeten aan de voorste demper, maar nog niet definitief. Dat moet ik nog doen, maar dat stelt nu niet zoveel meer voor. Ik heb gekozen voor de "luxe" uitlaatklemmen van Burton Car Company. Een aanrader!

maandag 20 april 2020

Software - De list (4: RGBDigit)

In de vorige drie berichten zijn al drie listen (in de woorden van Olivier B. Bommel) besproken die oplossingen bieden voor het geringe aantal in- en uitgangen van de ESP32-microcontroller. In dit bericht een vierde en voorlopig laatste list. Eigenlijk geen nieuwe list, maar dat blijkt zo...

Een collega op het werk is in zijn vrije tijd een professionele knutselaar. Hij heeft een nieuw soort 7-segmentdisplay bedacht. Eentje die niet alleen via één datalijntje aangestuurd wordt, maar ook nog eens per segment 16 miljoen kleuren kan tonen. Doet me denken aan de NeoPixels uit een vorig bericht (de list 2); en dat is niet zonder reden. Ze bevatten namelijk per segment én de decimale punt één NeoPixel. Acht in totaal per digit.

RGBDigit (https://www.rgbdigit.com/rgbdigit/)

Fijn, want een stuk software voor de aansturing van NeoPixels is al aanwezig. De RGBDigits kunnen in serie geknoopt worden. Als ik drie getallen wil presenteren, geeft dit 3 x 8 = 24 NeoPixels. En toch maar één enkele digitale uitgang van de ESP32 gebruikt. Met recht een efficiënte manier van aansturen. Een prima list dus!

De RGBDigits zijn best groot en geven enorm veel licht. Iets om rekening mee te houden bij het ontwerpen van het digitale display van de Burton. Het moet natuurlijk niet zo zijn dat je bij het rijden in het donker verblind wordt. Maar wel ideaal bij het rijden in de volle zon. Menig display is dan moeilijk af te lezen. Met deze schijnwerpers verwacht ik geen probleem. Ik denk dat ik een lichtsensor inbouw waarmee ik de helderheid van het display automatisch aan laat passen. Een lichtgevoelige weerstand (LDR) zou hier prima werken.

https://nl.wikipedia.org/wiki/Lichtgevoelige_weerstand

Wordt vervolgd...

zaterdag 7 maart 2020

Software - De list (3: TM1637)

Het dashboard van de Burton wordt volledig custom en digitaal. Geen analoge meters dus. Met de precieze lay-out en het design ben ik nog niet klaar, maar er komen in ieder geval grote 7-segmentdisplays in.


https://en.wikipedia.org/wiki/Seven-segment_display


En daar gaan we weer. Een 7-segmentdisplay zou zomaar - de naam verraad het al - zeven uitgangen van de microcontroller kunnen bezetten. Elk segment moet namelijk onafhankelijk aangestuurd kunnen worden. Om de snelheid van de Burton weer te kunnen geven zijn minimaal drie cijfers en dus drie van die 7-segmentdisplays nodig. Da's alleen al 21 uitgangen. Zoveel uitgangen heeft de ESP32 helemaal niet vrij, dus dat moet anders kunnen. En gelukkig kan dat ook anders. Met een I²C-bus I/O-expander bijvoorbeeld. Zou kunnen, maar in de praktijk worden vaak andere IC's gebruikt. Bijvoorbeeld de TM1637 van Titan Micro Electronics. Een speciaal IC waarmee tot zes 7-segmentdisplays aangestuurd kunnen worden.

TM1637, display driver.

Dit IC is nog tot meer in staat, maar daar maak ik geen gebruik van. Net als de I²C-bus wordt dit IC aangestuurd met een klok- en een datasignaal. Ook het communicatieprotocol lijkt erg veel op het I²C-protocol, met het verschil dat de TM1637 niet geadresseerd hoeft te worden. Je kunt maar één zo'n IC aanspreken.

Bij de NeoPixels uit het vorige bericht was de grootste uitdaging de timing van de bits die verstuurd moeten worden. Bij deze TM1637 is de timing veel minder kritisch. Zolang het klok- en datasignaal maar netjes op elkaar afgestemd zijn. In de figuur hieronder wordt dit weergegeven:


Timing van de TM1637

Elke bericht naar de TM1637 begint altijd met een start-conditie en eindigt altijd met een stop-conditie. Bij de start wordt het datalijntje (DIO) laag gemaakt terwijl de kloklijn (CLK) hoog is. Bij de stop wordt de DIO juist hoog gemaakt terwijl de CLK hoog is. Dit zijn de enige twee condities waarbij de DIO van niveau wijzigt terwijl CLK hoog is. De TM1637 kan hierdoor deze twee belangrijke condities herkennen.

Een commando of data (tussen start- en stop-conditie) wordt verstuurd in een groepje van acht bits. Ná elk zo'n byte volgt nog een Acknowledge (ACK) waarbij de TM1637 de kans krijgt om het ontvangen byte te bevestigen. De acht bits worden door de TM1637 één voor één 'ingeklokt' op het moment dat het kloksignaal van laag naar hoog beweegt. Easy peasy.

In de software worden bovenstaande condities op de volgende manier geprogrammeerd (voorbeeld van de start-conditie):

TM1637 Start-conditie

Omdat de absolute timing niet zo kritisch is kan ik gewoon gebruik maken van de eenvoudige pauzefunctie vTaskDelay(1). Hiermee wordt steeds 1 tick, ofwel 10 ms gewacht tussen de bitwisselingen. Een eeuwigheid als je het vergelijkt met de timing van de eerder genoemde NeoPixels. Een prima oplossing voor dit doeleind. Bovendien krijgen andere taken gedurende deze pauzes de tijd om hun ding te doen. Uiteindelijk gebruikt dit protocol bijzonder weinig processortijd.

Voordat de 7-segmentdisplays aangestuurd kunnen worden moet de TM1637 eerst geconfigureerd worden. Hierbij wordt een keuze gemaakt of de TM1637 gebruikt wordt voor het aansturen van een display of het uitlezen van een keyboard (het K-bit) en of de (maximaal) zes 7-segmentdisplays afzonderlijk of automatisch ná elkaar geadresseerd worden (het F-bit).

Bit:  7 6 5 4 3 2 1 0
Data: 0 1 0 0 0 F K 0

In mijn geval wordt zowel het K-bit (bit 1) als het F-bit (bit 2) laag gehouden. Dus:

Bit:  7 6 5 4 3 2 1 0
Data: 0 1 0 0 0 0 0 0

In de software ziet dit er als volgt uit:

TM1637 Configuratiebericht


Daarna wordt het display aangezet met een bepaalde helderheid:

Bit:  7 6 5 4 3 2 1 0
Data: 1 0 0 0 S A B C

Het S-bit zet het display aan. De drie bits A, B en C bepalen de helderheid van het display. De helderheid (brightness) loopt van 000 naar 111 en heeft dus acht verschillende standen. In de software gebruik ik hiervoor een eenvoudige functie:


TM1637 Brightness

Nu de TM1637 geconfigureerd is, kunnen de 7-segmentdisplays aangestuurd worden. De TM1637 wil eerst weten welke van de (maximaal) zes displays gewijzigd moet worden. We starten altijd bij display 0. Het adres wordt na het eerste cijfer automatisch opgehoogd, dat is met het F-bit (zie hierboven) zo geconfigureerd. In geval van zes cijfers worden achtereenvolgend de volgende commando's naar de TM1637 gestuurd:

  1. Start
  2. Adres ( = 0 )
  3. Ackn
  4. Cijfer 1
  5. Ackn
  6. Cijfer 2
  7. Ackn
  8. Cijfer 3
  9. Ackn
  10. Cijfer 4
  11. Ackn
  12. Cijfer 5
  13. Ackn
  14. Cijfer 6
  15. Ackn
  16. Stop

Dat is alles. Hoewel... De cijfers bestaan uit 7 segmenten. Bij elk cijfer moet een andere combinatie van segmenten oplichten. Het cijfer moet hiervoor omgezet worden naar een bitpatroon. Hiervoor is de software voorzien van een constant array met tien posities:


Van decimaal naar 7-segment

De bitpatronen weerspiegelen de op te lichten segmenten. De positie in het array bepaalt het cijfer dat gepresenteerd moet worden. Bij het achtste element (overeenkomstig het cijfer 8) is goed te zien dat alle zeven segmenten op moeten lichten.

Alle puzzelstukje bij elkaar ziet de functie om een getal (number) met al zijn cijfers (digits) te presenteren er als volgt uit:


Getal presenteren op het display


Met deze derde 'list' is het gelukt om maximaal zes cijfers op een display te tonen en hier maar twee digitale uitgangen van de microcontroller voor te gebruiken. Samen met list 1 en list 2 ben ik nu in staat om behoorlijk wat knoppen en lampjes aan te sluiten. Maar ik wil nog meer... Binnenkort list nummer vier!

vrijdag 6 maart 2020

Software - De list (2: NeoPixels)

Een tweede list voor het minieme aantal ingangen en uitgangen van de ESP32 wordt bedacht voor de aansturing van alle indicatie- en storingslampjes. De dashboardlampjes zouden aangestuurd kunnen worden met de I/O-expanders uit het vorige bericht. Maar dat zou te gemakkelijk zijn ;-). Het idee is om hiervoor NeoPixels te gaan gebruiken.


https://www.adafruit.com/


NeoPixels zijn RGB-leds die via één digitale uitgang van de ESP32 aan te sturen zijn. Over die digitale uitgang wordt een patroon van bits naar de NeoPixel gestuurd. Precies 24 bits; voor elke kleur - rood, groen en blauw - acht bits. Met die acht bits wordt de intensiteit van elke kleur ingesteld (0..255) en kunnen dus 256 x 256 x 256 = ruim 16 miljoen kleuren gekozen worden. Mooi, één digitale uitgang voor 16 miljoen kleuren! Maar het wordt nog mooier, want NeoPixels kunnen in een string achter elkaar geschakeld worden; en ook dan is er nog steeds maar één digitale uitgang nodig. Zijn er twee NeoPixels achter elkaar geschakeld, dan worden niet 24, maar 48 bits naar buiten gestuurd. De eerste 24 bits worden door de eerste NeoPixel 'gebruikt', de resterende bits worden doorgestuurd naar de tweede NeoPixel. Zo kunnen er honderden achter elkaar geschakeld worden waarbij elke NeoPixel telkens 24 bits van het treintje bits afsnoept en de rest doorgeeft. Ik wil (o.a.) gebruik maken van een stick met acht NeoPixels:


https://www.adafruit.com/


Voldoende voor alle indicatielampjes en nog voor andere creatieve uitingen. Zo kan zo'n balkje ledjes ook gebruikt worden ter indicatie van het toerental.

Tot nu toe klinkt het allemaal positief. Maar er zit een addertje onder het gras. De NeoPixels zijn behoorlijk kritisch als het gaat om de timing van de pulsjes die ontvangen worden. Dit komt omdat er maar één pin gebruikt wordt voor het bitpatroon en daarnaast niet net als bij I²C-bus een separaat kloksignaal aanwezig is. Een digitale 0 wordt gevormd door de uitgang van de ESP32 eerst gedurende 300 ns (jawel nanoseconde) hoog te maken en vervolgens 800 ns laag. Een digitale 1 wordt herkend als de uitgang 800 ns hoog en 325 ns laag wordt gemaakt.


WS2812-timing

Als de uitgang enkele tientallen microseconden laag blijft (Treset), dan worden de nieuw ontvangen RGB-waarden van alle NeoPixels gebruikt om gelijktijdig alle leds aan te sturen. De leds houden die kleur totdat er een nieuw treintje met kleurenbits is langsgekomen. Omdat de tijdwaarden zo kort zijn, gaat dit allemaal razendsnel. Dit protocol is vastgelegd in de WS2812-specificatie. Er zijn inmiddels enkele verschillende versies van dit protocol waarbij vooral de timing anders is. En omdat juist die timing een beetje kritisch is, is het belangrijk om te weten welke versie van de WS2812-specificatie bij de gebruikte NeoPixels hoort.

De ESP32 werkt - zoals in het vorige bericht vermeld - met een multitasking besturingssysteem genaamd FreeRTOS. De verschillende taken die hierin draaien moeten zo nu en dan wat tijd gunnen aan de andere taken. Normaliter gebeurt dit door een taak even zogenaamd te pauzeren. In een microcontroller zónder multitasking besturingssysteem (bijvoorbeeld een Arduino UNO) zal een delay-functie de processor eventjes bezig houden (blocking) en vervolgens weer met het programma verder gaan. In een multitasking besturingssysteem is dit uit den boze. Het pauzeren van een taak zal de processor niet blokkeren, maar juist de tijd geven wat aandacht aan een andere taak te geven. In een FreeRTOS-taak wordt hiervoor de functie vTaskDelay() gebruikt. Deze functie accepteert een aantal ticks als argument. Eén tick is de kleinste tijdsduur die te gebruiken is om een taak te pauzeren. De lengte van een tick is afhankelijk van de snelheid waarmee FreeRTOS tussen taken schakelt. En dat doet 'hij' standaard 100 keer per seconde. Zo'n tick is hierdoor ongeveer 10 ms. Je ziet direct dat dit véél te lang is om de WS2812-timing voor elkaar te krijgen. Dit moet dus op een andere manier aangepakt worden.

Bij de I²C-bus hadden we dit probleem niet, omdat de timing en afhandeling van die bus in de hardware van de ESP32 wordt uitgevoerd. Voor het WS2812-protocol is echter geen hardware in de ESP32 aanwezig. Of misschien toch wel...

Zoekende op internet en in de documentatie van Espressif (de maker van de ESP32) kwam ik de Remote Control-hardware (RMT) tegen. Net als de CAN-bus en de I²C-bus een stukje hardware in de ESP32 waarmee het bitpatroon van een afstandsbediening gerealiseerd kan worden. De meeste afstandsbedieningen werken met een infrarood-led. Deze led zendt afhankelijk van de ingedrukte knop op de afstandsbediening (en het merk) een ander treintje bitjes naar de ontvanger (bijv. de tv). Ook dit bitpatroon volgt een strikt tijdschema.

Een klein deel van het RMT-blokschema (Espressif)

De RMT-hardware is net als de CAN-bus en de I²C-hardware vooraf te voorzien van een reeks commando's - hier een serie getalletjes waarmee de tijd van het hoog en laag worden van de digitale uitgang bepaald wordt. Vervolgens krijgt de RMT-hardware vanuit de software de opdracht zijn ding te doen. Daar is de software dan niet meer bij betrokken. De precieze timing wordt volledig afgehandeld door de RMT-hardware zelf. Deze heeft een tijdresolutie overeenkomstig de interne klok van de microcontroller. Die draait op 80 MHz, wat overeenkomt met een tijdresolutie van 12.5 ns. Aangezien de timing van de WS2812 in de grootteorde van 100 ns ligt, is dit nauwkeurig genoeg.

Timing-data

De timing-data wordt aangeboden in een array van 32-bits woorden. Die 32-bits wordt gevuld met twee keer een tijdsduur van 15 bits en de resterende twee bitjes om het niveau van het signaal aan te geven. Als ik het niet zou weten, zou ik denken dat het bedacht is voor het WS2812-protocol. Voor elk bit heb je in dit protocol namelijk een Hoog- en een Laag-tijdsduur (zie hierboven) nodig. Om één NeoPixel aan te sturen zijn precies 24 (3 x 8 voor R, G en B) bits nodig; voor de RMT-hardware komt dit neer op een array van 24 x 32-bits woorden. Voor een stick van acht NeoPixels komt dit uit op 8 x 24 x 32 bits. Da's ruim 6000 bits. Voor een doorsnee computer een druppel op een gloeiende plaat, voor een microcontroller best wel wat geheugen. Gelukkig heeft de ESP32 aardig wat geheugen aan boord, dus dat levert hier geen beperkingen op.

Naast de taken die eerder beschreven zijn (CAN-bus en I²C-bus) is er nu weer een belangrijke taak bijgekomen. Het aansturen van NeoPixels via de RMT-hardware. Drie onafhankelijke taken die netjes door FreeRTOS afgehandeld worden. Er komen er nog meer...

zondag 1 maart 2020

Software - De list (1: I²C)

In het vorige bericht werd duidelijk dat het aantal vrije in- en uitgangen (19 stuks) van de microcontroller (ESP32) niet toereikend is voor alle dashboardfuncties van de Burton. Zeker niet omdat ik méér mogelijkheden wil introduceren dan dat er standaard in de eend zitten. Dit vraagt om een list, zou Burton-bouwer Anton Folkeringa zeggen. Zoek op het internet naar "i/o expander" en je komt al snel de PCF8574 van NXP (voorheen Philips) tegen.

https://pmdway.com/products/pcf8574-8-bit-i2c-i-o-expander-dip-5-pack

Dit is een relatief eenvoudig IC waarmee het aantal ingangen en/of uitgangen van de microcontroller uitgebreid kan worden. De PCF8574 wordt met de microcontroller verbonden via een tweedraads I²C-bus (Inter-IC-bus). De ESP32 heeft standaard twee I²C-bussen aan boord, dus daar kunnen we er wel eentje van gebruiken. Van de 19 vrije in- en uitgangen worden er twee gebruikt voor deze tweedraads bus. Eentje voor de klok (SCL) en eentje voor de data (SDA). Eén PCF8574 bevat acht digitale poorten. Ze kunnen als ingang of als uitgang gebruikt worden. De I²C-bus is - zoals de naam al doet vermoeden - een bussysteem waar - net als bij de CAN-bus - meerdere apparaten op aangesloten kunnen worden. Anders dan bij de CAN-bus gaat het bij de I²C-bus echter over het verbinden van IC's en hele korte afstanden, meestal op dezelfde printplaat. Er kunnen dus ook meerdere PCF8574-IC's aan dezelfde bus gekoppeld worden. Drie van de pinnen van het IC worden gebruikt om een digitaal adres in te stellen, van binair 000 tot 111 zijn dit acht verschillende adressen. Uiteindelijk kunnen er van hetzelfde IC dus acht verbonden worden met de microcontroller, resulterend in 8 x 8 = 64 in- of uitgangen. En alsof dat nog niet genoeg is, is er nog de PCF8574A (zie foto hierboven) waarmee nog eens acht IC's aan de bus toe te voegen zijn. Méér dan voldoende dus!

Op internet zijn mooie compacte modules te vinden met handige pinnen voor het aansluiten van de acht in- of uitgangen, de twee lijnen van de I²C-bus, de voeding en het instellen van het 3-bits-adres.

Twee varianten van een PCF8574-module

Voor de ESP32 is een handige bibliotheek beschikbaar waarmee de I²C-hardware van de microcontroller aangestuurd kan worden. De berichten voor op de bus worden eerst voorbereid en netjes op een rij in het geheugen gezet, waarna de I²C-hardware de opdracht krijgt om onafhankelijk van de afloop van het programma de I²C-communicatie af te handelen. De timing op de bus wordt door de hardware van de controller geregeld en is dus niet afhankelijk van de software. Da's mooi, want dan hoeven we ons daar geen zorgen om te maken.


https://www.freertos.org/


De ESP32 bevat twee processor-cores en wordt standaard voorzien van het FreeRTOS realtime operating system. Dat klinkt ingewikkeld, maar is het juist niet. FreeRTOS geeft namelijk de mogelijkheid om met parallel draaiende taken te werken (Multi Tasking). Erg handig als je gelijktijdig meerdere taken af moet handelen. Een van de taken is natuurlijk de communicatie over de CAN-bus. Nu hebben we er een belangrijke taak bij: de afhandeling van de I²C-communicatie. En wacht maar, er komen nog aardig wat taken bij...

dinsdag 28 januari 2020

Software - Who am I

Waarom één microcontroller gebruiken als het er ook méér kunnen zijn. Da's natuurlijk geen doel op zich, maar wel een resultaat van de gemaakte keuzes. Elke node op de CAN-bus wordt gevormd door een gelijke DevKit voorzien van een microcontroller van het type ESP32:

ESP32 DevKit

De pinnen van de node worden gebruikt voor het aansluiten van Inputs en Outputs (I/O). Eenvoudige I/O van het type GPIO (General Purpose Inputs/Outputs), maar ook I/O voor de CAN-bus en pinnen voor de stroomvoorziening. Veel van de pinnen hebben speciale functies die deels te configureren zijn, maar ook deels ongewijzigd moeten blijven. Nader onderzoek resulteert in het volgende schema:

Fysieke I/O

Van de 30 pinnen blijven er relatief weinig over om vrij te gebruiken. In de kolommen met de naam Functie staat <spare> vermeld als de pin vrij is. Enkele pinnen hebben al een vaste functie gekregen die voor élke node gelijk is:
  • PIN34, PIN35, PIN36 en PIN39 zijn pinnen die alleen als Input te gebruiken zijn. Drie van deze pinnen worden ingezet om de node te identificeren. Hierover zometeen meer.
  • PIN04, PIN05, PIN12 en PIN15 zijn zogenaamde strapping-IO's en hebben tijdens het opstarten een speciale functie. Er wordt geadviseerd om ze met rust te laten (floating).
  • GND (2x), VIN en 3V3 dienen voor de voeding.
  • PIN01 en PIN03 (resp. TXD0 en RXD0) zijn in gebruik voor het programmeren van de node.
  • PIN16 en PIN17 worden ingezet voor de koppeling met de CAN-bus.
  • PIN02 is intern verbonden met de blauwe LED op de DevKit. Deze zal gebruikt worden om activiteit op de CAN-bus te signaleren.
Uiteindelijk blijven er dertien pinnen over om ingezet te worden voor diverse functies zoals het uitlezen van schakelaars of het aansturen van lampen. Dat lijkt best nog veel, maar zeker bij het dashboard red je het daar niet (zomaar) mee. Denk maar eens aan alle schakelaars en indicatielampjes en je gaat al snel over de dertien heen. Dat betekent dat een list bedacht moet worden of dat er een node bijgeplaatst moet worden. In een later bericht meer over dit dilemma.

Hierboven werden al de drie identificatiepinnen (PIN34, PIN36 en PIN39) genoemd. Die worden gebruikt om de node te identificeren. Alle nodes zijn namelijk gelijk. Niet alleen hardwarematig, maar ook softwarematig wil ik ze gelijk houden. Alle nodes krijgen dus dezelfde software, maar moeten wel verschillende functies uitvoeren. Bij het opstarten worden de drie pinnen uitgelezen en op basis hiervan worden sommige functies in de software wel of niet geactiveerd. De drie pinnen kunnen elk aan 0 volt of 3.3 volt gekoppeld worden en zo ontstaan er acht verschillende identificatiecodes (binair: 000, 001, 010, 011, 100, 101, 110 en 111). Dat betekent dus dat er op deze manier maximaal acht nodes mogelijk zijn. Lijkt me genoeg voor een Burton.

Voor de liefhebbers een stukje C-code waarmee de drie identificatiepinnen uitgelezen worden:

Functie "whoAmI".

De software wordt ontwikkeld in Visual Studio Code met de plug-in PlatformIO. Een prachtige combinatie waarmee vrij eenvoudig software voor diverse microcontrollers ontwikkeld kan worden. Voor diegene die al eens met de Arduino IDE gewerkt hebben, stap gerust over op PlatformIO. Daar ga je geen spijt van krijgen. Om de softwarefuncties te testen zijn twee nodes op een breadboard geplaatst. Hieronder een testopstelling met de verlichtingsschakelaar aan de ene node en de lampen (hier blauwe LED's) aan de andere node. Lijkt al snel een onoverzichtelijke spaghetti op zo'n breadboard.


Testopstelling. Het geel/oranje kabeltje is de CAN-bus.

Inmiddels is er al heel wat meer software geschreven waarover nog wel wat berichtjes gaan volgen. De basisopzet is gereed maar het is nog lang niet klaar. Morgen komt - als het goed is - de hoge voorruit binnen. Fijn, want die heeft wel even op zich laten wachten.