Szia kissi!

Ha jól értem, a DS18S20 digitális hőszenzor nálad működött 30m-nél nagyobb távolságon, igaz? Mennyire mér pontosan tapasztalataid szerint? A hestore-on a pdf-ében +- 0,5 C-fokot ír pontosságnak, ez kb. jó is lenne, ha tudja is.

Vezetékből milyet kell venni ezekhez? Van valami neve mint utp-nél pl. cat6e, vagy mindegy milyet veszek, réz drótot kérjek és kész? Az lenne a lényeg hogy a jel simán, sértetlenül menjen rajta végig, akár több 10 méteren is (egy családi házban helyeznék el szobánként 1 vagy több szenzort).

A több ilyen szenzor egy vezetékre ültetését, és megcímzését hogyan lehet megvalósítani? Nem fogja egy szenzor a jelei továbbításával a többi szenzor azonos vezetéken haladó jeleit zavarni, torzítani? Hogyan tudom kiolvasni és megkülönböztetni a jeleket, melyik melyiktől jött?
Ha ezek elég pontosak lennének (pl. gyakorlatban/ténylegesen max. +- 0,25-0,5 C-os mérési hiba, 0,5-1 C-os felbontás, tehát fél fok eltérést már tudjon érzékelni) és be tudnám őket így "buszra" kötni, akkor meg is lenne már a hőméréseimnek a hardveres háttere.
Ha ez a típus nem alkalmas erre, akkot tudsz másikat ajánlani? Max. 1000Ft/db ár körül.

Szia,
Csak egy kérdés. A házat már teljesen bevezetékezted? Vagyis az érzékelők helyét már kitaláltad? Sajnos nekem nincs családi házam, de lehet hogy xbee modult használnék hozzá. RF2.4GHz és nincs egy deka drót sem. Ráadásul rugalmasan a helyét is módosíthatóm. Mondjuk az valóban drágább, de esetleg másr funkcióra is használhatod.

Csak egy ötlet.......

Szia!

Nem, még nincs semmi hardveres kialakítás, most akarom eldönteni a tanácsok által hogy akkor hogy is legyen, milyen vezetéket, hőmérőt vegyek, stb.

Egy MSP430G2553-al felvértezett launchpad lesz a vezérlő eleme.
Az a lényeg hogy megbízható, pontos méréseket tudjak végezni, mindezt nem túl drága eszközökkel, amik viszonylag egyszerűen rávehetőek a launchpaddal való kommunikációra.

A cél egy fűtésvezérlés lenne, a launchpaddal, ami majd külön telepről menne. Ezt lehetne programozni a későbbiekben is PC-röl.

Központi fűtéses a ház, a vezérlőn van egy hőfok beállító tekerő/poti, csak radiátorok vannak a falakon (se padlófűtés, se más extra), gázkazán fűti fel a vizet, szóval az általános felállás.

Első lépésben 1-1 digitális hőmérőt raknék be 1-1 szobába/helyiségbe, kábelezve, ez max. 20m/vezeték, ezek csatlakoznának a launchpadra, ami egyenlőre az egyik "sarki" szobában van a gép mellett. Egyenlőre azt szeretném megoldani, hogy valós és pontos méréseket tudjak végezni legalább 4-5 ponton (4-5 helyiség), így képet kapnék az egyes helyiségek hőfokairól. Ez alapján meghatároznék egy minimumot, ami alatt bekapcsol a fűtés. Ehhez majd kellene valahogy egy megszakítást/elágazást építeni a fűtés vezérléséhez, hogy át tudja venni a launhpad a vezérlést, ha aktiválom.

Aztán ha ez OK, akkor megnövelem a hőmérők számát, ha szükségét érzem. Át lehetne térni vezeték nélküli kapcsolatokra is a hőmérőkkel, de azt még nem tudom hogyan kéne, hogy ne is legyen marha nehéz megcsinálni/leprogramozni, ne is zavarja a megosztott wi-fi-s net, és még biztonságos is legyen (pl. titkosítva a kapcsolat valahogy).

Vagy előbb megoldani azt hogy netről bárhonnan elérhető és vezérelhető legyen a fűtés (persze ha már működik a hőmérés és vezérlés), ezt vezetékesen meg lehet oldani egy alkalmas routerrel a házban és egy free dns-el. Persze kell egy LAN csatis shield is a launchpadhoz.

Esetleg mindent megoldani, mondjuk előbb a netről elérhetőséget, aztán a házon belüli vezeték-nélküli kommunikációt. Vagy akár bluetooth-on keresztül, ha képes lenne párosulni egy tablettal vagy telefonnal, akkor arról is lehetne monitorozni és vezérelni. Na az lenne talán a legmodernebb, legkényelmesebb megoldás.

Talán még elektronikus motorral szerelt szelepeket a radiátorokra, hogy helyiségenként lehessen szabályozni, de azt olvastam, az ilyen berendezések már nagyon drágák.

Az xbee az amúgy micsoda? Hogyan működik a kommunikáció? Mi kell hozzá? Árban mennyi kb.?

Szia,
Az Xbee modulok Zigbee szabványt alkalmazó RF egységek. Alapvetően kétféle jelöléssel: Xbee és Xbee PRO. A különbség voltaképpen a teljesítményben van. A PRO az izmosabb. Azzal épületen belüli kommunikációval nincs gondod. Kültéren akár az 1km is simán működik. Lehet az egy társasház is. 20 lába van a modulnak antenna csatlakozási lehetőséggel. A freki 2.4 GHz 802.15.4 protokoll szerint. Biztonságos átviteli rendszer. Kimondottan mérés+adatgyűjtéshez fejlesztették, viszonylag kis átviteli sebességre. Soros kommunikációt ismer max 240kbaud-al azt hiszem. Vagyis RX/TX kapcsolattal. Ehhez köthetsz PC-t v. kontrollert. Táp 3.3V, kis fogyasztás. A hálózat amit kiépíthetsz vele, ADHOC jelleggel saját magát képes felépíteni.Beállítható "koordinátor" vagy "router" vagy "végpont" üzemre bármelyik. A legnagyobb főnök a "koordinátor", a "router" mint általában egyébként, összekötőként teszi a dolgát ha nagyobb távolságra vannak a végpontok a koordinátortól. Akku kímélő megoldásban be tudod állítani hogy a végpont milyen időközönként küldje el az információt a központnak (hőfok pl.). Mindegyik modul egyedi azonosítóval van gyártva, így az azonosítás egyértelmű. Van benne 4 db 10 bites ADC is. Ide akár analóg jellegű hőérzékelőt is illeszthetsz. Néhány általános I/O port. Rugalmasan oda teheted az elkészült hőérzékelő modulodat ahol neked szimpatikus és a házat sem kell szitává fúrnod.

Itt a gyártó honlapján megtalálsz sok infót róla.

Az ár/érték viszonyokat, sok mindent figyelembe véve érdemes latba vetni. Ha érdekel PM-ben keress nyugodtan.

Így néz ki.

Szia!

Nekem üzemel ilyen rendszerem, de üzleti okokból a konkrét felépítését nem adhatom meg. A tapasztalataim:
- üzembiztos,
- van kb. 100m-es vezetéken 4 érzékelő, hiba nélkül dolgozik ( ennyi kellett, többet is elbírna a dokumentáció szerint! ),
- CAT5 kábelt használok,
- 3 vezetékes megoldást használok, mert a parazita táp már nem megy ilyen távon.
A pontosságáról nem igazán tudok nyilatkozni, mert nem mértem meg hiteles hőmérővel, illetve nem kalibráltam. Használok viszont DS18B20-ast, amit kalibráltatok, úgy néz ki, hogy 0-50 fokig pontos, 0-(-20) fokig max. 1 fok a hiba, ami benne van a megadott tűrésben!

A hőmérőknek egyedi címe van, ami alapján le lehet őket kérdezni egymástól függetlenül ( az adatlap leírja a módját ).

Az RF átvitellel kapcsolatban az a magán véleményem, hogy nem szeretnék mikrohullámú sütőben otthon üldögélni, inkább kábelezek ! Tudom, hogy nagyon kényelmes a WIFI, ZigBee, BlueTooth, stb. , de a kibocsátott frekvencia mikrohullámú sávba esik, amelynek az élettani hosszútávú hatásai szerintem nem egyértelműen semlegesek ( és akkor még óvatosan fogalmaztam! ) !

Steve

Sziasztok.

Tudom nem szabad kétszer ugyanazt a kérdést feltenni, de nagyon kéne egy kis segítség.

Még mindig a JD-T18" kijelzővel küzdök, és még mindig a kiíratással. A baj az, (régebben már írtam), hogy pl. az óra megjelenítésénél, amit másodpercenként teszek meg, a számokat egymásra írja, ahogy a képen is látszik. Azt próbáltam csinálni, hogy az újabba kiírás előtt rajzoltattam vele egy fekete téglalapot az órára. Így jó is lenne, de mivel minden időbe telik (a téglalap kirajzolása is) ezért vibrál az óra, és ez nagyon zavaró.
A kérdésem az lenne, hogy a kijelző nincs beállítva rendesen, vagy ez ilyen, és nem lehet vele mit csinálni? Csatolom az adatlapot is.

A segítséget előre is köszönöm.

Sziasztok egy hülye kérdés ismét : ha egy 20ms-os léptetésben számolom a leütéseket 0.1ms-os lépésben akkor azzal tudok mérni egy távirányitásu vevö impulzusát? Ugyebár egy fordulatszámszabályzot szeretnék csinálni.

Minden jól van beállítva, én is hasonlóan jártam egy másik típusú lcd-vel és azt tapasztaltam, hogy a színes lcd-knél előszőr törölni kell azt a pozíciót ahová íratni akarsz, utána kiííratni az adatom mert ha nem, akkor az előző ott marad.
Próbáltad, úgy hogy mikor megjeleníted az órát, akkor minden egyes alkalommal háttérszint is állítasz neki nem csak betűszínt? Nekem például a háttérszín állandó beadása segített.
Ennél az LCD-nél ha csak egy sort törölsz az is időbe telik és szaggatni fog. Vagy gyorsabb proci a megoldás vagy használj memóriát az LCD és proci között.

Tegnap megérkeztek a Stellaris Launchpad kártyáim. Itt nem akarok vele offolni, mert inkább az Arm - Miértek, hogyanok... topikba való téma. Csak annyit szeretnék itt elmondani, hogy a CCS 5-nél megoldható a kettős licenszelés: MSP430-hoz az ingyenes memóriakorlátos, a Stellaris Launchpadhoz pedig az XDS100 ingyenes licensz választása a célszerű. A CCS 5 Help/Code Composer Studio Licensing Information menüpontban az Upgrade fülön a Launch License Setup ugyanis nem átállítja a másik processzorhoz beállított licensz típusát, hanem egy újat hoz létre. Bocs, ha valaki ezt tudta, én csak most szembesültem vele...

Köszi. Így már megnyugodtam. Már egy pár napja az adatlapot bújtam, hogy hátha valamit rosszul állítottam be.

Most a háttérszínt is állítom 1 másodpercenként, de csak ott ahol az óra van, a proci 16MHz-en ketyeg, de még így is észre lehet venni a szaggatást. Még megpróbálom kisajtolni a prociból a max. órajelet, hátha úgy jobb lesz. Vagy egyszerűen nem íratom ki vele a másodperceket.
Sajnos már kész a nyák, ezért nem sok kedvem van másik procit keresgetni.

Ezt a memória dolgot, ha van kedved, kifejthetnéd bővebben. Ilyet még nem csináltam és érdekelne a mikéntje.

Még én sem, de hasonló a problémám, ha gyorsan kell a kijelzőt frissíteni főleg minden adatot akkor időbe telik és szaggat a kép. Arra gondoltam, hogy a a prociból holtidőben áttöltök egy vagy 2 képernyőnyi adatot valamilyen memóriába és majd a memóriából töltöm a képernyőbe aminek a sebessége a kijelző felé jóval nagyobb lesz mint a procié.

Sziasztok!

Próbálnék egy BMP085-ös légnyomásmérő szenzort beüzemelni, de nem jött össze a dolog eddig... ill. valahol a kommunikációnál vagy a csatlakozásnál elvérzik a dolog.

Találtam egy I2C library-t, amire korábban is kerestem már, de csak a hozzá tartozó PDF-et sikerült letöltenem a TI-től (lehet, hogy elnéztem valamit, nem tudom).
Ez korrektnek tűnik, bár nem tudom, valójában mennyire működik vagy sem.

BMP085-höz is találtam kódokat, persze más kontrollerhez.
Megpróbáltam átírni a TI-féle I2C library használatára, de valószínűleg itt is követtem el hibákat, bár az eredeti kódban is van - pl. a bmp085_read_up függvényben definiálja az lsb és xlsb változókat, de nem inicializálja, majd ezen végez bitműveletet.
...de ettől függetlenül egyéb hiba is biztosan van benne, amit én ejtettem.

Az eredeti kódot ott hagytam kommentbe téve, alatta pedig ugyanazt szándékoztam megvalósítani a TI függvényeivel.

--------------------

Az ....I2C_slave_present függvény úgy néz ki, hogy megtalálja az eszközt, legalábbis más címet megadva "0" értékkel tér vissza és ha lehúzom róla a modult akkor is, de ha rajta van, "1" a visszatérési érték.

Az olvasás ettől függetlenül sikertelen szerintem, bár elvileg végigmegy - viszont fals értékeket kapok vissza még az ac1, ac2... kalibrációs adatokra is.

Az igazsághoz hozzátartozik, hogy megpróbáltam egy ds1307-es RTC modult is működésre bírni, szintén sikertelenül. Mondjuk az 5V-os tápfeszültséget igényel, az SCL és SDA vonalat viszont 3.3V-ra húztam fel (persze a modulra tett 3.3k-s felhúzó ellenállásokat leforrasztottam előtte). Nem vagyok biztos benne, hogy ez így jó, lehet, hogy hülyeség.
Mindenesetre a címe alapján elvileg látta, de eredményt nem sikerült elérni... valójában találtam más címet is, amire azt mondta, jelen van meg olyat is, amire nem.
Mondjuk a modulon van egy EEPROM is, azzal nem foglalkoztam...

--------------------

A felhúzó ellenállások 10 kOhmosak a 3.3V-os VCC felé.
A modul megkapja ezen kívül a tápot és a GND-t is.

Gondolom, a 10k-s ellenállás nem lehet gond... vagy érdemes megpróbálni kisebbel is?

Rá tudnátok nézni a kódra, hogy mennyire hülyeség ez így vagy milyen hülyesége(ke)t csináltam?
...vagy valami tippet adni esetleg, hol lehet gond?

A "változó" átadásoknál pl. karaktertömböt adok át függvényparaméternek, amit pointerként használ a célfüggvény. Ide eredendően &xyz-ként adtam meg a paramétereket, de szimplán is ugyanezt csinálja (panaszkodott is rá a fordító).
...viszont van olyan char változó, ami így kerül átadásra.
Nem tudom, itt mennyire kevertem össze a dolgokat, elvileg a memóriacímet kellene átadni, ahol a pl. elküldendő character van.

A fordító *gcc Linux alatt, eclipse környezetben.

Tudnátok segíteni?

Elnézést a hosszú üzenetért.

Szia.

Bár csak átfutottam a kódokat, de ami elsőre feltűnt, hogy

ebben a függvényben, nem inkább azt kéne figyelni, hogy jött-e ACK? Én rendszeresen ebbe a hibába esek bele.
Mondjuk engem ez az össze-vissza inicializálás eléggé összezavart. Ha csak a BMP085 van az i2c vonalon, feleslegesnek tartom.
Indulásnál inicializálod az UCB0I2C-t, amiben kiküldöd a slave címet, és utána csak

az UCB0CTL1 regisztert kell állítgatni, a fentiek szerint. Mégazt hozzá kell tegyem, hogy nem értek a GCC-hez. Ezért nem tudom, hogy pl. ez "Wire.send(v);" mit csinál.
Szerintem ezt az agyonbonyolított TI_I2C valamit felejtsd el, bár ez csak egy magánvélemény. Egyszerűbb ha csinálsz egy sajátot.

Sziasztok valaki segitsen mert igaz hogy most tanulom de nem értem pedig már 10* átolvastam icserny irását. Szeretnék egy jelet mérni ami 20ms-os periodusban 0,1ms-os lépésben számolnék, de ezt egyszerüen nem tudom megcsinálni. Tanulok tanulok de nem haladok az irások feldolgozásával, értelmezésével. Esetleg van valakinek egy mintaprogramja valami más értékekkel??
Üdv Kovács Gábor

Nemigazán értem, hogy mit akarsz csinálni, csak sejtem. A "szervó jelet" akarod figyelni?
Arra ott a "capture" modul. Adatlap, FUG, mintaprogramok!

Ok köszönöm és igen azt szeretném (szervojel mérés és átalakitás)

Szia!



Elég sok mindent "összeolvastam" (úgyhogy már a "fene sem tudja"), de azt írták, hogy ezt hardveresen elintézi (?), ill. a NACK esetén kellene leállítani a kommunikációt.
Ez utóbbit látom, hogy benne van a rutinban.

Ha viszont a slave fogja a kommunikációt, akkor a busz nem lesz szabad, így ez a ciklus is biztosan fogja a végrehajtást...



Engem a sokféle I2C kezelés zavart össze, ezért is kerestem egy "fix library"-t - mivel nem tudtam, én csinálok hülyeséget vagy az (is), akitől a kommunikációt "lesem".
Azt mindenesetre már látom, hogy az első próbálkozásoknál miket hagytam ki, ami kellett volna, talán megér még egy nekifutást.

Mondjuk már ráment elég sok időm és elkezdtem gyanakodni arra is, hogy valami "hardveresen" sem stimmel nálam... a felhúzó ellenállásokat pl. egy kisebb próbapanelba (?) szúrtam be teljes lábhosszal, stb.

A vonalon nem csak a BMP085 lesz majd, de legalább az egyiket látnám már működni...
Egyébként igazad van, fölöslegesnek tűnik újra inicializálni az egész mindenséget, csak ha már ez volt a library-ben...

A Wire.send(v) nem tudom, mit csinál, ezt a wire függvénykönyvtárat nem ismerem, meg amúgyis Arduino-hoz volt szerintem. Amúgy elküldi a v (char) változót I2C-n.

A szükséges címet is tisztába kellett tenni - ugye az "utolsó" bit az írást/olvasást jelöli ki, de az MSP430 hardveres I2C-jének "regiszterébe" nem ezt kell írni, hanem eltolva, az utolsó bit nélkül (ő majd tudja, 1 vagy 0 kerül a végére attól függően, hogy ír vagy olvas).


Lehet, az lesz belőle (egyébként is át lenne pofozva)... csak sokkal jobb volna, ha látnám, hol van a gond (pl. azt, hogy tényleg a library-vel /is/ van vagy valami mással)...

Mindenesetre az I2C kommunikáció nem lopta be magát a szívembe.

Nekem "belopta". Szerintem az MSP430G sorozatnál, egyszerű, könnyen kezelhető, és jó. Pláne ha érti az ember.

Akkor sem kell mindent újrainicializálni, csak a slave címet kell megváltoztatni.

Nem ez a lényeg, hanem az, hogy a "master" kapjon ACK-t.
BMP085 adatlap, írás menete:
" slave cím + W -> ACK -> reg cím -> ACK -> control cím -> ACK -> STOP "
Tehát, miután kiküldöd a slave címet, (más néven elindítod az írást) meg kell várni az ACK érkezését!
A fogadásnál ugyanez van, csak itt be kell iktatni az újra startot, ahol "slace cím + R" lesz, ezt megcsinálja hardveresen, nem kell vele foglalkozni!, és a végén kell küldeni egy NACK-ot, amit az elején állítasz be.

Bedobok még egy programot i2c-re. Bár már lehet régebben beraktam. Ebben egy gyorsulásmérőt írok olvasok i2c-n. Nézd meg benne a NACK-ot, és az írást. Az olvasás megszakításban van.

Ha valamit rosszul írtam, elnézést kérek érte. Én sem vagyok profi ebben.

Ez így van... de azért el kell jutni ide.


Ez igaz, csak az "első próbálkozásnál" nem akartam bántani a TI-s kódot.



Igen, ezt néztem.
Ebből az első kettőt intézi hardveresen, amikor írásra állítom.
Ezutám elküldöm a regiszter cimet, majd olvasás esetén indíthatom a kommunikációt.

Arról olvastam, hogy az újrastartot megcsinálja hardveresen az UCTXSTT határára.
A következőt viszont nem értem a TI fogadás függvényében:


UCB0CTL1 |= UCTXSTT; // I2C start condition
while (UCB0CTL1 & UCTXSTT); // Start condition sent?
UCB0CTL1 |= UCTXSTP;


Ez akkor van, ha a byteCount 1.
Biztos megvan az oka, mert 1 fölött kettőt von, de valójában nem értem ezt a dolgot... mondjuk konkrétan a küldést/fogadást interruptból csinálja, de valahogy azért fura.
Ill. azért csak tudni kéne azt is, mikor végez.

Ok, elfelejtem.

A fentit csak azért írtam, mert a megcímzem --> regisztert írok --> olvasok (közben ott vannak az ACK-ok persze) sorba ez a plusz STOP/START lehet, hogy bezavar.



No ezt majd meg kellene néznem, hogyan is.



Köszönöm.
Ha jól nézem, a while (!(IFG2 & UCNACKIFG));-val nézed az ACK-okat vagyis azt, hogy az IFG2-nek az UCNACKIFG bitje "1"-e (ekkor megy tovább, vagyis válik nullává a while-ban lévő kifejezés).
Eszerint ez ACK és NACK esetén is "1"? - vagy csak a név miatt megtévesztő?



Tehát az elején beállítom a NACK-ot és amikor a STOP-ot kiadom, elküldi?
...vagyis enélkül a végén nincs NACK?

Úgy néztem, ez a BMP085-nek és a ds1307-nek is kellene - valójában nagyon hasonlóan kell velük "beszélni". - Talán épp' az I2C miatt?
...vagy konkrétan ez a viselkedés nem annyira általános...

Szerintem holnap estefelé nekifutok újra az írás-olvasás megírásának, most már azért tisztább a kép...

Igen. Pl.egy i2c-s soros eeprommal is hasonlóan kell "beszélgetni"

Nem ! A "while (!(" ciklus, ha megfigyeled, tagadás "!" !



Pedig egyszerű, mint az egyszer egy(=2 vagy 3).

Kb. ennyi. Az READ többi része meg mehet megszakításba, mivel az inicializálásnál bekapcsoltuk, de a megszakításvégén törölni kell a flag-et:IFG2 &= ~UCB0RXIFG;

Ez afféle humor akart lenni, de azt tényleg nem tudom, van-e olyan (egyszerűbb) eszköz, ami nem a NACK-ra vált vételbe, hanem mondjuk bizonyos számú vett byte-ot követően.



Lehet, hogy a késői időpont teszi...

Tehát ha while belső értéke 0, kilép... amíg 1, bent marad.

A belső érték (IFG2 & UCNACKIFG) tagadása.
Vagyis ha a feltétel hamis, akkor a while belső értéke igaz lesz.
Emiatt while akkor lép ki, ha a fenti kiértékelése igaz, vagyis "1".

Rossz az okfejtésem? - ezért kérdeztem a fentit.
...vagyis miért a NACK "1" az ACK esetén. - persze tényleg késő van.


Arra gondoltam, hogy emiatt hiúsulna meg a kommunikáció... de lesz itt más is, majd át kell nézni.

Ami azt illeti, nem tudtam nyugodni és közben összeollóztam a fent csatolt main.c kódod alapján pár függvényt, lent csatoltam.
Benne van a több byte-os írás/olvasás.

Ennek használatára nem volt nehéz átírni a BMP-s "függvényeimet" - amit az Arduinos vagy milyen környezethez írt valaki - és látszólag működik.

Hőmérsékletre 251-et kapok, ami stimmelhet, mert az elvileg 25.1 fokot jelent.
Nyomás jelenleg -31799, ami nyilván nem jó, de a dekódolásban van egy hiba, amit fent is írtam, ezért random bitek kerülnek a gépezetbe

Ha ráteszem az ujjam, a hőmérséklet emelkedik, ha leveszem, csökken...
...vagyis az I2C kommunikáció működik.

Majd kicsit pihentebb állapotban át kell írni, a TI-s példában azért van néhány ötlet.
Mármint a TX is mehet szerintem ISR-be és tetszett ez a jelen van-e lekérdezés.

--------

Megnéztem, a nyomás számításánál a "|=" "=" csere nem sokat változtatott - majd összenézem még másik kóddal, valahol 1000 körül kellene lennie...
Mondjuk a jelenlegi értékkel számolva 32768-31855=913 lenne, az még akár hihető is.
Bár ez gondolom, csak véletlen.

Köszönöm a kitartásod, most már tudok vele "beszélgetni".

...de hogy ezen hozzászólást miért írtam több mint fél órán át...
Tényleg megyek aludni...

Köszönöm még egyszer a segítséged.

Van, pl.: PCF8574 I/O expander.

A lényeg az, hogy már legalább valamit mutat. A többi meg adja magát.

Én még dolgozom egy kicsit (7-ig), és utána megyek aludni.

Köszi az infókat!
Egyenlőre maradnék a vezetékes megoldásnál, de későbbiekben upgrade-re ha sor kerül, akkor szerintem valami ilyesmi lenne célszerű. Zigbee-ről olvastam, eddig jónak tűnik.
Pár dolgot azért még kérdeznék előre vetítve:
A vezérlés az hogyan is néz ki?
Valahogy a kitüntetett szerepű egységen (a koordinátoron) kell futtatni a programom?
Azzal hogyan tudok kommunikálni PC-ről?
Hogyan lehet programozni?

Jó, hogy mondod - ilyet rendeltem párat, lassan meg kell érkezniük.
Mondjuk nem néztem utána, de talán ez sem sértődik meg, ha kap egy NACK-et - max. ignorálja gondolom.



No igen, innen már könnyebb.

A szenzorral még "nem volt időm" foglalkozni, de ez a while (!(IFG2 & UCNACKIFG)); nem hagyott nyugodni és a következőre jutottam:

Az UCNACKIFG az UCBxSTAT, ill. USCI_Bx regiszterhez tartozik, ennek a harmadik bitje (Familty User's Guide 482. oldal).
"Not-acknowledge" interrupt flag, start kondíciónál automatikusan törlődik.

Ez rendben, de hogy lesz belőle ACK flag?

Szintén ugyanez az olvasmány (Family User's Guide, de 459. oldal), IFG2 regiszterei, ennek is a harmadik bitje: UCB0TXIFG.
"USCI_B0 transmit interrupt flag"
USB0TXIFG akkor van beállítva ("1"), amikor UCB0TXBUF üres.

Valójában a fenti while (!(IFG2 & UCNACKIFG)); pontosan ezt a feltételt vizsgálja.
(Vagyis azt, hogy a TXBUF tartalmát "elvitték-e".)

Tehát a feltételvizsgálat "helyesen" így hangzik: while (!(IFG2 & UCB0TXIFG));

Magyarázat:

Valójában az UCNACKIFG és a UCB0TXIFG "bit" (jelen esetben legalábbis) azonos sorszámú bitet jelöl ki.
Ez pedig a harmadik bit, így ha jól számolom, mindegyik esetén 0x04-et helyettesít a fordítás során.

Így esik, hogy mindkét elnevezés használata esetén a program ugyanazt csinálja, a fent használt elnevezés mégis elvben hibás.
Nem tudom, lesz-e olyan eset bármikor is, amikor e két elnevezés nem ugyanazt az értéket takarja, de éppen előfordulhat (nem itt, hanem újabb vezérlőknél).

-----------------

Elnézést a fenti tartalom miatt - nem kioktatás akar lenni, csupán korrekció "némi" indoklással karöltve, miért is gondolom így.

Az ellentmondások feloldása segíthet a folyamat jobb megértésében, így végül korrektebb kód előállításában.

...és persze végül a TI-s I2C kód is megteszi a hatását (segítségét) ha lesz kis időm rá - bár most nincs előttem, a fenti TX flag-et szerintem használhatta, ill. volt benne egy ISR részlet a NACK kezelésére, ezt majd a saját rutinban is el kell végezni - jobban értve a folyamatot már ez is lehetséges.

Köszi, akkor áttérek privátra!

Én egy ilyen modulpárral szeretnék majd kísérletezni - persze csak miután megérkezett...

Kíváncsi leszek rá, mit lehet kihozni belőle - mindenesetre nem volt drága... eddig.

Kicsit utánaolvastam a nyomás kiszámításának, de végül valójában a debug segített...
...kiíratásnál vesztettem el a legfelső bitet, csak 16-bitnyi adatot írtam a kijelzőre sima integerként.

Mostmár ki tudom jelezni a ~100000 nagyságrendű, korrekt értéket.
Kicsit igazítani kell még a BMP085 kódon és közreadom.
Ill. az RTC kódját is meg kell írni, de ezeket kicsit később majd.

Tehát mind a hőmérséklet, mind a nyomás értékem kb. korrektnek tűnik.

Szia!

Linkelt eszköz hatótávolságáról tudsz valamit? Egész jó áron van.

A panelre rajzolt antennától ne várj csodákat!

Itt 1000métert ír, de szerintem meglehetősen dúrván kerekített felfelé. Ha 100 métert tudna még azt mondanám megéri.