Atmega328P-AU crystal (parallel) capaciteit?

Op 4 september 2023 11:44:39 schreef harry64:
Want de data van het kristal heeft het over 9 pF.

Tja, waardeloze specificatie van chinese leverancier... De datasheet heeft het over 10 of 20pF, please specify.

In ieder geval heeft ieder kristal een gewenste "load capacitance". Dat is capaciteit die jij extern moet aanbrengen.

Een gedeeltje krijg je gratis kado, die komt van je processor-pinnen, en sporen erheen. Meestal is dat ordegrootte 7-10pF.

Dan zet je nog twee C'tjes naar ground neer. Voor het kristal (dat niet aan ground zit!) staan die in serie, dus de effectieve capaciteit is de helft.

Als jij de 20pF versie van het kristal hebt zit je dus wel goed met 22pF.
Als je de 10pF versie hebt zit je met 22pF veel te hoog, en zonder wellicht net te laag (7pF voor alleen de CPU). Probeer eens 10pF.

Ga ik dat doen. Dank.

Ik gebruik altijd 2x22pF, nooit problemen. (afwijkende waarde is alleen nuttig als de kristalfrequentie heel erg nauw luistert, kun je dan iets 'tweaken')
Oscilleren doen alle kristallen wel met 22pF...

Er komen steeds meer kristallen met een lage load-cap, die doen het niet meer met 22pF.

Voordeel (en reden) is dat ze minder vermogen verbruiken.

De LCSC pagina heeft het over 9pF. Dus ik denk dat je de 10pF variant hebt....

Verder, die twee condensatoren, die staan voor het kristal geloof ik in serie (dubbelcheck dat!)(*), dus met 22pF zit je rond de 11, redelijk close.

Maar daar komt dan nog de capaciteit van de baantjes en pootjes bij. Dat is ook zomaar 5pF kunnen zijn, dus heb je maar 5pF extra nodig, en kan je beter 2x 10pF monteren.

Dat gezegd zijnde: Ik douw er altijd 18pF op of zoiets, en heb NOOIT problemen gehad. Ja, met de atmega328. (mogelijk niet-P).

Edit: Oh. Niet overlegd met blurp. Maar effectief zeggen we precies hetzelfde.

(*) Blurp zegt precies hetzelfde, voor mij voldoende gechecked.

Ik gebruik al 6 jaar de ATMega4809 ipv de 328. En die heeft een prima interne oscillator. (en een werkende debugger!)

Ik zou (behalve hobby en "ik vind het leuk zo") geen enkele reden weten nu nog een 328 op een nieuw ontwerp te zetten...

Op 4 september 2023 14:41:15 schreef blurp:
Ik gebruik al 6 jaar de ATMega4809 ipv de 328.

Dan heb jij de ATMega4809 zeker zelf uitgevonden
Onder aan de datasheet staat:
"Obsolete Publication Rev.A - 02/2018 Initial relaese".
Er was ook nog "Obsolete Publication Rev.B - 03/2019" en "Obsolete Publication Rev.C - 08/2019"
Huidige versie is: Rev.A - 01/2020

Je praat over "(en een werkende debugger)", dat moet haast wel de ATmega4809 Curiosity Nano zijn, en die is van 2020.

[Bericht gewijzigd door Spog2 op 5 september 2023 23:20:10 (18%)

Op 5 september 2023 22:58:42 schreef Spog2:
Dan heb jij de ATMega4809 zeker zelf uitgevonden

Zou zomaar kunnen, ik ben namelijk erg goed

Maar ik heb nog eens in mijn archief gekeken en het eerste Atmega4809 ontwerp was van eind 2018. 5 jaar dus¹.

Je praat over "(en een werkende debugger)", dat moet haast wel de ATmega4809 Curiosity Nano zijn, en die is van 2020.

Nope, dat is de Atmel ICE. En die is uit 2014 volgens de handleiding.

¹Waarvan ik 3 jaar in de tropen gewoont heb, en tropenjaren tellen dubbel. 8 jaar dus

De kristallen gebruik ik alleen nog in een testbordje. Voor de rest oscillatoren op frequentie zoals deze. Eenvoudig in gebruik en geen vragen meer welke c er ook weer bij hoort.

Op 6 september 2023 08:27:17 schreef buckfast_beekeeper:
De kristallen gebruik ik alleen nog in een testbordje. Voor de rest oscillatoren op frequentie zoals deze. Eenvoudig in gebruik en geen vragen meer welke c er ook weer bij hoort.

Dat begrijp ik niet goed. Waaarom niet de toch al aanwezige oscillator gebruiken met een gewoon kristal?
(een gewoon kristal is doorgaans 20ppm, de oscillator uit je link is maar liefst 200ppm, dus 10x slechter...)

Omdat kristallen een stuk kritischer zijn qua opstarten en betrouwbaarheid, speciaal over temperatuur dan aparte oscillatoren.

De meeste kristallen doen het uberhaupt niet bij -40, en al helemaal niet binnen de 20ppm.

Sowieso is de trim sensitivity (hoeveel de frequentie afhankelijk is van de load capacitance) makkelijk 20-100ppm/pF. Met een 20pF load capacitance, 5% heb je die pf, en dus 20-100ppm afwijking al te pakken.

[Bericht gewijzigd door blurp op 6 september 2023 09:08:04 (55%)

Op 6 september 2023 08:58:47 schreef blurp:
Omdat kristallen een stuk kritischer zijn qua opstarten en betrouwbaarheid, speciaal over temperatuur dan aparte oscillatoren.
De meeste kristallen doen het uberhaupt niet bij -40, en al helemaal niet binnen de 20ppm.
Sowieso is de trim sensitivity (hoeveel de frequentie afhankelijk is van de load capacitance) makkelijk 20-100ppm/pF. Met een 20pF load capacitance, 5% heb je die pf, en dus 20-100ppm afwijking al te pakken.

Als een kristal niet wil opstarten of afslaat dan deugt je schakeling niet...
Wij hebben tienduizenden cpu schakelingen met kristal uit staan, ik heb nog nooit een niet werkend kristal teruggezien.
Zolang je er niet mee gaat gooien is een kristal uiterst betrouwbaar; in zo'n oscillatorblokje zit tenslotte ook een soortgelijk kristal.

Oscillatorblokje uit bovenstaande link werkt ook maar tot -40 graden.
Trouwens irrelevant, want waar haal je -40 graden in Nederland en omgeving? (of je moet apparatuur in de Russische toendra's hebben...)

Bij wisselende temperaturen kun je eenvoudig een correctie toepassen op de klokfrequentie.
Zolang je niet continu van merk/type kristal en condensators wisselt, kun je de boel akelig precies krijgen.

@arco: Tuurlijk, als je er voldoende moeite en testen in steekt kun je een kristalschakeling net zo goed en betrouwbaar krijgen als een (ietsje duurderde) oscillator.
Maar dan moet je er soms wel duizend wegzetten om de ontwikkeltijd terug te verdienen.

-40 vind je in Scandinavie, in de alpen, op 10km hoogte (vliegtuigen, meetballonnen) en op schepen die de kustwateren verlaten. Plek genoeg, en klanten genoeg die het eisen en erop testen.

De interne oscillator in de AtMega4809 is nog veel minder nauwkeurig, maar dat is voor mij ook niet altijd een probleem geweest. En geen externe klokbron (of het nu een kristal of oscillator is) is altijd nog goedkoper en betrouwbaarder.

Op 6 september 2023 08:54:13 schreef Arco:
[...]
Dat begrijp ik niet goed. Waaarom niet de toch al aanwezige oscillator gebruiken met een gewoon kristal?
(een gewoon kristal is doorgaans 20ppm, de oscillator uit je link is maar liefst 200ppm, dus 10x slechter...)

Voor mijn toepassingen is de nauwkeurigheid meer dan voldoende. RS485 tussen 10 bordjes werkt perfect op 19200Bd (volgens datasheet is 230 400Bd mogelijk met 0% afwijking). De aanwezige DS3231 is dan weer meer als nauwkeurig genoeg om de tijd bij te houden. 2 7-segment display aansturen, elke minuut een DS18B20 uitlezen, 2 niveau sensoren controleren, indien nodig een relais aansturen, een WS1812 en enkele leds. Elke 10 minuten een RS485 berichtje beantwoorden of elke 5 seconden indien het water te laag komt. Dat vraagt echt geen 20ppm nauwkeurigheid.

Mocht er in een ATmega644(P) een kristal zitten, dan was de standaard 8MHz waarschijnlijk al voldoende.Bij nader inzien zit er wel een 8MHz kristal in. Nauwkeurigheid standaard 10%.

Op 6 september 2023 10:33:09 schreef buckfast_beekeeper:
Bij nader inzien zit er wel een 8MHz kristal in. Nauwkeurigheid standaard 10%.

Noem het in deze context geen kristal. Er zit geen kristal in. Een oscillator, een RC oscillator. Niet een kristal-oscillator.

Interne clocksource in een MCU is inderdaad RC. geen kristal.
En een nauwkeurigheid van 10% is wel heel erg slecht... (een pic interne clock is 0.5% nauwkeurig)

Het is goed te realiseren dat een kristal een stukje elektromechanica is, met bijbehorende uitgebreide eigenschappen. Overigens zullen die niet allemaal relevant zijn bij een toepassing als klok voor een µC.

Naar mijn hobby-ervaring werkt "gewoon" 22p en een willekeurig 16 MHz xtal prima bij de 328, maar voor iets dat in productie gaat kan het bij een zelf uitgekozen kristal zeker geen kwaad een test in de (geïmproviseerde) klimaatkast te doen over het relevante temperatuurbereik en vooral ook het drive level te controleren.
Zeker als er nog niet veel analoge ervaring is met kristaloscillatoren.

Het heeft op mijn werk wel eens uitval gegeven, daar hebben we van geleerd.
Als energie en kosten geen beperking zijn kan ik mij goed voorstellen dat het aantrekkelijk is dit stuk ontwikkelwerk af te kopen door een compleet gespecificeerde oscillator in te kopen.

Op 6 september 2023 11:35:33 schreef Arco:
Interne clocksource in een MCU is inderdaad RC. geen kristal.
En een nauwkeurigheid van 10% is wel heel erg slecht... (een pic interne clock is 0.5% nauwkeurig)

Dat is altijd zo geweest bij Atmel. Pietsie vervelend, want eigenlijk kan je dus niet twee atmels met mekaar serieel laten babbelen. (op zeg "afgesproken 9600 baud", nee je moet eerst calibreren bijvoorbeeld met "ik stuur een nul", jij meet de laag-tijd van de puls en gebruikt bittijd = laagtijd/9)

In de praktijk is ie wel vaak veel beter. Maarja: het blijft lastig: Je weet niet wanneer ie de uiterste hoek van de toegestane range opzoekt. Als dat is: Als de chip 85 graden is, dan kan je zeggen: Dat gebeurt bij mij niet. Maar als het "bij volle maan" is, dan gebeurt dat dus toch echt 1x per maand.

Andere fabrikanten, microchip, ST die doen een fabrieks calibratiestap. Bij ST weet ik dat ze een 7 bit calibratie register hebben. Die wordt getuned op +/- 0.5% en vervolgens mag je nog een signed-5bit getal er bij optellen. (om van -7 tot plus5 te tunen ongeveer).

Op 7 september 2023 12:12:47 schreef rew:
[...]Dat is altijd zo geweest bij Atmel. Pietsie vervelend, want eigenlijk kan je dus niet twee atmels met mekaar serieel laten babbelen. (op zeg "afgesproken 9600 baud", nee je moet eerst calibreren bijvoorbeeld met "ik stuur een nul", jij meet de laag-tijd van de puls en gebruikt bittijd = laagtijd/9)

Huh? Een UART is niet voor niets 'Asynchroon' en in de praktijk gebruik je nooit een 1:1 deler voor de clock van je seriele data bij een UART. Meestal is de verhouding 1:16 of 1:64 waardoor er geen enkel probleem is om een startbit te herkennen en ruim binnen de marge 1 byte foutloos te ontvangen (daarna begint het spelletje opnieuw). Dat is juist het sterke punt van een UART.

Bij Synchrone seriele data overdracht stuur je een clock signaal mee en is dat dus ook niet aan de orde.

Ik weet nu even niet uit mijn hoofd wat de specs zijn van de interne oscillatoren van de ATMEGA4809 en ATTiny 419, maar ze kunnen prima UART met elkaar babbellen op 250kbit, dat heb ik uitgebreid getest.

Die 250kb is dan ook net een baudrate die 0% error geeft op 8MHz. Bij 230.4kb is de fout 8,5% (volgens ATmel datasheet). Kans is reëel dat het dan nog alleen werkt tussen dezelfde periferie. Is er een apparaat bij dat effectief klokt op 0% met een 14,7456MHz of 18,4320MHz kristal/oscillator (of FTDI chip of gelijkwaardig), dan is de kans vrij groot dat het niet gaat werken.
Tot 19.2kb en op 38.4kb zal het wel los lopen. Dan is de error niet groter dan ±0,8%.

edit: de maximale fout ligt blijkbaar op 5% totaal. bron.

[Bericht gewijzigd door buckfast_beekeeper op 8 september 2023 10:44:53 (18%)

Op 8 september 2023 05:48:41 schreef KGE:
[...]

Huh? Een UART is niet voor niets 'Asynchroon' en in de praktijk gebruik je nooit een 1:1 deler voor de clock van je seriele data bij een UART. Meestal is de verhouding 1:16 of 1:64 waardoor er geen enkel probleem is om een startbit te herkennen en ruim binnen de marge 1 byte foutloos te ontvangen (daarna begint het spelletje opnieuw).

Nee. Er zijn ongeveer tien bits (het stopbit moet je ook correct ontvagnen. Je begint te samplen in het midden van het eerste bitje. Als je dan op het begin van de bittijd aan het samplen bent tegen het eind van de byte dus dat je in de tijd van 8.49 bits van de zender tot 9 bits hebt geteld met de ontvanger, dan zit je in het laatste bitje ipv in het stopbit te samplen. Goed. de data is dan al correct ontvangen, maar je krijgt op even bytes een frraming error.

Dit is een afwijking van maar iets meer dan 5%. Zelfs als de zender een kristal heeft, kan je er officieel niet op vertrouwen dat een rc-clock atmel het kan ontvangen.

@blup: Dat zeg ik ook: In de praktijk zijn ze veel beter, maar de specs zeggen: je zou rekening moeten houden met 10% afwijking.

Als Microchip de atmel familie de das om wil doen, brengen ze een ex-atmel batch chips in omloop die 9% snellere RC hebben. Prima binnen spec toch? JE KAN ER NIET OP VERTROUWEN. hoeveel je ook getest hebt. Baudrate maakt niet uit.

P.S. Ik zat te denken aan twee atmels waarbij er eentje een "+9%" afwijking heeft en de andere een "-9%". Allebij binnen spec. En omdat het allebij atmels zijn zullen ze de zelfde afwijkingen hebben voor specifieke baudrates. Maar inderdaad die "ongeveer 9%" kan je ook krijgen door 230.4 te willen doen met een ongeschikt kristal. Wacht effe. we hadden het over de RC interne klok. Die 8.5% afwijking is omdat je 250k moet instellen ipv 230k4....

[Bericht gewijzigd door rew op 8 september 2023 10:57:29 (13%)

Toegestane afwijking voor serieele communicatie via UART is +/- 3% verschil max.

Daarboven ga je bits missen, juist omdat het asynchroon is.
(er is geen synchronisatie tussen beide uarts, de ontvanger berekent het 'window' waarin een bit moet worden gelezen vanaf de startpuls m.b.v. de baudrate)

Wat ik tot nu toe gemerkt heb van het kristal gedoe is dat de rotary schakelaar niet echt lekker werkte en er soms een probleem was met data uit de onboard eprom halen. Maar dat kan ook samenhangen met de belaberde voedingslijnen en ontkoppeling. Gevolg was dat de LCD soms geen beeld gaf terwijl de AD9833 wel werd aangestuurd.

Ondertussen overweeg ik wel om ook maar een TH versie te ontwerpen omdat die componentjes (R's, C's en kristal) laten plaatsen toch wat duurder is. Ik heb nog wat setjes 328 DIP/DIL met bijbehorend kristal.