Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Nálam a szimulátor szerint hogyha a BF bit 0 akkor csak egy ciklus.
Szerintem ha nulla akkor a következő utasítás, ( 1 ciklus) ha 1 akkor egy nop és a program folytatódik (2 ciklus)
Egyetértek. A btfss, btfsc, decfsz, incfsz, lehet 1 vagy 2 ciklus, kiértékelés eredményétől függ.
Hacsak nem történt valami újítás amiről nem tudok. A hozzászólás módosítva: Máj 12, 2014
A kép kirakása után tartja magát. A fő probléma az egymás után következő ledek között nem lehet késleltetés ??? .Bár az adatlap alapján nem igazán derül ki, ha az alacsony szint több mint az alacsony jel hossza, de kevesebb a resetnél mit csinál. Lehet simán lehetne két rgb led között számolni sok mindent.( resetig hátralévő időig).
Félreérthetően fogalmaztam :
Ha 0: btfss /1 ciklus utasítás /1 ciklus, ha 1: btfss /1 ciklus nop /1 ciklus Így az eredmény mindig 2 ciklus.
Ez nem jó megközelítés. Az utasítást nem szoktuk beleszámítani. Az külön kell saját magaként.
Mi van ha az egy goto, máris borul az elmélet.
Hát, ha szigorúan a tűrés nélkül számolunk akkor 60 LED esetében a végrehajtási idő ~1,8ms.
Ez alatt mondjuk sokminden történhet az igaz. A két LED közti idővel még nem játszottam, de lehet benne valami. Ki kell próbálni. 50usec a reset, az 20 MHz-en 250 utasításciklus. Az nem kevés. A hozzászólás módosítva: Máj 12, 2014
Az általam használt vitaindító bitbanged verzió tegnaptól megy az órámban. Másodpercenként állaptot vált 2 led. Az egész csőalávilágításra lett tervezve, arra tökéletesen működik 16f886-tal. Az SPI akkor lenne fontos, ha gyors színátmenetet szeretnék. Persze itt az óra is megy mellette... A két led közötti időben adok értéket a színt tartalmazó változóknak, azt elviseli . Egy komolyabb számítás vagy feltételrendszet viszont már nem fér el a két led írása között.
Két LED írása között nem is kell számolni semmit. Előre ki kell számolni a következő képet, letárolni közben, majd kivinni a csomagot, bármilyen hosszú is legyen az. Utána magasban tartani a vonalakat, amíg ki nem számolod a következő adagot. De ki kéne ezt próbálni...
Két led írása között jelenleg az értékadás és a kiíró szubrutin meghívása van. A ledek írása után ott van egy egész óraprogram megszakításvezérléssel, kijelző és input kezeléssel, dcf dekódolással stb. Most csinálok egy 6 ledes próbaáramkört, hogy a folyamatos színátmenetet tesztelhessem. Magasan tartani a vonalat nem kell, nem reset történik 50uS alatt hanem csak a latch tartalma íródik át a megjelenítéshez. A led viszont kb fél perc után resetel le (lehet hogy más okból) ezalatt újra fel kell frissíteni a " képet".
Nem ugyanazt értetted a "két LED közötti időről". Ha van 60 LED, akkor mind a 60-nak ki kell számolni az adatait, majd kiküldeni (először a 60. adata megy ki, majd szalad végig a soron).
Úgy értettem, hogy az első és a második és így tovább LED-ek adatai között nem kell számolni semmit, azt előre kell kiszámolni. Aztán a következő 60 adatát kell kiszámolni, amire van idő, ahogy minden másra is. Az időkritikus rész a 60*24bit kivitele.
Ugyanazt mondjuk... ugyanúgy értjük. (az első 24 bit után belefért még az értékadás és a szubrutinhívás is, persze az érték adott volt (pl. 5,5,0) de ha folyamatosan szeretnék egy szivárvány effektet (6 vagy 60 leden), akkor valószínű előre le kell tárolni az értékeket)
Sziasztok. Kocsihoz építenék egy többfunkciós műszert. Azt szeretném megkérdezni hogy turbó nyomás méréshez milyen érzékelőt tudnátok javasolni? Ezt találtam neten, lineárisan növeli a kimenőfeszt. a nyomás növekedésekor és 4,5V a végkitérése" tehát egy analóg csatornát feláldozok rá a picen és működne is. Azt nem tudom hogy ez bírhatja-e akár a 80 fokot levegőt is tartósan. Bővebben: Link
Bár nem tudom, hogy a szenzor kiválasztásának mi köze a picekhez, ez a szenzor nem lesz jó. Azért nem, mert 0-100kPa tartományban mér, ami egy szívómotorhoz jó lenne, de turbóshoz nem. Ha esetleg nem találsz máshol, akkor nézz szét LPG rendszer alkatrészek között, annak is szüksége van a szívótér nyomására, és ott van olyan szenzor, ami turbós motorhoz is jó. Vagy bontóban nézelődj turbós autó nyomásszenzora után, dízelé is jó szerintem.
Viszont turbós motornál kellene lennie nyomásszenzornak, amivel a motorvezérlő méri a nyomást, annak a jele nem jó? Az is ilyen 0-5V közötti tartományú kimenő jelet ad.
Érdekes elehet még a Configurable Locic Cell CLC.
Azt nem próbáltam még, de eljátszottam a SPI busszal.Bármily meglepő nem mindegy az órajel forrás. Az első kép SPI bemenete az órajel/64 a második a timmer2/2
A belső oszcillátor forrásnál a 8. bit után rak egy kis hibát.
Azt elfelejtettem pic16f1503 volt a tettes
A két freki mennyire tért el és mekkora volt?
Igazából az eltérést pontosan nem mértem, 1Mhz belső órajel a SPI először 64-ed része ( amennyire megítéltem 15khz környéke (tehát osc/64) A TMR2 esetén T2CON=05 a PR2=1 esetén ugyanaz (ránézésre) a periódusideje egy ciklusnak. (itt még PR2=2 volt ezért nem volt egyforma a két jel pontosan. A szkópon nem váltottam semmit)
A hozzászólás módosítva: Máj 19, 2014
Az lenne érdekes, mit csinál valahol 1..10MHz között az SPI, ha pakolod bele a 0x55-ket...
Amit mértél, azt melyik lábon mérted? Az órajel is érdekes lehet, de az adat kimenet jobban. A hozzászólás módosítva: Máj 19, 2014
Ez az órajel volt..Megszakításra adat bele, itt lényegtelen hogy mi. Az adat váltás otthon hangkártyán nézve nem tűnt problémásnak , az az órajel megfelelő éleivel szinkronban volt, így azt nem is vizsgáltam. De ez az extra szünet az órajelen meglepett. Az után mikor a Microchip a clc-t ajánlotta , gondoltam megnézem ott milyen a jelalak. Legnagyobb meglepetésemre ott már nem volt benne az extra szünet.Egyértelműen csak az órajel forrást változtattam, mást nem.(Az előosztó sem segített rajta, arányaiban maradt a hiba a hangkártyán, szkópon nagyobb frekin azt már nem is néztem....)
A hozzászólás módosítva: Máj 19, 2014
A "kihagyás" nem a megszakítás kiszolgálásával kapcsolatos? A megszakítás nem tudta addigra beírni az új adatot, mire az SPI shift regisztere kiürült. Mivel az SPI az órajeléhez szinkron működésű, igy SPI slave eszközök nem törődnek a kihagyással. A WS2812 csak az adatot kapja meg, így a "kihagyás" elrontja az időzítést.
Egy 48MHz -es 18Fx550 -nel kb. kijön az időzítés, de nem sok tartalék van benne. Egy tömbben tárolt minta kiküldhető vele - a mutató léptetése is megoldható. Az Advanded Midrange kontrollereken van movi utasítás is, ami az adatmozgatással egyidőben növelni / csökkenteni tudja az FSR regisztert.
Jelen pillanatban csak annyit változtattam, órajel forrás fclk/64 ill fclk/16/2/2 csak a tmr2-n keresztül.Minden más maradt.Adatbeírás megszakításra programozva konstans olvasás, kiírás ( legrosszabb esetben 4-5 utasítás ciklus a rendelkezésre álló 16*8 ból. egy önmagában zárt ugróutasítás mint fő program mellett. De ez a környezet mindkét esetben azonos.
Két érdekes link Bővebben: Link és Bővebben: Link
Azért jobban körbe járom hozzá a tűréseket. Itt is van némi rés a reset impulzus hossza és a többi alacsony szint hossza között, amiről az adatlap mélyen hallgat.
A hozzászólás módosítva: Máj 20, 2014
Sziasztok!
MPLAB 8.92, TMR1 szimuláció nem működik. PICKit3 használata esetében megáll a breakpontál, de nincs StopWatch a Debugger menü alatt. Ötlet, hogyan lehetne a Timer1 idejét mérni? (debuggra gondolok, nem külső eszközökre, mert az elég gáz lenne egy IDE használatához kötni...) |
Bejelentkezés
Hirdetés |