Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Idézet: „A továbbiakban azt kell még megoldani, hogy különbőző címtartományra forduljanak, a címkéket elérjék.” Bocsanat, hogy kozbe kotyogok, de epp erre valo a linker script, hogy ezek automatikusan megtortenjenek. Nyilvan az asm-ben ugyelni kell arra, hogy ne abszolut modban legyen megirva...
Szerintem vegyél pár TPIC6B595 vagy TPIC6C595 léptetőregisztert és ezekbe told ki programmal a LED-ek állapotát. Bármilyen kis lábszámú PIC meg fog felelni a célra, a léptetőregiszterekhez csak egy adat és egy órajel láb kell.
A TPIC-k több száz mA áramot elviselnek a kimenetükön és open drain kimenetűek, így akár óriási, sok LED-ből felépített füzérek (szegmensek) meghajtásához is megfelelőek, a LED-füzérek tápfeszültségével fel lehet menni egészen 30 vagy 50V-ig.
Én a múltkor csak DS18S20-as adatlapot találtam, és abban az eszköz rajzán DS1820 a felirat. Jó lenne látni a két adatlapot, amik között különbséget látsz, mert én is úgy tudom, hogy a kettő ugyanaz (létezik még DS18B20, az tényleg más, és a DS1821 is egy másfajta eszköz).
A DS1820 esetében tudtommal ki lehet kerülni a ROM-kód nyűgösségét abban az esetben, ha nincs több eszköz felfűzve az 1-wire buszra. Ekkor minden parancsot a "skip ROM" (0xCC kód) bevezetéssel kell kezdeni. Felhívom még arra a figyelmedet, hogy komplett "tranzakciók"-kal lehet kommunikálni vele, azaz a reset-presence-parancs-adat folyamnak mindig meg kell lennie, nem lehet reset nélkül új parancsba fogni.
Akkor olyan típust keress, aminek van belső oszcija és emiatt az oszcillátorlábak is átválthatók kimenetnek. Ebbe biztos bele fog férni a 32 kimenet, bár kérdés, hogy valami input nem kellene-e a programnak, hogy mi szerint vezérelje a LED-eket... Pl. a 16F887 (vagy kisebb memóriájú, de szintén 40 lábú testvére, a 16F884) szerintem jó választás lenne.
Idézet: „Az LCALL szintén két sorosra fordítódik(illetve 3), ezért figyelni kell a fent említett elágazások lekezelésénél. Írj egy példát és nézd meg szimulátorban, hogy mit lehet itt elrontani, utána már menni fog!” UFF! Ezert nem ajanlja a Microchip az LCALL-t ujabb tervezesekhez - meg mas pseudo utasitasokat sem...
Nezd meg, hogy a map file-ban nagyjabol 3 resz van, az egyik a szekciokkal foglalkozik - most ezt hanyagoljuk - a masik ketto meg a cimkek elhelyezkedesevel. Az egyikben nev szerint, a masikban meg cim szerint rendezve.
Namost a GOTO es CALL utasitast ha megnezed az adatlapban 11 bites cimzest enged meg, tehat 2^11=2048=0x800 szoval a cim szerint rendezett nezetben lathatod minek van nagyobb cime, mint 0x800... Namost ha valahonnan a 0x800 elotti teruletrol hivsz 0x800 utanit, akkor PAGESEL kell - es forditva, ha 0x800-asrol elobbire, akkor is kell... Ilyen egyszeru, azzal megtoldva, hogy a fejlesztes folyaman a cimek csuszhatnak es azokat folyamatosan figyelni kell. Be is lehetne makroztatni a figyelest de most inkabb ne menjunk bele ilyen melysegekbe. Kivancsi vagyok sikerul-e a problemat megoldani!
Idézet: „De még mindig nem vágom, hogy lehet egy 10 lábú izéről, egy, vagyis 32 db ledet meghajtani” Olvasd el a Microchip MCP23017 vagy MCP23S017 adatlapját!
Sziasztok!
Még egy ötlet... A másik lapon levő rutin hívását "be lehet csomagolni" úgy, hogy a főprogramban nem kell módosítani.  Az eredeti programban ez volt CIM2 ; Ez itt egy hosszú rutin, melyben nincs más rutin hívása ; és nincs kiszámított ugrás ..... return A módosítás után: A hivásoknál nincs változás. call CIM2 A becsomagoló programrész: CIM2 ; Ez az 5 utasítás még a 0. lapon van movlw high(CIM2_2K) movwf PCLATH call CIM2_2K clrf PCLATH return org 0x800 CIM2_2K ; Minden marad változatlan return E megoldás hátránya, hogy egy szintet elhasznál a stackból, de egy pillanat alatt beilleszthető a kódba (amennyiben a szubrutinok hívási maximális mélysége (beleértve a megszakítási rutint és az abból hívottakat is) eddig nem érte el a 7-et ). Tovább finomítható, ha a CIM2_2K -ból minden visszatérés elött közvetlenül töröljük a PCLATH-t. Ekkor a hívó részlet call utasítása goto-ra cserélhető. Ekkor becsomagoló programrész: CIM2 movlw high(CIM2_2K) movwf PCLATH goto CIM2_2K org 0x800 CIM2_2K ; Minden marad változatlan btfss valami goto CIM2_2K_VEGE ; itt return volt decfsz valami2 goto CIM2_2K_VEGE ; itt is return volt CIM2_2K_VEGE ; Minden visszatérés ide ugrik clrf PCLATH return Ha a CIM2-ben vannak hívások, akkor legegyszerűbb azokat is áthozni 0x800 fölé. Ha közös lapon vannak, nem kell változtatni. Sok sikert...
Általánosságban: Igen, lehet. Na, most akkor ezzel mire mégy?
A legegyszerűbb elv pedig (szintén általánosságban) az, hogy az ASM és a C is tárgykódba (object) fordul, s a Linker pedig összelinkeli őket.
A PIC-ben valahol tarolod a 32 led allapotat (amit szeretnel). Utana szetkapcsolod egy labon a shift regiszter kimenetet es a belso adatat, aztan a data es orajel segitsegevel 'mogeje sorakoztatod' a megfelelo biteket, majd ha az osszes bit kiment, akkor ujra 'osszekapcsolod' a shift regiszter belso adatat a kimenetekkel.
Ha egyetlen led allapotat valtoztatod is meg, mindig a teljes belso tarat ki kell shiftelned. Hatranya, hogy sok lepesbol all, elonye, hogy fuggetlenedsz a labszamtol. Valahogy ugy kepzeld el a shift regisztereket, mint egy hosszu, atlatszo csovet, amibe pontosan 32 db fekete vagy feher golyo fer. Ha egy golyo szinet meg akarod valtoztatni, akkor letakarod az egeszet, az egyik oldalon 32 uj golyot kell beletenned a megfelelo sorrendben (mikozben a masik vegen meg potyognak ki a golyok) majd a vegen felfeded a csovet. Ha jol csinaltad, csak az a golyo valtoztat szint, amit akartal. Persze, ez csak latszolagos, de amit akarsz, azt elerted. Kozben a kimenetek tartjak az elozo ertekuket, amig 'atlatszova' nem teszed. Tulajdonkeppen tagabban ertelmezve a mozifilm is igy mukodik, meg pl. a TV (egyetlen, tuhegynyi sugar van, te megis folyamatos kepet latsz!) is.
Itt van a DS1820 adatlapja, itt pedig DS18S20 adatlapja.
A gyártó (MAXIM) szerint a DS18S20 szoftver kompatibilis a DS1820 típussal a legtöbb alkalmazással (tehát helyettesítőként ajánlják).
Sziasztok!
Igen ezek szerint ez így igaz, de valami mégsem stimmel mert az Oshon-os pic demoprogrammal mégsem működik! Lehet hogy ebbe beleszámít egy kicsit az is hogy kezdő vagyok ezen " szoftveres" téren ?!Egy próbapanelon összeraktam a Vicsys által épített ezzel a szenzorral működő hőmérőt és végül is az Ő programjával ólvastam ki a ROM kódot, átírtam, visszatöltöttem, és nagyon klasszul működik. (Egyébként nagyszerü munka!! Gratulálok Neki) Már csak azt kell megértenem hogy hogyan hozzam össze ezt a kódot az én Basic programommal...
Hat ez mar tiszta DLL API call table, szerintem a PICeknel ez felesleges program memoria es CPU pazarlas. Ha valaki nem tud egy linker scriptes, lapozasos projectet ossze utni akkor lehet nem kellene ekkora fejszebe vagnia a fajat -- vagy hogy is hangzik ez eredetiben hehe
 De az is lehet akkor inkabb magas szintu nyelven kellene megirnia az alkalmazasat.
Szia!
Igazad van, de lehet, hogy holnapra működik....
Noigen, a DS1820 ezen adatlapja egy "őskövület", még a Dallas-os időkből.
Azt a Maxim-os különbséglapot jó, hogy belinkelted, abból számomra az derül ki, hogy más technikával mérik a hőmérsékletet, és valószínűleg ebből adódóan a DS18S21 maximális konverziós ideje kicsit hosszabb. A felhasználó felé nem látszik a konverzió mikéntje, ez számára nem is érdekes, a konverziós idő lehet gond, ha a lassabbal akarjuk a gyorsabbat helyettesíteni. Egyéb vonatkozásokban szoftveresen meg ugyanaz a kettő, ahogy látom. Tehát nem igazán értem csiefjancsi ROM-kódokra vonatkozó korábbi állítását.
Nézd meg az Oshon progiban, hogy mennyit vár a konverzióra. A DS18S20-nál ez maximum 750ms, a sima DS1820-nál maximum 500ms. Az éppen okozhat "nem működést" is, ha nem vár eleget az eredményre.
(Amúgy van itthon valami ilyen DS cuccom, lehet, majd ránézek arra az Oshon-ra, ha lesz egy kis időm.)
Na rendben van, de akkor legalabb igy modositsd, mert nem biztos, hogy az adott API-t mindig a nullas laprol fogod hivogatni:
Még két dolog a működéshez...
1. A megszakítási rutin mentse és állítsa vissza a PCLATH értékét. 2. Magának pedig állítsa be a 0. lapot. ORG 0x004 ; interrupt vector location movwf w_temp ; context switching swapf w_temp, f ; w_temp is in common RAM swapf STATUS, w ; Save STATUS movwf status_temp swapf PCLATH,w ; Save PCLATH movwf pclath_temp ; Needed only if >2K program memory used clrf PCLATH ; IT routine is in page 0 ; Megszakítási rutin .... swapf pclath_temp,w ; Needed only if >2K program memory used movwf PCLATH swapf status_temp, w ; restore conext for main program movwf STATUS ; this will also restore bank selection swapf w_temp, w ; w_temp is in common RAM retfie ; return from interrupt Persze ez is típusfüggő, az adatmemória szervezése miatt (kétféle megoldás van - közös tartömány, ami minden lapról látszik 16F876,877, - külön lapok 16F763,874).
Most már kezdem érteni és gyanítom is hogy mit szurhattam el!!! Most már nem tudom kipróbálni mert hajnalban kelek de holnap délután meló után első dolgom ez lessz. Már alig várom!!!!!
WaitMs 1 Ez az eredeti programban van és szerintem ez lessz a megoldás, nem láttam a fától az erdőt... Minden esetre, előre is köszönöm ha lenne időd és ránéznél a témára.
Sziasztok! Köszönöm az aktivitasotok az oldalvaltasokat illetoen.
A 18F kalandba biztos bele fogok fogni, de majd ez utan a project utan, ahogy irtam is ennek hamarosan menni kellene és biztos vagyok benne lesznek a PIC váltással bajok. Addig is fogyókúrára fogom a kicsit túlméretesre sikerült programom, illetve teszek pár bátortalan lépést pagesel ügyben is. Hp41C! Elküldöm a programom a hozzá készitett folyamatábrákkal a könnyebb érthetőség kedvéért. Nagyon szivesen veszek bármi programozás technikai ötletet (mint peldául a tizedére redukalt EEPROM mentő forrásfile esetében), de világért sem szeretném ha fél éjszakát a programom átírásával töltenél. Részben sajnálnálak a sok valószínűleg szokatlan megoldás bogarászása miatt (sosem tanultam programozni, csak amit ellestem főleg innen a fórumról, meg magam kikombináltam), részben meg azért mert igazából szeretek vele "gyötrődni". Ami jól jönne, az pár tanács, ha valamit nagyon nem úgy szoktak megoldani. Azt mégegyszer hangsulyoznám fontos volt az áttekinthetőség a későbbi alakítgatások miatt ezért vannak sokszor felesleges pl cimkek. Kösz mindenkinek mégegyszer!
Kitaláltam!!!
Én egy útkereszteződés jelzőlámpáit szeretném vezérelni, és kitaláltam, hogy 877-essel dolgozom! Képek csatolva! már csak a progival kell törődnöm, valamint a tereppel. (a 2. rajz régi de valamit mutat)
Na az így már majdnem jó, csak az X vezetékeket meghajtó tranzisztorokhoz vagy bázisellenállást kell tenni, vagy pedig pnp tranzisztorokat kell használni emitterkövetőként bekötve.
???
Ezt nem értem! Lerajzolnád nekem, ezt a részletet, ha szépen megkérlek? Ha igen akkor szépen megkérlek arra, hogy rajzold meg nekem azt a részletet! Még valami: hogyan találom meg az eagle-ben a 877-est?
Hu de jo ez a kockas papir effect az Eagle-ben
 Bazis ellenallas: Egy ellenallas a pic labatol a tranyo bazisahoz - ahany tranyo, annyi ellenallas ertelem szeruen. Hogy mekkora, az a tranyoktol fugg... Amugy ugyanezt megtehetned ellenallas nelkul fet-ekkel, es azokon raadasul kisebb is a feszultseg eses - ami itt mondjuk nem jatszik nagy szerepet... Viszont amit ha jol latom Portyo nem emlitett neked, hogy a LED-ekhez is kell ellenallas... Ha jol latom azt tervezed, hogy multiplexalod, tehat egyszerre csak egy rail fog foldelodni az Y agakbol es kozben az X agaknal hatarozod meg ki vilagit? Mert ha igy van akkor eleg X agankent 1 ellenallas a LED-ek fele...
itt van egy módosulat a 2-es képről, csak az x-hez kell bázisellenállás?
Valamint nem találom a 877-est az eagle-ben, és az x tranyókat cseréljem le pnp-re
Bazisellenallals mindenhova kel ahol van tranyo - okolszabaly elektronikahoz... Gyakorlatilag a tranyo bazis aramat kell beallitanod az ellenallassal - nezz utana hogy mukodik a tranzisztor.
Amugy ez akkor ugy mukodne, hogy bekapcsolod Y1-et, ami mondjuk a piros jelzes, es bekapcsolod azokat, amiknel piros a lampa, utana Y1-et kikapcsolod es bekapcsolod Y2-t, majd azokat amik sargak, majd Y2 ki, Y3 be, es azokat amik zoldek -- igaz?
Hi All!!
Egyik barátom szakdolgozatának a témája a rendőrlámpák. Kitalálta, hogy épít egy modell kereszteződést és az egészet PIC-el szeretné vezérelni. Emiatt kell egy rakás bemenet, minimum 8 db nyomógomb, és kimenet a lámpáknak (ledeknek),min 32 db. Nos a gondom az, hogy tök láma vagyok a picekhez, de a hardwer összeállítása az én feladatom. arra kérnék 5letet , hogy lehet kivitelezni ez a nem túl kevés "I/O"-t! Anélkül, hogy egy ezerlábút venne a barátom.
Szerintem, nem jár rosszabbul, ha 100 vagy 64 lábút vesz, mert annyival nem drágább (szinte semmivel sem) mint amennyivel egyszerűbb lesz utána a dolga.
Pont az imént volt szó a multiplexelésről, gondolom ezzel a fogalommal képben vagy. A PIC-ek nagy előnye, hogy egy láb kimenetnek és bemenetnek is definiálható bármikor a programban, ezért tényleg nem kell egy százlábút választani. Ha csak I/O-kkal akartok dolgozni, akár egy kisebb lábszámú PIC is megteszi, és külső kapuzással kibővited, ez rád van bízva. Amit leszögeznék, hogy a 18-as családból válasszatok, ha még van lehetőség választani. két példa: 18f46k20 vagy 18f4321
A 100 vagy 64 lábúak valóban nem drágák, de ezek nincsennek DIP tokban. Ha ez nem jelent gondot, akkor nyugodtan választhattok ilyet is.
Van ennek valami koze a Kiskacsa2009 projectjehez?
Ha nem akkor nezd meg o hogyan probalkozik megoldani a kerdest, jo uton halad!Nyomogombok: Analog bemenetre tedd ra egy ellenallas letraval, es akkor egyetlen bemenettel meguszod. Szepseghibaja a megoldasnak, hogy nem tudod erzekelni ha egyszerre tobb gombot nyomtak meg. |
Bejelentkezés
Hirdetés |
