Atmega328P-AU crystal (parallel) capaciteit?

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 (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 dus1.

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.

1Waarvan 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 (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 (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 (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.

Ondertussen overweeg ik wel om ook maar een TH versie te ontwerpen

De AD9833 bestaat alleen in MSOP10...

Op 8 september 2023 10:52:35 schreef rew:
@blup: Dat zeg ik ook: In de praktijk zijn ze veel beter, maar de specs zeggen: je zou rekening moeten houden met 10% afwijking.

De 4809 is gespect als max 4% afwijking over de full operating range.

Omdat de UART intern gewoon op de 20MHz klok loopt pakt ie op 250kB gewoon 80 samples van iedere bit. Intern zit een tellertje welk sample de middelste is, en die bit gaat als ontvangen bit door.
Tellertje wordt gereset op iedere flank.

Dus als je op 4 % afwijking zit, zit dat tellertje er na 9 gelijke bits er 36% naast. Minder dan 50%, dus als je signaalvorm een beetje OK is gaat dat nog goed....

Meer dan 9 gelijke opeenvolgende bits kan niet met 8 databits op de seriele poort.

Op 7 september 2023 11:40:35 schreef Aart:
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.

Daarbij komt dat ‘uit en weer aanzetten’ niet altijd zomaar kan.

Bij een stage van mij stonden de producten ‘in het veld’ daadwerkelijk in het veld. (Grondwaterstandmeters of iets dergelijks). Niet waar ik toen aan werkte, ik zat nog pas in mijn 2e studiejaar, maar er waren collega’s druk op zoek naar een klokprobleem. En ik leerde geïnteresseerd mee. Dat was dan geen kristaloscilator die afsloeg, maar wel een temperatuur-gerelateerd oscillatorprobleem: als ik mij juist herrinner, haalde de WDT klok als het koud of warm genoeg was het externe kristal in. Waardoor de MCU de watchdog niet meer op tijd resette/voederde, en de watchdog dus beet/de mcu resette. Dat ging ‘bijna altijd’ goed, maar door onderlinge variaties in de specificaties van de interne oscillator in sommige gevallen bij sommige temperaturen mis.

‘In het veld’ betekende dat er een mens in een busje heen moet, en mensen (al dan niet in busjes of boten) zijn duur.
Als je eenmaal weet hoe het zit is zo’n wdt klok gaat sneller lopen bij bepaalde temperaturen issue nog wel op te lossen met een ota update op een dag met gematigd weer, maar ik weet niet of ota bij de waterstandenmeters mogelijk was.

Voor de hobby kun je ook volstaan iets in de koelkast / vriezer te leggen en het daarna ‘s goed met een haarfohn te bewerken, als je geen klimaatkast hebt staan. Bij voorkeur wel de temperatuur meten.

Op 8 september 2023 14:05:49 schreef blurp:
Omdat de UART intern gewoon op de 20MHz klok loopt pakt ie op 250kB gewoon 80 samples van iedere bit. Intern zit een tellertje welk sample de middelste is, en die bit gaat als ontvangen bit door.
Tellertje wordt gereset op iedere flank.

Nope.

Bij de gemiddelde U(S)ART stel je een deler in op 16x de baudrate.
Er wordt dan tot 16 geteld voor ieder bit. Als de teller dan op 8, 9 en 10 staat wordt er een bitje ingelezen. Daar wordt de meerderheid van bepaald en DAT is je bitje.

De USART van Atmel chips werkt ook zo.

De Atemel chips hebben dan nog een extra truuk die niet iedere U(S)ART kan: Je kan de tel-tot-16-per-bit veranderen in tel-tot-8. Zo kan je 2x hogere clock rates bereiken.

Zie voor dit alles datasheet ATMEGA4809 blz 285.

Wat ik niet opgezocht heb is: Bij de atmega328 is de deler een geheel getal. Bij de atmega4809 mag die 6 bitjes achter de comma hebben.

Voor 230k4 wil je dus een 3.6864 MHz klok als master klok in je USART hebben. Bij de atmega 328 moet je dan 20MHz / 5 = 4.0MHz doen. Bij de '4809 kan je door (5 + 27/64 = 5.421875) delen zodat je een baudrate van 230547 krijgt ipv 250000 zoals op de '328.

@blurp: Die 4% is al veel bruikbaarder dan 10% van de '328 (in de titel van deze thread!) Dat gaat goed mits je een "echte 230400 baud" ergens vandaan haalt. Een kant met een kristal of zo. Als je twee '4809's met mekaar wil laten babbelen dan is de max afwijking ineens 8% omdat er 1 4% te langzaam en de andere 4% te snel kan zijn. Wederom: Dat zal zeer zeldzaam zijn. Bijvoorbeeld omdat zoals Lucky Luke al aangeeft: Ze zullen wel allemaal dezelfde temperatuurafhankelijkheid hebben en b.v. vandaag zijn ze allemaal "warmer dan normaal".

[Bericht gewijzigd door rew op (18%)]

Op 8 september 2023 15:42:29 schreef rew:
[...]Nope.

Bij de gemiddelde U(S)ART stel je een deler in op 16x de baudrate.
Er wordt dan tot 16 geteld voor ieder bit. Als de teller dan op 8, 9 en 10 staat wordt er een bitje ingelezen. Daar wordt de meerderheid van bepaald en DAT is je bitje.

Dat komt praktisch op hetzelfde neer... Met "slechts" 16 samples komen ze (ongeveer) op 43, 50 en 56 % terecht. Zelfs als er eentje omgevallen is dan is de meerderheid nog goed.

Ook de Atmel-UART zal synchronizeren op flanken van de data. Moet wel, want de juiste frequentie betekend niet de juiste fase.

Op 8 september 2023 12:58:45 schreef Arco:
[...]
De AD9833 bestaat alleen in MSOP10...