Fórum témák
» Több friss téma |
Sziasztok!
Nem pont ide való de segítséget kérnék: lenne itt valaki aki feltudna nekem programozni egy 18F4550-et szerdán Pesten? Van ebayes K150-es programozóm de nem tudja megírni sajna... Köszönöm! Laci
Nem voltam egyértelmű. Úgy gondoltam (igaz, én nem szeretem a multiplexelést), hogy minden egyes kijelzőnek jut egy regiszter és egy UDN2981. Nem is 12 szegmensre, hanem 12 kijelzőre gondoltam, nekem soknak tűnik multiplex vezérléshez.
Az ULN tranzisztormező közös anódos kijelzőhöz jó (nyitott kollektoros), az UDN pedig közös katódos kijelzőhöz (nyitott emitteres). Tranzisztormező mindkettő, a belső felépítésüket hasonlítsd össze, látni fogod a különbséget. Egyszerűen leírva: A ULN a testre húz le, az UDN pedig tápfeszültséget ad ki.
Vannak erre kitalált IC-k, mint pl. a MAX7219. Gyakorlatilag ugyanúgy felfűzhető, és SPI-vel betölthető, mint a 74HC595, emellett beépített áramkorlátozással és programozható fényerősséggel vezérel, s egy IC max. 8 számjegy x 8 szegmens vezérlésre (7 szegmens + DP) alkalmas. Kívánságra a számjegyeket dekódolja is.
A MAX7219 nagyon jó kis IC, de engem kicsit zavart, hogy semmiféle reset funkciót nem raktak bele. Szóval ha induláskor valami táp-gebasztól bekattan, akkor még az esély sincs rá, hogy újraindítsuk.
Senki sem akadályoz meg abban, hogy a tápfeszültségét le-fel kapcsold egy FET-tel vagy egy engedélyező bemenettel rendelkező tápegységgel, power manager IC-vel.
Igen, vannak külső reset áramkörök, csak én hiányoltam az IC-ből, ha már ennyi mindent tud. De félreértés ne essék, én is csak ajánlani tudom ezt az IC-t, akár LED mátrixot is jól lehet vele hajtani.
Szia!
Most épp nincs időm végig nézni a kódodat, amúgy sem vagyok C guru. De kb fél éve én is kísérleteztem ezzel az UH modullal. nekem 400cm ig simán mért bár nem túl pontosan. Mikropascal környezetben csináltam, ha az neked segít itt a kód. Ne zavarjon meg, hogy 3db unitra osztottam az átláthatóság kedvéért. Fő Unit :
MyUnit_meres:
MyUnit_LCD :
Köszönöm szépen a kódot. Micropascalba nem vagyok ott, DE!! A regiszterek értékei, a változók szépen értelmezhetők, mint ahogy a program logikája is, csak át kell tüzetesen néznem. Viszont azt had kérdezzem meg, ez is 16f887-re lett írva?
Nem! A fő Unit elején a kommentben benne van, hogy 16F690 re van írva. Ennek a számlálóját tudom külső (PortA.4 )lábról hardveresen indítani és leállítani. Így magához a számlálóhoz nem kellett megszakítást használnom.
A számláló tulcsordulást jelző Flag -et viszont a hibás , méréshatáron kívüli mérés detektálására használtam. Amit viszont tapasztaltam, szintén benne van a kód kommentjében, hogy a mérés indítása után nem rögtön húzza fel az UH modul a trig lábat hanem késik elég sokat. ezért van benne a 100ms késleltetés a mérés kiértékelése előtt. Amúgy sincs szükség olyan sűrű mérésre.. A hozzászólás módosítva: Márc 22, 2016
Oh, ne haragudj. Hogy lehetek ilyen láma?! Elvesztem a sűrűjében... Akkor így viszont az én PIC-em nem tudja ezt a külső timer indítást. De az elvek nálad is hasonlók. A timer indítását nálad hardveresen, nálam szoftveresen a megszakítás szubrutinból kell indítani amikor az "external interrupt" láb aktív, majd leállítani, amint az "echo" jel logikai nullára vált, majd kiolvasni a timer értékét, és kiszámolni a távolságot. Remélem így már a segítséggel sikerülni fog. Köszönöm a segítséget.
A hozzászólás módosítva: Márc 22, 2016
De igen. Az adatlapján azt látom, hogy nálad az RB.5 ös lábon van a T1G ! És a T1GSS bit -el engedélyezheted.
Ez kicsit off kérdés lesz, de mégis itt tenném fel, mert eszközök közti adatátvitelben e sorok olvasója valószínűleg nagy tapasztalattal rendelkezik.
Tehát a kérdés: Egy páratartalom mérő adatlapjáról kiderül, hogy 14 bites felbontásban kerül a mért adat átvitelre. Ez meglehetősen nagy felbontás (1 / 16384), amit nem is értek, mert az eszköz paraméterei alapján mindez messze nem használható ki: (Sensing Accuracy: 4.5%; Humidity Range: 0% to 100%) (ez már egy viszonylag jó szenzor, így arra nem gondolok hogy itt is 14 bitet használnak mint az ezred %RD -t mérni képesnél, amely utóbbi nem is létezik) De ezen túllépve a kérdésem az volna hogy a megadott képletben (lásd melléklet) miért szerepel a nevezőben a kettővel csökkentett hatványérték?
http://sensing.honeywell.com/i2c-comms-humidicon-tn-009061-2-en-fin...12.pdf
És a konkrét típus: HIH 6030 http://www.farnell.com/datasheets/1738716.pdf A hozzászólás módosítva: Márc 22, 2016
Ahogy latod, vannak egyeb szenzoraik is joval nagyobb pontossaggal. Es a kommunikacio mindegyiknel egyforma, tehat NEM kell atirni a szoftvert/firmware-t, ha masikat tesznek be vagy nagyobb pontossagot kivannak hasznalni. Masfelol atlagolassal is novelheto a pontossag.
A hatvanyos dologrol fogalmam sincs, talan hogy tenylegesen elerhesse a szazat.
Úgy látom van még mit tanulnom. Viszont megírtam a programot, úgy, ahogy a tied működik. A helyzet ugyanaz. Max 90 cm, amit tud. Szerintem a szenzor ennyit tud. Két mérési különböző elvvel is az eredmény ugyanaz. Már rendeltem egy másik UH szenzort az ebayről. Minden segítséget megköszönök.
Én is csak nem túl rég kezdtem neki. Bár a szándék nálam már 20 éve is megvolt, de valahogy sosem maradt rá elég időm.
Lehet, hogy valóban az UH modulod hibás, de ha jól emlékszem mintha lett volna az adatlapjában olyan, hogy kell neki minimum 0,5m2 visszaverő felület.
Még valami ami problémát okozhat. Az adatlapon kiemeltem.
Ha túl sűrű a mérés, zárt térben a fennmaradt visszhang is problémát okozhat.
Na még egyszer..
Kár, hogy a korábbi hozzászolást csak rövid ideig szerkeszthehetem. Néztem az eredeti kódodat. nem vagyok benne biztos, hogy a problémát ez okozhatja, de a megszakításban az "a" változód típusa "int" Ami C ben -32,768 -től 32,767 -ig tart. én számláló esetében mindenképp "unsigned int" -et használnék. Az én kódomban azért nem ezt látod mert a pascal -ban "unsigned int" helyett a "word" tipus szerepel ami 0 - tól 65535 - ig tart. A "C" tipusokat csatolom képben. A hozzászólás módosítva: Márc 23, 2016
Nem kell túlbonyolítani. Ez mindkét irányba illeszt, már nem egyszer linkeltük.
Míg a Péter által megadott IC-t a jó ég tudja honnan tudod beszerezni, ezt a fetet szerintem bármelyik sarki elektronikai boltban megapod.
Javítok, nem a FET-est linkeltem, de az i megteszi. Íme a FET-es.
Hát először is azzal kezdeném, éjszaka aludni kell nem ilyesmivel foglalkozni...
 Persze, hogy úgyan úgy viselkedik a program, ha folyamatosan az eredeti hex filét írom a picbe, nem a módosítottat... (fáradtság). Miután a T1G lábról vezérelt TMR1-el próbálom ki, látszólag rögtön olyan 160-180 cm távolságot mutat. De az öröm nem sokáig tart. A mért távolság kb. dupla mint a valós távolság. Ennek oka (amit találtam), hogy a TMR1 időzítőben te nem használtál osztót, míg az én eredeti kódomban ez 1:2 osztó volt. A te PIC-ed 8Mhz-es belső , az enyém 8Mhz-es külsőről oszcillátorról megy, tehát ez is ugyanolyan. Ez az "a" változó dolog nekem is eszembe jutott. Próbáltam unsigned int (előjel nélkülivel is), semmi változás. Próbáltam unsigned long változóként is, semmi. Bár elvileg az eredeti váltózóba(int) is bele kellene férni, hisz 400cm*58.82 = 23528. Abban viszont teljesen igazad van, hogy annak unsigned int-nek kell lenni. Viszont az meglepett, hogy az unsigned short az 16 bites változó típus. Én esküdtem volna, hogy az 8 bites... Jó pap is holtig tanul. A mérési ciklussal kapcsolatosan én 300ms-1s között néztem, semmin nem változtat. Nem gondolom, hogy itt lehet a hiba. Gondoltam, talán számítási hiba lehet, de miután a timer1 értékét is kiírattam a kijelzőre (hátha ott van valami hiba), kiderült, hogy az pontosan a távolság 58 szorosa. Nekem nincs már több ötletem a dologra, csak annyi, hogy a szenzor ennyit tud. Viszont szeretném megköszönni a komoly segítséged, hogy időt szakítottál a problémámra. Köszönöm szépen. 
Szia icserny!
Ezek szerint, ha MAX7219-t teszek a kapcsolásba, akkor elég lesz 3 port a pic-nél? Próbáltam lerajzolni,nem tudom mennyire lesz látható. Valami ilyesmire gondoltál? A hozzászólás módosítva: Márc 23, 2016
Köszönöm, valami ilyesmi megoldást kerestem ...
Megmondom őszintén én is kicsit túlzásnak véltem azt az IC-t erre a feladatra ... A BSS138 helyett valami ami nem SMD? A tranzisztoros és a FET-es változat is tudja az oda visszát? (3,3V ból 5V és az 5V-ból 3,3V-ot?) Igaz egyelőre csak egyik irányú átlalakítás kell... de, ki tudja ... Mi az előnye, hátránya a FET-es ill tranyós megoldásnak?
Igen ilyen kapcsolásra gondoltam.
Szóhasználat: A három "port" valójában csak három digitális kimenet. A port az általában 8 vagy több összetartozó (egy gépi utasítással írható) kimenetet jelent. A csak félig kihasznált MAX7219-nél inkább az alsó négy számjegyvezérlő kimenetet kellene használni, mert emlékeim szerint a SCAN LIMIT beállításával fentről lefelé haladva lehet letiltani a számjegy kijelzést. Azaz olyan beállítás van, hogy csak Digit 0, 1, 2, 3 él, de olyan nincs, hogy csak Digit 7, 6, 5, 4 él.
BSS92
A BJT-s csak felfelé illeszt, de egy plusz schottky diódával kétirányúvá tehető.
A FET-es kétirányú. A FET-es előnye, hogy kevesebbet fogyaszt. Ha nagyon gyors jelkövetés (<10ns) kell akkor a FET-et célszrerű push-pull áramkörrel meghajtani (pl: SD kártya). Hp41C fórumtárs pedig írta a megfelelő TO-92-es FET-et.
Jah, igen. Bocsánat, csak már siettem a rajzzal, azért volt a felső négy digit meghajtó kimenethez kötve, de már javítottam.
Még egy kérdésem van: - a szegmens kimenetekhez kell valami szegmens meghajtó áramkör ( pl. udn 2981), vagy mehet direktben a kijelzőkhöz? |
Bejelentkezés
Hirdetés |
