PIC, Arduino, Atmel, AVR, Adafruit.... i am lost!!!!


Egbert, kijk eens bij www.knutselaar.eu . gratis proton basic compiler voor een aantal pic Ic’s ook compacte 18 en 28 poots pic moederboardjes voor weinig.

buckfast_beekeeper

Golden Member

Als TS al geprogrammeerd heeft in C, waarom zou hij dan basic gaan gebruiken? Een arduino als opstap. Dan zit je ook snel bij een esp8266, esp32, ....

Van Lambiek wordt goede geuze gemaakt.
bprosman

Golden Member

Hoewel ik de PIC nu weer interessanter ga vinden omdat die blijkbaar ook met C te programmeren is.

Een AVR ook, en beiden ook in Basic :
http://gcbasic.sourceforge.net/Typesetter/index.php/Home

De jongere generatie loopt veel te vaak zijn PIC achterna.
EgbertG

Special Member

Ik kende de site knutselaar.eu nog niet ... toch ook wel weer de moeite waard! Staan leuke dingen te koop...

Basic zou een reden kunnen zijn als het om wat grotere programma's gaat, want ik las dat de C compiler beperkt is tot 4K. Dus ik download m ;-)

Herinner me opeens dat ik bij een van die Arduino's ook altijd gedoe had
met die USB TTL uart interface ellende.

Pe1jku
bprosman

Golden Member

Herinner me opeens dat ik bij een van die Arduino's ook altijd gedoe had
met die USB TTL uart interface ellende.

Met een beetje Googlen en de juiste drivers is dat meestal prima op te lossen.

De jongere generatie loopt veel te vaak zijn PIC achterna.

Omdat de I/O van 99% van de toepassingen zeer basaal is vind ik de programeertaal niet zo relevant.

Het is met 4 druktoetsen een display en wat sensors nou niet zo dat je zwetend zit te kloppen aan linked lists, bubble sorts op multidimensionale arrays en recursion.

Op 6 november 2020 11:53:23 schreef EgbertG:
Basic zou een reden kunnen zijn als het om wat grotere programma's gaat, want ik las dat de C compiler beperkt is tot 4K. Dus ik download m ;-)

En das precies de reden waarom ik nooit aan PIC begonnen ben. Iedere serieuze microcontroller heeft een goede, gratis C compiler zonder beperkingen. Behalve PIC.

Er zijn hobbyisten die hele mooie dingen maken in Basic, maar er zijn er veel meer die in C werken. Dus meer voorbeelden, meer fora, meer mensen die je kunnen helpen.

En das precies de reden waarom ik nooit aan PIC begonnen ben. Iedere serieuze microcontroller heeft een goede, gratis C compiler zonder beperkingen. Behalve PIC.

???
De XC compilers zijn onbeperkt en gratis. (alleen de zwaarste optimalisatiestap ontbreekt)

Er zijn hobbyisten die hele mooie dingen maken in Basic, maar er zijn er veel meer die in C werken. Dus meer voorbeelden, meer fora, meer mensen die je kunnen helpen.

Onzin dat basic altijd met hobbyisten verbonden wordt en wordt afgeschilderd (door onwetenden) als een 'knutseltaaltje', ik kan daar kwaad om worden... :(
Wat je in C kunt maken, kun je ook in een goede Basic als Mikrobasic maken... (Picbasic is te beperkt daarvoor)

Ik maak veel professionele software voor Windows en PIC en bijna altijd in basic.
Voor mensen die er niet mee opgegroeid zijn, is C eencryptisch en moeilijk te doorgronden taaltje. (heb vroeger wel Pascal gebruikt, dat was een stuk beter)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
Lambiek

Special Member

Op 6 november 2020 15:00:46 schreef blurp:
En das precies de reden waarom ik nooit aan PIC begonnen ben. Iedere serieuze microcontroller heeft een goede, gratis C compiler zonder beperkingen. Behalve PIC.

Dan moet je nog maar eens goed zoeken.

Er zijn hobbyisten die hele mooie dingen maken in Basic, maar er zijn er veel meer die in C werken. Dus meer voorbeelden, meer fora, meer mensen die je kunnen helpen.

Onzin, als ik zie wat ik allemaal al gemaakt heb met Proton "ook industrieel" wat gewoon allemaal goed werkt.

Maar het draait weer uit op nietes welles denk en het zoveelste je moet dit gebruiken of dat gebruiken.

Dus het zoveelste topic over microcontrollers en de voor en tegenstanders van allerlei merken en types.

En altijd wordt de PIC af gezeken. :(

Als je haar maar goed zit, GROETEN LAMBIEK.

Tegenwoordig maakt de taal waarin je programmeert totaal niets meer uit: de 'engine' die 'onder de motorkap' code produceert is voor allen gelijk.
Voor wel of niet goede programma's moet je de programmeur bekijken, niet de compiler... ;) Het bekende gezegde:

"It's not the paintbrush that makes a painting, but the artist "...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
EricP

mét CE

En altijd wordt de PIC af gezeken. :(

Zou dat een reden hebben? Ik ben ook met die dingen begonnen. In de tijd dat je ze nog met UV moest erasen. Taal was assembly. Wat een draak van een architectuur! (dat is later wel wat beter geworden hoor... maar toch...) En wat een verademing toen er wat anders kwam. (8051 en AVR).

"It's not the paintbrush that makes a painting, but the artist "...

Dat is ook maar ten dele waar. Een 8051 (derivaat) is - by design - erg beperkt in stack. Dat betekent dat wanneer je met een 'stack based' taal aan de gang gaat (ja, ook basic valt daaronder), de compiler allerlei trucen uit moet halen om te doen alsof er toch een stack is. Functioneel werkt dat doorgaans wel. Maar qua performance wordt het soms absurd 'duur' - terwijl je puur op basis van de source code denkt... dit kan toch niet zo spannend zijn (en als je dan naar de gegenereerde assembly kijkt denk je... f*ck... op deze architectuur... is het eigenlijk best spannend wat ik doe). Schoolvoorbeeld van een 'misser': void pointers in C op een 8051. Dat wordt ff gedoe om runtime te bepalen of het spul in ROM, RAM of XRAM zit - dat zijn andere opcodes!

Als je nu iets redelijk toekomst bestendigs wil hebben... STM32 in C. Ook dat zal wel weer een keer 'oud' worden. Maar dat duurt nog eventjes. En nee, het is niet de meest makkelijke combinatie om mee te beginnen.

Voor wat betreft de taal: ik denk dat je in basic ook best mooie dingen kunt maken. Ik ben er (35 jaar geleden...) in begonnen. Daarna kwam assembly (in diverse derivaten), Pascal en toen pas C (en tussen door nog andere assembly varianten). Dat laatste bleek toch een fijne combinatie te zijn van 'de mogelijkheden / efficiency van assembly' en 'het gemak van een hogere taal' zoals Pascal, Basic.
En zoals altijd... als een taal je veel 'mogelijkheden' biedt, dan heb je ook veel mogelijkheden om jezelf in je voet te schieten (been there, done it) - zeker als je kennis van assembly op die architectuur mist. In dat opzicht is Pascal veel formeler - met dus ook minder risico op dergelijke missers.

Arduino... Ik heb er wel eens naar gekeken. Vaak wel behoorlijke hardware (AVRs zijn best robuust en de originele Arduino's gebruiken ook behoorlijke componenten). Er zijn veel libraries, classes of hoe je het noemen wilt voor te krijgen. Van sterk wisselende kwaliteit - dus het is niet altijd een succes. Daardoor ben je erg snel in staat om een werkend iets te bakken - als je mazzel hebt.
Aan de andere kant: soms is het ook een beetje 'worst of all worlds'. Een taaltje wat best ver van de hardware af staat. Libraries die niet altijd doen wat je ervan zou willen - en ga het dan maar eens uit zoeken zonder behoorlijke kennis. Op wat vingeroefeningen na begrepen dat het voor mijn tak van sport het niet is.

Lambiek

Special Member

Op 6 november 2020 15:55:23 schreef EricP:
Zou dat een reden hebben? Ik ben ook met die dingen begonnen. In de tijd dat je ze nog met UV moest erasen. Taal was assembly. Wat een draak van een architectuur! (dat is later wel wat beter geworden hoor... maar toch...)

Dat was toen, over nu kun je niet oordelen.

Als je haar maar goed zit, GROETEN LAMBIEK.

Dat betekent dat wanneer je met een 'stack based' taal aan de gang gaat (ja, ook basic valt daaronder)

Basic heeft niks met wel of niet 'stack based' te maken.
't Is gewoon een front-end dat code aanmaakt die door een linker en assembler wordt gecompileerd tot uitvoerbare code...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Voor mensen die er niet mee opgegroeid zijn, is C eencryptisch en moeilijk te doorgronden taaltje. (heb vroeger wel Pascal gebruikt, dat was een stuk beter)

Dat is inderdaad helemaal waar, toch als je er goed voor gaat zitten en je op de goede volgorde leert gaat het steeds beter. IK had voor de eenvoud alles liever gewoon in basis gezien maar C is er nu eenmaal en zal de maar moeten leren.

Maar het iscfeitelijk gewoon discussie die er niet hoort te zijn. Is de Chinese taal beter dan de Nederlandse taal? Ook een zinloze discussie het is maar net waar je geboren bent, ik ga liever voor Plutonees, daar ben ik geboren :).

Het voordeel van Arduino is tevens ook zijn grootse nadeel. Het voordeel is heel veel bibliotheken die je kan gebruiken, het nadeel is dat ze bijna nooit doen wat ik wil of ten koste van performance.

Basic heeft niks met wel of niet 'stack based' te maken.

Als je een functie aanroept dan zal er toch naar een ander adres gesprongen moeten worden en dan zal je toch al minimaal het return adres op de stack moeten zetten. Als je dus veel geneste functies hebt kan dat zeker nadelig zijn voor de ruimte op de stack.

[Bericht gewijzigd door benleentje op 6 november 2020 16:44:42 (16%)]

Bijna alle libraries zijn veel te uitgebreid (doordat iedereen wat anders wil worden functies steeds uitgebreider) en slorpen daardoor veel meer geheugen op als nodig...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
Schimanski

Golden Member

Op 5 november 2020 19:37:56 schreef benleentje:
[...]Avr en Atmel zijn chip fabrikanten en hebben elk zo hun eigen platform. [...]

Op 5 november 2020 21:33:02 schreef Ex-fietser:
[...]PIC's, AVR, Atmel zijn net als intel en motorola vroeger chipbakkers. [...]

Microchip en Atmel zijn fabrikanten. PIC® en AVR® zijn microcontroller-families.

What, me worry? // Radiozendamateur - PA2HGJ // Stuff is the junk you keep -- Junk is the stuff you throw away // Tinkeo Ergo Sum
EricP

mét CE

Basic heeft niks met wel of niet 'stack based' te maken.
't Is gewoon een front-end dat code aanmaakt die door een linker en assembler wordt gecompileerd tot uitvoerbare code...

Eh... toch ff een college compilerbouw volgen :) Je ziet het iets te simpel - ik meende dat jij toch zeker ook wel de nodige assembly geschreven zou hebben en dus zou snappen wat ik bedoel.

Bijna alle libraries zijn veel te uitgebreid (doordat iedereen wat anders wil worden functies steeds uitgebreider) en slorpen daardoor veel meer geheugen op als nodig...

Dat is nog tot daar aan toe (ik bedoel... een paar k meer kost niks), maar door al die functionaliteit doorgaans ook meer bugs. En minder performance. Het eerste is altijd naar. Het 2de soms.

Maar het iscfeitelijk gewoon discussie die er niet hoort te zijn. Is de Chinese taal beter dan de Nederlandse taal? Ook een zinloze discussie het is maar net waar je geboren bent, ik ga liever voor Plutonees, daar ben ik geboren :).

Toch is dat niet helemaal waar. Alhoewel de vergelijking wat mank gaat (immers, de omvang van de source code is niet zo interessant), is de ene taal efficiënter dan de andere. Nederlands is doorgaans langer dan Engels. Duits is doorgaans langer dan Nederlands. En dan neem ik aan dat ik niet hoef uit te leggen dat het om dezelfde inhoud gaat. Zo zijn er ook talen die voor (vrijwel) hetzelfde begrip meerdere uitdrukkingen hebben, met kleine nuance verschillen. Als die nuances van belang zijn, dan is een taal die daar uitdrukkingen voor heeft waarschijnlijk beter om te gebruiken dan een taal die die uitdrukkingen niet kent en waar alles omschreven moet worden.
Als dat allemaal geen moer uit maakt... Doe het vooral in het Plutonees :). Maar zodra dat wel een rol speelt, is de taal wel degelijk van belang.

buckfast_beekeeper

Golden Member

Op 6 november 2020 17:14:12 schreef Schimanski:

[...]
Microchip en Atmel zijn fabrikanten. PIC® en AVR® zijn microcontroller-families.

En Atmel is opgeslorpt door Microchip, net als Micrel.

TS geeft aan dat hij al geprogrammeerd heeft in C. Heeft dan al zeker een basis om te starten. Als je in het Nederlands kan schrijven, wat je al beheerst, waarom zou je het dan plots in het chinees gaan doen, terwijl je die taal nog volledig moet leren.

NB: chinees is ook de gebruikelijke naam voor een Franstalige militair in het Belgische leger.

Van Lambiek wordt goede geuze gemaakt.

is de ene taal efficiënter dan de andere. Nederlands is doorgaans langer dan Engels. Duits is doorgaans langer dan Nederlands. En dan neem ik aan dat ik niet hoef uit te leggen dat het om dezelfde inhoud gaat.

Ik zei niet dat er geen verschillen zijn maar de discussie erover is vrij zinloos. Kijk gewoon naar de taal die je wilt gebruiken lees daarover wat de voor en nadelen zijn en maak op die basis een beslissing en daarbij mag persoonlijke voorkeur ook mee genomen worden.

Maar deze discussie hier gaat vooral over de persoonlijk voorkeur en die discussie is altijd zinloos. IK ga ze normaal gesproken ook zoveel mogelijk uit de weg.

Als je in het Nederlands kan schrijven, wat je al beheerst, waarom zou je het dan plots in het chinees gaan doen, terwijl je die taal nog volledig moet leren.

Dat is wat ik probeerde te zeggen maar blijkbaar verkeerd over kwam :).

En dat terwijl de Chinese taal veel uitgebreider is ze hebben bv veel meer gradaties voor het begrip ""je gelukkig voelen"" het is een oudere taal die meer geëvolueerd is. Maar dat betekend niet dat je in het Nederlands je minder goed kan uitdrukken je hebt er enkel meer worden voor nodig dat is ook wat EricP omschrijft in de efficiëntie van een taal.
Basic en C zijn ook nog lang niet uit ontwikkeld en voor beide zal er continu hard gewerkt worden om het nog efficiënter te krijgen.

Mijn persoonlijke ervaringen over een aantal zaken dat je moet afwegen:

-Arduino & de IDE.
Pro's: Goedkoop (ja ook de originele bordjes, het is meer dan enkel een mcu),eenvoudige programmeeromgeving ,je hoeft de datasheet van de mcu niet volledig uit te spitten, mooie library's te vinden (een lib schrijven kan soms heel erg veel tijd nemen), snel een resultaat, met de usb aansluiting is een software-update / aanpassing snel gedaan, grote community die daar mee bezig is.

Con's: Oogt niet geweldig pro, speciale hardware features van de mcu kan je niet direct aan (i/o is allemaal achter de schermen gelinked), Arduino taal is géén pure C taal als je in atmelstudio een mcu zou willen programmeren, library's op het www zijn niet altijd geweldig goed of er zijn problemen qua timing / afhandelen van taken. Het is dan meer wat knip- en plakwerk, ipv een eigen ontwikkeling.
In de meeste "basis" boeken besteed men erg héél erg weinig aandacht aan interrupts, structs en pointers, terwijl dat dat je programma toch krachtiger maakt, betere respons geeft. Veel te veel focus op de "millis" variabele.
Ook de "delay" functie zou verbannen moeten worden. Daar hebben ze gelukkig op de site van Arduino toch al wat meer "warnings" bij geplaatst.Een eerste knipperende led zou voor mij met interrupts en timers gedaan moeten worden ipv je mcu niets te laten doen...
In de IDE is er geen intellisense, of link naar functies.Je bent snel bezig in notepad++ in de lib te gaan neuzen welke functies er nog beschikbaar zijn. Het debuggen blijft bij een serial output, of een pinneke hoog en laag laten worden.

Alternatieven / aanpassingen op Arduino:
-Een bordje van ST gaan gebruiken in de Arduino ide -> pas op, io pinnekes moet je zelf juist gaan definiëren/linken in het programma.
-Je kan je Arduino IDE ruilen voor de Atmel studio, met "visual micro" software. (betalende licentie) Dat in combinatie met een Segger Serial Wire Debugger (SWD), heb je debugging capaciteiten en intellisense naar functies / classen enz..
Met visual micro blijf je dan met de taal "Arduino C", ipv echte "C".
Zo kan je ook nog "meeliften" op de lib's die je op het www vindt, maar toch een IDE met meer features.
(Ik spreek hier nu voor hobby projectjes hé)
Er bestaat ook PlatformIO voor visualstudio code, maar dan denk ik dat Atmel studio een beter platform is.

-Custom AVR/PIC whatever
Pro's: Je gaat de hele datasheet doornemen, je beheerst dus alle aspecten van de controller die je gekozen hebt. Je programma is dus meer op je mcu afgestemd. Je hebt door dat er soms een kristal nodig is om je mcu een kloksignaal te geven. Ook een MCLR pin hoog maken doe je vanzelf. Debugmodelijkheden als je voor SWD kiest, of JTAG, etc..

Con's:
De datasheet van je mcu zal je goed moeten doorlezen, wat meer tijd neemt.
Je programma is minder "universeel" tov een arduino programma. Hiermee bedoel ik dat bvb de instelling van een bepaalde prescaler van een timer bij elke mcu anders kan zijn. Daardoor is je programma wel performanter.
Library's -> zal je zelf moeten schrijven of voorbeelden op het www zoeken. Je hebt een breadbord en wat randcomponenten nodig om je mcu te laten werken. (of je neemt een ontwikkeldbordje)

Daarnaast wil ik nog volgende zaken meegeven:
-Een mcu kost niet zoveel meer, dus voor een hobby project wat extra rekenkracht en geheugen is zeker handig, al zit er dan een véél te grote, inefficiënte library in, geen probleem.
Maarrrr, de datasheet van een eenvoudige kleine mcu kan je nog eens gemakkelijk doorlezen, de datasheet van een 32bit monster is soms zéér uitgebreidt (1000 pagina's en meer), om dan een interruptje te gaan opzetten in je arduino... dan is het voor mij geen onstpanned namiddag projectje meer...

Alles heeft z'n voor en nadelen, in elk opzicht.
Financieël / leercurve / resources etc...

Om een voorbeeldje te geven, configuratie van een interrupt.
Bij mikrobasic, voor een dsPIC:

pic basic code:


 sub procedure InitTimer1()
  T1CON         = 0x8000      ' 0x8000 = TON op ON, 0x0 TON op OFF
  T1IE_bit         = 1       'Timer1 Interrupt Enable bit
  T1IF_bit         = 0       'Timer1 Interrupt Flag Status bit
  IPC0                 = IPC0 or 0x1000   ' Interrupt Priority Control Register 0
  PR1                 = 1000           ' 16 bit Timer1 Period Register
end sub

Bij Arduino IDE, voor een Arduino MKRzero:

c code:

 noInterrupts();           // disable all interrupts
  GCLK->CLKCTRL.reg = GCLK_CLKCTRL_CLKEN |                 // Enable GCLK0 for TC4 and TC5
                      GCLK_CLKCTRL_GEN_GCLK0 |             // Select GCLK0 at 48MHz
                      GCLK_CLKCTRL_ID_TC4_TC5;             // Feed GCLK0 output to TC4 and TC5
  while (GCLK->STATUS.bit.SYNCBUSY);                       // Wait for synchronization

  TC4->COUNT16.CC[0].reg = 29999;                          // Set the TC4 CC0 register as the TOP value in match frequency mode
  while (TC4->COUNT16.STATUS.bit.SYNCBUSY);                // Wait for synchronization

  NVIC_SetPriority(TC4_IRQn, 0);    // Set the Nested Vector Interrupt Controller (NVIC) priority for TC4 to 0 (highest)
  NVIC_EnableIRQ(TC4_IRQn);         // Connect TC4 to Nested Vector Interrupt Controller (NVIC)

  TC4->COUNT16.INTENSET.reg = TC_INTENSET_OVF;             // Enable TC4 overflow (OVF) interrupts

  TC4->COUNT16.CTRLA.reg |= TC_CTRLA_PRESCSYNC_PRESC |     // Reset timer on the next prescaler clock
                            TC_CTRLA_PRESCALER_DIV8 |      // Set prescaler to 8, 48MHz/8 = 6MHz
                            TC_CTRLA_WAVEGEN_MFRQ |        // Put the timer TC4 into match frequency (MFRQ) mode
                            TC_CTRLA_MODE_COUNT16;         // Set the timer to 16-bit mode
  while (TC4->COUNT16.STATUS.bit.SYNCBUSY);                // Wait for synchronization

  TC4->COUNT16.CTRLA.bit.ENABLE = 1;                       // Enable the TC4 timer
  while (TC4->COUNT16.STATUS.bit.SYNCBUSY);                // Wait for synchronization
  interrupts();             // enable all interrupts

Maarrrr, de datasheet van een eenvoudige kleine mcu kan je nog eens gemakkelijk doorlezen, de datasheet van een 32bit monster is soms zéér uitgebreidt (1000 pagina's en meer)

Ach,

Als 't voor hobby is heb je tijd genoeg (zeker nu... ;) )
Kleine controllers zijn tegenwoordig trouwens niet eenvoudig: een 8 pinner als de 12f1571 heeft al gauw 400 blz. aan datasheet...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Wat voor mij belangrijk was en is aan Arduino is dat het zonder gedoe een complete, werkende toolchain oplevert.
Om die zelf in elkaar te zetten en goed werkend te houden was voor mij over de jaren niet te doen, dat is mijn hobby niet.

Of men in de Arduino omgeving de Arduino functies / libraries gebruikt of niet, en liever direct naar de registers schijft is een vrije keuze.
In het laatste geval zijn er enkel enkele keywords bezet, verder is niets verplicht.

De impliciet meegecompileerde Arduino library (met functies als delay(), digitalWrite(), pinnummers etc.) was ooit bedoeld voor een niet-technische doelgroep, terwijl de Arduino ecosysteem inmiddels een soort grootste gemene deler geworden is voor open source microcontroller ontwikkelfrutsels.
Dat zijn erg verschillende dingen, die niet per sè op elkaar passen.

buckfast_beekeeper

Golden Member

Op 7 november 2020 15:34:39 schreef coldrestart:
[...]
Ook de "delay" functie zou verbannen moeten worden.

Niet geheel met je eens. Wat nut heeft het zaken naar een LCD, WiFi of Serial te schrijven als deze niet eens deftig zijn opgestart of connectie hebben gemaakt? Is het een probleem dat een µC in de setup een keer een seconde wacht alvorens de main uit te voeren? Ook in pure C zit de _delay_us en _delay_ms. Ik ben het met je eens dat je goed moet beseffen wat het doet en dat het niet altijd de goede keuze is. Maar geld dat ook niet voor de interrupt? Is een interrupt mandatory nodig voor een knopje wat niet tijd kritisch is en je main wordt meerdere keren per seconde doorlopen. Als voorbeeld een knopje wat je ledje laat aan of uitgaan. Komt dat op de ms nauwkeurig?

Van Lambiek wordt goede geuze gemaakt.

Een delay is goed met opstarten of als de processor verder toch niks te doen heeft, anders niet.
Een wait maken in een timerinterrupt is maar een paar regels code en veel beter.

Als je intensief interrupts gebruikt, kan een gewone delayloop zoals delay_ms(500) makkelijk 1000mS duren, ook een reden om een interrupttimer te gebruiken.

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Op 7 november 2020 15:34:39 schreef coldrestart:
Ook de "delay" functie zou verbannen moeten worden.

Doe niet zo dramatisch. Dan zou ik liever zien dat alle slechte libraries ook verbannen worden. Maar waarom je bent niet verplicht om een delay te gebruiken het is maar 1 van de vele functies die er zijn.

Een gevorderde programmeur zal zelf wel ooit eens tot de conclusie komen dat de delays niet werken en vanzelf iets anders moeten gaan verzinnen. Hoort gewoon bij het leer proces