Fórum témák
» Több friss téma |
Ok,
De valamiért szórakozik velem. Chip beállításoknál, XTAIL-t állítok akkor a switc... menüben RC re áll... Ha belül a menüövben XT re állítom akkor a chip/konfig menüben vissza áll RC re. RC az nem rezonátor? Nekem quartz-om van... most 4MHz. Szóval akkor XT kell legyen... de akkor kívül mért RC. A projekt menüt beállítottam közbe csak nem mentettem rá.
Itt van pár módosítással.
betöltöttem a pic be, de nem üzemel. Kiírja hogy - Fordulatszám: 240 és mereven áll. jelenleg a RA3 lábon egy nyomógomb van amivelé tudom imitálni a bemenő jelet. 10Kohm van a 5V-on és 1k megy a lábra amúgy testel. Hogyan kell erre az állapotra beállítani, hogy nyomásra adjon jelet. Mert ha jól értem, most egyből 1az értéke a lábnak az áramkör szerint és akkor lesz nulla, ha nyomom a gombot. Így a programot is át írtam, vagyis a feltétel nem "portA3 >0 hanem =0" akkor adon össze RPM+1, és a végén "RPMki" változóban tárolja.
Akkor egy kis segítség.Amíg fejleszted a programod,a config beállítások lényegtelenek.Kiválasztod a pic-et,beállítod az órajelét és kezdheted a program írását.Az órajel a késleltetések miatt kell a flowcode-nak.A configot égetés előtt ráérsz beállítani.Én pl. megcsináltatom a hex-et,beolvasom az égető progiba és ott állítom be(legtöbbször csak kiolvasom a picből).Természetesen ha egyből a picbe küldöd,akkor már a flowcode-ban be kell állítani.
Ahogy látom,fordulatszám mérőt szeretnél készíteni.Tanácsom,a megszakító jelét RB0/INT-re vezesd. A rutinjában növeled 1-el és kész.Az időhöz TMR1-et használj,1:8-as osztással,de ezt még be kell állítani a 4 ütemű,4 hengereshez a következő C kóddal: tmr1l = 0x84; tmr1h = 0x6D; Ekkor 0.3 sec-ig mér,hacsak nem tévedek. 
Biztos jó megoldás, csak nem nekem....
Ha később módosítanom kell akkor gondban lennék. Más: A megszakítás nem úgy működik ahogy gondoltam. Ha lépésenként megyek végig rajta teljesen mást csinál mint ahogy elvileg kellene neki. A valóságban pedig megint mást. Alapban nem értem, hogy írhat ki a fordulatszám értéknek, ha nincs bemenő jel, illetve a port értéke nem 0 Csináltam kis led kapcsolgató programot, hogy megtudjam, hogyan kapcsol ez a program. Az jól megy, vagyis bitet ad be. Ledet fel-le kapcsolja... Tehát az alap program nem számlál. Reset nem lesz 1 így nem lép ki a ciklusból, így nem is ír ki semmit, vagy hirtelen leszalad és valami fals értéket kidob. Szóval nem számlál. Ennek 1 oka lehet, hogy a megszakítás nem fut a háttérben a valóságban. Különben ha futna a nullát legalább ki kellene írnia. De ez vagy össze vissza számokat ír ki, vagy semmit, kivéve a szöveges részt az statikusan oda van ragasztva.
Az INT-et azért ajánlottam,mert mire odaér a program,hogy kiolvasd,lehet már meg is szünt a jel.
Csak az RB0 tudom használni az INT-et?
Azon van az LCD jelenleg. RB0-5 ig. Ilyen lassan futna le a program? 250ms ról van szó. Ehhez képest 4Mhz az órajel. Ha egy utasítás1 10 órajelig csinál akkor is több ezerszer le kell futnia 250ms alatt. Rosszul gondolom? Amúgy azt nem értem, hogy ha megy szimulációban jól, akkor miért nem megy a valóságban. simpi Módosítottam a TMR0-t a linkek alapján. lényegében a összeadás került máshova benne. Most picbe égetve 60at ír ki. statikusan, holott 0-t kellene. Nem értem miért. Ha a láb fel van húzva 10Kohm-al + ra, akkor jól tudom, hogy 1 az értéke mindig annak a lábnak? Ha igen, akkor a feltételben akkor kell számolnia, ha értéke=0 val, vagyis le testelem. Majd addig nem lép tovább amíg értéke ismét 1 lesz.
Ok.
De nekem külső quartz van... vagy ez nem arra vonatkozik? ---------------------- Közben módosítottam fel töltöttem és működik... va....eee. Szóval az ott nem azt jelenti, hogy külső vagy belső...
Na tesztelve lett a kocsiban.
Működik, csak abszolút semmi köze a fordulatszámhoz. Össze vissza ír ki számadatokat.
Közben agyaltam és sikerült.
Letesztelve a kocsiban. A fura az, hogy a matematikának ellentmond. 2 jel jön be fordulatonként. 1/perc esetén 60as osztás, illetve felszorzás kell. Ezzel szembe, a mérési idő 1041Hz vagyis a program ennyiszer futna le 1mp alatt ha a timer számlálója 1041re lenne megadva.(ez volt a legközelebbi a 100 ms hoz) Ezáltal elharmadoltam az időt. 347 ig számolt. Ez alatt bejövő jelek számát 90nel kell felszorozni, hogy jó értéket adjon. A valóságban 335ig számol és 50el szoroz. Ezzel mér pontosan. Feltételezem, ezek az eltérések a program lefutásából adódnak. Így ha telítódik a program akkor ezzel kell majd variálni. A vicc hogy 4Mhz-en fut úgy a program mint a Parsicban írt programom 20Mhz-en. ----------- Még egy érdekesség. Ki kellett vennem a ciklust, mert azzal állandóan hülyeséget adott vissza. Mivel a timer be kiugrott, elvégszett egy összeadást, és vissza ugrott... A program léptetésnél vettem észre.
Üdvözletek!
Ide írok, mert nem tudom, hogy a progi , vagy a pic hibája : 16f877 -ről van szó, eddig tökéleten működött a progi, de most az egyik pillanatról a másikra nem ír a pic a saját eepromjába, és a meghatározott címekről mindíg 0 -t olvas ki .Sajnos most épp csak 1 panelem van ,és smd a pic, úgyhogy feleslegesen nem cserélgetném. A progiban állítottam el valamit vagy tud így elhalálozni a pic saját eepromja???
Igen, most olvastam, és tényleg elírtam.
A pontos számítás: Amit parsicban is kellett használni... Pl: 6000 1/min 6000 fordulat*2jel/ford=12000jel/ford / 60s= 200 jel/s Ezt kellett vissza, felfelé számolni a másodperc annyiad részére leosztva amennyi a mérési idő. Vagyis ha 250ms (1/4es sec) akkor a jelek száma RPM*4*60/2 Vagyis RPM*120 De a mérési idővel lehet variálni. Ez Parcicban így volt. Mert minimum 2ms a mérési ciklus legkisebb léptetési ideje. vagyis ott 125ig elszámolva kapod a 250ms ot. Flowcode-ban más a helyzet.(sokkal jobb) Itt a Timerben meghatározott Hz-t tudsz megadni, és abból kell vissza számolnod. Most 1041hz=1mp. Vagyis ha jól értelmezem, ezzel a frekivel indul el a program. Az 1/4ed ideje 1041/4 vagyis 260.2 ig kell elszámolni, hogy 250ms ot kapjak. Mivel elég a 1/3ad másodperc is, 347 ig kell számoltatni. (normál esetben RPM*3*60/2 képlettel számolható így a fordulatszám. vagyis RPM*90. Ez volt a kiindulás.. Érdekes módon, a valóságban ezzel a tematikával 1000nél 1900at mutatott. Akartam számolgatni az eltérést, de parsic-os tapasztalatból kiindulva, gondoltam, hogy a program lefutásának, idejével csúszik el, de nem ért annyit, hogy kiszámoljam. Van referencia, bemért stroboszkópom amin hiteles a fordulatszám mérő. Addig változtattam a szorzáson és a számlálón amíg jó nem lett. Így 335ig számol 1041Hz-en és 50es szorzása van. Ezzel most 6000nél is pontos. Nem beszélve, hogy sokkal szebb mikor 50esével(50-100-150...) léptet és nem 60-120-180-240. Ha még nem tettem, köszönöm, hogy felhívtad erre a programra a figyelmemet. Sokkal tágabbak a lehetőségek, mint a parsicban. De nem felejtem el azt sem. Sok dolog abban tized annyi, idő alatt megoldható. Egyszerűbb. Ez viszont sokkal szolgáltatás gazdagabb. Köszi, még1szer.
Nem akarlak meg ijeszteni, de valahol olvastam, hogy korlátozott a pic eepromjának írási mennyisége.
Persze ez a szám nem kicsi. Valahol olvastam régen, hogy egy program folyamatosan használta az eepromot, vagyis szinte minden lefutásnál újra és újra beírta az értéket. Ha ezt csak 250ms onként teszi meg is akkor 1 nap alatt hányszor írja újra... Ott egy tanács az volt, hogy kikapcsolás előttre tervezzék az eepromba a tartalom letárolást, ha lehet. Még azt tanácsolták, hogy az elektronikába egy kicsit nagyobb kondival, lassítsák a leállást, és egy jeladó lábat használva akkor tárolja csak el az adatot, mikor a láb leesik 0ra a kikapcsoló gomb használata után. De hogy itt volt-e HE oldalon vagy más fórumon már nem emlékszem. Mennyire igaz, hogy korlátozott?, azt nem tudom, nem vagyok villamos mérnök. Én próbálkoznék a beállításokkal, programmal, addig is nem kell forrasztani. Ha mindenen átjutottál és nem jó akkor, csere és próba. Szerintem.
Ezt hogyan érted.
"Tesztkörnyezetnek Paksot használom elég pontos 50 vagy 100Hz-es jelet ad. " Tegyem a kocsit reaktorba?  --------- Amúgy igen, le kell tisztulnia a programnak. A változókkal nincs gondom. Csak más a nevük, de az elv ugyan ez. Lehet veszek új próbapanelt, ha megjön a többi alkatrész, és annak megfelelően más lábra pakolom az LCD-t. Egyenlőre most jól mér, tesztelésnek jó lesz így. Még az LCD-n a jobbra igazítást is ki kell találnom. Mert most balra igazít. Nem beszélve, hogy ékezetes betűket nem ír. Az á helyett y van. Más a karakter táblája az LCDnek mint a programnak. Azt is is ki kell találni, hogy hogyan módosítsam. (Pl ASCii kódokkal?) Vagy van más megoldás? Kommunikációt is ki kell próbálni először 2 pic-el aztán több pic-el. AD bemenetet is meg kell ismerni ebben a programban.
Ez ok.
Így helyeztem el a programban is a szövegeket. A 4db szóköz a fordulatszám értékeinek törlésére kell. Így nem kell az egész kijelzőt törölni és újra mindent kiíratni. Az meg azért kell, mert a flowcode balra igazít. Vagyis ha egyszer mér 900 at aztán 1000 és nem törlöm, akkor utána 900nál 9000 lesz látható. A szép az lenne ha jobbra igazítana vagyis a 0 állapotnál a legszélén jobboldalt lenne a nulla, és onnan növekszik balra ha 2 - 3 - 4 számjegy most ilyen. szöveg: 0 szöveg: 50 szöveg: 100 szöveg: 1000 de szebb ha: szöveg: ___0 szöveg: __50 szöveg: _100 szöveg: 1000 erre pedig változóval feltételt kell csinálni a kiírásba. Szóval jó nagy tartalmú makró kell a kiíratáshoz... Pedig menyivel logikusabb lenne ha a számokat alapból az lcd jobbra igazítva írná ki. Szóval akkor kell egy karakter táblát szerkesztenem külön az LCD-hez és azt indulás után egyből feltölteni? (Az LCD tudja az ékezeteket, csak nem azon a küdon van mint amit a programok ismernek. Parsicnál ASM be bele nyúlva 255(á értéke) lett kicserélve 160 ra és máris ott volt.(például: lcdRXTX2.asm) De ennél nem találtam sehol a szöveget.
Köszi, de nincs "agyoníratva" aeeprom. Bekapcsolásonként max 2 -szer olvassa a pic, és egyszer sem írja, csak ha hiba van , tehát a gyakorlatban egyszer sem, csak én adok meg 2 értéket az eepromba beégetésnél , hogy ne kelljen igazításnál a progit nyektetni. Eddig kb 5x volt írva.
Megoldódott, a pic volt rossz.
Újabb kérdés: Ha wdt -t akarok használni, miután a chipcfg-ban engedélyezem, mit kell még beállítanom a flowcod-ban, hogy működjön?
Megnéztem, de nem találtam választ azon a napon a hozzászólások között.
Akkor konkrétizálom a kérdést: Ha engedélyezem a wdt-t , akkor c-ben be kell írnom a progiba , több helyre a wdt resetet. Viszont delay közben ez nem fog működni. A progi amibe betenném elég kövérre hízott, nagyon sok helyen van benne delay, lehetetlen mindet felosztogatni, és közé rakni a reset -eket. Kérdés , hogy pl megszakításból resetelhető-e megbízhatóan a wdt ?
Írtam egy programocskát ,a szám ASCII konverzióra
a flow szimulációban tökéletes működik (megtalál minden ékezetes karaktert ) de a valóságban csak 4 karakter jó a kijelzőn : i j ö ü de ezek sem ott vannak ahol a szimulációban .
Éppen ez a problémám : a teljes 255 karakterből a kijelzőn csak ez a 4 ékezetes betű értelmezhető .
hol lehet a többi ?
Ja értem ! Akkor nem egyforma karaktertáblájuk van a kijelzőknek ? Vagy csak a kijelzőknek más a karakterkészletük , mint az ASCII kódtáblázat ?
Hali
Altalaban a szabvany LCD-k ezzel a ket valtozattal kerulnek forgalomba. Persze, a gyakoribb a ROM A00 vari, tehat a japan karakteres valtozat. Egyszerubb csinalni egy karakter tablat ami betoltheto a CGRAM-ba, es azt hasznalni. Nekem van ilyen megoldasom C-ben, de nem tudom be lehet-e illeszteni valahogy a FC-be. Akit erdekel szoljon, felteszem ide.
De jó...
Nekem egyikkel sem azonos. Amúgy HEstore -ból vettem. kék-fehér 4x20 Az az egy van. Annak teljesen más a karakter táblája.
Találni a neten többet is,de ITT egy.Ezzel készíthetsz egyéni karaktereket,amit a flowcode lcd kezelő rutinjával betölthetsz a kijelződbe.Egyszerre összesen ugye 10-t.De ezeket a dolgokat megtalálni a kijelző adatlapján.
De itt #891865 írja,hogy csak 4 ékezetes betűt talált,+ egyéb karakterekhez is jó.
off. Hogy lehet beilleszteni régebbi hozzászólást? on.
Hali
Idézet: Egyszerre ugye "0-7 " cimig az ugye csak 8. „Egyszerre összesen ugye 10-t”
8-as számrendszerben írtam.
Mármint persze,elírtam. Köszi simpi.
Mi a probléma,mert szó nélkül lefordul?
|
Bejelentkezés
Hirdetés |
