Fórum témák
» Több friss téma |
WinAVR / GCC alapszabályok: 1. Ha ISR-ben használsz globális változót, az legyen "volatile" 2. Soha ne érjen véget a main() függvény 3. UART/USART hibák 99,9% a rossz órajel miatt van 4. Kerüld el a -O0 optimalizációs beállítást minden áron 5. Ha nem jó a _delay időzítése, akkor túllépted a 65ms-et, vagy rossz az optimalizációs beállítás 6. Ha a PORTC-n nem működik valami, kapcsold ki a JTAG-et Bővebben: AVR-libc FAQ Idézet: „Igaz trudnai, ennyi az ADC felbontása nincs mit tenni.” Nem ezt mondtam  Hanem azt, hogy nem a felbontassal lesz a problemad, hanem azzal, hogy a mereseid pontatlanok lesznek. Probaldd ki, hogy egy fix ellenallast mersz sokszor, az also bitek szinte ossz-vissza fognak ugralni... (nem szimulatorban!)Idézet: „Az, hogy a bejövő feszültség mennyire pontos, az már a hardveres gondja” A firmware fejlesztes abban kulonbozik a szoftver fejlesztestol, hogy a firmware fejlesztonek ismernie kell a hardware-t, es arra a bizonyos hardware-re kell irnia a programot. Gyakran az eszkoz fejlesztese igenyli, hogy egyutt fejleszd a hardware-rel (vagy egyutt mukodj a hardware-essel, es nem ugy, hogy nesze itt a hw, csinalj hozza sw-t, hanem hogy ossze dugjatok a fejetek, hogy akkor hogyan is kellene ezt vagy azt megoldani). Tehat a valasz az, hogy kiserletezz, es tapasztalj, es mikor latni fogod, hogy meg a tized volt kijelzo is ugral akkor tordd a fejed hogy az miert van Ha megvan miert, akor meg tordd a fejed hogy lehetne kikuszobolni
Tudna valaki segíteni, hogy hogyan tudok AVR Studio-ban new-projectet elindítani, mert amikor a képen látható résznél nem megy tovább. Mint rontottam el? :no:
Mindent próbáltam, de nem engedi a proci kiválasztását, így nem is enged tovább.
Ha csak programot fejlesztgetni akarsz és konkrétan nincs égető harware-ed épp, vagy másféle van, mint a listán, akkor a bal oldali listából felülről a 2-dikat kell választani, azaz AVR Simulator. Utána jobb oldalt kiválasztod az AVR típusát, amire a programot írni akarod.
Ha meg van konkrét égetőd, pl. JTAG ICE, akkor azt választod, és utána értelemszerűen ismét a jobb oldali listából.
Valassz ki pl Simlatort vagy Simulator2-t, majd a konkret AVR tipusat, majd Finish...
UI: Ja, most latom mar ment valasz, bocsanat!
Na ez a problémám, hogy semmit nem enged kiválasztanai az atmelokból. És ezt nem értem sehogyan se.
Akkor egy elkezdett project előtt nem kell AVR-t választani?
Nem kötelező. Utólag is be lehet állítani a projekt beállításoknál.
Na jo, de akkor is kellene tudnod az elejen kivalasztani az eszkozt. Adminisztratorkent vagy bejelentkezve? Mintha valami jogosultsagi problemarol olvastam volna ezzel kapcsolatban.
Amugy masik otlet: Ha jol latom 4.13-od van, mar van 4.18-as is. A 4.13-asbol ket service pack is kijott, tehat lehet erdemes lenne frissiteni?
A frissítés segített.
Már csak az a kérdésem, hogy ha van egy régebben elkészített project, mert ha megnyitom az aps file-t akkor nem találja a dolgokat, mert amint látom más honnan is hivatkozás is van. Ezt áttudom állítani? Szeretném egy kicsit át variálni a progit, mert egy lengyel progi, így nyelvet, és az első LCD kijelzéseket.
Hát sajnos nem boldogulok, valaki ne tudna segíteni, örökhálám üldözné.
Most itt akadtam el. 
Szerintem még a célmappa helyével is probléma lehet.
Én a "C" meghajtó gyökérkönyvtárába szoktam csinálni egy mappát és oda mentek.
Megcsináltam a törtszám kiíró saját függvényt az LCD-re az ADC-ből.
Gtk 'LCD Driver'-ét használtam alapként. A következő a probléma: Kiolvasom az ADC egyik csatornájának értékét, kiiratom, majd kiolvasom a másik csatorna értékét, azt is kiiratom, és a két szám ugyanaz. Mindkét csatorna ugyanazt a 0-1023 közt levő számot írja ki, miközben csak az egyik AD bemeneten lévő trimmert tekerem, a kásik csatorna fix 5V-on van. Külön külön jó a kijelzés (tehát, ha csak az egyik csatornát írom ki, vagy csak a másikat, akkor annak megfelelő érték íródik ki). Rápillantanátok a forráskódra, hogy hol lehet hiba?
Gondolj bele itt mi tortenik: 5-os csatornat kiolvasod eloszor, azaz ADMUX valami xxx00101 lesz, majd 4-es csatornat, es az OR muvelet miatt lass csodat, ADMUX szinten xxx00101 lesz...
Sziasztok!
Tudnátok írni arról pár gondolatot, hogy az AVR Dragon és a Topi féle égető közül miben melyik a jobb és miért? Előre is köszönöm.
Köszi! Tényleg itt volt a hiba, előtte törölni kell az előző kiválasztást, most már működik szuperül a feszültség kiírás! Most jön a szépítés, meg az árammérés függvény megírása.
A vezetékdzsungelért én kérek elnézést! 
AVR Dragon!
- Automatikusan változtatja az SPI feszültséget a céláramkör feszültséghez. (Ha 3V3-as a rendszer, nem 5V-al programoz) - Van benne HVPP és HVSP (fuse bit, reset láb használat, stb) - Van benne JTAG a debugoláshoz - HW-es USB-je van, gyorsabb a programozás. Jobb, de cserébe drágább cucc. Kicsit furcsa, hogy a saját doper programozó változatomról épp lebeszéllek. De ez az igazság. Ha nem az összeg számít, akkor Dragon! Idézet: „Kicsit furcsa, hogy a saját doper programozó változatomról épp lebeszéllek. De ez az igazság. Ha nem az összeg számít, akkor Dragon!” Valoszinuleg mert Te szakember vagy es nem kozgazdasz, jogasz vagy politikus A Dragon tudja a debug wire-t is, nem? Amugy a PIC-es vilagban kicsit a PICkit2-hoz hasonlitanam, tehat amolyan mindenes es megis olcso, es olcso alatt ertem, hogy olyan 50 euros arkategoriaban van es nem par szaz vagy akar par ezer... Kulonbseg, hogy a PICkit2 dobozban van es meg szamitogep nelkul is kepes programozni + van benne logikai analizator es soros port emulacios kepesseg is ami speci debug dolgokhoz jol johet. Olyan nincs itt AVR berkekben ami meg ezeket is tudna? Vagy menjek a fenebe es inkabb epitsek par csatornas logikai analizatort magamnak? Idézet: „inkabb epitsek par csatornas logikai analizatort magamnak?” Inkább építs valami célhardvert, mert pl. a PICkit2 "logikai analizátor" sebessége is nagyon korlátozott: 1 MHz a maximális mintavételezési frekvencia. Van, persze, amire így is tökéletes (pl. a soros port sebességének ellenőrzésére), de van, amire alkalmatlan (pl. 10 MHz-es SPI porti kommunikáció ellenőrzése). A PIC18F2550 12 MIPS-hez képest az AVR 16 MIPS sem jelent lényegi gyorsulást. Már spekuláltam rajta, hogy egy régi Pentium I-es alaplapból kiemelt L2 cache memóriát kellene összeházasítani egy USB-s mikrovezérlővel, csak kell még egy számláló, ami a címeket pörgeti és a beíró impulzusokat generálja mintavételezéskor. (pl. W24129A-12 16kx8 bit statikus RAM, 12 ns elérési idővel)
Na jo, hat igazandibol a szoftvere sem kepes sokmindenre, az, hogy logic analyzator-nak hivja magat csak arra utan, hogy digitalis es nem analog (aka. nem digitalis oszcilloszkop). Magyaran nincs benne (legjobb tudomasom szerint) protokoll analizator sem ami egy ilyen SPI kommunikacios tesztelesekhez azert jol jonne. Arra viszont kituno a dolog, hogy mit tudom en, PWM jeleket nezegessen az ember, vagy akarmi mas digitalis kimenetet. na mindegy, szerintem jo dolog, hogy vegulis nemi firmware pofozgatassal vegulis ingyen odaadtak ezt a funkcionalitast is. Mostanaban keves ilyet latok, hogy egy ceg energiat fektet valami fejlesztesebe es cserebe nem ker el extra penzt -- pl siman csinalhattak volna egy "pro" valtozatot, meg csak fel sem haborodnank rajta annyira megszoktuk mar
És mi a helyzett az AVR ICE-al? Abból láttam clone változatot.
Igaz mind sorosportosak voltak, de vajon lehet valamilyen átalakítóval USB-re rakni?
ICE-ról lebeszélnélek megint.
Dragon! Jelenleg nem nagyon van más alternatíva a prog+debug-ra. Igazat megvallva, van külön JTAG-ICE-om is, meg dragonom is. Kettő is. De JTAG-et talán max 5-ször használtam debugolásra. Akit nem kényeztettek el ilyennel, az megtanult debugolni JTAG meg minden nélkül. LED-eket használva, sorost használva, fejlesztett készüléken szinte minden IO-t debugra használni. Fogadni mernék, hogy X hibát gyorsabban megtalálok JTAG nélkül hagyományos módszerrel, mint aki JTAG-el kezd neki hibát keresni. Nem is beszélve arról, hogy sok esetben real-time folyamatoknál JTAG és társainak használata esélytelen. Ki is fut az eszköt az időszeletből, taskból, stb.
Értem, amúgy nekem a te avr doper-ed van meg, és nagyon szeretem.
De sajnos most máshol akadtam el, mert van egy lengyel pákavezérlőm, de jó volna a nyelvet átállítani, csak sajnos nem boldogulok vele. C-ben íródot, AVR studióval, és a forráskódja megvan. Hát most ez szvt.
Bocs. Elkalandozott az egér
 Nem Neked címeztem, hanem labu01wx-nek. Idézet: „Nem is beszélve arról, hogy sok esetben real-time folyamatoknál JTAG és társainak használata esélytelen. Ki is fut az eszköt az időszeletből, taskból, stb.” Ne is mondd, anno mikor USB frameworkot heggesztettem meg a "debug LCD" is lassu volt neha. Ami miatt megis megerte LCD-vel szenvedni, hogy a kijelzett betucskekkel eleg konnyen meg lehetett mondani milyen sorrendben tortenik pl. az enumeracio, amit LED-ekkel sokkal nehezebb lett volna megmondani. Ugyanigy soroson is lehet ilyen kriptografikus betu-debugot alkalmazni. Na mindegy, Dragonon mar amugy en is regota gondolkodom, valoszinuleg ujevi "meglepetes" ez lesz magam szamara lencsefozelek helyett A ZIF foglalaton is gondolkodom, csak az a bonyolult patchelgetos megoldas amivel szinte minden eszkozhoz mas kombinacioban kell a vezetekeket egyesevel oda vezetni a tuske sorra, szoval az nem szimpi, de gondolom nincs tul sok valasztasa az embernek.Te beultetted azt a reszt? Csinaltal speci kabeleket a kedvenc tipusaidnak, hogy ne kelljen gondolkodni mit hova kell dugdosni, vagy hagytad a fenebe es az ajanlas szerinti kabel-dzsungel modszert hasznalod?
Nem csináltam, semmi speckót. Van egy tüskesor adapterem, ami egyik fele 5x2 szalagkábel foglalat, másik fele 6p-s RM2.54 tüske.
Alábbi sorrendben rajta a jelek: GND, VCC, RESET, SCK, MISO, MOSI. Miért? Egyszerű. ATmega szériának kevés kivétellel ez a láb sorrendje. Esetlen néha a reset máshol van. Atmega16 és társainál meg teljesen kézenfekvő, mert ott mivel egymás mellett vannak, esetleg kisebb programokat próbapanelen teszteléskor csak be kell szúrni. Nulla kábelezés. Fejlesztett eszközöknél meg van egy library-m amibe megcsináltam ezt a prog csatit. Így minden terméken egy sima felirat nélkül RM2,54-es pad sor található. Ez a programozásra. Dragonra annyit tettem összesen, hogy oldalára forrasztottam egy 5x2-es szalagkábel aljzatot, így 10p-s kábellel könnyen kötöm. Cserélhetek programozót is. Maga az 5x2 -> 6p kis adapterem tartalmazza a fentebb idézett sorrendre való átkötést. De van egy adapterem 3x2 -> 5x2p ISP csatira is. Ez csak egy kábel, mert az 5x2 az megint ISP szabvány. Szóval nekem nagyon kényelmes a dolog, mert ritkán próbapanelezek, szinte kivétel nélkül éles környezetben használom a programozót. Ott meg kis saját csati megoldás...
Sziasztok!
Az a probléma áll fent nálam, hogy Atmega16-nál a Fuse biteket véletlenül sikerült átálítani így: CKSEL3=0 CKSEL2=1 CKSEL1=1 CKSEL0=1, ami külső 3-8MHz-es RC oszcillátor. Nos én 22pF-os kondenzátort és 8,4k ellenállásal építettem meg de még mindíg nem érzékeli a programozó? Mit kellene tegyek?
Üdv!
Szeretnék egy csengőt építeni, és ha jól tudom, akkor egy ATtiny45-20SU-val ezt meg lehet oldani... Az még kérdéses. hogy milyen a kimenete (600mV 800mV) Ezen ügyben szeretnék válaszokat kérni...
Általában egyre többen programozzák a panelban az AVR-t. De vannak olyan áramköri elemek, amik miatt nem lehet programozni a kész áramkörben. Például a szervó teszter a 8 lábú cikkben. ha a poti le van tekerve, akkor esélytelen a dolog, mert leföldeli a jelet.
Ti hogyan szoktátok ezt kiküszöbölni? Vagy ez olyan, hogy "ez van", ezt kell megszokni? |
Bejelentkezés
Hirdetés |
