Optimaal kristal / UART

Kijk hier maar eens:

http://www.nerdkits.com/forum/thread/214/

14.7456MHz zou dus een mooie kunnen zijn.

Zie datasheet AtMega1284:

1.4 % error op 20 MHz is nog wel goed bruikbaar volgens mij.

[Bericht gewijzigd door deKees op dinsdag 5 mei 2020 17:26:15 (43%)

Ik snap het.

Het zal dan dus een 18.432Mhz kristal worden.

Met de huidige 16Mhz heb ik wel duidelijk seriele problemen.
Maar wellicht dat het meer een buffer probleem is.

Thanks.

Met 16MHz heb je 2.1% afwijking, bij 20MHz 1.4% afwijking. Beide moet goed werken.
Ik zou 20MHz kiezen, dat geeft veel mooiere deeltallen bij timing loops als een 18.432 kristal.

Ik vermoed dat de problemen eerder in de verwerking van het binnengekomen signaal zitten, met 115k2 moet je serieus aan de bak om geen bytes te missen...

Ik zou 20MHz kiezen, dat geeft veel mooiere deeltallen bij timing loops alsdan een 18.432 kristal.

Dat is maar wat je timen wilt. Als het klok-gerelateerd is (zo'n ding wat de tijd aan geeft, niet iets wat virtueel tikt in een controller), dan is 20MHz helemaal niet zo mooi...

met 115k2 moet je serieus aan de bak om geen bytes te missen...

Kom op zeg... nog geen 12000 interrupts per seconde. Ruim 1500 cycles tussen de interrups. Tenzij je in een onmogelijke taal werkt of een beroerde architectuur hebt doe je dat binnenhalen en in een buffer mikken met 2 vingers in je neus. Of je de processing ook redt is natuurlijk afhankelijk van hoe complex die is.

baudsnelheid van de UART voor een optimale verwerking van de data.

We zullen het maar over een bitrate hebben - dat is wat eenduidiger (de uitdrukking 'Baud' komt uit modemland en heeft lang niet altijd een relatie met de bitrate; met een beetje handige modulatie kan 1 Baud best 4 of 16 bits per seconde doen).
De ontvanger wordt na elk frame gesynchroniseerd. Aangenomen dat je iets met N81 doet, is dat dus elke 10 bits op de lijn, zijnde elke byte. De gebruikelijke manier voor een UART om te ontvangen is op de leading flank van de startbit een timer starten die 150% van de bittijd loopt. Daarna wordt de lijn gesampeld, bit wordt bewaard, timer wordt gelijktijdig weer gestart op 1 bit tijd en daarna herhaalt het spelletje zit. Je moet dus feitelijk 9 bits 'gelijk genoeg' blijven lopen om minder dan een halve 'bittijd' verkeerd te zitten - en dus geen (framing)errors te krijgen (waarbij gemakshalve de aanname wordt gedaan dat de andere kant 'exact' is qua timing; de fout kun je natuurlijk prima 'delen' en Murphy schrijft voor dat de ene te snel en de andere te langzaam is ). 2.1% afwijking is niet de moeite waard daarin. Als je ellende hebt, dan zit die ergens anders.

Buffering blijkt voor veel programmeurs toch moeilijk. Interrupts ook. En beiden zijn doorgaans wenselijk voor betrouwbare communicatie. Zou het kunnen dat daar je ellende zit?

Of je de processing ook redt is natuurlijk afhankelijk van hoe complex die is.

Dat bedoel ik juist. Het heeft weinig nut data met 115k2 te verzenden als je niet in staat bent er wat zinnigs mee te doen.
Als je complexe berekeningen doet met bijv. floats kom je zo in de problemen met de beschikbare tijd.
Gebruik van een buffer en interrupts is verplicht als je geen bytes wilt missen.

Op 9 mei 2020 11:01:39 schreef EricP:
[...]We zullen het maar over een bitrate hebben - dat is wat eenduidiger (de uitdrukking 'Baud' komt uit modemland en heeft lang niet altijd een relatie met de bitrate; met een beetje handige modulatie kan 1 Baud best 4 of 16 bits per seconde doen).

Correct, kom nog uit het 1200/75 split baudrate tijdperk. Soms val ik nog wel eens terug

Op 9 mei 2020 11:01:39 schreef EricP:
[...]
Buffering blijkt voor veel programmeurs toch moeilijk. Interrupts ook. En beiden zijn doorgaans wenselijk voor betrouwbare communicatie. Zou het kunnen dat daar je ellende zit?

Klopt, de RFM69 data wordt middels interrupt binnengehaald. Ben nu bezig om het in een ringbuffer te plaatsen.
Mijn eerst gekozen oplossing werkte minder zonder buffer, zeker bij veel berichten.

Op 9 mei 2020 11:08:41 schreef Arco:

[...]
Dat bedoel ik juist. Het heeft weinig nut data met 115k2 te verzenden als je niet in staat bent er wat zinnigs mee te doen.
Als je complexe berekeningen doet met bijv. floats kom je zo in de problemen met de beschikbare tijd.
Gebruik van een buffer en interrupts is verplicht als je geen bytes wilt missen.

Check.

Vond deze pagina nog :
https://cache.amobbs.com/bbs_upload782111/files_22/ourdev_508497.html

Op 12 mei 2020 21:21:31 schreef bprosman:
Vond deze pagina nog :
https://cache.amobbs.com/bbs_upload782111/files_22/ourdev_508497.html

Thanks.
Schept ook wel duidelijkheid

Op 5 mei 2020 15:21:01 schreef wvdakker:
... dat de freq van de kristal een veelvoud moet zijn van de baudsnelheid van de UART voor een optimale verwerking van de data.

Als je dat kiest dan is de baudrate perfect. Maar een paar procent afwijking zorgt meestal niet voor onoverkomelijke problemen. Zo van: het werkt gewoon.

Dat gezegd zijnde op de meeste hardware is het zo dat je kristal een veelvoud moet zijn van 16x de baudrate. In dit geval dus 16x115200 = 1843200. Dus je hebt keuze uit 1.8432MHz, 3.686MHz, 5.529MHz, 7.3728MHz, 9.216MHz, 11.0592MHz, 12.902400 MHz, 14.745600 MHz 16.588800MHz, 18.432000MHz. De volgende 20.2752 MHz is boven de toegestane 20Mhz.

Ik heb wel een 18,432 MHz kristal liggen als je geinteresseerd bent ...