Problémy s AVR Studiem

Je toto v pořádku?

_delay_ms(500);

Už mi ale totiž sakra došla trpělivost, protože to je každou chvíli, co narazím na problém, za který může AVR Studio - respktive překladač C.
Silně totiž tentokrát pochybuji, že zápis výšezmíněného příkazu je chybný.
V Libc-reference manuálu jsem se dočetl, že fce _delay_ms() může poskytnout až 6,5s zdržení (sice se sníženou přesností, ale to mi v tomto případě vůbec nevadí).
Za to mi neskutečně vadí, že kvůli tomuhle příkazu mi přestane fungovat kompletně celý program.
Protože jsem už fakt byl v koncích, proč mi naprosto tupý program o 20 příkazech pro tiny26 není schopný fungovat, zakomentoval jsem celý program, a začal to kompilovat a zkoušet po jednotlivých přidávaných řádkách kódu. A na tomhle příkazu, mi shnije celý program.
To je proboha to AVR Studio vážně tolik nespolehlivé? Jak v tom pak má člověk něco programovat, když to neni schopné ani bez problémů překládat triviální programy?
Případná rada nebo pomoc vítána, budu vděčný.
Bude-li se někdo chtít podívat na zdroják toho krátkého programu, mohu ho sem vložit.

EDIT: Další hodinu jsem strávil tím, že jsem koumal nad chybou… Chyba tedy není na příkazu co jsem uváděl, ale dvojice příkazů, _delay_ms() a náseldný přístup na port mi kolidoval s funkcí, která byla pouze definovaná a nikde v programu nepoužitá. Zakomentování té definice funkce podivnou chybu sice odstranilo, ale nevysvětlilo, v čem je chyba. Jak přece může kompiler něco tvořit z funkce, která je pouze definovaná, ale nikde v programu není volaná ?
EDIT2: Proč mě vlastně kompiler neupozornil na nikde nevyužitou funkci ? Normálně přece dává hint, že tam mám něco zbytečného navíc. Nebo ne?

Edit3: Programování mi vydrželo jen chvíli, a už se zase objevují problémy. Zkoušel jsem spustit DEBUG, abych zjistil, co tam hapruje. On ale hapruje i DEBUG, takže to nezjistím. V debugu mi to skáče na tělo funkce přerušení, přestože v programu se to ještě nedokrokovalo ani k instrukci SEI. Takže výborné, jen tak dál.

Bez kódu ti k tomu moc neřeknem. Zatím jsem osobně na problém s _delay_xx() nenarazil. Akorát se ty delaye dost blbě krokuje (ikdyž dáš step over, tak se program zastavuje někde uvnitř zpoždění).

Ten kód jsem už vzteky celý vymazal a píšu to kompletně znova.

Víš, třeba nejvtipnější od toho kompileru bylo, když mi zároveň s blikající LEDkou (na PA7) do rytmu pocvakávalo krátkými pulzy relátko (na PB3), přestože je na úplně jiném portě než ta LED a název registru portu na kterém jsou relé v programu nikde nebyl zmíněný ani náznakem. (až na inicializace výchozích stavů) Ten kompilátor si opravdu občas dělá co chce, a sám si jistě vzpomeneš, že není prvně, co na to nadávám.
Přesně nevím, jak ej AVR Studio konstruované, kde se nachází kompiler C. Ale AVR Studio mám už staršího data v. 4.14 a pamatuju se, že jsem si musel zároveň na PC nainstalovat akési Win-AVR aby mi šlo v AVR Studiu překládat zdroják v C.

Při té příležitosti jsem narazil na zajímavost:
Proč ATtiny26 má USI_STRT_vect kdežto ostatní procesory USI_START_vect ? (Přitom když jsem to pod palbou nadávek kompilátoru prohodil ~ missspelled int vector nebo c oto dycky nadává ~ tak se program choval stejně (debilně) jako s tím druhým.

Shodou okolností se mi ATMEL dnes uráčil po asi půl roce poslat odkaz na stažení nové verze AVR Studia 4.18.(589?)
(To jsem si vzteky před tím stáhl AVR STudio 4.17 z uloz.to, ale zatím sjem nic nepřeinstalovával, protože stejně nevím, v čem je chyba, jestli v AVR Studiu, nebo ve WinAVR)

V AVR Studiu céčko nepoužívám, takže ti neporadím, ale měl jsem podobný problém s AVR32 Sudiem. Šlo to nainstalovat, ale nešlo to vůbec rozchodit. Dlouho jsem si s tím nevěděl rady, snad 10x jsem to přeinstalovával a výsledek byl stále stejný. Až mě pak napadlo nainstlovat správnou verzi Javy. Pak to začlo chodit.
Možná, že ty patálie, které máš AVR Studiem, mohou být způsobeny nesprávnou verzí Javy, nebo MS net frameworku, či podobných podpůrných prostředí připatlávaných k OS windows. Opravdu čert aby se v tom vyznal.
Mimochodem i v těch hlavičkových souborech jsem našel chyby.

Jo no, chyby tam jsou. Ale aspoň by nemusel bugovat kompilátor. Hlavičkový soubor se dá opravit, a chyba v simulátoru mě tolik neštve. (Třeba vím o chybné simulaci jednoho USART registru na mega8, v té verzi 4.14, a v ASM kompilátoru, tam mě to udělalo botu jednou taky.)

Časem možná přejdu na nějaké lepší prostředí. To AVR Studio je sice celkem snadno (až na to jejich zdržování s registrací) opatřitelné, ale imho píše se v tom jak v MS Wordu a né jako v programátorským editoru. Vyjmenoval bych celou stránku věcí, které mi vadí na tom editoru. (vzít si tak příklad z PSpadu :wink: )

Mno ať to tu zbytečně nekalím, program jsem celý smazal a začal psát znovu. Nyní, malinko jinak napsaný program využívající shodné algoritmy se chová naprosto normálně. Před asi půlhodinou jsem dal dokupy přenos dat takovou hybridní sběrnicí mého patentu (kombinace symetrických linek spolu s SPI a I2C) :slight_smile: Tak ještě aby ta data chodila opačným směrem (Slave>>Mater) a bude pohoda. (Pokud mi zase AVR Studio nepřipraví nějakou kaluž).

Technik, piityy: Co byste mi doporučili jako jiné vývojové prostředí pro 8bit-AVR ?

Osobně ti nic jiného nedoporučím. Pracuji totiž právě v AVR studiu (což je pouze IDE, ktetré samo o sobě programy nepřekládá), ovšem v poslední čtyřkové verzi 4.18 SP3(nutno nainstalovat verzi 4.18 a poté 3 servicepacky) a AVR Toolchain 3.0.0.240(překladač C, nahradil dříve používané stále ovšem funkční WinAVR - verze GCC). Obojí dostupné z webu Atmelu(po registraci, ovšem co do ní zadáš je tvoje věc :wink:). Žádné problémy jsem nezaznamenal nyní ani v předchozích verzích. Jediné, co pravidelně blbne, je simulace timerů.

Co se týká názvů vektorů přerušení, stačí přeložit program s vloženým avr/io.h. Tenhle soubor se ti zobrazí vlevém panelu v “external dependencies” spolu s definičním souborem procesoru. Ve tvém případě to bude iotn26.h. Když ho otevřeš, najdeš tam kromě jiného i názvy vektorů, třeba zmíněný “USI_STRT_vect”.

Když máš takovou prehistorickou verzi IDE, překladač na tom bude patrně stejně. Jenže právě překladač je to co tě obvykle (krom tradičních chyb mezi klávesnicí a židlí) dělí od úspěšně přeloženýho programu.

jo to chápu, ale mě vadí právě to IDE. To zpracování je příšerný. (textový editor)
Myslel jsem právě, zda neexistují nějaká volně dostupná jiná IDE. (k 8051 toho třeba existuje mrtě)
A Asi udělám ten upgrade AVR Studia a okolí, až dokončím tenhle projekt.

Jo, to external dependencies znám. I některé ty soubory co se tam nachází.

ze ti litalo relatko na jinem portu je jen indikaci toho, ze mas spatne nastavene porty.

Jasne ze existujou :slight_smile: Nejsou urceny pro konkretni platformu, ale jsou to obecne IDE, konfigurovatelne pro jakykoliv prekladac.
Bud Eclipse na jave, ale ja osobne Eclipse nemam rad. A nebo naprosto bezkonkurencni Code::Blocks. Pouzivam ho jak pro AVR, tak pro ARMy a i pri psani programu pro PC v C++. Vyzaduje to ale trosku znalosti s nastavenim kompilace a linkeru. Zakladni sablony pro AVR projekt ale ma.
Prekladac ale budou pouzivat stejny jako avr studio - gcc toolchain.
Jinak jako IDE se da pouzit i MS Visual Studio, vcetne prekladu :wink:
Simulator ale budes mit jen v AVR studiu.

Popřemýšlím o tom :wink:
Teď ale nemám časa si s tím hrát, až ke konci prázdnin.
Chybějící simulátor mi tolik vadit nebude - stejně jej nepoužívám a simuluji raději v realitě.

michalll: Si chytrý, jako hodinky. (nebo holinky?) Tak mi vysvětli, jak špatný nastavení portů (tím rozumím nastavení registrů DDRx) způsobím to, že zároveň s přístupem na PORTA se mi mění PORTB, a to ještě né stejně.

To je nejaky divny :slight_smile: Podivej se do vypisu po prekladu jak to prelozil.
To vidim spis na nakou chybu v programu, blbe zapojeny (nekde zkrat nebo studenak), nebo proste chyba mezi zidli a klavesnici. A nebo spatny avr. Jaka je to verze prekladace? prikaz slozka_win_avr/bin/avr-gcc -v

Do výpisu jsem se díval, je tam bordel jako v tanku, a i přesto že jsem nejmíň rok na AVR dělal v ASM, prd jsem se tam vyznal.
Chyba v programu. Kde? Oba porty jsou inicializovaný, a jen PORTA se používá, pouze tupě bliká LEDkou pomocí přerušení od časovače. A do toho na PB3 poklikává relátko v nějakým intervalu, který nikde ani není definovaný. To není chyba mezi židlí a klávesnicí.
Špatný AVR nevylučuju. Tenhle kousek už toho zažil dost. Bohužel náhradní zrovna nemám.
gccc verzi jsem zjistil že je 4.3.2 (Win AVR 20090313)

k tomu relatku mas neco pripojeny ke kontaktum? Jestli jsi si jistej svou praci a mas i dokonale udelany zapojeni, tak uz muze byt spatny to avr jedine.

Neni jedno, co má relátko na kontaktech? (nic tam nemá).
Jsem si jistý svou prací, není to první zapojení který jsem s AVR dělal. V elektronice mám praxi už 11 let, tak snad umím zapojit relé a LEDku na tiny26 :slight_smile:
Mno zatím to AVR spolupracuje… Pořád mi ten program nefunguje jak bych chtěl, ale teď to jsou chyby mezi židlí a klávesnicí.

EDIT: Momentálně poslední chyba byla že jsem si pospletl světové strany a z MSB udělal LSB a divil se, že mi přes komunikační linku chodí dycky komplement těch dat :smiley:

Ještě ohledně PB3 - je tam pwm výstup, možná bylo nějaký nepatřičný nastavení timeru.

Vidíš, to je pravda. Jelikož jsme ale původní program smazal, tak už ani nezjistím, jestliten timer, co jsem měl puštěný byl zrovna v kooperaci s tím PB3. I kdyby to ale PWM generovalo, tak to relátko cvakalo tak na o řád nižší frekvenci. Timer byl 30,5Hz, a relátko cvaklo tak 2x za sekundu.
PS: Ještě oprava, v mém předchozím příspěvku jak jsem psal o tom prohozeném LSB a MSB - tím se doplněk nevytvoří, ale zrovna to číslo, co mi skrz to něják prošlo se udělalo jako přesně jeho doplněk.
Nyní už mi ta sběrnice oběma směry chodí, takže už jen odlaďuju mouchy a zrychluji komunikaci, schválně kam až to půjde dostat ]:>

EDIT: Nejvyšší dosažená CLK frekvence je asi 100kHz po 100m kabelu, přičemž sběrnice je na obou stranách softwarově emulovaná. To je myslím dobrý úspěch ne ? :slight_smile:

No v nekterych pripadech neni. Musel jsem nejaky typ relatek vymenit, kdyz spinaly 230V~, i kdyz ve specifikaci to mely povolene. Nejak se to naindukovalo, a relatka cvakaly jak o zivot i bez napeti na civce. Ptal jsem se jen pro jistotu :slight_smile:

eh, to měl být vtip? “nějak se to naindukovalo”
Spíš chyba v otm, že se ti indukuje bordel z okolních obvodů do procesoru a ovlivňuje jeho činnost. (Špatně navržený plošný spoj, nedostatečná filtrace napájení, …) O tom, že za to může samo relé silně pochybuji.

Tak o tom nepochybuj :wink: Do procesoru se nic neindukovalo, makal jako hodinky. Bylo to nevhodnym typem jakychsi mini relatek. Nebyla to moje konstrukce, jen jsem to pomahal rozchodit.
V kazdym pripade to tvuj pripad neni.

Mne, to fakt není. Já mám všecky čtyři relata bez zátěže, pět optoizolovaných vstupů je taky bez zdroje signálu.
Co to bylo za relátka ? Nebyly to nějaká signální relé 200mA na kontakt? Ty na síť rozhodně nejsou, přestože je na nic třeba psáno že to má kontakty na 250V.
Ale i tak pochybuju o tom, že když na relé (jeho kontakty) připojíš větší střídavé napětí, že bude jen tak cvakat cívkou. Tu cívku musí něco připnout ke zdroji, třeba tranzistor, ovládaný procesorem. A ten budící signál pro tranzistor se může vzít jedině z procesoru, případně se naindukuje nepořádek do báze, neníli báze na nízkoimpedančním zdroji (například zapomněl-li člověk programátor nastavit PIN jako výstup, a běhá mu to jen na pull-up).
Hádat se o tom s tebou nebudu, je to trochu mimo zdejší téma, ale třeba se přidá někdo jiný, a řekne co si myslí o problému, který se ti vyskytl.