Fórum témák
» Több friss téma |
Fórum » CCS PIC Compiler
12F683 jó is lesz - arra, hogy minden henger mellé tegyél egyet-egyet, és a mérés eredményét mondjuk másodpercenként egy másik kontroller kiolvassa belőlük Valami nagyobb lábszámú példányt válassz, lehetőleg kvarc oszcillátorosat - mert amit az oszcillátor téved, az direktben jelenik meg a kijelzett fogyasztásban, és ezt tényleg nem nehéz elkerülni.
Majdnem jól számoltad, a kivonás eredménye*16,3/65536 a helyes. Lebegőpontos számokkal számolni ilyen kontrolleren lassú, így ezt a számítást fixpontosra kell átalakítani, de kiindulásnak jó. Idézet: „A 16ms maximumot honnan számoltad?” Négyütemű motor egy hengere ugye minden második fordulatnál végez munkát. Benzint ezen idő alatt végig lehet befecskendezni egy munkavégzéshez, mivel azt a szívócsőbe fecskendezik be, tehát van két fordulatnyi idő befecskendezni minden egyes munkaütemhez. Persze nem szabad elmenni a 100%-os kivezérlésig, mert akkor már nincs tartalék, nagy fordulaton és terhelésen pedig a szegény keverék nem a hosszú élet titka, ezért hogy maradjon még tartalék, 80%-os kivezérlés fölé nem szoktak menni. A motor két fordulatának ideje 7500-as percenkénti fordulatnál 60/7500*2=16ms, ennyi idő tartozna az injektor 100%-os kivezérléséhez, de a fentiek alapján a gyakorlatban nem hiszem, hogy 13ms fölé menne. A hozzászólás módosítva: Júl 22, 2014
Csak egy hengerhez teszek és azt feltételezem, hogy a többi is ugyan annyit dolgozik Vagyis a mért időt megszorzom az egységnyi átfolyási mennyiséggel x4.
Mindenképp külső kvarcos lesz, mert a belső "csak" 1% pontos, de tapasztaltam már (óra projekt) hogy ez bizony nagyon pontatlan tud lenni ilyen kis időszeleteknél. A másodpercenkénti kiolvasást poénból írod, de tényleg így van tervezve Van már egy központi kijelzőm (nokia lcd 16f688-al) amire 1 vezetéken csatlakoznak be a modulok. A ds18b20-ak 1wire kommunikációval ugye csak 1 lábat visznek el, de még maradt bőven szabad. Még tervben van egy rs232 is rá, hogy adott esetben egy adatgyűjtőre küldjem az értékeket. Amúgy nem véletlen tervezem ilyen modul rendszerben! Könnyebb a javítás, ha szükséges illetve ha fejleszteni akarok valamit nem kell mindig az egész rendszert szétkapni.
A 12f683-ban csak egy ccp van. Azt beállítom felfutó élre addig ok. Ekkor kapok egy megkszakítást. De lefutónál hogy lesz jelem?
Mi lenne, ha az egyik bemenetet használnám fel ccp nélkül valahogy így:
Így nem kell összeadni, kivonni stb, mert a timertől pontosan a megfelelő értéket kapom. Illetve ezt még annyival lehet továbbvinni - ahogy említetted is - hogy fordulatszám méréshez a timer1 kinullázás előtt is kiolvasom az értékét és abból meg megvan a teljes fordulat ideje. Vagyis ez így nem pontosan igaz, hiszen a timer1 többször túlfut, de ha kapok egy megszakítást (?) a túlcsordulásról akkor minden egyes túlfutásnál növelek egy változót 1-el és abból + az utolsó nem túlfutott timer1-ből megvan a fordulat ideje.
Hát ha ennyire egyszerűre gondoltad a program működését, akkor végülis működni fog, de hogy iktatsz ebbe bele olyat, hogy kommunikálsz másik kontrollerrel?
Sziasztok!
Az FRC divider-t akarnám változtatni, úgy hogy PLL-t használok. A datasheet szerint először át kell váltani PLL nélküli alkalmazásba, beállítani az osztót, majd vissza állítani a PLL-t. Amennyiben én jól értem felül kéne írni a FUSE-t. Ezt hogy tudom megcsinálni CCS-ben? Előre is köszi!
Ez milyen PIC lenne? PIC24HJ és dsPIC33 esetén a legegyszerűbb PLL nélküli FRC módban indulni, s utána a program elején elvégezni a PLL beállítására vonatkozó beállításokat. Ezeknél a fentiekhez nem kell a FUSE (konfigurációs) biteket bántani.
Az elképzelés kb az 1wire protokollhoz hasonló. Minden modul 1 buszra csatlakozik és amikor adni szeretne megvárja, míg rá kerül a sor. Természetesen addig nem mér semmit.
A fenti módszerrel kb 1mp-ig mérek, majd a mérések eredményének átlagát küldöm a kijelzőhöz. Ez is max 1mp lenne. Összfogyasztás számításnál legfeljebb a mért értéket 2x veszem és így megvan a kiesett idő is. 1mp alatt túl nagy változás nincs a motor életében, legfeljebb padlógázas gyorsításkor, de hát nem egy f1-es autó computerét építem... Aztán majd meglátjuk mit mutat ez a valóságban! Fejleszteni persze mindenképp kell a kódot, hiszen ebben nincs timeout sem, könnyen ki tud akadni a rendszer. A while helyett lehetne fix idejű ciklus is és ha az alatt nincs jel (hiba miatt) akkor megfelelő hibajelet küldene a kijelzőhöz. Mivel nem vagyok profi, ezért lépésenként szoktam mindent csinálni. Ha az alap működik akkor továbblépek
És miért nem úgy csinálod mindjárt, hogy a kommunikáció ideje alatt is tudjon menni a mérés? Értem, hogy lépésenként akarsz haladni, de a hátrafelé lépéseket azért ki lehet hagyni Én inkább I2C buszt használnék. Tudom, hogy a hőmérőkhöz ott van az 1-wire, de az I2C kevésbé érzékeny az időzítésekre.
Idézet: „A 12f683-ban csak egy ccp van. Azt beállítom felfutó élre addig ok. Ekkor kapok egy megkszakítást. De lefutónál hogy lesz jelem?” Mindig, amikor megszakítás jön, átállítod, hogy az ellentétes jelre adjon megszakítást. Két él között eltelik minimum 1ms idő, van bőven idő átváltani. A hozzászólás módosítva: Júl 24, 2014
Azért, mert ezeket a "trükköket" nem tudom MÉG!
Pl ezt az átállítást sem tudtam, hogy bármikor lehet. Sajnos megszoktam, hogy sok dolgot csak 1x indulásnál tudok beállítani, úgy gondoltam, hogy ez is olyan. Így persze sokkal logikusabb is a módszered! I2C-t sem használtam még, de itt az ideje
Mi az, amit csak indításnál tudsz beállítani? Nagyjából bármit bármikor állíthatsz, csak esetleg nincs értelme a későbbi állításnak, mert ugyanazzal a beállítással kell üzemelnie végig.
Ez egy kicsit off. Az injektor jelét hogy figyeljem? Illesztésre gondolok. Sima fesz osztó elég?
Elég lehet, 4k7 menjen az injektor vezetékére, 2k7 a földre, 2k7-el párhuzamosan 4V7 zéner, és így mehet a kontroller lábára.
De inkább leválasztanám optocsatolóval. Mondjuk 4N35 típusú, injektorral párhuzamosan bekötni a ledjét egy 390 ohm-os ellenállással, kontroller lábát 470 ohm-mal felhúzni tápra, és az opto tranzisztora meg húzgálja lefelé. A hozzászólás módosítva: Júl 25, 2014
Az opto lesz a nyerő. Közben megnéztem és talán közveltel a computertől tudom levenni a jelet. Gondolom utána nincs "erősítő fokozat" stb
Készül a projekt, 16f628a-val csinálom az első verziót. Az injektor nyitást már fogom tudni mérni, de szükség lenne a sebesség adatra is. Erre egy pici reed relé van az órában, azt fel tudom használni. Viszont ötletet várnék hogy tudnám ezt megtenni? Timer0-t fel lehet erre használni valahogy?
Csinálsz külső megszakítást a reed relé segítségével, és a megszakításkor felírod a timer pillanatnyi értékét, majd következő megszakításkor az aktuálisból szintén kivonod az előzőt, és így tovább ugyanaz az elv, mint az injektoroknál. Úgy kell belőni a timert, hogy pl. 5km/h-nál már ne csorduljon túl két mérés között, akkor kellően nagy tartományban tudsz mérni úgy, hogy nem kell a túlcsordulással foglalkozni. Most hirtelen ez jutott eszembe.
Mechanikus meghajtású a sebességmérő?
Közben találtam egy rajzot, amin azt mutatja, hogy a motorvezérlő 9-es lábára valami vehicle speed sensor jel megy be. Namost ezt nem tudom, hogy a tiéden is van-e (lehet, hogy pl. csak ABS-el szerelt példányokon van), de hátha onnan egyszerűbb jelet szerezni, mint a reed reléről.
Viszont azt is látom, hogy hülyeség lett volna minden injektoron külön-külön mérni a befecskendezési időt, mert ez nem szekvenciális rendszerű, a négy injektor egyszerűen párhuzamosan van kapcsolva
Megtaláltad az autóm cuccát? Átküldenéd?
Mechanikus az óra, ez egy 2x éves autó... A külső megszakítás az oké, de melyik timerrel foglalkozzak hozzá? A timer1 biztosan (többször is) túlfut, mivel az az injektorhoz lesz beállítva. Bár gondoltam arra is, hogy számolom a túlfutások számát és abból kapok meg egy brutál pontos sebesség adatot (de minek) Illetve ami inkább érdekes, hogy mi van, ha a két megszakítás egyszerre történik? Nem tudom pontosan milyen jelmennyiségem lesz az órától, de az biztos, hogy 1 sebességjel megszakítás között lesz több injektor jel. Na most ha épp sebesség miatti megszakítási rutin közben jön az injektoré is akkor átugrik annak a függvényére vagy hogy zajlik ez a pic-ben?
Csatolom, hátha másnak is hasznos lesz még.
Közben megnéztem, hogy a Capture mód is a Timer1-et használja, de ha lekezeled a túlcsordulásokat, akkor jó lesz a Timer1 is. Ha két megszakítás egyszerre, vagy nagyon rövid időn belül történik, akkor abban a sorrendben lesznek kiszolgálva, amilyen sorrendben a kezelésük következik a megszakítási rutinban. Namost CCS-nél a sorrendet nem tudom, hogy csinálja, mert ugye külön rutinok vannak a megszakítási forrásokra, és maga a fordító pakolja egybe azokat. Viszont esetedben nem kötelező a CCP megszakítási kérést valódi megszakításból kezelni, hanem lehet a főprogramból is, ha tudod biztosítani, hogy le lesz kezelve mondjuk 1ms-on belül. Tekintve, hogy a TRM1 regiszterek áttöltése a CCPR1x regiszterekbe hardveresen történik, nem veszítesz semmit a pontosságból, ha az eseményt csak később kezeled le. Ami a lényeg, hogy még az előtt lekezeld, mielőtt a másik irányú élváltozásra kellene reagálnia a kontrollernek. Ezt talán már most is le tudod mérni, hogy mennyi az injektorok minimális nyitási ideje, és akkor azzal tudsz a továbbiakban tervezni.
Rendeltem 16F876A-t, csak hogy legyen elég I/O láb
Ebben viszont már 2 CCP modul is van, szóval akár külön is lehet játszani vele. Találtam egy kész terméket UTCOMP néven, ebből sok újabb ötletet is merítettem, meg persze az igények is változtak Természetesen a program is bonyolódni fog emiatt, ezért ismét lenne kérdésem: Ha valamilyen megszakítást használok, akkor ez miként fog viselkedni a program futása közben? Tehát ha a főprogramom épp az lcd-re ír ki adatot de közben jön injektor vagy sebesség jel akkor gondolom oda ugrik, majd a megszakításhoz tartozó függvény lefutása után ott folytatódik, ahonnan elugrott? Akkor is, ha az lcd kiiratás nem a főprogramban van, hanem külön függvényként írtam meg? Ezek elég kardinális kérdések szerintem. Továbbá nincs ötletem arra honnan tudják a mostani autók pontosan mennyi üzemanyag van a tankban? Mert ugye ha tele tankolom akkor abból könnyen ki tudom számolni az (aktuális fogyasztási adatoknak megfelelően) a még megtehető távolságot. Bár lehet ezt a funkciót egy "full tankolás" nyomógomb segítségével oldom meg, mert a tankba nem nagyon szeretnék szerelgetni... A hozzászólás módosítva: Aug 5, 2014
Idézet: „Tehát ha a főprogramom épp az lcd-re ír ki adatot de közben jön injektor vagy sebesség jel akkor gondolom oda ugrik, majd a megszakításhoz tartozó függvény lefutása után ott folytatódik, ahonnan elugrott? Akkor is, ha az lcd kiiratás nem a főprogramban van, hanem külön függvényként írtam meg?” Igen, miután a megszakítási rutin végzett, pontosan onnan folytatja, ahol épp tartott a megszakítás előtt. Idézet: „Továbbá nincs ötletem arra honnan tudják a mostani autók pontosan mennyi üzemanyag van a tankban?” Sehonnan. Van egy szintjeladó a tartályban, mint 30 évvel ezelőtt is, és amit az mutat, abból számolják ki. Az egy dolog, hogy kiírják literre pontosan, de semmi sem garantálja, hogy az tényleg pontosan annyi. Lehet kalibrálni, hogy a tartály formáját kompenzáljuk, és ne legyen az, hogy 100km alatt elfogy negyed tank, majd utána 200km alatt fogy el a másik negyed tank, de nincs ott semmi ettől komolyabb. Illetve vannak gyártók, akik csinálnak olyat, hogy tankoláskor eltárolják, hogy meddig tankoltál, és utána a pillantnyi fogyasztás alapján hajtják meg a szintjelzőt is a következő tankolásig, de ez csak ilyen szellemi önkielégítés, és amúgy totál haszontalan, sőt szerintem inkább káros, mert még egy benzinszivárgást se veszel észre időben, hogy valami történt, és jobban fogy az üzemanyag, mint kellene, hanem egyszercsak megáll a verda, miközben azt mutatja, hogy félig van a tank.
Az első jó hír, bár eleve így logikus. Lcd kíratásnál, 1 wire kommunikációnál és A/D konverziónál meg gondolom nem okoz galibát az a pár ciklus "kimaradás"
Az üzemanyag szintjelzéshez amúgy is bőven sok a 10bit.
Végre megjött az usb-s szkópom, gyorsan néztem is egy sebesség jeladó adatot.
Az órában egy reed kapcsolgat testre, egy fordulat alatt 4 jel van. A mellékelt kép kb 104-105km/h óra mellett készült. Gondoltam első lépésként megcsinálom az aktuális sebesség kijelzését, így legalább lesz némi tapasztalatom Mérni jelkezdettől jelkezdetig gondoltam és mondjuk 500ms-enként iratnám ki az aktuális sebességet lcd-re Ja a kérdés lemaradt... Szóval vegyük 200km/h-nak a max sebességet, akkor durván 7ms a legrövidebb jel. Viszont lassú haladásnál meg elég nagyra jön ki a periódus idő, durván 1400ms. Jól számolok? A hozzászólás módosítva: Aug 11, 2014
Köszönöm a segítséget így már működik ha minde egyes lcd-re írás után újra engedélyezem az interruptokat.
De van egy újabb kérdésem most egy új projektbe kezdtem másik procival(16f1936) és nagyobb kvarccal ami 10Mhz-es. A problémám hogy a delay-ek sokkalta rövidebbek szkóppal megmérve konkrétan pont a negyede mint amilyen hosszúnak lennie kellene. HS fusebitnél máshogy kell beállítani az órajelet? Így néz ki a kódom eleje:
Köszönöm a gyors segítséget így már minden rendben!
Megcsináltam egy régebbi projektem próbapaneljával a sebességmérést. 16F688 és 1602-es lcd van benne. Az A1 lábat használom inputként megszakítás nélkül. 4MHz-en fut a pic.
A ciklusfigyelést egyelőre hibakezelés nélkül oldottam meg így:
A főprogram pedig így néz ki
Ez így működik is, természetesen nem hibátlanul. Lassú haladásnál több mp amíg frissül a kijelzőn az adat, mivel olyan nagyok a periódusidők és hát én 10-nek veszem az átlagát. Ezt majd átalakítom. A gondom inkább 100km/h felett van. Itt már nagyon rövidkék a periódusidők és valahol kifutok a mérésből ezért. Feltételezem nem az órajel kevés, hanem az lcd-re iratás tart sokáig. Mivel (még) nem megszakítással oldottam meg a figyelést ezért ha csak ez a gond akkor ez is meg lesz oldva a nagyobb pic-el. Honnan tudhatom biztosra, hogy tényleg ez a gond és nem az aritmetikai műveletekkel dolgoztatom agyon a pic-et?
Szimulátorban meg tudod nézni, hogy egy-egy művelet meddig tart. Így szemre az az osztás is eltarthat sokáig, a printf sem az a sebességbajnok megoldás, plusz még az LCD-re írás is ott van. Nem véletlen vannak a megszakítások és a CCP modul kitalálva, használd azokat. Ezt a feladatot azok használatával röhögve tudnia kell a picnek 4MHz-ről is.
Több probléma is volt, de megszakítással úgy néz ki már jól működik a cucc
Legalábbis a sebesség mérés... Most 4MHz-en ketyeg a pic, a timer1 8-as osztásra van beállítva, így 524ms a túlfutása és 8us a felbontás. Szeretnék átköltözni a nagyobb pic-re (16f876a) amiben már 2 ccp modul van. Az 1-es méri majd a sebességet a 2-es az injektor nyitást. Ha jól gondolom mindkét modul a timer1-et használja, tehát NEM tudom más előosztóval beállítani a ccp1-nek és a ccp2-nek. Ez esetemben talán nem is baj, mert az injektor maximum jele ugye 16ms (timer1=2000) a minimum meg gondolom azért legalább 1ms (timer1=125) szóval talán még így is elég szép felbontásban tudom majd mérni. Viszont mivel még egyéb más műveletet is akarok végeztetni szegény processzorral ezért szeretném az órajelét 20MHz-re venni. Így viszont a timer1-em is szépen átállítódik. A megoldás a külső órajel lenne. Alap esetben a belső 4MHz esetén ugye 1MHz volt amit 8-al osztottam. Viszont ha külső órajelet használok akkor nincs osztó? Mert ez esetben ugye 1MHz/8-as, vagyis 125khz-es jel kell. Jól gondolom?
Miért nem állítasz be előosztót a Timernek? Ha beállítasz egy 1:8 előosztót, akkor 500kHz-el fog számolni (ha 20MHz a kvarc órajele), akkor 1ms alatt 500-ra ér a Timer. 20ms-nyi injektor nyitást még mindig túlcsordulás nélkül tudsz így mérni. Sebességet mondjuk nem, de tanuld meg lekezelni a túlcsordulást
|
Bejelentkezés
Hirdetés |