Sterrenhemel Deel2

Bavelt

Golden Member

Bij die delay kan ik me iets bij voorstellen. Maar ik vermoed dat een keuze tussen 6Khz of 31Khz allebei niet onder 'supersnel' vallen?

Of is het dan toch de moeite waard om - wanneer het niet uitmaakt - toch voor de lage te gaan?

Fouten zijn het bewijs dat je het probeert..
Bavelt

Golden Member

In het kielzog hiervan: met de clockfrequentie en timers kun je aardig spelen.

Zo is de interrupt / timer iedere 100 uS.
Dat kan ik doen met een clock van 16 Mhz en een pre=1 en post=4 en PR=99.

Maar ook met een clock van 8Mhz en pre=1 en post=2 en PR=99.

Is daar nog wat zinnigs over te zeggen? Ofwel: maakt het gewoon niet uit wat je doet als je die 100 uS maar hebt?

Mijn gevoel zegt steeds "hoe lager hoe mooier", maar wellicht is er iets anders om mee rekening te houden bij de keuze?

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

Enige verschil is dat je op 16MHz in die interrupt tweemaal zoveel code kunt uitvoeren. (aantal cycles verdubbelt)

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

Golden Member

Ja, dat is natuurlijk ook zo. In mijn geval niet zo kritisch omdat er niet zo heel veel wordt uigevoerd en het eindresultaat in de seconden ligt.

Kwartje opgooien dus maar... :)

Fouten zijn het bewijs dat je het probeert..
Bavelt

Golden Member

Ik heb in ieder geval het MB-programma voor de sterrenhemel verder geschoond en het project plaats ik hieronder.

Sterrenhemel.zip

Fouten zijn het bewijs dat je het probeert..
Bavelt

Golden Member

Wat ik niet zo gauw kan vinden (meeste voorbeelden zijn Arduino Sketches) of het nog wenselijk / noodzakelijk is om na een SPI-Write naar een MAX7219 een aantal mS te wachten woordat je wéér een write doet.

Ik heb (gevoelsmatig) gekozen voor 5 tot 10 ms, maar dat is maar een gok.
Is daar nog iets zinnigs over te zeggen?

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

SPI kun je gewoon achter elkaar blijven sturen als het goed is...
(je moet de data natuurlijk nooit sneller sturen als dat de bus op die frequentie kan verwerken.)

Je kunt eventueel de BF flag lezen (die kun je clearen door het SSPxBUF register te lezen)

[Bericht gewijzigd door Arco op vrijdag 14 mei 2021 22:27:40 (60%)

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

Golden Member

Even nog iets algemeens in MikroBasic:

Je kunt variabele definiëren voor het hele programma, dus

pic basic code:


Dim i1 As Byte

Maar je kan een variabele ook declareren in een Sub (waar je hem gebruikt).

Heeft dit nu de voorkeur boven een algemene declaratie? Ik neem aan dat de compiler het beste regelt?

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

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

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, 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 zaterdag 15 mei 2021 13:44:49 (15%)

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

Special Member

Het staat ook in de helpfile:

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

Golden 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.

Fouten zijn het bewijs dat je het probeert..
Bavelt

Golden 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...

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

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-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden 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.

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

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

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

Golden 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)..

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

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

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

Golden 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'. :)

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

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-, firm-, en software ontwikkeling: www.arcovox.com
Bavelt

Golden 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?

Fouten zijn het bewijs dat je het probeert..
Arco

Special Member

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-, firm-, en software ontwikkeling: www.arcovox.com
Arco

Special Member

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-, firm-, en software ontwikkeling: www.arcovox.com