Hát nekem azonnal lefagy amint elkezd a saját lábán futni a program, és érdekesség hogy Programmers Notepad-ból nyomom fel akkor meg nincs ez a hiba.
Levittem az órajelet is amennyire csak lehet, de hiába....

Szóval amit feltöltök rá az már egy kiforrott, tesztelt program ami már futott egykoron'

Ha a reset, illetve a tápfeszültség túl lassan fut fel, akkor a processzor általában nem indul el. Akkor sem, ha a brownout nincs becsekkelve.

Túl lassú vélhetően a reset felfutása magán a programozón.

Biztos hogy ez program függő? Nem csak épp szerencséd volt? 10 esetből 10-szer igaz az elmélet.

Akkor mas mint ami nekem volt, mert az enyem el sem kezd futni. Szerintem nalam az a gond hogy a jtag nem resetet ad ki, hanem a programot elinditja a megadott kezdocimtol, ami igy tippre a bootloader cime, csak en nem hasznalok bootloadert...

Gyorsan írtam néhány pár soros kis programocskát, ledekre meg lcd-re.

Tapasztalt : Porgrammers Notepad mindig hibátlan, AVR Studio-bol meg néha fut egy kicsit, néha nem, de előbb utóbb meghal.

A programozó a HEstore féle STK500.

Sziasztok!

Egy elég fura problémával fordulok hozzátok. Tegnap a HEStore-bol vettem egy AVR-ISP USB-s programozót, ugyanaz, mint ami itt van: AVR-Doper. Összeforrasztottam, atnéztem és amikor a géphez csatlakoztattam a következőt irta: Usb Device Not Recognized. Kipróbáltam winXP, Vista és win7 alatt is, néztem más PC-n is, de mindenhol ezt az üzenetet irta.

Találkozott már valaki ilyennel?

Hali!

Az USB D-, D+ diódái jól vannak benne?
Nekem akkor írta ezt amikor nem jó diódákat tettem bele.

Szia!

A diódákat a leirásnak megfelelően forrasztottam be, de még egyszer megnézem.

Megnéztem és jól vannak beforrasztva.

Hellosztok!

Ma egész nap egy MEGA644-es sorosporti illesztésével szenvedek max232-őt használva. A kommunikáció egy ideig ok (1-2 sec) majd összeomlik. Ugyanezt a hibát produkálja belső 8 MHz-s oszcillátorról és külső 4 MHz-s varcról (2*27 pF-dal) Mi lehet a probléma?


Mi okozhatja a hibát?
Segítségeteket előre is köszönöm: Hurka

A topik felett lévő pontok közül a 3.
ATmega644 187. oldaltól kezdődik a táblázat. Ki kell választanod, hogy melyik kommunikációs sebességhez milyen kvarcot kell használnod ahhoz, hogy a kommunikáció hibamentes legyen! --> 0.0% Ha ez nem teljesül, akkor ahogy te is írod, "összeomlik".

Sziasztok!

Tudna valaki tanácsot adni egy elméleti kérdésben?

Egy ATmega8-al építek egy AC ventillátor fordulatszám-szabályzót. A hőmérséklet mérését egy DS18B20-as digitális szenzorról veszem le 1-Wire buszon, a fordulatszám szabályzást pedig egy triak-al oldom meg, a triak gyújtásáért egy MOC3023-as opto a felelős. Az AC zéró átmenetét egy optocsatolón (4n35) keresztül figyelem és megszakításból adom a gyújtóimpulzust a megfelelő késleltetett időzítéssel. A gondom ott kezdődik, hogy az 50Hz-es hálózati frekvencia miatt összesen 10ms lesz egy félimpulzus, míg a fő program futhat, utána megint jön a következő interrupt. Viszont a hőmérő IC-nek akár (pontosságtól függően) 600ms is kell, míg választ ad a hőmérséklet-mérési utasításra. Azaz, ha közben bejön egy megszakítás, az szétcseszi a kommunikációt ergo addig le kell tiltanom az interruptokat.

Arra gondoltam, hogy nem minden egyes félhullámra szinkronizálok, hanem csak mondjuk minden 100.-ra, így lesz ideje a főprogramnak elvégezni a mérést és a számításokat. Csakhogy ehhez kellene egy processzor-független jelgenerátor, amit addig futtathatok, vagyis a PWM. Jól okoskodok? Csinált már valaki ilyesmit? Megköszönném az ötleteket, mert nem nagyon vágom, hogy ezt hogyan lehetne összehozni!

Hali
A dolog SW reszet most ne bogozzuk, de az AC motorok (nem univerzalis, vagy kefes) a fazishasitasos szabalyzast indian fustjelzessel jutalmazzak. Magyarul nem szabalyozhatok fazishasitassal. A homerseklet meresere pedig lehetne alkalmazni valamilyen analog kimenetu erzekelot (MCP9700A, TC1047A chpcad-nal), mert az AD sokkal gyorsabban vegez, mint a soros atvitel.
Udv Vili

Csinalsz egy idozitest a 600ms-ra, ha a homero IC nem general interruptot... Az ISR-ben pedig eleg ha bebillentesz egy flag-et, majd mikor a 10ms varakozas (semmit teves) van akkor azt a falg-et lekerdezed es megfeleloen cselekszel...

Masik megoldas, hogy a homero interruptot megszakithatova teszed, akkor csak nagyon keves pontatlansag all elo ami elviselheto.

Amugy nem kell karomkodni, megertjuk a problemad anelkul is

Kösz a figyelmeztetést, de kefés motorokról van szó, vagyis a fázishasítás játszik, ha teljesítményszabályzásról van szó. Sajnos a szenzornak is muszáj ezt a digitális változatot használnom, mert zajérzékeny a környezet és változó a kábelhossz is. A hardveres résszel nincs gond. Próbakörnyezetben, két külön uC-n működik a hőmérsékletmérés és a fázishasítás is. Csak nem tudom őket egy kontrolleren összehozni ezért kértem segítséget az ötletelésben.

Hali

Nalam a digitalis atvitel (kiveve RS485) sokat hibazott zajos kornyezetben. Az analog jelet lehet szurni sima RC taggal, es akar 500 meterre is elviheted zavaras es jelvesztes nelkul. A digitalis atvitelt viszont barmi arrajaro kobor szikra megzavarja. Melle a jel feldolgozasa AD-vel sokkal gyorsabb.
Udv Vili

Először is kösz a választ!
Másodszor nem értem (egyik verziót sem).

A hőmérő nem csinál interruptot, tehát időzítve kérdezem le, ez világos. De maga a lekérdezés és a rá a válasz eltart 600ms-ig. Közben ki fogja nekem figyelni a a zero-crossing-okat, ha kikapcsolom a megszakítást? Ha engedélyezem, akkor viszont az aktuális interrupt tönkre fogja vágni a lekérdezési eredményemet (egy darab függvényről van szó, ami kiadja a lekérdezést, majd fogadja a választ és letárolja. Nem lehet megszakítani, mert a 1-wire bus kommunikáció szoftveresen van emulálva és pontosan időzítve).

Flag-eket sem tudok használni, mert a fázishasítás trigger-jelének időzítése úgy van belőve, hogy az interrupt-vektor indulása a kiindulási pont. Ha a zéro-átmenet érzékelésekor bebilletek egy flag-et, amit "később" majd lekezelek, akkor mi értelme van az egésznek? Mihez fogok időzíteni?

Vagy én nem értem, hogy mit javasolsz, vagy te az én problémámat! Magamat ismerve, valószínűleg az előbbi, szóval magyaráznál még egy kicsit?


off!
ps. Nem káromkodtam. Átolvastam, amit írtam és becs'szó nem káromkodtam benne sehol. Vagy a "szétcseszi a kommunikációt" megjegyzés volt erős neked? Sajnálom...majd jobban vigyázok a nyelvezetemre!

A digitális jelnek van crc-csekkolása, valamint gyárilag kalibrált IC-ről van szó. Az analóg szenzor tökéletes, ha adott kábelhosszról van szó, ha van időd kalibrálgatni, stb...arról ne is beszéljünk, hogy nem egy szenzorról van szó egyszerre, hanem...

Na haragudj, de nem mellékeltem kapcsrajzot, valamint pár oldalas ismertetőt arról, hogy milyen környezetben, pontosan mire és hány darabot kell belőle használnom. Szándékosan, mert irreleváns tényezők. Fogadjuk inkább el, hogy tudom, mit miért csinálok. Köszönöm, hogy segíteni próbálsz, de nekem csak a SW részében kell a segítség és abból is csak elméleti.

Hali
Bocs hogy eroskodok, de az analog erzekelo 10mV/C feszultseg kimenettel rendelkezik es semminemu kalibraciot nem kivan. Mivel aram nem folyik a jelvezeteken, nincs jelentosege a kabel hosszanak. Ami szerintem azt jelenti hogy ha rossz a meres akkor eldobod, es majd a kovetkezo merest felhasznalod, ha jo a CRC (ujabb 600 msec). De vegulis Te tudod.
Udv Vili

Igen, felre ertettem akkor, azt hittem a homero 600ms-enkent tud ujabb meresi adatokkal szolgalni.

Sajnos azt kell mondjam hogy ha szoftveresen nem sikerul ezt kiokoskodni akkor rossz eszkozoket valasztottal a feladatra -- vagy a kontrollert vagy a homerot kell akkor lecserelni.

Nem tudom, hogy milyen hibaturesek vannak a 1-wire-ben, es, hogy mekkora latency-vel jarna a zero crossing detektalassal jaro feladatok, de ezt szamold ki. Ha nem megy akkor tenyleg nincs mese, mas eszkozok utan kell nezni, vagy egy masik AVR-t beallitani ami csak homersekletet mer es mondjuk parhuzamos kapcsolaton keresztul kommunikal a fo AVR-eddel stb.

Szia!
Nem vagyok jártas annyira az ipari környezet technikáiban... De nem pont a digitális átvitelnek lenne nagyobb létjogosultsága hosszú távon? Számomra az analóg jel tűnik zavarérzékenyebbnek a digitális jellel szemben. Gondolom nem véletlenül írtad, amit írtál, de mégis kétkedem benne. Valószínűleg a tapasztalatlanság miatt...

Hali
Gondolj bele: van egy kabeled, amin soros formaban megprobalsz atvinni informaciot, ami 16 bit hosszu. Tetelezzuk fel, hogy az atvitel ideje alatt bekapcsolunk, vagy kikapcsolunk egy szep nagy motort, vagy egy magnesszelepet. Ezek ugye termelnek valami eros elektromos zavart, ami valamilyen uton atindukalodik az en jelvezetekembe. Ez okoz nekem egy bit (jo esetben) hibat a bitfolyamban. Amennyiben az LSB hibazik csak 1 az elteres. de ha a MSB mar 32768 lesz a hiba erteke. Es meg akkor nem beszeltunk a tavolsag miatti jeltorzulasrol. Viszont ha analog modon probalom atvinni a jelet, ami 10 mV/C meredeksegu, belathato hogy arnyekolt kabelen atvive es egy egyszeru RC szurot alkalmazva sokkal kisebbek a hibak, es raadasul (mivel a jelvezeteken nem folyik aram) a tavolsag valtozasa sem fog hibat bevinni a meresbe. Ugy roviden ennyi a digitalis atvitel josagarol. Persze ha mindket oldalon van egy par GHz-es processzor+kornyezete, van eleg ero kiszamolni a hibas adatokbol a valos ertekeket, de itt egy kisteljesitmenyu procirol beszelunk ipari kornyezetben, soros adatatvitellel.
Udv Vili

Sziasztok,
tudna valaki segíteni, hogy kicsit magasabb matematikával hogyan lehet dolgozni az AVR-C ben?
egy kis logaritmus?
A lényeg, hogy van egy páramérő szenzor ami ATMEGA8-hoz van illesztve.
Meg vannak a mért 8bites számok, meg van az összefüggés is, de logaritmus is van benne, és itt már nem tudom hogy kell. (helyes adattípusok, funkciók...stb)
Előre is köszi.

Úgy látom kezdünk átmenni az analóg vs. digitális szenzorok tárgykörbe...

Amit írsz az teljesen igaz, csak pár apróságot nem veszel figyelembe: 16 bitet áttolni egy vezetéken pár tíz ns. A motorodat pont ez alatt kell beindítanod. Tegyük fel sikerül. Ekkor a crc-ellenőrzés visít, hogy vacak az adat és megismétled az átvitelt. Probléma megoldva. Mellesleg a digitális szenzor drótja is árnyékolt...és távolsági torzulásról ne beszéljünk, mert pár tíz méteres szakaszon ez nem releváns.

Aztán minden egyes analóg szenzorodhoz kell egy csatorna ADC. Egy ATmega8-ason pontosan 6db van, vagyis ennyire vagyunk belimitálva, vagy muszáj külső ADC-t használni.
És igenis kell kalibrálni a szenzort. A gyárilag megadott értékek szépek és jók, de ha ráforrasztasz pár méter drótot, akkor maga drót melegedése is beleszól a mérési eredménybe. Vagyis a pontos értékekhez (nekem 12bites pontosság kell!) nem árt tudni, hogy tényleg mennyi az annyi, pláne - mint esetemben - több szenzor értékének időbeli deriváltja, illetve azok különbségét kell meghatározni.
Mindezt meg lehet csinálni sima rezisztív érzékelőkkel is, de minek görcsölni vele, ha van egyszerűbb módszer is.

Bent a cégnél úgy 8-10ezer darab thermoszenzort használunk üzemben, ipari körülmények közt. Egy sem analóg...tudom, nem túl jó érv erre hivatkozni, de azért valami csak jelent, nem?

Köszönöm!
Rávezettél a megoldásra! Ott volt a gond, hogy a szenzor lekérdezése (pontosabban a parancs kiadása a mérésre) és a válasz közti idő volt túl nagy. De ha a választ nem a főprogramban, hanem azt is egy megszakításban kezelem le, akkor megvagyok!
Most már csak meg kell csinálnom, de legalább már tudom, hogy mit!

Hali

Nem tudom mirol beszelsz, vagy nem ertem. A szenzor feszultseggenerator, tehat a terhelestol nem valtozik a kimenofeszultsege. Kalibralni nem kell, mivel gyarilag kalibralt. A derot ellenallasa (par ohm) nem valtoztatja meg a feldolgozas helyen a feszultseget, mivel az AD bemenoellenallasa sokkal nagyobb mint a drot ellenallasa.
Udv Vili
Ps En tobb mint 20 evig dolgoztam egy porcelangyarban es csak analog hoerzekeloket hasznaltunk (PtRh-Pt hoelemek tomkelege).

A digitalis vs analog-hoz meg csak annyit, hogy itt van pl ez a digitalis TV adas. Ezzel az a problemam, hogy digitalis: Vagy tukor tiszta a kep (1) vagy nezhetetlenul kesze-kusza (0) . Eleg ha jon egy kis esozes es maris 40 csatornabol kiesik 28 -- a tobbi valoszinu mas adon van es erosebb a jel...

Vissza sirom ilyenkor a regi jol bevalt analog technikat, ahol max a kep kicsit szemcses lett, de meg ugy is nezhetok voltak a csatornak...

Nyilvan hasonlo a helyzet minden mas digitalis megoldas eseteben amit vilmosd mar felvazolt.

Sziasztok,
A matematikai funkciókat megtaláltam a direktívák között (math.h), csak nem a util könyvtárban, hanem eggyel feljebb.
A log(double __x) funkció meg is van.
Ha beírok egy konkrét számot azt kiszámolja, és el is küldi a logaritmusát szépen a Hyper Terminál-ba.
A baj akkor kezdődik, amikor változót teszek a zárójelbe.
Ilyen hibát kapok:
d:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr4\libc.a(floatsisf.o): In function `__floatunsisf':
Ja ás még néhány fontos lemaradt AVR Studio-val csinálom
Előre is köszi

Sziasztok,
Azért szeretem ezt az oldalt, mert előbb utóbb megválaszolom magamnak a kérdéseimet.

A megoldás kulcsa a hibaüzenet, amelyre keresve egy angol oldalon meg van a megoldás. Mivel vannak akik még annyira sem bírják az angolt mint én, azoknak leírom.
A hiba üzenet:

A megoldás:
AVR Studio
Project menü
Configuration option...
Libraries ikon
.. és itt a libc.a-t kell a projekthez adni.
... és lám a log(x) vígan működik a megfelelő típusú változóval is.
Jelenleg is működik a páratartalom mérő, úgy hogy közvetlenül a RH%-ot írja a Hyper Terminálba és ehhez a páratartalom mérő helyettesítő függvényével számol.
Szóval a profiknak ez semmiség, de én nagyon meg vagyok elégedve ... az oldallal.

Orulok, hogy megtalaltad a valaszt!

Egy apro kiegeszites:



Ezek nem direktivak, hanem fuggveny deklaraciok. Nem kotozkodeskeppen, hanem mert ha a pontos kifejezeseket hasznalod akkor hamarabb megtalalod a megoldasokat.

Sajnos ez a zéró kezdők baja lehet, mert a Cprogramozás jegyzetben #-vel kezdődő dolgokat direktíváknak írják, és mivel #include volt a megoldás az első problémára, (és az ugye #-vel kezdődik) ezért mentem/írtam a leírt betűk után.
Köszönöm a korrekciót.