Fórum témák
» Több friss téma |
Fórum » CCS PIC Compiler
A problémádra sokféle megoldás elképzelhető. Nem muszáj ágyúval lőni verébre. A legegyszerűbb megoldás az, ha átszervezed a főprogramot.
A feltételvizsgálatokból vegyél ki minden késleltetést, s gondolkodj olyan méretű időszeletekben, amelynek minden késleltetésed egész számú többszöröse (pl. 50 ms). A főprogramban egyetlen végtelen ciklus legyen, melyben a feltételvizsgálatok elhanyagolható időtartamúak, s a ciklusmag végén van egyetlen fix idejű késleltetés. Minden más késleltetés ezeknek a ciklusoknak a számlálgatásából áll. Tehát számlálókat inkrementálsz vagy dekrementálsz, s amikor a kívánt értéket elérted,akkor kell akcióba lépni (LED állapotváltás). Ha megbarátkozol a véges állapotgép módszerrel, akkor gyerekjáték lesz a dolog:csupán az állapotváltások feltételeit kell figyelgetni. ----------------------------------------------------- A következő fokozat majd az lehet, ha az 50 ms-os időszeleteket valamelyik timer megszakításaival időzíted, s a főprogramnak szemaforral jelzed az időszelet leteltét.
Gondolod, hogy ez lehet a probléma lényege?
Sziasztok!
Valaki el tudná küldeni nekem emailben az első oldalon közzétett alkalmazást? (CCS compiler) A link sajnos már nem elérhető. Nem olvastam végig az összes oldalt, csak az utolsó párat és azok között nem találtam.  Köszönöm előre is G
Ez nem warez fórum! Egyébként nem muszáj minden oldalt végigolvasni, azért van a kereső (K gomb).
Sziasztok!
Van egy Nokia 3510i színes kijelzőm, Pic18F2620 -al működik is szépen. Képet akarok megjeleníteni és az lenne a kérdésem, hogy hogyan tudnék egy képből hexa kódot generálni? Van valakinek esetleg ilyen segéd progija?
Ilyesmire gondolsz?
UI: Vagy esetleg:
Gugli mindig segit.
Igen ilyesmire.
Ha Mac vagy Linux/Unix geped van akkor a 'cut', 'od' es 'sed' mar rajta kell legyen a gepeden. Ha nem akkor le kellene toltened a UnxUpdates.zip-et innen es kibontanod az exe-ket valahova ahol elered (pl C:\Windows\).
Utana a command line-bol (xterm linuxon, Terminal Mac-en, vagy cmd Windows-on) futtasd le a parancsokat amiket oda irtam a dollar jel moge...
Rendben köszönöm.
Egy dsPIC33fj256mc710a -t szeretnék használni a fordító legfrissebb verziójával. Az adatlap a 147.oldalon szépen leírja, hogy az órajelet a PLL használatával hogyan állíthatom be, de a fordítóban az eszköz header fájljában a fuse bitek közt még hasonló rövidítéseket sem találok, és egyáltalán olyat sem amiben szerepel valami szám, hogy előosztóra vagy egyébre utaljon (aminek meg van szám a nevében, az egyértelműen brownout reset, és watchdog). A setup_oscillator()-ra sincs olyan paraméter, amivel meg tudom mondani neki, hogy milyen kvarc van rajta, és milyen belső órajelet akarok.
Tud valaki egy helyes #fuses sort adni, hogy mondjuk 10MHz kvarcból hogy születik 80MHz órajel?
Ilyen PIC-el még nem volt dolgom, de gondolom, hogy valami ilyesmi lehet. 
Az alkalmazott fordítótól függetlenül a dsPIC33 sorozatnál az az ajánlott módszer, hogy a beépített oszcillátorral induljon (FRC, 7,37 MHz), s menet közben a programod váltson át PLL-re.
Belső oszcillátor és C30 esetében ez így néz ki:
Valami ehhez hasonlót kellene CCS C-ben is csinálnod.
Ez lett a megoldás. Ez a fordító komolyan veszi a magas szintű nyelv fogalmát...
Sziasztok
Egy ideje próbálkozom egy probléma megoldásával de sajnos segítség nélkül nem jutok előre. Egy darabig azt gondoltam, hogy működik a cucc de sajna nem. 16f628a-val szeretnék rs485 ön kommunikálni egy pc-vel. A pc oldal rendben van, írtam egy egyszerű programot amivel tudom a portot írni olvasni. Csináltam egy rs232-485 konvertert az működik. A problémám az, hogy nem működik a getc() a programomban. Printf(), putc() megy. Itt a kód.(már eléggé le lett egyszerűsítve a sok próbálkozás során.)
A PIN_B3 mondja meg az SN75176-nak, hogy írok vagy olvasok. A PIN_A3 és A2 csak a hibakeresés miatt van benne, hogy egyáltalán eljut-e a prg addig a pontig. A küldött üzenetet a '\n' zárja. a counter csak azért van, hogy lássam hány karakter érkezett. Ha a printf("RECEIVE_OK\n") helyett azt mondom hogy:printf(r_message) akkor nem érkezik semmi a porton. A RECEIVE_OK és a küldött karakterek száma átjön. Egy if-el és egy kimenettel teszteltem az r_message-t:
Ilyenkor "EMPTY" jön amiből arra következtetek, hogy nem működik a getc(). Ugyanez a megszakítás egy másik programban működik. Szerintem az rs485-öt kezelem rosszul vagy valamilyen időzítési gond lehet de kevés vagyok hozzá hogy rájöjjek. Gyúrom már egy ideje de semmi. Ha valaki tudna segíteni azt megköszönném. Üdv. Idézet: „azt mondom hogy:printf(r_message) akkor nem érkezik semmi a porton.” A getc()-re nem tudok mit mondani, de a printf-nél ez így nem elég még a CCS-nek sem. A kiírás formátumát is meg kell adni: printf("%s",r_message) vagy printf("%s\n",r_message).
Szia
Nekem egy másik helyen így működött:
??
Kipróbáltam sajna így sem megy. A baj az, hogy nem íródik semmi a stringbe gets() nél.
Hol van a gets()? En nem talaltam ilyet a kododban...
Bocs getc() és nem a stringbe nem kerül semmi hanem a rec_char -ba.
En tobb problemat is latok a kodban, nem biztos, hogy azok javitasa megoldja a problemad, de ki kell probalni es utana tovabb menni:
1. r_message es ismessage volatile kell legyen! 2. Egy buffer overrun hiba van a beolvasasnal... addig olvasol be, ameddig jonnek a karakterek, igy ha a bejovo string lanc hosszabb, mint amekkor a a bufferben van, akkor a buffer mogotti resz szepen felul irodik! 3. Ugyanigy az strcpy-nel sem ellenorzod a buffereid hosszat! 4. Nincs szinkronizalva az r_message buffered -- tehat pl a foprogramban eppen olvasod azt a buffert, de meg nem ertel a vegeig, es ekozben jonnek tovabbi karakterek, es az interrupt rutinban szepen felul irod... 5. Valtozoid nincsenek inicializalva, mint pl az ismessage vagy a counter es a num_of_char...
Szia köszi a választ.
-A bejövő stringlánc hosszúságát azért nem ellenőrzöm (egyenlőre) mert a pc ről csak olyat küldök ami biztosan rövidebb mint buffer. -A strcy nél a két string egyforma hosszú, kell ellenőrizni? -Lehet hogy rossz a logikám de az ismessage akkor 1 ha megjön a stringlezáró. Amíg ez nem történik meg nem nyúl a főprogram a stringhez. Az üzeneteket én küldöm a pc-ről és mindig csak egyet küldök és várom a választ. -Inicializáltam a változókat de ugyanaz. -Már flag-ek is volatile-k de semmi. Köszi
Az mindegy, hogy neked mi a szandekod, hogy hany karaktert szeretnel kuldeni, igy is ugy is a kliens oldalon kell ellenorizni, hogy minden rendben van-e. Ilyen allapotban a kodod serulekeny es hibalehetoseget rejteget. Nem jo ezt igy berogziteni.
Az is lehet, hogy csak Te, es kizarolag Te fogod ezt hasznalni, tehat kicsi az eselye, hogy valaki majd megprobalja hibas mukodesre hasznalni az eszkozod (esetleg ezzel anyagi javakat szerezve maganak). Azonban ott vannak mas elemek is: Pl a kommunikacios vonalban hiba tortenik es emiatt leped tul a buffered. Vagy mert egy masik alkalmazas "kozbe dumal" es ezzel megzavarja az eszkozod. Vagy mert a PC oldali szoftveredben is ilyen lazan vannak kezelve a dolgok es ott is tobbet kuldesz ki valami hiba folytan... Hibalehetosegeket nehez lenne mindet felsorolni, ezek kozul egy is eleg, hogy a buffer meretet ellenorizd! Jelen esetben max 15 karaktert + a lezaro 0-t tudod elhelyezni, ezt ellenorizni kell... A masik: A ket string nem feltetlen egyforma hosszu, jelen esetben a szamukra fenntartott buffer merete azonos. De ez valtohat a fejlesztes soran. Bizhatsz a sajat ellenorzeseben amit a fenti leirasom alapjan bele tettel, azonban celszerubb lenne strncpy-t vagy memcpy-t hasznalni. Logika: Ellenorzi a foprogramod az ismessage-et, majd bele megy az if agba ha az 1-be valt. Kozben jon egy vagy tobb masik karakter, es a foprogramod futasa felfuggesztodik, es beolvasod a karaktereket es felul irod az r_message-et... Na ezt akartam volt elkerulni, azonban most jobban megnezven a kodot lattam, hogy nem is olvasod ki az uzenetet egyenlore, ugyhogy teljesen mindegy jelen felallasban. Amugy eloszor interruptok nelkul probaldd meg elerni, hogy a karaktert kiolvassa. Ha az mar megy akkor irdd at megszakitasosra.
Teljesen jogosak az észrevételeid. Azért butítottam le ennyire, hogy minél rövidebb legyen a kód a hibakeresés miatt. (Már lehet hogy túl rövid lett
 )
Hosszas szenvedés után úgy tűnik működik.
strcpy(r_message, serial_buffer) helyett:memcpy(r_message, serial_buffer, sizeof (r_message)) lett a befutó. Igaz, hogy ebben benne van az, hogy hány bájt legyen másolva, de nekem akkor sem egyértelmű hogy miért így jó. Pedig nagyon jó lenne tudni. Mire leírtam lehet, hogy rá is jöttem. Talán a stringlezáró 0 nem volt ott és így túlcímezte a tömböt?
Oda teszed a lezaro nullat, azt neztem elotte. A baj az lehet szerintem, hogy kicsi a buffer. pl 16 karakter ley van, es ha a PC-rol 16 karaktert kulsesz, akkor a lezaro az mar a buffereden kivulre esik. Namost ha megnezed a 'serial_buffer' -t koveti az 'r_message', tehat nagy valoszinuseggel a lezaro mar az r_message elejere kerul. Igen am, de a masolaskor az a karakter rogton felul is irodik a serial_buffer elso karakterevel, igy elveszited a lezaro 0-t... Remelem ertheto volt ahogy elmagyaraztam.
Ha valoban a PC-rol 16 karaktert kuldesz, akkor probaldd csak ki megnovelni mindket bufferedet 17-re, es az eredeti koddal kiprobalni.
Szia
Értem mit mondasz. A memóriában a két tömb egymás után van. Ha túlírom az elsőt, akkor a másodikba írok. A próbálkozások során viszont max 3-4 karaktert küldtem.
Voltak meg ott egyebek is, pl, hogy a num_of_char nem volt inicializalva, ill hogy egy-egy beerkezett string/sor utan nincs nullazva, igy folyamatosan irodik tovabb a memoriaban, meg ehhez hasonlo dolgok. Na, pl meg ez is lehet:
Bejon a CR karakter, amit a '\n' osszehasonlitas miatt ugy ertekelodik ki hogy megjott a sorvege. Ekkor beteszed a lezaro nullat, beallitod a flag-et, a foprogram meg elkezdene feldolgozni a buffered, minden szep es jo. Csakhogy a DOS es Windows alapu operacios rendszerek egy LF karaktert is oda biggyesztenek, aminek hatasara keletkezik egy megszakitas, ahol a lezaro nullat felul is irod... De ez csak egy elmelet, mert ugye az LF-nek kellene lennie a '\n', nek, a CR-nek pedig a '\r'-nek nem pedig forditva, ugyhogy ilyen jellegu gondnak sem lenne szabad lennie. Debuggerrel ezt meg kellene vizsgalni, PICkit2 serial analyserrel meg kellene nezni mi jon ki a PC felol stb...
Hello
Tudna valaki segítteni, hogy az alábbi programkód mért nem akar menni?
Próbáltam már mindenhogy de sehogy se működik, olyan mintha össze vissza menne az egész, ha csak simán az asztalon van a pic akkor nem történik semmi, de ha elkezdem fogdosni akkor néha bekapcsol a LED, aztán további tapizástól néha elaszik, de az egész teljesen rendszertelenül történik. A 9es lábán van a LED, 4es lábon tápfeszültség van,5ös láb föld,14es szintén tápfeszültség, 17,18as láb egy kapcsolón keresztül földpontra vankötve(később szeretném majd ezt használni).
NOWDT, NOMCLR es NOLVP mindenkeppen kellene oda, azonkivul nem tudom 100nF keramia kondit tettel-e nagyon kozel a PIC Vdd es Vss labai koze?
|
Bejelentkezés
Hirdetés |
