Sterrenhemel Deel2


Locale variabelen declareer je als je die alleen in die sub nodig hebt. (spaart geheugen uit)

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

Dat is "te kort uitgelegd", arco. Iemand die het niet al weet, kan daar niet uithalen wat er aan de hand is.

Als jij een variabele globaal declareert, dan reserveert ie dat stukje geheugen. Dus bijvoorbeeld voor een 4-byte variabele reserveert ie geheugenplekjes 260-263. Altijd als jou programma in de CPU zit, worden die geheugenplekjes voor precies die ene variabele gebruikt en nergens anders voor.

Als jij een variabele in de subroutine declareert dan reserveert de compiler een plekje geheugen zodra die routine actief is. Als die routine niet actief is dan kan daar een andere sub z'n variabelen in kwijt....

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
bprosman

Golden Member

Vandaar ook de benamingen :-)

"Globaal" (Global) -> Zichtbaar / bruikbaar door je hele programma, alle subroutines/functies kunnen die variabele gebruiken.
"Lokaal" (Local) -> Alleen zichtbaar / bruikbaar door de subroutine/functie die hem (haar?) declareert en is (definitief) weg op het het moment dat je de subroutine/functie verlaat.

Dit is overigens niet alleen in BASIC zo, sterker nog, volgens mij kent de "oer BASIC" zelfs geen locale variabelen.

[Bericht gewijzigd door bprosman op 15 mei 2021 13:44:49 (15%)]

De jongere generatie loopt veel te vaak zijn PIC achterna.

Het staat ook in de helpfile:

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

Special Member

OK, dank allen.
Het is me wel helder. Ik heb mijn programma's hier op aangepast. Niet zozeer omndat ik nu gebrek aan geheugenruimte heb, maar gewoon om netter en efficiënter te programmeren... :)

Ik dacht nl heel even dat wellicht de compiler, zodra hij ergens een Dim tegenkwam hier een vaste locatie aan toekende, maar is dus niet zo.

Man is still the most extraordinary computer of all. JF Kennedy
Bavelt

Special Member

Beetje off-topic, maar

Inmiddels is mijn eerste bestelling bij Arrow binnengekomen: 3 PIC's type PIC 16F1847. Keurig bezorgd door DHL, zonder administratie-verzend of andere kosten.

Dit soort kleine leveringen zullen uiteraard niet rendabel zijn voor zo'n bedrijf. Toch past het blijkbaar in hun business model.
Farnell deed dat eerst ook, maar gooit nu altijd € 5 handling-kosten er overheen.

De geleverde PIC's zijn van Motorola. Ik ga er dan maar van uit dat hier geen Chinees in het spel is die dat logo er even op heeft geprint... ;(

De PIC16F1847 is toch wel echt mijn favoriet geworden. Handzaam met zijn 18 pins DIP, 2 MSSP modules, 8K Flash, etc.

Een aardige 'tweede' is de PIC16F1936. Heeft echter maar 1 MSSP, maar wel weer meer poorten.

Maar dit terzijde...

Man is still the most extraordinary computer of all. JF Kennedy

De geleverde PIC's zijn van Motorola.

Dat kan niet, om 2 redenen:
1) Alleen Microchip maakt ze.
2) Motorola bestaat al lang niet meer...

Ik gebruik tegenwoordig voor kleine projecten de 16F1709 en 16F1769, die kunnen weer een stuk meer: hebben ieder o.a. 2 OPA's (OpAmps ;) )
aan boord.

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

Special Member

Op 15 mei 2021 23:36:40 schreef Arco:
[...]
Dat kan niet, om 2 redenen:
1) Alleen Microchip maakt ze.
2) Motorola bestaat al lang niet meer...

Ik gebruik tegenwoordig voor kleine projecten de 16F1709 en 16F1769, die kunnen weer een stuk meer: hebben ieder o.a. 2 OPA's (OpAmps ;) )
aan boord.

Inderdaad!
Mijn eerste ingeving was Motorola, vanwege het logo. Dat lijkt zo voor de vuist weg best wel aardig op MicroChip vind ik.

Maar het is dus inderdaad Microchip.

De PIC16F1709 en 1769 hebben zo te zien maar 1 MSSP module. Daarmee kun je dus niet I2C en SPI naast elkaar gebruiken, wat de 1847 wel kan.

Man is still the most extraordinary computer of all. JF Kennedy

Ik kies altijd voor een van de twee: SPI of I2C. (allebei is wat overkill)

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

Special Member

Op 16 mei 2021 12:35:43 schreef Arco:
Ik kies altijd voor een van de twee: SPI of I2C. (allebei is wat overkill)

Nou.. wanneer je bv zoals ik deed de tijd van een RTC DS1307 (I2C) wilt weergeven op een OLED-SPI of op een LED matrix via een MAX7219, dan is het zeker wel handig dat je ze beiden aan boord hebt!

(of je moet gaan soft-I2c-en of SPI-en)..

Man is still the most extraordinary computer of all. JF Kennedy

Of een SPI versie nemen (bijv. de DS1302+)

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

Special Member

Ja, dat kan natuurlijk. Dan zou je bij de keuze altijd even moeten oplettten
welke type device je kiest.

M.a.w. eerst de processor kiezen, dan de devices. (uiteraard afhankelijk van je doel).

In mijn geval had ik die dingen al en ging ermee 'spelen'. :)

Man is still the most extraordinary computer of all. JF Kennedy

Ik probeer altijd zoveel mogelijk dezelfde devices te kiezen (spi of i2c), en de processor kies ik afhankelijk van de applicatie.
Voor grotere applicaties kies ik altijd een 24FJxxxxx, dan heb je altijd genoeg... ;) (en die zijn 2x sneller)
(veel i/o, 3xSPI/I2C, 4xUART,tot 1Mbyte aan flash,...)

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

Special Member

Op 16 mei 2021 14:03:57 schreef Arco:
Ik probeer altijd zoveel mogelijk dezelfde devices te kiezen (spi of i2c), en de processor kies ik afhankelijk van de applicatie.
Voor grotere applicaties kies ik altijd een 24FJxxxxx, dan heb je altijd genoeg... ;) (en die zijn 2x sneller)
(veel i/o, 3xSPI/I2C, 4xUART,tot 1Mbyte aan flash,...)

Maar kan MikroBasic daar wel mee overweg?

Man is still the most extraordinary computer of all. JF Kennedy

Ja,

De MBPro compiler voor dsPic en Pic24 (werkt exact hetzelfde, er is ook nog de MBPro compiler voor Pic32...)

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

DIP gebruik ik alleen soms voor wat testjes, verder nooit meer. (meestal ssop, qfp, of msop)
Er zijn wel wat DIP versies in de 24FJ familie (zoals de xxGA1xx en xxGA2xx), maar die zijn net zo duur als een 80 of 100 pinner, dus waarom zou je die kiezen?

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

Special Member

Op 17 mei 2021 17:52:42 schreef Arco:
DIP gebruik ik alleen soms voor wat testjes, verder nooit meer. (meestal ssop, qfp, of msop)
Er zijn wel wat DIP versies in de 24FJ familie (zoals de xxGA1xx en xxGA2xx), maar die zijn net zo duur als een 80 of 100 pinner, dus waarom zou je die kiezen?

Hoe kan ik ze anders testen? Een breadboard gaat niet meer lukken. Of is er wellicht een 'socket' o.i.d. waar je ze in kunt doen?

Dus niet eerst een printplaat maken..

Man is still the most extraordinary computer of all. JF Kennedy

Ik maak altijd meteen een proefprint (kost tegenwoordig toch geen drol meer)

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

Special Member

De sterrenhemel doet het nu best wel goed. Dankzij verbeteringen aan het programma. Plus de inbouw van 'compensatie' middelen, zoals WatchDog en een Power Reset bij 'hangen' (komt overigens bijna tot niet meer voor).

Maar er zit nog wel een apart probleempje: Er blijft een aantal ledjes héél flauwtjes branden, terwijl die eigenlijk helemaal uit moeten zijn.
In daglicht zie je het amper, in het donker zijn ze wél zichtbaar.
Maar dat moet dus niet. Ze moeten helemaal uit zijn en geen licht meer produceren.

De bijbehorende MAX7219's reageren wel op het binnenkomende 0x0C (shutdown) commando, dan krijg ik ze alsnog uit, maar bv niet op 0x0A om de helderheid te wijzigen.
En ook niet op het schrijven van nullen.
Vreemd...

Het lijkt er dus een beetje op dat enkele Max-en 'lekken' of zoiets.

Is dit een bekend verschijnsel?

Man is still the most extraordinary computer of all. JF Kennedy
Bavelt

Special Member

Het probleem zit hem wellicht - of liever waarschijnlijk - in een MAX7219, maar de panelen zitten aan het plafond en deze verwijderen zou weer een brekerij opleveren.
Daarom heb ik - ook nu weer - het kunnen oplossen met het bestrijden van het symptoom:

Bij de 'Fading Heaven', m.a.w. de sterren doven één voor één, tel ik hoeveel er nog 'aan staan'.
Als de teller eenmaal op 0 staat, dan volgt het command Max_Write(0x0c, 0x00), ofwel shut off display.

Dan is alles uit, zoals bedoeld... ;)

Als het niet kan zoals het moet, dan moet het maar zoals het kan! :)

Man is still the most extraordinary computer of all. JF Kennedy
Bavelt

Special Member

Wanneer ik SPI gebruik, bijvoorbeeld bij een PIC16F1936, Dan heb ik in het programma gezet:

pic basic code:



Dim ClockPin As sbit at PORTC.3           'pin 14                   'Clock
    Datapin  As sbit at PORTC.5           'pin 16                   'SDO

Maar omdat de SPI-pinnen hardwarematig bepaald zijn, kan ik bovengenoemde statements ook gewoon weglaten. Dan werkt het gewoon.

Verdient het desalniettemin aanbeveling ze tóch op te nemen of juist liever niet?

Man is still the most extraordinary computer of all. JF Kennedy

Wordt nooit gebruikt dus wordt er bij compileren automatisch uitgesloopt...

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

Special Member

Ah, ok.
Dan zou ik het dus alleen kunnen laten staan als documentatiedoel...
(heb je de gebruikte pinnen bij elkaar staan).

Man is still the most extraordinary computer of all. JF Kennedy
Bavelt

Special Member

Die 1936 is trouwens ook wel een aardig ding. :) Compact en redelijk wat I/O pinnen in DIP-28 uitvoering.

Man is still the most extraordinary computer of all. JF Kennedy