Nove AVR - SIGROW.OSC20ERR5V

[Pavel Hudecek]

Tak úspěšně otestováno:

#define F_CPUnom 20000000L
#define F_CPU (F_CPUnom + (F_CPUnom * (int8_t)SIGROW.OSC20ERR5V) / 1024L)

Dal jsem v 1kHz přerušení invertovat port. Bez korekce osciloskop ukáže 503,něco Hz, takto 500,9. Stejně dopadl i _delay_ms z delay.h.

Zajímavé je, že veškeré pokusy o použití >>10 místo /1024 selhaly a lezly z toho ňáký MHz. A to včetně varianty, kdy jsem místo (int8_t)SIGROW.OSC20ERR5V) dal natvrdo 6L.

Což znamená, že chybu má nejen DS od Microchipu (opačný směr korekce), ale i wizard v CodeVisionu, kde jsem se inspiroval ohledně >>10. Původně jsem totiž zkopíroval jím vygenerovaný řádek kódu a místo BaudNěco dal F_CPUnom.

PH

Od: Miroslav Šinko
Jaj, tak to je OK. Ano, rano mudrejsie vecera, pochopil som to naozaj
nespravne :)

miro

št 30. 4. 2020 o 3:23 Pavel Hudecek <edizon na seznam.cz> napísal(a):
> Myslím, že došlo k nedorozumění. Nebudu nic měřit, jen chci místo konstanty F_CPU dát makro, které s použitím SIGROW.OSC20ERR5V vypočítá výrobcem změřenou hodnotu. Žádný build pro každý ks.
>
>
>
> Od: Miroslav Šinko
>
>
>
> Pri kusovej vyrobe mozno.
>
>
>
> Nominalna hodnota F_CPU je dolezita pre jeden build SW, ktory nahrate do
>
> vsetkych MCU seriovo vyrabaneho produktu. Odchylky jednotlivych kusov su
>
> v korekcnych registroch a o to sa nijak nestarate. Nie je rozumne mozne
>
> merat frekvenciu osc kazdeho MCU, ku kazdemu robit specialny build a
>
> uchovavat variant SW s dokumentaciou serioveho cisla vyrobku. Problemy s
>
> tym spojene nestoja za to. Staci update SW a mate X-nasobne buildovanie
>
> a zlozitu logistiku distribucie.
>
>
>
> Este ma napada dalsi dovod, preco pouzit nominalnu F_CPU a korekcny
>
> register. Priklad USB-AVR, kde si samotny SW urobil kalibraciu a zapisal
>
> do registra. Ked to vezmeme zo siria, da sa robit relativne casta
>
> rekalibracia a tak reagovat na zmeny teploty, starnutie suciastok
>
> (vseobecne podmienok). Hodnota kalibracneho registra sa pouziva potom na
>
> roznych miestach SW pocas runtime, kludne v roznych vypoctoch (inac sa
>
> pocita BdRt, inac USB clock, apod). Ak budete mat v zdrojakoch fixnu,
>
> hoci v danom momente a podmienkach presne nastavenu F_CPU a nikde v kode
>
> nebudete brat ohlad na kalibracnu hodnotu, tak popisany sposob
>
> rekalibracie nie je mozny.
>
>
>
>
>
> On 29.4.2020 10:20, Pavel Hudecek wrote:
>
> > Dotaz: Je nějaký důvod, proč místo jednotlivých korekcí na různých
>
> > místech, nenahradit konstantu F_CPU makrem, nebo funkcí stejného jména,
>
> > ze kterého rovnou vyleze správný Fclk?

------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20200430/6899c4b2/attachment.html>