xtal picbasic veranderen voor 3.2768MHz

Ik ken PicBasic niet zo goed... en ben ook pas kort bezig met Pic's

Let in elk geval op dat een Pic vier klokcycli gebruikt voor 1 instructie.

Dat betekent dat je volgens mij met een prescaler van 128 en een timer die op elke 256 stappen een interrupt geeft, uiteindelijk op 25 Hz uitkomt.

Als je een klok wilt maken die ook op de lange termijn nauwkeurig blijft, kun je overigens ook gebruik maken van de 50Hz van het lichtnet.

De waarde voor xtal kan met de lite versie enkel op 4 en 20Mhz ingesteld worden.
De waarde is enkel belangrijk voor een zeer beperkt aantal functies van picbasic. Denk hierbij aan de delay functies en de timeout waarden in somige functies. Als je bv 1sec wilt wachten met delay en je kristal is 2x sneller dan aangegeven wacht je dus eigenlijk 2sec. Dit kan je dan aanpassen door gewoon 0.5sec in te vullen.

Echter voor de meeste andere functie is de kristal snelhied niet van belang. Bij seriele communicatie kan je de baud snelheid ook zelf uitrekenen en dat in het register plaatsen.

Voor wat jij wilt doen maakt het dus ook niet uit. Vul alles waarden in de registers in.

Je kan nu geen delay's gebruiken in je programma omdat die worden dan niet kloppen maar ook omdat dat niet handig is ivm interrupts die dan in de war kunnen komen.

Je zou eventueel in het programma met 4Mhz kunnen werken... dan hoef je er alleen maar rekening mee te houden dat het èchte kristal (ongeveer) 20% langzamer draait...

als het voor een klok is kun je dan niet beter zoon http://www.voti.nl/winkel/catalog.html?IC-PCF8583-DIP chipje bestellen?? dan heb je klok en kalender. de waarde kun je dan via I2C binnen halen.

Groetjes

De systeemsklok hou je gewoon ergens tussen 4 & 20MHz, daarnaast gebruik je een 2e kristal voor de timer klok

Er bestaan ook PIC's met een RTCC ingebouwd (bv. de PIC18F45J50)
Gewoon een kristal van 32.768kHz aan de juiste pin hangen, RTCC inlezen en op het display brengen.

Op 29 augustus 2010 19:32:47 schreef Bas Smit:
De systeemsklok hou je gewoon ergens tussen 4 & 20MHz, daarnaast gebruik je een 2e kristal voor de timer klok

Een 2de kristal aan een pic hangen is bij mijn weten niet mogelijk.

Even ter info: voor dit project gebruik ik de pic16F870.

Waarom zou je in vredesnaam nog een kristal van 32.767Hz willen? Dat was alleen handig in de tijd dat de deling nog met eenvoudige hardware gedaan moest worden.

Waarom zou je de cycles van een 32.767kHz (of 3.2768MHz) nauwkeuriger kunnen tellen dan die van een 20MHz kristal? Ook een seconde is een arbitraire eenheid, je kunt in elke andere eenheid tellen (en dus je eigen "seconde" definiëren), en die omzetten naar uren/minuten/seconden zodra je de tijd in dat formaat nodig hebt. Een afrondingsfout of meetfout heb je altijd, in welke eenheid je ook telt.

Je kunt wel degelijk 2 kristallen aan een PIC aansluiten indien de PIC pinnen kan reserveren voor Timer1. Voor de 16F870 zijn dat pin 15 /T1OSO en 16T1OSI.
Lees de datasheet voor Timer1 er maar op na (hoofdstuk 6).
Meestal zijn dit overigens kristallen van 32.768KHz en ik weet niet of een kristal van 3.2768MHz wel gaat werken.
Als je dat kristal voor de primaire klok gebruikt krijg je in PicBasic inderdaad wel malle effecten bij alle routines die zich op de kristalsnelheid baseren (Delay... HSerin,.. Shout denk ik ook).
Verder schrijf je een paar keer "265", dat moet natuurlijk "256" zijn.

SparkyGSX heeft overigens helemaal gelijk met de nauwkeurigheid.
Dit is op zich weer op te lossen als je beschikt over een stabiele tijdbasis zoals bv een GPS ontvanger.

Op 29 augustus 2010 21:59:25 schreef elektronic:
[...]
Een 2de kristal aan een pic hangen is bij mijn weten niet mogelijk.

Toch nog eens goed kijken: Timer1... In Counter mode, it increments on every rising edge of the external clock input. A crystal oscillator circuit is built-in between pins T1OSI
(input) and T1OSO (amplifier output)

[Bericht gewijzigd door Bas Smit op zondag 29 augustus 2010 22:52:55 (14%)

Daarin moet ik je dan toch gelijk geven. Ik was dus mis, alweer bijgeleerd. Ik denk dat ik dan met een 2de kristal zal werken en deze dan intern te delen door de prescaler en softwarematig te delen (mbv een teller)

Op 29 augustus 2010 22:31:00 schreef SparkyGSX:
Waarom zou je in vredesnaam nog een kristal van 32.767Hz willen? Dat was alleen handig in de tijd dat de deling nog met eenvoudige hardware gedaan moest worden.

Waarom zou je de cycles van een 32.767kHz (of 3.2768MHz) nauwkeuriger kunnen tellen dan die van een 20MHz kristal? Ook een seconde is een arbitraire eenheid, je kunt in elke andere eenheid tellen (en dus je eigen "seconde" definiëren), en die omzetten naar uren/minuten/seconden zodra je de tijd in dat formaat nodig hebt. Een afrondingsfout of meetfout heb je altijd, in welke eenheid je ook telt.

Omdat je met de prescaler op 256 ingesteld dan een kloksignaal van 25.6Khz hebt en met de timer overflow terug deelt door 256 kom je perfect aan kloksignaal van 100HZ uit. Als ik in de het programma dan deel door 100 kom ik perfect 1HZ uit.

Als ik een kristal van 20MHz neem, kom ik niet perfect uit en ald ik die dan deel met de prescaler en de timer overflow moet ik dat signaal dan delen door 783,20802005012531328320802005013 om perfect 1 Hz uit te komen. Delen met een kommagetal zal ik toch niet echt doen met een pic.

Bij het nader bekijken van timer0 module kan men zien dat de hoofdfrequentie (afkomstig van de pic's oscillator) eerst gedeeld wordt door 4. Dit betekent dat ik de prescaler op 1:128 moet instellen. Timer module0 zal dus een frequentie geven van 6.4kHz. De timer0 overflow (interrupt) zal me dan een kloksignaal geven van 25Hz. Deze moet ik dan nog eens softwarematig delen (m.b.v. een teller) door 25 om een 1Hz kloksignaal te krijgen.

De interrupts zullen dus in het programma 25 keer per seconde uitgevoerd worden.

Ik denk als ik timer1 gebruik dat ik veel meet interrupts zal krijgen dan dat ik timer0 gebruik. Of ben ik verkeerd?

Ik wil alvast iedereen bedanken voor de snelle hulp.

[Bericht gewijzigd door Henry S. op maandag 30 augustus 2010 17:50:06 (84%)

Je hoeft niet perse de overflow interrupt te gebruiken; je kunt ook een compare value instellen. Bij deze PIC kan dat niet met Timer0, zie ik, maar je kunt natuurlijk een andere timer gebruiken.

Met een timer clock van 20MHz en een prescaler van 128 krijg je nog 156.250 pulsen per seconde. Als je de compare value instelt op 250, moet je softwarematig nog 625 pulsen tellen voor een seconde.

Met een clock van 5Mhz (20/4) heb je nog 78.125Hz over na een prescaler van 64, en met een compare value van 125 kom je weer op 625 pulsen.

In plaats van een compare value in te stellen, kun je ook de waarde van de timer laden in de interrupt routine. In het laatste geval zou je die dan op 256 - 125 = 131 schrijven.

Lees dan ook even precies welke waarde je in moet stellen voor de juiste deling; waarschijnlijk moet je de deelfactor -1 instellen als compare value, maar ik ken de PICs ook niet zo goed.

Beetje offtopic, maar een reden om een 32.768Hz kristal te gebruiken is dat deze nauwkeuriger is, zo'n 20ppm tegenover zo'n 100ppm voor een standaard kristal.

Dat, en het stroomverbruik. Je kunt de PIC in slaap brengen en de timer een interrupt laten geven als hij overloopt. De PIC houdt dan de tijd bij en gaat weer in slaap. Of als je een RTCC in je PIC hebt, kun je gewoon in slaap blijven.

Klopt, maar voor het stroomverbruik ben je helemaal niet afhankelijk van zo'n 32.768kHz kristal. Met een 20MHz clock en een 16-bit counter kan dat ook gemakkelijk. Ook met een 8-bit counter trouwens, maar dan krijg je wat meer interrupts, waardoor je ook weer meer stroom gaat verbruiken.

@Gyrbo: daar heb je op zich wel een punt, maar je kunt andere kristallen ook wel met een betere nauwkeurigheid krijgen.

Op 29 augustus 2010 22:31:00 schreef SparkyGSX:
Waarom zou je in vredesnaam nog een kristal van 32.768Hz willen? Dat was alleen handig in de tijd dat de deling nog met eenvoudige hardware gedaan moest worden.

32768 is ook voor een uC makkelijker delen dan 32000, gewoon de bits 15 plaatsje opschuiven.
Ben het wel met je eens dat het met de krachtige uC van vandaag de dag niet zoveel meer uitmaakt.

Precies; je hebt niet voor niets een processor die software kan uitvoeren, het is een beetje zinloos om dan nog voor een oplossing te kiezen die in discrete hardware het handigst zou zijn.

Je kunt in software ook eenvoudig delen door een breuk (in tegenstelling tot delen door een floating point getal), zolang je pulsjes telt. Je telt dan gewoon bij elke puls (interrupt) de interval op bij een totaal, en zodra je de gewenste interval bereikt hebt, hoog je de secundaire teller (in dit geval voor de secondes) op, en trek je die interval af van het eerste totaal.

Op 30 augustus 2010 12:11:28 schreef SparkyGSX:
Klopt, maar voor het stroomverbruik ben je helemaal niet afhankelijk van zo'n 32.768kHz kristal. Met een 20MHz clock en een 16-bit counter kan dat ook gemakkelijk.

Die 20 MHz klok valt stil als de PIC in slaap is. Misschien dat je met power managed modes de oscillator kunnen laten draaien, maar niet met de F870, en dan nog is er een aanzienlijk verschil in stroomverbruik met de 3 μA die een 32,768 kHz kristal nodig heeft. Kan-ie op een knoopcelletje jaren mee.

Een waarschuwing voor de TS wegen chatten en onnodige quotes.
We hebben een edit.

Dag iedereen, ik heb inmiddels al wat zitten programmeren en de manier met de timer0 en timer overflow werkt en lijkt mijn programma niet in de war te sturen.