Üdv !

Valaki használt már MAX132 nevezetű AD konvertert?

Az a gondom vele, hogy gyanúsak a kiolvasott értékek és az adatlapjában sem viszik túlzásba a kiolvasás taglalását.

Ahogy én csinálom:

Elindítom a konverziót (Read zero módban)
Várok, hogy EOC 1 legyen.
Elindítom a konverziót (Read Vin módban)
Kiolvasom a status register-t
Kiolvasom Msb-t
Kiolvasom Lsb-t

Ez olyan értékeket hoz, amik nagyobbak mint amit a konverter mérhetne.

Valamit magyaráz az adatlap a Read zero által kiolvasott értékkel kell talán elosztani a Read vin értéket, de ez mindíg 0-nál kisebb szám nekem.

Ha valaki tudna segíteni annak nagyon örülnék.

Üdv!
Az adatlapban én nem találtam semmi olyasmit, ami arra utal, hogy bonyolult lenne kiolvasni. (halkan megjegyzem, nem a legnagyobb alapossággal néztem még át az adatlapot).
Bár a problémád nem teljesen világos.
Elsősorban erre gondolok:
A konverter felbontása ugyebár 18 bit. Ennél nagyobb értéket csak úgy kaphatsz, ha 18-nál több bitet olvasol ki.
Mivel használod? PIC-el?
Ha azzal, és a hardweres SPI-t használod, akkor a következő lehet a hiba:
A 18 bit ugyebár 3 bájtra osztható fel.
Az első két bájtot (16 bit) még fogadja rendesen, a maradék 2 viszont hibás lehet. Ennek 2 oka lehet:
- az SPI bufferben nem a 2 alsó bitet foglalja el, hanem a felső kettőt;
-vagy pedig összefolyik a következő olvasási ciklus első 6 bitjével.

Ezen kívül ami nem világos:
2 pozitív szám hányadosa nem lehet 0-nál kisebb, vagyis negatív szám. Ez program hibára utal.

Amit én javasolnék: Szoftveresen kellene egy SPI rutint írni, ami 18 bitet olvas be.

A P0..P3 lábak gondolom párhuzamos portként szolgálnak, ha ezt használod, akkor is az lehet a hiba, hogy 16 bitet jól olvas be, a maradék 2 viszont rossz helyre kerül.

Üdv !

Az SPI-t már kínomban szoftveresen próbálgatom, úgy ahogyan az adatlap végén van. Az szerintem jó, mert a 4 db programozható I/O lábat hibátlanul tudom vele kapcsolgatni.

A readZero részt még tegnap átolvastam és rájöttem, hogy az osztáshoz semmi köze, inkább kivonás, amit ha jól értelmezem a konverter el is végez. Tehát nekem nem kellene babrálni az eredménnyel.
A bitek azért zavarnak mert elvileg 18bitesnek hívják a konvertert, de a kiolvasható érték az 0-18 bitig van tehát ez szerintem 19 bit. Ráadásul még az sem lehet hogy előjel bit lenne, mert az külön megtalálható az Output status regiszterben.

Talán a 19.bit valami túlcsordulás jelzés lehet?

Elvileg helyes beállítások és feszültségek esetén a kiolvasható érték 262144 dec lehet.
Ez is zavar, mert ha a Vref lábakra ráadok 440mV-ot ill. a mérólábakra is ugyanennyit adok, akkor lenne teljes kitérésben nem ?
Hiába tud 512mV-ig mérni, ha én adok neki egy ref feszt akkor kutya kötelessége lenne a konverternek a 440mV-omat felbontani 18 bitre.

Hát nem értem, pedig azért választottam ezt a konvertert, mert a tc7109 évek óta hibátlan, de annak párhuzamos portja van és nekem az spi jobban jött ennél az alkalmazásnál. Ráadásul ez a konverter 3 szor annyiba kerül mint a tc7109.

Ha valakinek van ötlete akkor azt szívesen venném, ha megosztaná velem.

Üdv!

Azért 19-bites, mert valóban tartalmazza az előjel információt, az adatokat 2-es komplemens formátumban adja vissza.
Vagyis ha negatív feszültséget mérsz vele
(INLO > INHI), és az eredményt pozitív számként próbálod értelmezni akkor elég érdekes eredményeket kaphatsz.

Ha 16-bites felbontással megelégedsz, akkor elég az OutputRegister1 és az OutputRegister0 registereket kiolvasni, ez így egyszerűen feldolgozható:

OutputReg1 OutputReg0
[B18....B11] [B10...B3]

Ha az összes bitre szükséged van ahogy le is írtad, a StatusRegistert is ki kell olvasni:

OutputReg1 OutputReg0 OutputStatusReg
[B18...B11] [B10...B3] [x,x,x,x,x,B2,B1,B0]

Ahhoz hogy ez értelmes legyen a két felső bájtot jobbra kell shiftelni, és az előjellel balról feltölteni, hogy 2-es komplemens egész számként feldolgozható legyen, így a három byte:

[B18, B18, B18, B18, B18, B18, B17, B16]
[B15, B14, B13, B12, B11, B10, B9, B8]
[B7, B6, B5, B4, B3, B2, B1, B0]

Leírásod alapján talán ez lehet a gond, feltételezve hogy a hardverrel nincs probléma.

Én így csinálom, kivéve, hogy a b18 as bit csak egyszer van, tehát nem töltöm fel vele a maradék felső biteket.
De gondolom ennek csak negatív tartományban van szerepe.

Viszont, az adatlap azt írja, hogy a zeroConvertet kétszer-háromszor ajánlott megcsinálni mérés előtt.
Most, hogy csak egy mérés előtt egy zeroConvert van így már egész jó eredményeket kapok.

Igy van, pozitív feszültség esetén, ha nincs túlcsordulás akkor B18=0.

A collision bit az néha 1 az baj?

Sőt az Integrating bit is néha 1.

Tehát Megvárom amíg az EOC az egy lesz. Elvileg ilyenkor kell kiolvasni az adatot.

De a status regiszterben vagy az integrating vagy a collision bit 1 -el jön vissza.
Egyszerre mindíg csak az egyik lesz magas, vagy ez, vagy az.

Ez szerintem úgy lenne jó, hogy az EOC az 1 az Integrating az 0 és a collision is 0. nem?

Igen. Az Integrate bit az integrálási fázis alatt 1.
A Collision bit azt jelenti, hogy a register adatok változtak a kiolvasás alatt.

Nem lehet hogy túl hamar olvasod ki az adatokat?

Nézd meg az adatlap 12. oldalán a Collision bitre vonatkozó részt. Ha gondod van az angol nyelvvel, lefordítom neked.

A 16. oldalon van egy folyamatábra. Aszerint megy az algoritmusod?

Még egy dolog:
Amikor olvasni akarsz a Command regiszterbe íráskor a D7 bit == 0? Mert ha az magas szintű, akkor újabb konverzió indul, és az Integrate bit akkor áll 1-be.

Igen a 16. oldal szerint csináltam az spi-t.

Elvileg az EOC megjön egyból olvasok, nem várok semmire.

A 10. ábra szerint (11.o.) az EOC és az INTEGRATING jel nem is lehetne egy időben magas.

Igen, a D7-re figyeltem.

Pedig úgy tűnik hogy kiolvasás alatt már a következő konverzió megy. Ez egyébként nem baj, integrálás alatt lehet olvasni.
A Collision bit bebillenése esetén pedig szerintem csak meg kell ismételni a teljes beolvasást.

Talán valami időzítési probléma az SPI kommunikációban? SCLK, /CS stb.

Ha egyik sem, akkor lehet az áramkörben is probléma. Ilyen kicsi jelszintek esetén akár 50mV-os zaj a bemeneteken, a feszültségreferencián vagy a tápon, eredményezhet hibás mérést.

Üdv !

Valószínüleg a TCP stack kavart valamit, mert írtam egy csak a max 132-t kezelő programot, és itt már gond nélkül megy a hw spi is és tökéletesek az eredmények.

Köszönöm a segítséget.

Zaj nem lehet számottevő, mert Ratiometrikus a mérés.

Egyébként így hogy működik már nagyon jó tapasztalataim vannak ezzel a konverterrel. Csak az alsó 1-2 bit billeg, ami hőmérséklet mérésnél is igen elhanyagolható.

Gratula
Az a pár mikroV már tényleg nem számít.