Jednoduchý měřič frekvence s AVR. (diskuse)

[trekker.dk]

Oprav si odkaz, nefunguje

[Petr Tomášek]

Opraveno, díky!

[trekker.dk]

Ještě nějaké detaily:

- SIGNAL() je deprecated, místo něj se má použít ISR()

- funkce uart_print_freq() pravděpodobně občas zablbne, pokud program poběží dost dlouho. Může se totiž stát, že hodnota freq se změní mezi vyhnodnocením podmínky a přiřazením do temp.

(Dobrá, asi se to nestane, protože vypsání proběhne jenom po změně status a je rychlejší, než jedna vteřina.)

- status by měla být deklarována jako volatile. Když není, tak u gcc-3.4 to projde - nevím proč, ta proměnná by pro ten překladač neměla měnit hodnotu a optimalizace by její testování měla odstranit.

U gcc-4.3 už to ale neprojde, když je proměnná nulová, program skočí na instrukci rjmp -2, což je nekonečná smyčka.

[Petr Tomášek]

Ještě nějaké detaily:

- SIGNAL() je deprecated, místo něj se má použít ISR()

...

- status by měla být deklarována jako volatile. Když není, tak u gcc-3.4 to projde - nevím proč, ta proměnná by pro ten překladač neměla měnit hodnotu a optimalizace by její testování měla odstranit.

OK, tyhle věci opraveny, díky.

[trekker.dk]

Stejně je to zajímavé. Když se člověk podívá na kód, který vygeneruje gcc a pracuje přitom s volatile proměnnou větší než 8 bitů, tak tam vidí po sobě jdoucí instrukce načítání z paměti:

lds r24, 0x0060
lds r25, 0x0061
lds r26, 0x0062
lds r27, 0x0063

Přitom když je ta proměnná volatile, tak to znamená, že se obsah té paměti během vykonávání těch instrukcí může změnit a do registrů se pak načte naprosto nesmyslná hodnota - napůl stará, napůl nová. Podle mě by to mělo být takhle:

in r23, SREG
cli
lds r24, 0x0060
lds r25, 0x0061
lds r26, 0x0062
out SREG, r23
lds r27, 0x0063

obecně nebo

cli
lds r24, 0x0060
lds r25, 0x0061
lds r26, 0x0062
sei
lds r27, 0x0063

v případě, že vím, že přerušení bylo předtím povoleno.

[petr]

Klicove slovo volatile rika, ze prekladac ma hodnotu vzdy nacist z/ulozit do pameti. Nic vic, nic min

[trekker.dk]

Což to jo. Jenže zrovna u procesoru tohohle typu je typický důvod, proč vždy načíst z/uložit do paměti, že se proměnná může změnit v přerušení. V takovém případě je kód, který generuje gcc, vadný (moje mínění), protože při čtení/zápisu nijak neošetřuje případ, že se ta hodnota opravdu změní a načtený/uložený výsledek bude naprosto nesmyslná hodnota.

Přitom jediná cesta, jak z toho ven, je

register uint32 tmp;

...
cli();
tmp = freq;
sei();
uart_print_freq(tmp);
...

Akorát je docela opruz tohle psát u každého přístupu k té proměnné a vygenerovaný kód není úplně optimální.

Přitom by určitě bylo jednodušší, kdyby gcc pro AVR vypínal/zapínal přerušení automaticky (i když to zas narážíme na otázku, jestli by byl schopen to dělat efektivně)

[petr]

To si musite osetrit sam, chova se to presne, jak se ma volatile chovat.

[petr]

Jinak C nemuze vypinat preruseni, protoze na to v C neni klicove slovo. Proste to Ccko je moc vysokourovnove. Proto to slovo volatile dela to, ze zabrani optimalizacim - prekladac nic neusuzuje o hodnote a vzdy ji bere z pameti. Zbytek si musite obstarat sam.

[Petr Tomášek]

Akorát je docela opruz tohle psát u každého přístupu k té proměnné...

Mno, v tom případě přeci není problém připravit drobné makro, ne? Něco jako:

#define get_volatile(x,y) cli();x=y;sei()

[trekker.dk]

Tak to je o něco lepší, pak už by to bylo jenom na dva řádky (definice proměnné + volání). N

icméně nejjednodušší by stejně byl pro AVR specifický přepínač pro sledování/nesledování volatile proměnných a obklopení přístupu k nim cli/sei

[petr]

Takhle se to nemuze resit, protoze volatile ma jasne definovany vyznam. Nemuzete si zmenit vyznam klicovych slov, jak se Vam zrovna hodi. To by vnaselo do jazyka zmatek a zhorsilo prenositelnost kodu.

Je dokonce mozne, ze makro, ktere tak s promennymi zachazi, bude definovane nekde v hlavickach.

[trekker.dk]

To by vnaselo do jazyka zmatek a zhorsilo prenositelnost kodu.

Přenositelnost kódu by to asi zhoršilo, jenom nevím, kam by mělo smysl přenášet kód z AVR (pokud to má dělat něco užitečného, polovina kódu je specifická pro architekturu a jinde se nepřeloží)

[Josef Kufner]

Jde hlavně o princip. Ale představ si, že za rok vyrobí trochu jiný model a ty budeš chtít program přenést na něj a zrovna tohle tam bude trošku jinak...

[trekker.dk]

Jde hlavně o princip.

To jsem si všiml

Ale představ si, že za rok vyrobí trochu jiný model a ty budeš chtít program přenést na něj a zrovna tohle tam bude trošku jinak...

Nový model se objevuje každou chvíli a všechny mají stejný vnitřek - jádro AVR. A stále nevidím žádný problém - kdyby se náhodou objevil model, kde by tohle bylo jinak (což si teda opravdu představit nedokážu, jak by se v jednočipu musel změnit přístup k paměti, aby to mohlo být jinak), tak by se prostě ten přepínač při překladu programu pro ten nový model zakázal.

[Josef Kufner]

No, pak by mohly být ještě potíže se sloučením dvou programů, kde jeden by ten přepínač používal a druhý ne.

[trekker.dk]

Bavíme se ještě pořád o jednočipech?

Přiznávám, že pod sloučením dvou programů si nedovedu nic moc představit. Ale budiž, pokud bych měl dva programy a chtěl je nějak "slučovat", tak stejně musím na úrovni zdrojového kódu a ten přepínač by byl v překladači (avr-gcc --neprerusitelne-volatile), tzn. po překladu by se to buď používalo v celém výsledku, nebo nepoužívalo v celém výsledku.

[Josef Kufner]

Jo, pořád o jednočipech. Vem si, že jeden program využívá přepínače a k volatile proměné přistupuje normálně (přímo; hlídá překladač). Druhý program přepínač nepoužívá a místo toho využívá makro/funkci, která to pohlídá. Že toto nastane je celkem pravděpodobné, pokud ty programy vytvoří různí lidé (jedním z nich jsi mohl být ty).

Každý z těchto dvou programů implementuje věc, kterou chceš použít ve svém programu, ale ani jeden kód není zcela vyhovující a budeš v tom chtít dělat menší úpravy. To taky není nic neobvyklého.

A teď si představ jaký bordel v tom bude a nakonec to skončí tak, že jeden kus kódu budeš muset ručně projít a upravit. Při troše štěstí toho nebude moc, ale i tak to je otrava a zdroj zbytečných, tězko odhalitelných chyb.

[trekker.dk]

A teď si představ jaký bordel v tom bude a nakonec to skončí tak, že jeden kus kódu budeš muset ručně projít a upravit.

Proč? Jediné, co se hlídá, je zablokování přerušení na dobu přístupu k proměnné. Jestli to zajišťoval překladač nebo makro je jedno, protože podstatné je, že ten přístup je ochráněn. Víc nepotřebuju.

(Ano, je tu záležitost, že se zapnutým přepínačem by ten kód byl chráněn dvakrát. Nicméně mám důvěru v autory toho překladače, že jsou schopni vytvořit takové optimalizace, které odhalí dvě stejné instrukce za sebou a tu jednu vyhodí.)

Co chci říct, že kdyby byla vůle, tak by to pravděpodobně šlo vyřešit nějak automaticky i s možnými problémy okolo.

[Petr Tomášek]

Jen tak mimochodem...

[trekker.dk]

Jo, tím je víceméně vyřešené to makro zmíněné v příspěvku #18

[cenda]

Odkaz na projekt stále nefunguje. Máš tam http://www.abclinuxu.cz/blog/vejsplechty/2008/8/www.etf.cuni.cz/~tomasek/avr_freq_0.1.tgz a pravděpodobně by mělo být www.etf.cuni.cz/~tomasek/avr_freq_0.1.tgz.

[Blab]

Lidi, už se vám někomu podařilo zprovoznit AVRstudio 4 + WinAVR s WINE? Na AVRfreaks se někdo chlubil , že mu to jede pomocí originálních .dll z Windows, ale bohužel,stejný postup u mě nefunguje.

[Milan Hejpetr]

Podle me to funguje jen za opravdu specifickych podminek, ja jsem to funkcni tedy nikdy nevidel. Zkousel jsem vsechno mozne a nakonec jsem to vzdal. Pro vyvoj v assembleru tedy pouzivam AVRStudio 3, ktere pod wine funguje dobre. Pokud neco delam v C, pak samozrejme prekladac neni problem, ale pokud je potreba krokovat atd. je asi jedina moznost pomoci gdb pro AVR + avarice + hardware pro JTAG - ladite pak primo v hardwaru.

[Dancer]

Odkaz stale nefunguje. Prosim opravit naozaj.

Dakujem

[Petr Tomášek]

Hm, tak to byly dva odkazy, co nefungovaly . Sry, už je opraveno...

[Josef Kufner]

Jak tak koukám na ty pinhead věci ve schématu, doporučuju vyzkoušet příkaz "mirror" Ale jinak je to hezké a roztomilé