Fórum témák
» Több friss téma |
Fórum » CCS PIC Compiler
Én ilyen esetben felveszek egy string változót és sprintf(s,"bla-bla"); függvénnyel írom bele a konstans szöveget. Ez nem járható út neked?
Eddig is hasonlóan csináltam, csak sprintf helyett strcpy-t használtam.
Ha sehogysem jön össze, akkor így csinálom, de az egész program nagyon hosszú, tehát mindenképpen a legrövidebbnek és a lehető legáttekinthetőbbnek kell lennie.
A szöveget le kell másolni a RAM-ba. Flasht szerintem nem tud pointerezni.
sysy
Sziasztok!
Itt a karácsony és a CCS fiúk küldtek ajándékot: 4.058. Tudom, hogy nem a legfrissebb, de ajándék compilernek ne nézd a bitjeit. Itt van!
Wáow!!!
Hálás köszönet a cuccért! Épp valamelyik nap akartam volna pont kérdezni, hogy nincs-e friss "csomag", csak valamiért kiment a fejemből egy picit...
Szevasztok!
Letöltötem innen a CCS compiler-t (4.58), de nem akar elindulni. Registration file error, CRG file is too old hibajelzés jön rögtön indításkor. A 3.2-es CCS crg fájljait másoltam be az új alá de ez így nem OK. Tudna nekem valaki segíteni, hogy hogyan tovább. Köszi! P
Ooops!
A 3.2 regfile tényleg régi. Itt van egy frissebb.
Hali!
Köszi szépen a frissítést! Müxik! Üdv: P
Sziasztok !
Feltettem a 4.058-as verziót.Próbálgattam a példaprogramokkal és a PIC16-osokkal szépen műxik, de a 18-asokkal "Access violation at address 0137660C. Read of address 0137660C" hibaüzenettel kiakad fordítás közben. Találkoztatok már ezzel?
Srácok!
Az mplab8.0 felrak egy css compilert, amit ki lehet választani a project-nél, a cssc.exe is megvan, működik. Mégis ez a hibaüzenet fordításkor: Executing: "C:\Program Files\Microchip\Third Party\PICC\Ccsc.exe" "elso.c" +FM +DF +LN +T -A +M +Z +Y=9 +EA Error: The selected compiler: "PCM" is not installed on this PC Mit csinálok rosszul? 
Letöltöttem azt amit ide felraktatok, minden ok.
Megoldódott a problema. 
Sziasztok!
Tegnap a CCS ifjak itt jártak és hoztak egy kis ajándékot. Nem fogjátok kitalálni, hogy mit! PCWHD_4.065 verzióját. Megigértem nekik, hogy közkincsé teszem. A frissítéshez szükséges kisegítő program is benne van a csomagban. Íme. Bővebben: Link
Hali,
Egy olyan problémám van,hogy soros portoto szretnék használni egy PIC18F2550-en. De ha feltöltöm rá a tesz progimat (persze előtte újrafordítom a procira) ami más PICekkel működik csak mindenféle összevisszaság jelenik meg a PC terminál ablakjában. Valami olyasmi minta baudrate probléma lenne,de ugylátszik a kódban minden rendben mégsem müködik. Mégis olyan érzésem van mintha az oszcillátor beállítással lenne valami baj. A segítsége előre is köszi.
Az usb-s chipek oszcillátorbeállító konfigurációs bitjei másképp vannak, mint a nem usb-s 18F chipeknél. Adatlapban mindent megtalálsz ahhoz, hogy úgy állítsd be, ahogy neked kell.
Szia Potyo
A probléma ugyan az 18F4550-el ugyhogy tuti igazad van.  A beállításokat csatoltam. De 1-2 dolog nem tiszta a az oszcillátor beállítással CCS-ben. Ha tudsz légyszives segíts.
Úgy nemnagyon lehet segíteni, hogy nem írod le, hogy mit akarsz! A csatolt pdf-ben levő rajzhoz hozzá kell még venni az adatlap 25.1 fejezetében a config bitek leírását is, úgy lesz érthető.
Én az ilyet jobban szeretem a forráskódba beírni, akkor nem kell lesni, hogy most CCS-ék milyen beállítást hová tettek. Pl. ezt a sort elhelyezve:
20MHz-es kvarcot a kontrollerre kötve a processzor 48MHz-en fog futni. A fuses.txt fájlban megtalálod, hogy melyik config szó mit jelent.
Bocs a hiányos dolgokért...
Szoval szeretném a 18F2550-et USB-n keresztul PC-vel használni pl.: CDC(virtual serial port via USB) vagy mint HID eszköz.A CCS fordítónak vannak példái erre. A soros portot 'Debug' céllal használnám,addig amig az USB-t fölélesztem. Próbáltam a példaprogramot de nem müködött rendesen. Ugygondoltam soros porton keresztül debugolom,de akkor estem pofára,mert az sem müködik. Idáig soha nem volt a soros porttal problémám és a fordító is normálisan működött kisebb bugoktol eltekintve. Most ezekkel a 2550/4550-es PIC-ekkel került elő a probléma. Utána néztem a beállításoknak nekem is hasonló beállítások vannak.
Engem ez a beállítás is aggaszt: setup_oscillator(); Ha nem állítom be akkor: //Setup_Oscillator parameter not selected from Intr Oscillotar Config tab  Mondjuk ha beállítom: setup_oscillator(OSC_8MHZ|OSC_NORMAL|OSC_31250|OSC_PLL_OFF); De a soros port egyik beállítással sem müxik..... Mit csinálhatok rosszul? Mi lehet elrontva? :no: Nincs ötletem.... :no:
Pedig az ex_usb_serial példaprogram működik rendesen, kipróbáltam. Csak vedd ki belőle a #define USB_CON_SENSE_PIN PIN_B2 sort.
Idézet: „Utána néztem a beállításoknak nekem is hasonló beállítások vannak.” Csak hasonló, vagy ugyanaz? Először indulj el abból, ami biztosan működik, utána lehet kisérletezni. Idézet: „Engem ez a beállítás is aggaszt: setup_oscillator();” De ezzel mit akarsz elérni? ------------------- Egyébként a kész, lefordított hex fájlt mplab-ba beimportálva meg lehet nézni, hogy mire vannak a konfig bitek állítva.
Sziasztok!
Szerettem volna két PIC között aszinkron soros kommunikációt létesíteni (egyenlőre dróton, majd ha az megbízhatóan megy akkor rádión), de nem mondhatni hogy elsöprő sikerem volna. A két PIC egy 12F629 és egy 12F683-as. A méretük miatt esett ezekre a választás, ahova végleg kerülnének elég szűk a hely (tudom, van SMD, de ahoz már vak vagyok  )A lényeg... az adóból kijövö jelet egy MAX232-n keresztül a PC-re kötve az jön ki amit küldök (minő meglepetés) de a vevő oldalon byte-onként továbbküldve egy másik soros portra hogy a PC-n lássam mi jött be, csak az első byte jó, a többi mintha baudrate problémás lenne. Ha adóoldalon byte-onként küldöm az adatokat akkor még úgy ahogy át is jön, de ha 2-3 vagy több byteot akarok küldeni egy csomagban az már nem megy. Adó oldal:
Vevő oldal
Valaki segítsen! Két hete küzdök vele és nem megy. Hogy kell a kódba sortörést varázsolni????
Tényleg úgy tűnik, hogy baudrate probléma. Az adó oldalon álítsál be 2 stop bitet és a vevő oldalon maradjon 1 stop bitre állítva. Az RS232 minden startbitnél újraszinkronizál és csak a stop bitig kell tartani a szinkront. Ezt, úgy látszik, hogy tudja a renszered. Lehet, hogy belső oscillátort használsz? Kvarcról nem kellene ilyen rossznak lennie. A kódba vesszőt
A vevőoldali picben inkább olyat csinálj, hogyha bejött mondjuk 5drb 'A' karakter, akkor begyujtasz egy ledet. Ezzel tudod felismerni, hogy a fogadás jó-e. A 12F-ben nincs hardveres soros port, ezek a beépített függvények meg ki tudja, mit csinálnak. Gyanús, hogy valahogy egymásba futnak a bitek.
Köszi, ezt már próbáltam. Betettem 2-3 "U"-t, aztán egy STX-et. Az STX után jött volna az érdemi adat. A jelenség ugyan az, byteonként küldve jó, de a két byte közti szünetbe rádión már beleszemetel.
sysy: igazad van, eleinte belső oszcillátorral hajtottam a dolgot épp a kevés láb miatt, aztán lemondtam egy két csingilingiről, hátha... de kristállyal sem nem megy. Szerintetek ha legalább vevőoldalra beteszek egy 16F87-et - annak már van USART-ja - valamelyest javulhat a helyzetem? Igencsak kezdő vagyok a dologban (a PIC-ben os és a CCS-ben is), a PIC USART-nak van puffere, vagy nekem kell foglalni?
Egy olyan pic-el, aminek van hardveres usart-ja, máris sokkal jobb helyzetben vagy.
A hardveres usart-nál van 2 bájtnak hardveres puffer, de a többi adatnak neked kell foglalni. Ez a baj az ilyen CCS féle beépített rutinokkal, hogy elfedi a hardvert annak korlátaival együtt...
Asszem megvan a hiba!
Ha jól értelmeztem a dolgot: A vevőd leveszi az első karaktert, majd elkezdi echo-zni a PC felé a levett karaktert. Adás közben a vétel megáll. Majd miután elküldte a PC-nek a karaktert, akkor fog megint levenni egy újabb bejővő byte-ot. Ez alalatt veszhetnek el bitek. Szerintem csinálj egy hosszú vevő buffert (amennyi kell) és annak megtelte után küldi el a PC felé a buffer tartalmát. Eközben az adó vár egy kicsit, hogy biztosan elküldésre kerüljön az egész buffer tartalom. (Bust üzemmód). Nekem nem voltak problémáim a soros kommunikációval. HW usartal simán megy 115200 baud, míg mellette 9600-al ment az SW usart is. Igaz, megszakítással csináltam meg azt is.
Ezaz, nem tudni, hogy ezek a beépített függvények mit csinálnak. Nem lehetetlen szoftveresen küldeni és fogadni is adatot egyidőben, csak ahhoz át kell gondolni az algoritmust, és azt azután finoman le kell programozni, igencsak ajánlottan asm-ben. Kell hozzá egy timer, aminek a megszakításában végezzük a műveleteket. Ezek a beépített függvények meg gondolom valami delay() tipusú dolgokkal működnek, aminek a használatáról egyébként is le kellene szokni...
Köszönöm, valami ilyesmitöl tartottam.
Összedobok egy hw-usartos verziót, ha az pufferel megoldódik a nyűgöm. Bár ahogy Topi cikkében láttam (vezetéknélküli kommunikáció 434Mhz-en) Ő sem használta a hw usart-ot, vagy legalábbis nem az Rx Tx lábakat használja, hanem egy-egy mezei IO lábat, és neki érdekes módon tán működött. Lehet hogy egyszerűen csak szerencséje votl? A végsö cél tulajdonképpen ay lenne hogy, max 2 byte-ot át tudjak biztonságosan küldeni, a legroszabb esetbem 80ms-es időnklént (ez a max küldési gyakoriság) Olvastam fórumokon hogy a rádió "élesztéséhez" illik kiküldeni egy-két "U"-t(10101010). Tetszett volna a megoldás hogy UU STX Adat ETX, ez 2400-on még épen belefér az időbe.
Hát pont ez a szép az egészben, hogy nem tudni, mit is csinálnak a belső függvények. És nem is kell tudni róluk semmit. Azért programozgatunk C nyelven, hogy ne kelljen assemblerrel kinlódni. Én programozgattam vagy 20 évet mindenféle asm-ben, de amikor megnézek egy CCS kódot befordítva a PIC-be, még mindíg meg kell, hogy állapítsam, a CCS fiúk értik a szakmájukat. A delay() tipusú dolgok, meg egészen korrekten meg vannak írva. A SW usartok működése közben pedig illik mindenféle más dolgot letiltani. Ha az RX láb egy megszakítást generáló láb is egyben, akkor még a start bitet sem kell figyelni, mert szól, hogy megjött. Innentől kezdve a delay() típusu dolgok pontosan elegendőek egy byte levételére. A RTOS pedig félkézzel lekezel két SW usartot.
Uff. sysy
Szerintem nem kell ekkora feneket keríteni a dolognak. Nem is kell usartot használni, mert ugye, a rádiós átvitelnél nagyon ajánlatos az NRZ kódolás. Ennek a legszebb példája a Manchester kódolás. Ez C-ben néhány sor csupán. Úgy a kódolás, mint a dekodolás oldalán. Nem is beszélve arról, hogy a net tele van jobbnáljobb példaprogramokkal. Gondolj csak bele, ha az átvinni kívánt információd 0x00 0x00. Ezt simán leveszi az vevőd, ha kimarad az adás valamilyen okból. ( pláne, ha nem is ezt akartad küldeni). A profik mindíg NRZ kódot használnak! Szart mindenki tud csinálni. Megbízható átvitelt nem. Te se add alább.
sysy
Oké, RTOS használatával természetesen nem probléma a dolog. Csakhogy a kezdők igen nagy részének fogalma sincs róla, mi az az RTOS, másrészt az ilyesmi használatával egy csomó számítási teljesítményt és memóriát pazarolunk el. Persze ide lehet beírni, hogy veszek nagyobb/gyorsabb chipet, de mindannyian látjuk, hogy hol tart a pc ipar.
Én sem azt mondom, hogy ne használjunk magas szintű nyelvet, mert tényleg gyorsabb, kényelmesebb a fejlesztés. Sőt ha néhányszor megnézzük, hogy mit mire fordít a fordító, és azután ennek figyelembevételével programozunk, akkor a generált kód sem lesz sokkal rosszabb, mint egy jól megírt asm kód (mert asm-ben is lehet rossz kódot írni). De ahhoz, hogy ezeket a függvényeket összetettebb feladatoknál is tudjuk használni, ahhoz tudni kellene, hogy a függvények hogyan működnek. Továbbra is azt mondom, hogy a kontroller az nagyrészt elektronika, és csak kisrészt programozás, ismerni kell a kontroller lehetőségeit/határait. Ahogy egyik tanárom mondta az egyetemen: két termék közül nem az a jobb, amelyik magasabb órajelen dolgozik, hanem az, amelyik alacsonyabb órajelen tudja ugyanazt...
Hehe... ez igaz. Ezt az aranyköpést néha kölcsönkérhetem?
Persze, neked is igazad van. Ha whalaky tényleg 2 byteot akar átküldeni 'A' pontból 'B' pontba, akkor nem szabad ágyúval verébre lövöldözni. Erre a feladatra pedig van C nyelven megoldás (mint tudjuk). Ha nagyon élére akarjuk állítani a biteket, akkor valóban le kell menni ASM-be. De itt nem hiszem, hogy kiélezett lenne a feladat. :nevetes1: A RTOS-t nem Whalaky-nek ajánlottam, csak mintegy jelzésképpen, megemlítettem, hogy a járatosabb kollégáknak is eszébe jusson: jé! tényleg. sysy |
Bejelentkezés
Hirdetés |
