Waar zijn we nu mee bezig ? Microcontrollers

[PeterC]

citaat:Geplaatst door doomslu

Nostalgie. 16 K geheugen hadden we toendertijd ter beschikking.
Voor de jeugd: niet lachen h?. [!]

In mijn jonge jaren nog een volledige liftsturing geprogrammeerd op net iets minder dan 1K (1024 bytes) - noodgevallen waren er niet bij (geen ruimte om te programmeren) - en als we nu kijken naar een PC geheugen (als je wat mee bent: 4GB ) is dat 4 miljoen keer meer dan dat ik toen ter beschikking had....

Met diezelfde code van weleer kan ik nu (in code en met die hoeveelheid geheugen): de lift sturen;  de dames een 'heel uitgebreide' verwenbeurt geven, de heren van een aangepast drankje voorzien en met z'n allen een gezellig praatje maken...  

...helaas is met de toegenomen hoeveelheid geheugen het programmeren er enorm op verwaarloosd.  Bytes tellen niet meer en enkele MB's (GB's) meer om sneller een 'product' af te leveren spelen geen rol meer...

[PeterC]

Controllers en nauwkeurigheid...  Valkuil!

Bij het uitbreiden van mijn 16F684-projectje, wou ik een dokatimer maken.  Met twee potmeters de tijd instellen (??n voor de minuten, ??n voor de seconden - dit om de werking van de ADC te laten zien) en de tijd op een LCD scherm laten zien (ingesteld en resterend).  Via een knopje wordt de timer gestart.  Geen probleem, alles werkt.

Maar toch...  ...aangezien ik een controlefreak ben, toch een chrono ernaast en de werkelijke tijd meten...
Bij 3000 seconden (volgens de ?C) kwam ik in werkelijkheid op 3021.6 seconden...  Meerdere metingen (over lange tijd) en er was telkens een fout van -0.7%!

De code nagezien en nogmaals nagezien...  tot ik de datasheet van de processor nog eens ter handen nam en daarin staat letterlijk dat de interne oscillator (die ik gebruik) vanuit het productieproces gecallibreerd is op +/-1%!  Met mijn -0.7% zat ik onder die limiet.  Een andere controller met dezelfde software gaf een afwijking van -0.5% (telkens een negatieve afwijking - de werkelijke tijd is minder dan de gecontrolleerde).

De oplossing: een kristal aan de controller hangen (tollerantie 0.000050 % - 50 ppm) maar dan 'verlies' je twee aansluitpennen...

[Geert]

Kan je met de OSCTUNE Register de OSCILLATOR-frequentie niet aanpassen?

Geert

[PeterC]

Geert, inderdaad, maar dat moet voor iedere PIC afzonderlijk gebeuren en dan heb je een juiste referentie nodig om je tijd mee te synchroniseren...  Je zou al een testcircuit moeten opbouwen, software in de chip die de klok op de juiste frequentie instelt en die die waarde teruggeeft (of in zijn geheugen opslaat).  Je definitieve software zou dan die waarde kunnen uitlezen.

Ik ga voor de 1% fout of een kristal [^].

[Steam.N]

Peter,

heb je niet automatisch een kleine vertraging, omdat je telkens de interrupt routine activeert?
Fout zal klein zijn, maar als je dat duizende keren doet ...
Zelfs als je als eerste instructie de timer terug opstart ...

[PeterC]

Jean, ja en neen: je interrupt komt klokvast op hetzelfde tijdstip.  De routine wordt telkens evenveel ?s later geactiveerd en de vlag wordt ook weer telkens evenveel ?s later gezet.  Er is wel een vertraging tussen het moment van de interrupt en het moment wanneer de tijd op het scherm verschijnt, maar dat verschil is constant en cummuleert niet.

Het is wel degelijk een afwijking van de oscillatorfrequentie en om heel zeker te zijn zou ik er eens een 4MHZ kristal moeten aanhangen en opnieuw testen (maar dat kristal vinden in al die doosjes met componenten [:0][:0][:0]...).

[PeterC]

Hello World!

Het 16F684-project (pagina 4)
...

[Steam.N]

Duidelijke uitleg.  Goed te volgen.
Benieuwd hoe je verder gaat []

[PeterC]

Het vervolg: Terug naar analoog.

Het 16F684-project (pagina 5).
...

[Geert]

Goe bezig Peter. Ik heb me tot hiertoe enkel beperkt tot ASM-code en de C-taal. Ik weet dat er een JAL-taal bestaat, met jou handleiding zal ik binnenkort ook eens iets programmeren met JAL.

Geert

[PeterC]

citaat:Geplaatst door Geert

...ASM-code en de C-taal...

Geert, lang met ASM bezig geweest maar kan er de moed niet meer voor opbrengen om zo op bitniveau bezig te zijn.  Met ASM heb je 200% je controller in handen maar is ook zo foutgevoelig.  Weinig of geen foutcontrole en zoveel tijd om te debuggen (je progje mag nog zo goed geschreven zijn, foutjes zitten er altijd in...).

C?  C en C++ enkel gebruik voor (Windows) programma's.  Ook al een tijdje geleden van afgestapt omdat je werkelijk alles kan (ook zaken die je niet wilt!) en alles in de handen hebt.  Overgestapt op object-pascal (Delphi) die wel veel overhead geeft (enorme exe's) maar die minder 'fouten' toelaten.

Voor PIC's vind ik JAL een ideale taal.  Je kan zowel high- als lowlevel gaan werken (gebruik de statement ASM of ASSEMBER/END ASSEMBLER en je kan ganse blokken in ASM toevoegen).

...

Er komt (tijdelijk) een onderbreking in mijn 16F684-projectje...  Vanaf volgende week heb ik enkel nog mijn rechterarm ter beschikking en wordt het wat moeilijk om die (toch enorm veel werk vragende) HTML pagina's te maken...

Nog enkele zaken heb ik in het vooruitzicht: digitale input (schakelaars) en dan als 'eindwerkjes' een doka-timer (tot 23:59:59 instelbaar) en tenslotte een servotester.

Tot...

[Steam.N]

Veel sterkte, en een spoedig herstel!

[Geert]

citaat:Geplaatst door PeterC

citaat:Geplaatst door Geert

...ASM-code en de C-taal...

Geert, lang met ASM bezig geweest maar kan er de moed niet meer voor opbrengen om zo op bitniveau bezig te zijn.  Met ASM heb je 200% je controller in handen maar is ook zo foutgevoelig.  Weinig of geen foutcontrole en zoveel tijd om te debuggen (je progje mag nog zo goed geschreven zijn, foutjes zitten er altijd in...).

C?  C en C++ enkel gebruik voor (Windows) programma's.  Ook al een tijdje geleden van afgestapt omdat je werkelijk alles kan (ook zaken die je niet wilt!) en alles in de handen hebt.  Overgestapt op object-pascal (Delphi) die wel veel overhead geeft (enorme exe's) maar die minder 'fouten' toelaten.

Voor PIC's vind ik JAL een ideale taal.  Je kan zowel high- als lowlevel gaan werken (gebruik de statement ASM of ASSEMBER/END ASSEMBLER en je kan ganse blokken in ASM toevoegen).

...

Er komt (tijdelijk) een onderbreking in mijn 16F684-projectje...  Vanaf volgende week heb ik enkel nog mijn rechterarm ter beschikking en wordt het wat moeilijk om die (toch enorm veel werk vragende) HTML pagina's te maken...

Nog enkele zaken heb ik in het vooruitzicht: digitale input (schakelaars) en dan als 'eindwerkjes' een doka-timer (tot 23:59:59 instelbaar) en tenslotte een servotester.

Tot...

Je vooruitzichtjes mogen er best wezen. Ik ben ??n al oor (en oog).

Goed herstel gewenst...


Geert

[PeterC]

Die vooruitzichten zijn eigenlijk meer als 'tutorials' bedoeld (oa voor mezelf: wanneer ik enkele maanden geen zin meer heb in PIC's, vergeet ik veel).  Die servotester is met dit projectje de uiteindelijke doelstelling.  Die doka-timer is een 'spin-off' voor een collega modelbouwer bij wie ik in zijn draadjes nogal graag commentaar lever (telkens als stimulans []).

Mijn uiteindelijke doelstelling reikt net iets verder: het probleem van Argilla heeft mij aan het denken gezet (automatische adresherkenning) en dit onderdeel zou ik in mijn (ooit eens te verwezenlijken) automatische schuif-fiddle-yard willen gebruiken (zie mijn  'testbaantje').  Het MM protocol decoderen is ??n, het uiteindelijk terug coderen is een andere zaak (en nogal tijdkritisch - 18 ?s voor een kleine puls...).  Misschien iets om 'gemeenschappelijk' over te brainstormen?

waneer ik zoonder hoofdleters enveel vauten terug de draadopneem ben ik aan de beterhand [^][^][^]

Aan allen: Bedankt voor de steun!

[sn00zerman]

Hoi allemaal,


Nu pas dit topic ontdekt ...
Electronica is voor mij een even grote hobby als het (model)spoorgebeuren zelf.
Ik heb reeds m'n eigen bussysteem ontwikkeld, waarmee ik letterlijk alles aanstuur in m'n modelspoorkamer.
Verder nog een complete dag/nacht sturing, bestaande uit dimbare TL's, RGB LEDstrips en halogeen plafondspots.

Het "laatstenieuwe" waar ik nu mee bezig ben, is een variant op het digitale Faller Carsystem.
Ik moest en zou FCS implementeren op m'n baanuitbreiding, en 't moest ook nog eens digitaal zijn :-)
Bij het bekijken van de mogelijke varianten, kwam ik steevast op enkele nadelen uit, waar ik absoluut niet mee wilde leven :-)

- het systeem van VPEB, nog 2 extra draden naast de rijdraad, man man,  wat een werk :-)
- infracar/dccar, overal IR zenddiodes implementeren, dat zag ik ook niet echt zitten.
- het nieuwe digitale FCS, is ook niet "het van het", buiten duur, stoppen en starten de voertuigen nogsteeds even "bruut" als altijd.

Mijn eisen: goedkoper dan bestaande systemen, en RF-based. (dus ??n zender)
Zodoende ben ik wat beginnen "rommelen", en ben ik begonnen met een digitale fotoframe die ik nog had liggen, een O2 Joggler (met touchscreen). Na wat googlen, ben ik erin geslaagd om Android 2.2 draaiende te krijgen op deze fotoframe. Vervolgens ben ik begonnen om te "programmeren" op dit ding. SRCP implementatie, en die vervolgens via bluetooth doorsturen naar een zelfgebouwde centrale, die dan die data omzet in RF-signalen voor m'n zelf-ontwikkelde decoders.

Status: alles werkt eigenlijk, centrale & 2 decoders op breadboard opgebouwd. Printen zijn al getekend, maar kan pas in april beginnen met frezen van de PCB's en solderen en inbouwen in de voertuigen.
In combinatie met Rocrail draait alles perfect, maar in principe werkt dit dus met elke software samen die SRCP ondersteunt. (Ook koploper dus)
Snelheid van de voertuigen kan geregeld worden, knipperlichten, voor/achter-lichten, remlichten en claxon :-)
(later komt er nog een sequencer-uitbreiding voor ambulances, brandweerauto's enz ...)

Verder heb ik al enige tijd verkeerslichten modules hiervoor gebouwd,
dus die komen nu ook goed van pas. (m'n verkeerslicht-modules hebben zelfs voetgangers-lichten, dat zie je te weinig op modelbanen)

Aangezien RocRail de Merg RFID modules ondersteunt, maar dit systeem alleen maar beschikbaar is als je een jaarlijks MERG lidgeld betaald, ben ik ook dit systeem zelf aan't nabouwen. 8 RFID lezer, die via een zelf ontwikkelde print, de data via USB over een virtuele COM-poort aan RocRail doorgeeft, volgens het (simpele) MERG protocol zelf.
RFID tags van 0,6mm dik en 22mm diameter, heb je al voor 1 euro per stuk, dus dat valt ook nog mee :-)
Dit systeem is zowel bruikbaar voor treinen, alsook voor m'n eigen FCS systeem eigenlijk ...

Zo, dat was het even, ben namelijk nogsteeds met m'n HHC behandeling bezig. (moest normaal vorige week m'n laatste behandeling hebben gehad, maar na bloed-onderzoek is er beslist om nog 3 bijkomende sessies te doen, laatste behandeling is dan 8 maart, dus hopelijk ben ik vanaf half maart terug wat "actiever" (alhoewel dit soms met momenten nu ook wel een beetje gebeurt, maar dan vooral "rustig" achter m'n PC schema's tekenen, PCB's tekenen en firmware schrijven, het "echte" fysische werk is voor later en kan ik momenteel niet aan))

Verder ben ik niet zo "merk-trouw". Ik gebruik meestal Microchip PIC's, maar voor Atmel AVR's deins ik ook niet terug, en heb dan ook van beiden de nodige voorraden liggen :-)
Qua programmeertaal: meestal grijp ik voor de PIC naar Microchips' C zelf, maar h??l af en toe durf ik PicBasic ook wel eens gebruiken :-)
Voor de AVRs gebruik ik ook meestal C, maar evengoed al eens Bascom ...
Op Android programmeer ik in Googles' App Inventor, maar ook al eens in Basic4Android :-)
Voor m'n FriendlyArm dev boards programmeer ik gewoon in Visual Studio C#
Eigenlijk programmeer ik op alles wat enigsinds gedocumentari?erd is, zo heb ik ook enige "ervaring" op Sega Dreamcast, Playstation & Xbox, waar ik zowel simpele games op ontwikkelde, alsook meewerkte aan free libs voor de home-dev scene wat te ondersteunen ...


Interesse in bepaalde zaken ? Meer info kan je altijd vinden op m'n webstek:  http://www.digitalplayground.be


groeten,
Kris