Fórum témák
» Több friss téma |
Lefordítottam, bár nincs kéznél az áramkör, hogy ki tudnám próbálni...
Mindkét I2C vezetéket 4,7kohm-al húzd fel pozitívra, A0,A1,A2 cím vezetékeket testre.
Üdvozlök mindenkit a fórumon.
Az után érdeklőnék, hogy lehet a PIC kiterjesztésű fájlokat megnézni mert nekem csak fekete kép lessz ACDC-vel valamit rosszul csinálok? Előre is köszönettel.
Köszönöm a választ én is most kezdek próbálkozni
a Parsic-kal.
Sziasztok!
Hátha valakinek jól jön egy stopper  Egyre jobban tetszik a program, ahogy kezdem megismerni egyre jobb ötletek jutnak eszembe mit lehetne megcsinálni. Gábor
Arra jöttem rá, hogy pár másodpercig meg a progi addig mér is rendesen, aztán megáll. Tettem hozzá egy LM35ös analóg szenzort, és azt is meg állítja. Ha csak külön annak írok a pic be progiat az jó. szóval nem a kapcsolással van baj. Mi lehet ez?
Szerintem nem megy az I2C kommunikáció rendesen...
Nálam hetekig ment mikor megírtam, aztán átalakítottam egy Ricoh RTC óra Ic olvasási tesztre... Az analóg szenzor teljesen máshogy müködik itt az Lm75-höz viszonyítva. Kipróbáltad az általam lefordítottat is? Próbáld meg ezt is...
Mit módosítottál ezen a progin? Már vagy 3-4 perce megy lefagyás nélkül!
Üdv. mindenkinek
kkrisz75 szeretném megkérdezni hogy a 16f628 04/p az csak 20mhz-n nem komunikált neked vagy egyáltalán nem? válaszod elöre is köszi
A 16f628 04/p 4 MHz feletti mukodese nem garantalt !! Adatlap olvasasa sokat segit. A Trabant mennyit fogyaszt 200 km/h nal ?
köszi a választ akkor megyek és megveszem azt az 1 darabot ami a boltban van!
Nem tudom, hogy működött-e, mert nem kommunikált 20MHz-n.
Naturba saját magát a működést nem próbáltam, de szerintem nem fog menni.... de aztán lehet, hogy mégis.
Nem értem! Ha jól látom csak a timer1 et vetted vissza 250 ms-re. már tegnap este óta megy gyönyörűen!
lenne egy kérdésem! Mennyi az a maximális 7 szegmenses kijelző amit 1 picel meg lehet hajtani? 2*20 as LCDvel akartam megoldani egy projektet, de nem jó, mert kocsiba menne, és csak szemből jó oldalról már alig látszanak a számok! Egyébként egy fekete alapon zöld kijelzésű LCD nagyon jól néz ki, csak szemből. ):
1 db 7 szegmenseshez 8 láb kell minimum.
2db 7 szegmenseshez 9 3db hoz 10 1db esetén 7 szegmens negatívja 7 láb és egy pozitív a 8. láb. 2db esetén 7 szegmens párhuzamosan kötve és az első szegmens pozitívja 1 lábra a második szegmens pozitívja másik lábra. Amelyik pozitívon megy ki áram az a kijelző világít. Gyors egymás urtáni váltogatással, folyamatos kijelzést lát a SZEM. Ban példaprogram parsic könyvtárában.
Ezt vágom! Nem is a bekötés érdekel, hanem az, hogy mennyire marad jó a kijelzés, ha sok kijelzőt használok, illetve programban hogy lehet mondjuk 20 kijelzőt le kezelni?
A parsicos 7 szegmens kijelző ha már nem magában állt áll a programban szemmel láthatóan villog használjátok az általam feltett példát az garantáltan jól működik
Nekem ez alapján volt megcsinálva. 4x7 szegmens és nem villogott.
Ettől függetlenül, lehet ha több szegmens van akkor villog. Hol a te példád, mert az is érdekelne. mert ha nem bírja a több szegmenst akkor valamit majd ki kell találnom mert 8x10 ledet kell villogtatnom majd.
Én már csináltam azzal egy projektet, ahol 7*4 volt és tökéletes, csak nekem most kB 20 kellene! ill. 2*20 és arra gondoltam 2 16f877 menne bele smd kivitelben. De még kitalálás alatt van.
Ilyen sok kijelző egyidejű meghajtását villogásmentesen szerintem kemény feladat lesz megoldani, főleg ha a mikrovezérlőnek mást is kell csinálni a kiíráson kívűl.
Akármilyen is a program, ha ASM-ben van megírva 1db kijelző legfeljebb az időegység 1/40-ed részéig aktív. Ha sikerül is egy nagyon optimális programot írni és a mikrovezérlőt 20MHz-el hajtani, a villogás eltűnhet de a kis fényerő problémája akkor is fennáll. Én megfontolnám a helyedben minden kijelző elé egy tárolós BCD/7szegmenses dekóder beiktatását pl:CD4543 Ez tuti villogásmentes akár több ezer kijelzővel is  3db 4067-es alkalmazásával pedig nem kell kettő PIC sőt egy 18-as lábszámú is bőven elegendő.
Én nemrég építettem egy hőmérőt, be is linkeltem ide. Ott 6db kijelző van hajtva, egyáltalán nem villog, a fényerő is jó, pedig még mást is csinál a pic. A lényeg, hogy a multiplexelést ne a parsic-al csináljátok, hanem egy include fájlban legyen, amit mainprogramként hívogat a parsic. Ha kell majd felteszem ide.
dcsabi, kaqukk, többiek...
A párhuzamosan kötött adatátvitelt nem sikerült megoldani. Az elv a következő volt a teszt során. A szolga pic-ekben 50ms-onként kéri a KIMENET változó adatait. Ha ennek a változónak értéke =10 el akkor az első szolga pic elküldi 2ms os frissítéssel a RPM értékét. Ha 20al akkor az első nem csinál semmit hanem a második küldi el a KMH értékét. A mester picben lévő számláló 50ms-onként elküldte a KIMENET értékét, amit az én logikám szerint mind a két pic megkapott és feldolgozott. Ugyan akkor mikor elküldte, és a kimenet értéke 10el vagy 20al volt egyenlő ugyan így 2ms os frissítéssel fogadta a RPM vagy KMH adatot. Sajnos nem találtam példa programot erre. Az uart modul ACT( visszaigazoló láb) működésére nem jöttem rá. Fórumot is vissza olvastam de nem találtam rá... (Lehet sok száz hsz. közt elvesztem) Valakinek ha van magyarázata leírása az ACT láb használatáról lehet sokat segítene. 628_RXTX és 628_RXTy a két szolga pic külön külön programja. 877_RXTX a mester pic programja. 4MHzra cserélve minden, mert az egyik 628as csak azon megy...
ACT=Aktív
Magas szinten van amíg az adás vagy vétel folyamatban van. PARSIC helpjében is leírja.
Örülök neki...
Egyébként ha megnézed, van ott egy gombóc is valahol pluszban...
Két dolgot csinálnék másképpen, így első ránézésre.
A 2ms az nagyon rövid idő, azt mindenképpen nagyságrendekkel megnövelném, ennyi idő alatt nem fog kommunikáció lefutni... Régebben egy freki mérőnek vagy fordulatszám mérőnek simán elég volt 100ms időalap (vagy még 1s is!) maradjunk egyenlőre 100ms-nál, de lehet akár 200ms is. ehhez próbáld alakítani a mérésed feldolgozását. A mérésbe mindenképpen kell egy átmeneti tároló, ne az aktuálisan töltődő számláló pillanatnyi értéke kerüljön ki a kijelzőre. erre tettem fel régebben példát. A kommunikáció előtt miért van az "és kapu" és ráadásul azzal a rövid időalappal... A Parsic rajz sok mindent elbír, de gondoljuk csak végig mi történi a processzorban, nem biztos, hogy ezt vártuk töle. Főleg ha több "határt" is átlépünk egyszerre. És csak az egyik (628A) Pic-el foglalkoztam... Ehhez hasonló méréssel próbálkozz.
Ha rá rugok a gázpedálra akkor a motor felpörög 3000ig és vissza esik 1000re 1.2sec alatt.
Ha 1sec a mérési idő, lényegében meg se fog moccanni a fordulatszám mérő. Ha pl. utcán haladok és kiforgatom 6200ig, és felváltok egy sebességet, mire vissza esne a fordulat, már 1000el megint feljebb van. Ez alacsony fordulaton nem gond, de váltás határon már 1sec 250-300fordulat, a szelep becsörgést jelentheti, ami töréshez és motor széteséshez vezethet. Az 1sec teljesen jó, egy számítógépbe, ahol 99% statikusan állandó a fordulatszám. De egy autóba 100ms az ideális. A 250ms már darabos de kompromisszumos megoldás. De ettől függetlenül jó a program, lényegében ha jól látom a programot a 250ms leosztását(2ms x125 =250ms) vetted le róla. A többi ugyan az. RBx - számláló - tároló, amit a frissítési idő vált 0 vagy 1re és a 1nél kiküldi. Ez van nekem is, mert ebből és egy másikból loptam az időmérést, a frissítés nálam 250ms. Az LCD-n is ha kell, de mégsem kommunikál 3 pic párhuzamosan. 2db egymással 2ms on is jól kommunikál eddig azon volt. 3pic csak sorosan de már késnek.(1200nál még csak 1000 mutat, bár ez orvoslódik 20MHz val. Most 4Mhz) Nincs ötletem a párhuzamosan kötött picek hogy tudnának kommunikálni. És most nem a sebességről van szó. Mert ha 1mp el léptetek egy számlálót mind a kettőben, akkor sem kommunikálnak.
Na eljutottam odáig, hogy a mester kommunikál az 1es pic-el, párhuzamos kötés esetén.
Igaz nagyon-nagyon lassan, sok késéssel. A másodikkal is kellene kommunikálnia, ha az elv jó. Ha jól sejtem a probléma az adat vissza igazolással van. Vagyis mikor a mester kiküldi az adatot, amit mind a kettőnek értelmeznie kellene, csak az egyik értelmezi. A másik lehet meg se kapja, mert az első gyorsabb kicsit és leigazolja a fogadást mielőtt a második meg kapja. Jól sejtem ez lehet a baj.... (most 50ms 100ms és 250ms és 500ms és 1sec frissítésen próbáltam, mindegyiknél csak az 1es pic-el kommunikált, nagyobb idő alatt, nagyobb eltérések adódtak csak, de volt kommunikáció)
Ha megnézed a gyári példaprogramokat, akkor ott is látod, hogy Pl: a vételnél be van iktatva az ACK lábra egy 20ms késleltetés.
Ettől eltérni nem célszerű. Ebből is látszik, hogy az ACK az nem az ellenállomásnak szól, (hogyan is szólhatna így)hanem a programban lehet használni segédletként. Nézd meg a gyári segédprogramokat is az Uart-hoz. A 2ms és a 100ms között 50x-es eltérés, ez idő alatt sok mindent meg lehet csináltatni a PIC-el. Nyilván az 1s az nem komfortos, csak példaként említettem. az adott mondatban. |
Bejelentkezés
Hirdetés |
