Szerintem belső felépítési hiba lehet hardver szinten.

Néztem az errata-t, de ott nem ír ilyesmiről. Számomra az az érdekes, hogy csak a belső felhúzással működik jól. De lehet, hogy én kötöttem el valamit.

Sziasztok!
A PWM szabályozást valaki kicsit magyarázná nekem? A cikksorozatban a 2. rész 8. oldalon van a 8_1. ábra. Elolvastam pár cikket a ventikre vonatkozóan is. Ha jól értem, az egy periódus alatti kitöltés arányát határozzuk meg így, vagyis meddig kapjon áramot a LED, ill. meddig nem. 1 MHz-nek 1 millió periódusa (négyszögjele) van. Ezeknek 1/1000000s = 0,000001s a periódusideje. Ez a max. elvégezhető műveletek száma, felfutó éllel vezérelve. Eddig jól mondom?
Na most, azt nem értem, hogy lentebb a szoftveres PWM-nél, ha 15000 ciklus van, akkor egy ciklus ideje az nem 1s/15000 ciklus = 0,00006667s lesz? Akkor pedig hogy jön az ki hogy egy óraleütés 0,0001s, ami 100 ciklussal egyenlő? Mit gondolok rosszul?

Ha 150 óraütés van, az azt jelenti hogy a többire nem is végzek műveletet, mert kimaradnak, nem?
Egyáltalán, hogyan jöttek ezek ki? Kérlek segítsetek, nagyon belegabalyodtam...

Szaiasztok probálkozok valami mipulzus mérés egyszerüsitéssel, ez igy megy esetleg
Ez csak a lényeg ami mérné az impulst, illetve ha igen akkor hogyan adok meg változot amit tovább tudok használni?
Üdv Kovács

"ha 15000 ciklus van, akkor egy ciklus ideje az nem 1s/15000 ciklus = 0,00006667s lesz?"
1 Mhz-en fut az órajel ami 1 uS ezt szorzod fel 150ezerrel és így kapod meg egy periódusidejét ami 15 mS. A lednek 1,5-s-es félperiódust választ (tehát amíg növekszik a fényerő vagy csökken) 15mS-nél ez pont 100 lépés. A 8_1-es ábrán a periodus=256 helyett írj 15ezret és érteni fogod.

Köszi!
Így már azt hiszem értem, de azért kérek egy megerősítést: ezek szerint megmarad az eredeti skálázás/felbontás, tehát 1 millió négyszögjel, és ezt az 1 milliót felosztjuk 15-ezrével, ez lesz 1 periódus, ami 0,015 s-ig tart (így marad az 1uS/négyszögjel). Ez alapján 1s alatt 66,67 periódus lesz így, ami 0,015 s x 66,67 = 1s. Akkor ha egy periódus 1 lépés, 100 lépés = 100 x 0,015s = 1,5s. Engem az zavart meg, hogy a LED-nél is periódusról beszélünk, de az egy másik, a sajátja, ami 200 lépésből áll, 100 lépésig növekszik a fényerő, majd 100 lépésig csökken, a teljes periódus 3s-ig tart. Ez a lépés pedig = az elsőnek megnevezett 15000 órajelből/ciklusból álló periódussal.
A másik ami megkavart, hogy a 15000 ciklus a be-és kikapcsolt állapot összideje. Na igen, de csak periódusonként (0,015s) nézve, ezt értelmeztem félre.
Jól gondolom?

Jól.
Icserny cikkjei álltalában tömörek és lényeget ragadják ki, de hátrány hogy a sorok között néha többet kell gondolkodni.

Ezt úgy kell felfogni, mint programírásnál a két (vagy több) egymásba ágyazott "for" ciklus esetét. A PWM jeleknek is van periódusideje, s abban a példában a kitöltést is periodikusan változtatjuk, ezért annak is van egy ismétlődési ideje (azaz periódusideje).

Remek, akkor minden tiszta! Köszi!
Igen néha kicsit tömör, de ez csak olyanokat zavar meg, aki ebben a témában még kezdő. mint én. De komolyan, a cikkek nagyon jók, angol leírásokból szinte nem értettem semmit, a projektből sem lett volna semmi ha nem találok ide véletlenül.

Köszi a magyarázatot! Most már értem.

Sziasztok!

Próbálkozom az I2C kommunikációval, de van valami, amit nem értek (430g2553 vezérlőkkel nézem).

Pl. az msp430g2xx3_uscib0_i2c_04 (és párja) mintaprogram segítségével a kommunikáció tökéletesen működik egészen addig, amíg meg nem szakítom valahogy az átvitelt.

Ekkor ugyanis a master mélyálomba kerül és többet nem fogad adatot, amíg resetet nem nyomok neki, hiába lett újra üzemképes a slave eszköz.

Lehet ezzel valamit kezdeni?
...vagy ilyenkor teljesen újra kellene inicializálni az I2C buszt (és mondjuk timerrel csinálni egy timeout-ot / bevetni a watchdog-ot)?

Mi ennek a normális menete?

Tehát minek kellene történnie, ha a slave-vel megszűnik a kapcsolat, majd helyreáll?

Ez már a dolog alkalmazásfüggő részéhez tartozik, amire nem lehet általános receptet adni. Mindenesetre az I2C kapcsolat elakadásának detektáláshoz a watchdog timert célszerű élesíteni a CPU altatása előtt, ami felébreszti a CPU-t ha a slave nem válaszol záros határidőn belül. A masternek minimálisan alaphelyzetbe kell helyezni a buszt (STOP), de hogy a kapcsolatot honnan lehet értelmesen folytatni, az a konkét alkalmazás függvénye.

Köszönöm a válaszod.

Tehát az I2C szempontjából egy STOP állapot küldése jelentene megoldást, ha jól értem.
Nyilván a hibát le kell kezelni, ill. az I2C elakadása esetén is bizonyos funkciókat még használni szeretnék.

Azt mondjuk nem értem, miért áll le a master órajele.
Tehát elég hozzá egy rádiófrekvenciás zavar - akár az asztali lámpa kapcsolgatása és a kommunikáció megáll úgy, hogy az I2C órajele is megszűnik - és ez az, amit furcsállok.

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

Próbálkoztam kicsit.

Felhúztam egy timert az I2C vétel indítása előtt - ha x másodpercig nem történik semmi, akkor beavatkozik.

Helyesebben csak felkelti az MCU-t - aki még mindig LPM0-ban van és várna I2C (USCI_B0) interruptra, amit SCL órajel nélkül hiába is tesz... ugye az órajelet neki kellene adnia.

Ezután a vétel helyreáll, tehát újra érkeznek adatok a slave-től.

Nyilván hibakezelés kell hozzá.
Azért még mindig nem értem, egy zavar miatt miért áll le az I2C órajele is...

"Játszottam" még egy kicsit a dologgal.

A lámpa kapcsolgatása így is meg tudta állítani a számlálót (de a másik kontroller kihúzása nem - mármint visszakapcsolva ment minden).
Ellenben, ha ilyenkor újrainicializálom a kommunikációt, akkor a kapcsolgatás keltette zavarokon is túlteszi magát - folytatja a számlálást gond nélkül.

Így már kezd tetszeni a dolog, legalábbis jobb mint előtte.
Már csak kéne belőle egy library-t faragni.

...vagy csak én nem találtam még olyat, ami a hardveres I2C modult használja és egyszerűen kezelhető?

Mondjuk a fórumtéma közepéből még 34 oldal vissza van.

Én igazából nem egészen értem ezt a problémát. Már elég sokat játszadoztam a HW I2C-vel, jelenleg is van egy pár futó programom ami i2c-t használ, de ilyen hibát, adatvesztést, leállást, még nem tapasztaltam (kop-kop-kop). Igaz én nem is használom folyamatosan az i2c vonalat, de kipróbáltam, hogy egy 24lc512-t teljesen teletöltöttem adattal, közben kapcsolgattam a villanyt, próbáltam zavart kelteni, de nem állt le a kommunikáció. Minden adat (0x01) a helyére került. Közben a szkóp az SCL vonalon volt, de semmi zavart nem láttam rajta.

Ha visszalapozol, nemrég raktam fel az rs5c372a i2c driverét. Nézd meg hátha tudod használni, bár nem megszakításból kezelem, de nem nehéz átírni.

Köszönöm, ezt is át fogom nézni.



Nem kizárt, hogy az én problémám innen ered.
Ugyanis alapvetően a megszakítás nem fut le ilyenkor, úgy látom. Tehát innen kell "kirángatni", ha elakasztja magát.

Egyébként csak elindítottam az egyik eszközt küldésre, másikat pedig fogadásra, majd megpróbáltam elérni, hogy ne működjön... mivel sikerült, így azon kezdtem törni magam, hogy ne sikerüljön.

A kommunikációs vezeték "elvágásával" rögtön meg is állt... az asztali halogén/LED-lámpás tesztem csak ráadás volt - ez tudtam, hogy generál zajt, mivel a bekapcsolt hangfal elektronikája is összeszedi.
(A LED-eset kapcsolgattam, ezt egy normál halogénes lámpából alakítottam át, tehát a ~50VA-es transzformátor benne van...)

Az ilyen hibák kikerülése, egy jól megtervezett hardver. /szerintem/

Bár nem vagyok mestere a témának (i2c), csak kezdő szinten vagyok, de szerintem nem minden esetben jó megszakításból kezelni a kommunikációt. Pl. az említett RTC drivert is át lehetne rakni megszakításba, de nem sok értelmét látom. Egy másodpercenként elindítom a kommunikációt, és pár mS után le is áll, mert kiolvasta az adatot. Bár lehet, hogy rosszul gondolom.

Amin most dolgozom, abban szintén használok I2C-t plusz SPI-t és még UART-ot is, és az eszközök mellett kapcsolgatok egy relét, ami azért tud zavart kelteni, de az eddigi tesztek elég jól sikerültek.

Valójában két projekten töröm a fejem, most az ezekhez szükséges dolgokat szedem össze, ill. próbálom ki.

Az egyik esetén 1-2 mA plusz áramfogyasztás nem számít, másiknál pedig igyekszem majd a fogyasztást a lehető legkisebbre venni (bár lehet, túl sokat itt sem számít, de valamit csak-csak). Mondjuk az I2C kommunikáció valóban csak az idő töredéke, de azért a stabilitásra szükségem van és nem baj, ha zavarteli környezetben sem esik hanyatt.

Egyébként a hasonló hibák felderítése (produkálása/tesztelése), ami több időt vehet el az úgy-ahogy működő első változat megvalósításánál is...

HIBAIGAZÍTÁS:

Hibát találtam a mintaprogramjaimban használt számkiírató eljárás működésében: Ha a kiírandó érték a 10-zel történő osztásoknál "elfogy", mielőtt a tizedespontot kiírnánk, akkor a tizedes pont nem kerül kiírásra, s így hamis lesz a kiírt érték. Például 0.075V helyett 75V eredményt kapunk!

Javítás: A hiba orvoslására figyelnünk kell azt is, hogy legalább annyi számjegyet mindenképp írassunk ki, mint ahány tizedesjegyet ki akartunk íratni.

Példa: Az alábbi példában legalább egy számjegyet kiíratunk a tizedespont előtt, tehát az értéktelen nulla egész is kiírásra kerül (pl. .735 helyett 0.735).

További módosítási lehetőség: A sign='+'; utasításban a pluszjel helyett szóközt is írhatunk a fölösleges előjel kiíratásának elkerülésére.

Sziasztok.
Beállítom az analóg referencia feszt 2.5V-ra, pl. az A0-ra. Hogyan tudnám a mérés előtt megmérni a referencia feszt?

Mihez képest akarod mérni a referenciát?

GND. Mihez képest van a 2.5V ref? Azt elfelejtettem írni, hogy a belső referencia feszültségről lenne szó. Ha jól tudom alapba, a GND-hez képest van a ref fesz.

Azt sejtettem, hogy a belső referenciát akarod mérni, de milyen referencia feszültséghez viszonyítva akarod megmérni? A tápfeszhez lehet, bár sok értelme nincsen. Vagy lehet egy külső referenciához hasonlítani, de akkor miért nem használod azt?

Azt hiszem, hogy a belső referenci értékét csak úgy tudod ellenőrizni, hogy a belső referenciához képest mérsz egy ismert feszültséget (például az egyik csatornában a tápfesz felét, vagy egy analóg bemeneten egy külső referenciát), s abból számolod vissza fordított aránypárral, hogy mennyi is lehet a referencia tényleges értéke a névlegeshez képest. Ha a belső referencia tényleges értéke nagyobb a névlegesnél, akkor a mért érték kisebb lesz annál, mint amennyinek az ismert feszültség és a névleges
referencia alapján lennie kellene.

Bocsi lehet, sőt biztos, hogy rosszul fogalmaztam. (tegnap dolgoztam, és a műszak 24 órás)
Tehát, hőmérsékletet szeretnék mérni, (TC1047A szenzor) ehhez bőven elég a 2.5V belső ref fesz. Méréseim szerint (szkóp) nem olyan stabil a ref.fesz, mint ahogy azt az adatlap írja. Mértem 2.43-2.57V között mindent. Ezért arra gondoltam, hogy a hőfok pontos kiszámolásához mindig az "aktuális" ref. feszt. kellene használni. Ezért kellene megmérni, a szenzor beolvasása előtt. De ezek szerint halott ötlet.

Nem lehet, hogy felszedtél valami brummot? Azon segít, ha hosszabb ideig csinálsz méréseket és kiátlagolod.

Még az is lehet, mert itt a dugipanelon már elég nagy a káosz.

Ha szkóppal mérsz, számolnod kell a leolvasás pontatlanságával, még kurzoros mérés esetén is. Ha jól láthatóan ingadozik a ref. fesz. akkor érdemes esetleg trükközni, de ha csak az ismételhetőség gyenge az nem feltétlen a forrás hibája.
Ezen felül, (legalábbis szerintem) mivel az A/D konverter a referenciája maga a referencia feszültség, ezért nem tudod megmérni vele a belső referenciát (önmagát). Róka fogta csuka, hehehe.
Ha meg külső referenciához viszonyítod, akkor is ott van, hogy a külső is elmászhat, dönteni kellene, melyiknek hiszel jobban. De ha a külsőben jobban megbízol, akkor kösd be azt külső referenciának, akkor méregetni sem kell, automatikusan az lesz az alap.

Szoval egy TL431 elo tud allitani 25-30 ppm-es Vref-et. Egy 3k3 ellenallas alul, es egy 500 ohm poti felul. Ezzel lehet csinalni egy 2,56 volt Vref-et. Ez 10 bites AD felbontasnal pontosan 1/4 C felbontast eredmenyez. Elony a homerseklet szamitasnal, mert nem kell float szamokkal buveszkedni, eleg a 16 bites int muvelet a homerseklet szamitashoz. En csinaltam hasonlokat (mas uC, de 10 bites) es atomstabil merest eredmenyez. Fontos a TL431 szurese (10 uf + 100 nF). A masik fontos, hogy a TC1047A (LM35, MCP9700) nem szereti a kapacitiv terhelest, ezert az IC kimeneten sorosan kell alkalmazni egy 1k ellenallast, es a uC bemeneteree szinten 470 ohm -> 1k soros ellenallas, + 100 nF a GND-re. Plusz a szenzor taplabaira szinten 100 nF hidegites. De kozvetlen a labra!!

Köszönöm a kimerítő választ mindkettőtöknek.

A külső ref. feszt, jelen esetben hanyagolnám, mert a használt mikrovezérlő összes ki-bemenetét felhasználtam már.

Megmértem újra a ref. feszt, ahogy Icserny javasolta, szkóppal, plusz 3 multival, és valóban csak valami zavart mérhettem bele. A mérés alapján csak akkor mászott el kb. +-0.01V-ot, ha épp mért az ADC, amúgy stabil. (mint az adósság)