Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Ja most esett le, hogy itt SPI-s A/D-k illesztéséről volt szó, én meg PIC<->(PIC A/D-je) illesztésben gondolkodtam. Na mindegy, lehet válogatni!
Igen, de itt konkrétan egy készülékben van a 4AD, ez csak egy 4 csatornás teljesen független DVM akarna lenni így a távolság itt teljesen lényegtelen és ugye így csak
a 4 ad meghajtó a 4 AD és 1 pic szükséges (és persze az optok) Watt: Esetleg - ez - is érdekes lehet persze ez sem olcsó.
Nem rossz, és érdemes kiszámolnod, hogy a megfelelő sebességű optók mennyiből jönnének ki, mert lehet, hogy nem is lenne sokkal olcsóbb. Viszont most nem néztem meg, hogy ezek nyitott kollektorosok-e, azaz fel lehet-e építeni plusz alkatrész nélkül az illesztést.
Igen én is rá gondoltam, közben nézve a költségeket ezen is elgondolkoztam: pm328 4 1/2 digites DVM modul
Persze, igazad van és köszönöm a segítségedet!!!
Csupán kíváncsi voltam hogy mennyiből is jön ki így és mennyiből úgy a dolog. Meghát az építés öröme ott kimarad és a testreszabhatóság is csorbát szenved, a pic-es vonal sokkal jobban fejleszthető, bővíthető!! Mégegyszer köszönöm az építő hozzászólásokat, segítséget!
A BCD-be konvertálás/kiírás természetesen a printf()-fel így most egyszerű és eléggé el is van nagyolva. A printf() a C-ben gyári könyvtári függvény, így azzal nem kell foglalkoznia a felhasználónak, hogy a decimális kiírással bajlódjon, ha gyorsan akar eredményt elérni. Cserébe viszont megkapja, hogy amint a printf()-et hozzácsapja a programhoz a flash kihasználtság megugrik rögtön vagy 50%-kal a 16F882 esetén (2Kword-je van), ami most a breadboardomban van. Saját, célirányos átalakító és kiíró rutinokat írva sokkal takarékosabban is ki lehetne hozni.
A timer1 megszakítása azért van engedélyezve, mert kevésnek találtam a 16 bites szóhosszt, ezért minden egyes timer1 túlcsorduláskor egy harmadik byteot, a TMR1U-t növelek szoftveresen. A TMR1U:TMR1H:TMR1L egy 24 bites értéket ad így. Belső 8MHz oszcillátorról járatva a motyót, 8-as előosztást alkalmazva 67 másodperc lesz a 24 bites számlálólánc periódusideje, ami már bőven sok is, de 16 bitnél még 262ms lett volna, ami meg kevés, mert ha jól számolom, az 1.7m-es kerékkerület mellett a 16 bit csak 23km/h felett lenne használható. A 24 bites értékekből képzek különbséget (ez a sebesség reciprokával arányos lesz), valamint számolom az impulzusokat (megtett út). Azt írtam is, hogy a kijelzőre írás előtt nem skálázom a mért értékeket, magyarul nem számolom ki a km/h és a megtett km értékeket a különbségből illetve impulzusszámból. De C-ben ennek a kiszámolása nem jelentene gondot, egy sima értékadással elintézhető, akár lebegőpontos számokkal is lehetne számolni. Véleményem szerint ez már a kozmetikai része a dolognak, a működés lényegét szerettem volna csak bemutatni a példával.
Mikro c-ben szerettem volna írni egy futófényt de elakadtam.
ime a progim: void main() { TRISD = 0X00; PORTD = 0X1; DELAY_MS(1000); PORTD = 0X2; DELAY_MS(1000); PORTD = 0X4; DELAY_MS(1000); PORTD = 0X8; DELAY_MS(1000); PORTD =0X10; DELAY_MS(1000), PORTD = 0X20; DELAY_MS(1000); PORTD = 0X40; DELAY_MS(1000); PORTD = 0X80; DELAY_MS(1000); while(1); } Nem azt csinálja amit én szeretttem volna azt szerettem volna, hogy 0,1,2,3,4,5,6,7 kigyullad elalszik sorba. Amit csinál az 0,1,5,4,3,2 és utána 2 es égve marad. Nagyon kezdő vagyok mit rontottam el? Köszi elöre is Tamás
Elsősorban az a rossz, hogy az a while(1) nem jó helyen van. Az egész kimenet-billegtető kódot be kellene tenni a while(1) utáni blokkba. A kimenetek sorrendjét meg úgy változtasd meg, hogy a LED-ek jó sorrendben villanjanak fel.
Tul azon amit Szilva mondott, a TRISD-t meg kellene vizslatni hogyan kell inicializalni -- azt sem irtad le milyen PIC-kel dolgozol, sot a konfig sincs megadva tehat ez igy akarmi is lehet.
Amugy az X-et ne irdd nagy betuvel a hexa szamok eseteben, egyreszt a konvencio a kis betu, masreszt van olyan C compiler ami el sem fogadja ezt, tehat erdemes mar ideje koran raszokni a helyes irasi modra. Az 1 digites szamoknal is amugy meg erdemes mindket digitet kiirni a jobb atlathatosag erdekeben. Tehat pl: PORTD = 0x01;
Csak egy szösszenetnyi megjegyzés a hozzászólásodra:
Néhány hete én is elkezdtem nézegetni a hi-tech fordítóit, egy-két korábbi CCS-ben írt forrást át is írtam. Nagyon szimpatikusnak tűnik. A printf-hez csak annyit tennék hozzá - de csak azért, mert szóbakerült ez a függvény és egy pár órás keresgélés árán ismerkedtem meg a hi-tech változattal -, hogy más fordítokkal (azokal, amivel én találkoztam) ellentétben "kapásból" nem működik, ugyanis a putch függvényt használja, ami alapból üres, azt előbb a felhasználónak kell megírnia. Ennek viszont előnye a rugalmasabb, célirányos felhasználás...
Így van, ha nézted a forrást, amit feltettem, abban a main.c-ben van benne a putch(), ami az LCD-re ír. Ha soros portra akarnék írni, akkor olyan putch()-t kellene írnom.
Egyébként ez a megoldás nekem így egész természetesnek tűnik, mivel egy mikrovezérlőnél nem igazán lehet "standard output"-ról beszélni. A Hi-Tech manualban pedig egyértelműen le is írják, hogy ez így működik. Nem vagyok egy gyakorlott c programozó, de nekem nem telt pár percnél többe ezt megtalálni a pdf-ben.
Igen, hat van olyan micros fordito, ahol mindenfele parameterekkel, pragmakkal es egyeb wodoo-kkal megadni hogy a printf, puts stb hova dolgozzon. Nekem ez a putc-s megoldas eleg szimpi, bar megjegyzem ha lehet akkor kerulni erdemes a printf-et, es inkabb erdemes egyeb alternativakhoz fordulni, mint pl itoa-val atalakitani a szamot egy bufferbe teve es utana onnan kitenni. Azert gondolnam ezt szerencsesebb megoldasnak mivel egy printf hasznalata esetleg beranthatja az osszes konverzios fuggvenyt a kodba, azonkivul ha hagyomanyos modszerrel dolgozik a printf akkor a formazo sztringet meg mindig parse-olnia kell futas kozben (bar nem lehetetlen a forditas ideju optimalizacioja sem ha a formazo string statikus).
Persze, néztem a forrásodat.
Ügyesebben olvastad a manual-t, mint én  , de azért a Hi-Tech oldalán a FAQs-ben megtaláltam a megoldást...
ok, akkor a PORTD-vel nem lehet nagyobb baj. es a config hogy nez ki?
Configot nem állítotam mert nem tudom micro c ben magagában a progiban hogy kell.
mert ha abba arészében fordítom le akkor hatalmas lesz a file 1KB helyett 46KB. de már fut a fényem de kéne config is késöbbiekben.
Hali! Köszönöm a segítséget. Sajna teszt áramkörre meg a további szutykoláshoz nemvolt idegzetem, kapott egy szép kis gombot az mclr láb aztán kész az egész.
Idézet: „Hali! Köszönöm a segítséget. Sajna teszt áramkörre meg a további szutykoláshoz nemvolt idegzetem, kapott egy szép kis gombot az mclr láb aztán kész az egész.” Remelem azert 20k-val felhuztad Vcc-re  Amugy akkor most mar mukodik?
Sziasztok!
Az a problémám, hogy sikerült zárlatot csinálnom egy PIC jelenlétében. A pic felforrósodott, és minden kimeneten folyt áram. Ez mekkora baj a pic-nek? Válaszotokat előre is köszi! szerk: A PIC 12F629
Elegge nagy problema -- igy roviden. Lehet, hogy meguszta, lehet csak bizonyos reszei szalltak el, lehet csak par het mulva fog furcsasagokat muvelni... En kukaznam es elovennem a tartalekomat...
Hát amikor már nem működik, úgy is visszahozzák, majd azt mondom, hogy valami rosszat csináltak, amitől beállt. (Tudniillik eladjuk...)
most azért 500Ft-ot kidobni, ha még működikik... 
Már én is jártam így, annak szerencsére nem lett baja, mert a portvédő dióda intézkedett. De már az ilyenekben tényleg nem lehet bízni. Esetleg fejlesztésre lehet még használni, csak akkor a vicces, ha fejlesztés közben megadja magát az egyik periféria, és majd nem tudod, hogy miért nem működik jól a program 
Kép: Hivatkozás
A húsvéti nyúlnak már kilóg a nyelve a fáradtságtól, de hozott egy újabb fejezetet a PIC-kwik projekthez(PIC24 programozás assembly és C nyelven). Az új "Mutatók, tömbök, szubrutinok" c. fejezet tartalma: * Mutatók használata C programokban * Mutatók használata assembly programokban * A PIC24 indirekt címzésmódjainak áttekintése * Tömbök használata C programokban * Tömbök kezelése assembly programokban * Karakterfüzérek kezelése * A REPEAT utasítás * A veremtár * Szubrutinok * Szubrutinhívás és a veremtár kapcsolata * Szubrutinhívás és visszatérés assembly programokban * Szubrutinhívás és a veremtár kapcsolata * Rekurzív szubrutinhívás * Veremkeret (paraméterátadásra és lokális változókhoz) * Programterület láthatóság (PSV) * Globális változók inicializálása A korábbiakhoz hasonlóan ez a fejezet sem igényel alkatrész-beszerzést, áramkör építést! Elég hozzá az MPLAB szimulátora.
Gratulálok a nyuszinak! Remélem duracel van benne és kitart a végéig! Ha nem akkor cserélünk benne elemet! :yes: További jó munkát! Köszönjük!
Ha eladasra megy akkor foleg ne azt tedd be. Most anelkul, hogy mely elemzesekbe belemennenk a reputaciot illetoen csak gondolj bele, hogy veszel valamit es az nem ugy mukodik ahogy annak kellene. Pl egy mobil telefon. Es mikor vissza viszed a boltba csak megvonjak a vallukat, biztosan rosszat csinaltal vele... Hat nem tuom, nekem tuti felmenne a pumpam es tobbet attol a cegtol semmit sem vennek. Mindezt egy sor vagy egy fagyi araert...
Sziasztok!
40 lábú pic-et használnék egy feladatra, és miután beterveztem a kapcsolásokat, alig 4 db portláb maradt arra, hogy megjelenítsem a műszerdobozon az aktuállis állapotot. 11 féle állapot lehetséges, amit ledekkel jelölnék. Lenne egy matrica a dobozon a 11 állapottal egymás alatt, és mindegyik mellett egy-egy led. Amelyik állapot az aktív az mellett világítana a led. Hogyan tudom ezt 4 lábbal megoldani? Gondolom valami multiplexer megoldás kéne, csak ilysmit még sosem láttam, hogy van megcsinálva.
Látom, te sem követed a témát, ugyanis nemrég elég mélyen kiveséztük a multiplexelést. Keress rá!
Na visszaolvasgattam, de szerintem nem egyre gondolunk.
Én úgy képzelem, hogy a 4 lábon binárisan kiküldöm, az 1-11-ig az értéket majd az befut valami demultiplexer jellegű dologba, ami ennek megfelelően aktiválja 1db kimenetét. Tehát egy 4-ből 16-ba dekódoló ic kellene... Ha tudtok fejből akkor érdekelne még 3-ból 8-ba dekódoló is. |
Bejelentkezés
Hirdetés |
