Ahhoz hogy elinduljon,a DB -vel kezdődő sorokat az első byte kivételével (ami a hosszt tartalmazza ) meg kell etetni vele.(egy sor egy parancs az első byte a hossz -ez csak a feldolgozhatósághoz kellett,nem kell küldeni - második a regiszter sorszáma,illetve az írás kódja , a többi az adott regiszterbe írandó adat ) Ez után szerintem 3 byte-os csomagokat emlékeim szerint a nagykönyvben megírt módon lehet küldözgetni.
Annyi hogy talán az egészet a bank( 1) regisztermező kiválasztásával kell kezdeni.
A távolságról annyit ,nyilt terepen enyhén ködös időben 40-50m-t rálátással, szobában viszont a második falon fennakadt.(sőt az elsőt sem igazán szerette.Azt mentségére kell felhozni ,hogy 30 cm falak vannak és vályogból.

Szabványa válogatja. De gyakorlatban 10 méterre számíts szerintem.

Egyet értek sikolymesterrel.
Nekem elméletileg Class 2-es modulom van, ami +4dBm-vel ad.
Viszont átállítható +8dBm-re is, így valahol a Class 1 és Class 2 között van.
Személyes tapasztalat, hogy 20-30 méterre gond nélkül elvitt, ekkor egy emberi test volt az adó és a vevő között(falas próba nem volt, illetve volt, de ipari létesítményben,sűrű vastag vasbeton fallal, amit egyáltalán nem vitt át, így ezt nem tartom mérvadónak). Ha elmentem 60-70 méterre, akkor is működött, bár ekkor ha az adó és vevő közé beálltam, akkor már megszűnt az adatkapcsolat.
Üdv Kiborg

Sziasztok. Most kezdtem az Atmel procikkal (konkrétan atmega8) foglalkozni AVR studió4-ben C-vel. A kérdésem az lenne, ha a PIND2 pinjét olvasnám (PIND) úgy, hogy nincs rajta semmi annak az értékének 0-nak kellene lennie nem?
A beállításai:

Előre is köszi a választ.

Ha nincsen rajta semmi, akkor nem lehet tudni milyen bemenetet olvas.
A bemenet értéke csak akkor biztosan 0, hogyha földelve van.

Szia!
A felhúzó ellenállások kikapcsolása esetén nagy-impedanciás lesz a bemenet, ami valóban bármilyen értéket felvehet.
"Lehúzó ellenállás" pedig nincs beépítve.

Sziasztok!

A megszakítások működésének értelmezésében és a főprogram működésében kicsit elbizonytalanodtam.
Jó értem, hogy a főprogramban lévől belül írt kód az másodpercenként annyiszor fut le mint az órajel (leszámítva a késleltetéseket) és, ha bármelyik megszakítás aktivizálódik akkor a főprogram ott ahol van megáll végrehajtja az ISR-be lévő utasításokat majd visszatér és folytatja a futást?
Sikerült úgy megirnom a programom, hogy a főprogram lényegében üres mert minden megszakításba került, de félek, hogy ezzel valahol hibát követek el igaz egyenlőre jól működik minden. A következő megszakításokat használom: TIMER0_OVF_vect, TIMER1_OVF_vect, USART0_RX_vect, PCINT2_vect, PCINT3_vect

Neked is és Mikee91-nek is köszönöm a választ. Valóban nincs lehúzó ellenállás beépítve. Mindkettőtök válasza tökéletes, sajna ezeket tapasztaltam én is.

Valahogy így. Arra ügyelj, hogyha hosszú tevékenységeket ne végezz interruptban.

Illetve olvass utána a nested interrupt témának, hogy mi van akkor, hogyha az egyik interrupt éppen fut és bejön egy másik.

Az nem elég, ha az adott ISR- valahogy így kezelem:


Kicsit most fennakadtam ezen mert okozhat valós gondot. Pl. belefuthatok abba, hogy az USART-ban épp fut a kód, de a TIMER0 közben túlcsordul és fel kellene dolgoznom. Ezek szerint ez nem fog összejönni ami baj nekem egy kritikus időzítés esetén. De fordítva is, baj, ha nem jön meg az adat az USART-on.

Hát, ha még explicit le is lövöd a cli() -vel az interruptokat, akkor biztosan nem fut le más interrupt közben, utána persze igen.

Mérlegelni kell, hogy elég-e neked az, hogyha az UART interruptod után kezeled le a TIMER0 túlcsordulását. Mert ugye annak a flagje aktív lesz, és amint vége van az USART interruptnak, akkor az is sorra kerül.

Abban az esetben maradsz le valamiről, ha mondjuk egy bejövő élváltozást számolsz egy bemeneten szoftveresen interruptból. Ekkor ha az UART interrupt futásod alatt 2 élváltozás is bejön, akkor te csak egyet veszel abból észre utólag.

Élváltozést nem figyelek csak szintváltást. És ott a két TIMER. TIMER0 mindig aktív ebben kezelem az RTC és az LM35-ök (ADC) értékének megjelenítését és TIMER1 ami csak bizonyos időzítésekhez indul el. Pl. kimenet késleltett kapcsolása.

Ezek szerint, ha jól értem akkor végülis ebben az esetben nem maradok le semmiről mert amikor végzett az egyik megszakítással megy a másikba, ha közben ott is volt változás. Csak ekkor "áll" a főprogram.

ISR-ben UART-ra, LCD-re kiíratni és SPI-vel szöszölni? Ez már túlzás.
Meg kell mérni/ki kell számolni az egyes ISR-ek lefutási idejét (a megszakítást kiváltó ok kezdetétől a főprogramba történő visszatérésig tartó idő), és ezeket összevetni a kritikus időzítésekkel.
Bár értem, így biztosan le tudod kezelni a beérkező karaktert, és nem történik semmi butaság. Ilyesmire találták ki a vevőoldali bufferezést.

Tippek:
- Nagyobb/újabb AVR-ek HW alapú UART buffere 3 byte-s. Így itt ha nem is beszed ki a bufferből, 3 karakterig "gyűjtögethetsz" (A PCINT-ből tippelem, hogy az újabbad van).
- Minek lövöd le az INT-et, hiszen az INT nem megszakítható második INT-l (1 szintű a kezelése). ha iNT alatt jön egy másik, akkor bebillen a jelzőbitje. Ha kilépek az első INTből, és van bebillent INTFlag, akkor a prioritásosabbra megyek tovább.
Soros out-ot INT alapon kezeled, hogy 1 byte-t beraksz a bufferbe és onnan küldöd ki, majd ha végezér a küldés INT alapon a következőt küldöd? vagy pollingozod a kimenetet és komótosan megy avisszaküldés?
- az LCD-t nem kezeljük INT alatt. INTben bebillentesz egy LCDKiiras valtozot, es lemented a kiirandó változót egy másikba. A főprogramban ha ajelzőbit bebillent, akkor a kiirando_valtozoban levő értéket kiíratod, majd a jelzőbitet törlöd.

Sziasztok!

LM35 használata vezetékkel elég maceráns. Mondhatni nem akar összejönni. A mérés eredménye ugrál. 1,5 méter hosszú jóminőségű árnyékolt vezetéket használok és az árnyékolás GND-re van kötve. Egész pontosan az maga a GND LM35 számára.
Tehetek én bele bármilyen kondit/ellenállást nem javul. Szoftveresen tudok javítani ezen? Igazából a mérésnek másodpercenként kell megtörténnie így az idővel nem nagyon tudok játszani és az LM35 közelébe sem tudok tenni semmit csak a vezeték másik végére. Szívesen veszek akár "hardweres" akár szoftveres tanácsot.

Mégis mekkora ugrálásról van szó?
Csak hogy átfogóbb képet alkothassunk.

1-2 Celsius fok, vagy egy nagyságrenddel több esetleg?

Illetve egy kicsit még mesélj, hogy milyen beállításokkal megy az ADC.
Referencia feszültség honnan van, mennyi. Ilyesmik.

A LM35 (MCP9700A, TC1047) silicon termisztorok jellemzoje az, hogy utaljak a kapacitiv terhelest es ezt egy gerjedessel jutalmazzak. Megoldas a kovetkezo: az IC taplabara kozvetlenul 100 nF kondi, valamint a kimenettel sorosan 470 ohm 1 k ellenallas. Utana az arnyekolt kabel, es mintha elvagtak volna a gerjedest. Egyebkent az adatlap kulon kiter erre a problemara. Jo olvasgatast! 7. oldal.

vilmosd
Az adatlap szerint jártam el és az ott leírtak ellenére ugrál.

sikolymester
0,5 - 1,5 C körül ugrál.


Az AVR-en minden táp láb előtt ott a 100nF kondi és az AVCC 10uH tekercsen keresztül kap tápot.
Az AVR042: AVR Hardware Design Considerations leírás alapján jártam el a tápok bekötését illetően.

Ha feltételezzük, hogy a szenzor tökéletesen sima kimenetet ad egészen az AVR-ig, akkor az ADC mérés 5-15mV -ot téved. Ez 5V-os referencia mellett 10 bites ADC-vel az alsó két bit ugrálását jelenti csak.

Nem tudom milyen AVR-t használsz, de tegyük fel, hogy atmega16.
Tegyük fel, hogy a táp feszültséged 5V.

Azt mondtad, hogy a Vcc a referenciád. A szenzor 150Celsius fokig tud mérni, amikor 1,5V feszültséget ad ki. Belátható, hogy teljesen felesleges 5V-os (vagy netán 3,3V ha annyi a tápfeszed) skálán mérned. Javaslom tehát, hogy használd a belső referenciáját az AVR-ednek. Atmega16-nál ez 2,56V értékű, jellemzően elég stabil kimenetet ad. Így máris kisebb kvantálású lesz a mérésed. 5V tápfesz esetén majdnem kétszeres felbontású. Így az alsó két bit ugrálása azonnal csak ~0,25-0,75 Celsius ugrálást jelent.

További tipp: ADC mérés közben le lehet állítani a rendszer órajeleit, ami csökkenti a zajt, ami zavarhatja a mérést. Ez ún. "ADC Noise Reduction" sleep mode.

Nem tudom hogyan néz ki a NYÁKod, de analóg jelek mellé, alá, fölé ne tegyél nagy frekvenciájú digitális jeleket.

Nem tudom akkor mit csinalsz, mert en hasznalom ezeket az erzekeloket, nemelyik 150 m arnyekolt kabelen van, es nincs semmi zavar. Raadasul en 2,56 V referenciat hasznalok, igy 1/4 C a felbontasom. Ha ilyen lenne mint amit irsz, egyszeruen hasznalhatatlan lenne homersekletszabalyzasra. Talan ra kellene nezni szkoppal a bejovo jelre. Ja es probald meg a tapot egy kulon kabelon, a jelet egy kulon kabelon vinni. A foldhurok csodakat tud tenni.

Nekem ez gyanús, nem is értem miért nem vettétek észre:
Ez annyit jelent, hogy a kimenő feszültség 5-15mV. Lényegében NULLA.
Most vagy az IC nem kap feszültséget, vagy a kábel szakadt/zárlatos.
Vagy nincs a műhelyben fűtés.

Azaz ugrálás mértéke. Amúgy valóban nincs fűtés a műhelyemben. Jelenleg 14 C fok van és az AVR 14 - 15,5 C között mutat.
Holap kipróbálom a belső referenciát. Amúgy nincs a közelben nagyfrekvenciás veztetősáv.
Nyák:
Bővebben: Link
Bővebben: Link

ADC bemenetek az elemfoglalat alatti 3db fehér csatlakozó.
MCU: Atmega324

Szerk:
És ilyen Klotz vezetéket használtam:Bővebben: Link

Két kérdésem lenne még:
Atmega324 esetén két belső referencia van. 1,1V és 2,56V. Nekem alapvetően elég lenne az 1,1V is mert 80 C felett már nem mérek ill. riasztást adok ki és lekapcsolok minden kimenetet. Viszont sok helyen olvasom, hogy a belső referencia nagyon nem pontos és jobb nem használni. Ebből mi az igazság?
A másik, hogy én az AREF lábat VCC-re kötöttem és 100nF-el pedig földre. Ez így jó nem?

Az 1,1V még jobb esetedben.
Szerintem ha ADC sleep mode-ba mész, akkor jó pontosságot várhatsz a belső referenciától.
Bár ahogy az adatlapban nézem, a 2,56V referencia elég gyatra. Az 1.1V pontosabbnak ígérkezik.

Sziasztok!

UART-on keresztül szeretnék adatot küldeni számítógépről. 16 bites formában, sajnos a küldendő információk 8bites módot nem teszik lehetővé.

A kérdésem az lenne, hogy ez a 16bit információ melyik regiszterben, regiszterekben tárolódik?

Olvastam Fizikus UART-al kapcsolatos cikkét, és látom hogy ott az UDR regiszterből olvassa ki, és tölti az adatokat, de nem tudom hogyan használom ezt 2bytos módszerrel.

Előre is köszi a segítséget: Tecsa

Ha AREF AVCC-re van kötve, ne kapcsold át belső referenciára!

Nekem az az érzésem, hogy vagy az UART alapjaival sem vagy tisztában, vagy már hétvége van.
Az UART kevés regisztert használ, melyek UDR,UCSRA/B/C,UBRR(H/L).
Úgy általánosságban(tehát nem bit szinten) illik ezek szerepét megismerni mielőtt nekilátsz valaminek.

16 bit átküldése:
Pont az a nehéz benne, hogy végtelen lehetőséged van erre.
Például ha van valamilyen speckó szabály a számokra, akár 1 bájtba is tömörítheted.
Általános esetben a legegyszerűbb ha elküldöd egymás után a két bájtot, majd vársz X időt.
Ha sok az adat és várakozni nem lehet akkor beiktatsz egy harmadik bájtot:
ezek felső két bitje azt hordozná hogy a 16 bites adat melyik részletét hordozzák,
az alsó 4-6 bit pedig maga az adat lenne. A sorszám alapján tudod hogy mennyit kell shiftelni...

Minden zajból eredő szűrést érdemes egy IIR aluláteresztő szűrővel végezni, ezzel szépen meg lehet válni a zajok nagyrészétől. Mivel a digitalizálás nagysebességgel történhet, így bőségesen lesz az IIR vagy esetleg FIR szűrőhöz megfelelő számú bemenő adatsorod.

Ezen felül kihasználhatod hogy az LM35 szenzor adott hőmérsékletre beállása integráló jelleget mutat, így a mérési eredményeket is nyugodtan integrálhatod (vagy az utolsó 10-20-30 mérés átlagát veszed).

A két módszert egyszerre is használhatod. Integrálás alapja az IIR szűrő y(n) kimenete is lehet.

y[n] := y[n-1] + A * (x[n] - y[n-1])

Ezt ciklikusan le kell futtatni a mérési eredményeken, (vagy folyamatosan kalkulálod az y[n-1] ismeretében) és az így kapott érték nagyfrekvenciás zajoktól mentes lesz. Az "A" tényező az elnyomást fogja adni, célszerű nagyon közel 1 alattinak választani.

A mérési eredményeket mindenképpen átlagold. Egy mérés max pár us, tehát bőven lesz mintád az átlagoláshoz, másodpercenként egy mérés pedig rengeteg.

Célszerű ezen kívül áram értékkel "távadót" építeni belőle. Kép mellékelve, illetve van egy SNOA748B nevű doksi, melyben két vezetékes (two-wire) megoldások láthatók.

De a kulcsszó mindenképp a már régi ismert: Egy mérés, nem mérés!

20 percel a kérdés feltevése után természetesen rájöttem, hogy butaságot kérdeztem. Akkor már nem tudtam szerkeszteni a hozzászólásomat.

rFactor szimulátorhoz készítenék, egy külső kijelző eszközt, amin fordulatszámra, sebességre, sebességfokozatra, és időre vonatkozó adatok jelennének meg. Az idő legkisebb egysége ezred másodperc, és minden folyamatosan változik. Nem tudom, mindent meg tudok-e valósítani.

Bontottam már szét olyan termosztátot amihez 6m vezetékkel csatlakozott LM35 és az LM35 oldalán nem volt semmi szűrő sőt még csak minőségi vezetéket sem használt a gyártó.
Sajnos már nincs nincs meg ezaz eszköz így nem tudom mi volt a vezeték panel felöli végén.
Az LM35 oldalára nem tudok tenni semmit mert egy csőhüvelyben lesz.

Próbálkoztam már az átlagolássan, de nem nagyon jött össze. Megpróbálom, hogy 100 mérés átlagát veszem és a megjelenítés idejét növelem 3-5 sec-re.