Fórum témák
» Több friss téma |
Köszi ezt értem, a következőkhöz viszont enyhén szólva lövésem sincs:
Az átnevezett már piccolo_uart.c a 'FILE *stdin;' sorára a fordító a következőt dobja: type mismatch in redeclaration of 'stdin' próbáltam megfejteni az okát, nem jutottam eredményre. Az előzőekben felvetett problémám megoldódott, (a fordító már tovább lép, remélem majd működik is) újból csináltam az egészet valószínű valamelyik fejléc állomány maradt le. Tanácsot kérek a probléma megoldására. Üdv. Idézet: Keresd meg, hogy miért és hol van ez újradefiniálva! „type mismatch in redeclaration of 'stdin'” Úgy tudom, hogy a C18-hoz kapott könyvtárak nem kezelik (ezért nem is deklarálják) a stdin sream-et. A FILE típus pedig a stdio.h-ban van definiálva.
Helló!
Szeretnék készíteni a PICkit2 klónomhoz egy kiegészítő panelt http://www.hestore.hu/prod_10025842.html foglalattal. Valaki tudna mutatni ilyet, hogy hogy is nézzen ki, valamint mi az ami mindenképpen legyen rajt? Köszönöm!
Példának okáért http://mickey5.fw.hu/kaqkk_sys.html#20111017_Pk2
Köszönöm!
Köszi az infót, ismét sikerült segítségeddel megoldani egy újabb feladatot.
Működik a dolog, legalábbis a fordítás sikeres. Holnap (illetve már ma) kipróbálom a hardverrel. A PICCOLO projekt _usb.c és a PICula projekt _usart.c állományát 'összefésültem' és létrehoztam a piccolo_usb_usart.c file-t. Így sikeres lett a fordítás. Amikor két állomány volt piccolo_usb.c és a piccolo_usart.c (átnevezett picula_usart.c) akkor nem, az előzőekben leírt hibát generálta a fordító. Még egyszer örök hála, köszönöm a segítséget. Idézet: Ennél azért valmivel bonyolultabb lesz az "összefésülés"... Nem tudom, hogy észrevetted-e, hogy a picula_usart.c inicializáláskor a _H_USART_-ot, a piccolo_usb.c pedig a _H_USER_-t állítja be standard outputként. Ha mindkettőt lefuttatod, akkor mi lesz a standard output, s hová ír a putchar() függvény?„létrehoztam a piccolo_usb_usart.c file-t. Így sikeres lett a fordítás.” S milyen függvényhívásokkal kívánod megoldani, hogy egyidejűleg lehessen USB-re és soros portra kiírni? Javaslom, hogy próbálj meg egy nagyon egyszerű főprogramot összedobni, ami az USB-ről érkező karaktereket kiírja a soros portra, a soros portról érkező karaktereket pedig kiírja az USB-re. Ez könnyen tesztelhető: csak össze kell kötni az USART TX/RX lábait (hurok teszt).
Szia!
Idézet: „Próbálj meg egy nagyon egyszerű főprogramot összedobni, ami az USB-ről érkező karaktereket kiírja a soros portra, a soros portról érkező karaktereket pedig kiírja az USB-re.” Annyit tennék még hozzá, hogy semelyik kommunikációt ne blokkolja a megoldás: - Az USB puffereléssel dolgozik. Negatív Ack -t kell küldeni, ha netalán túl sok adat jönne a PC -től. - Az UART vevőjéhez és adójához hozz létre egy-egy alkalmas méretű (valamely 2 hatvány), körforgó buffert. Ha az UART vett egy karaktert, a megszakítási rutinja az esetleges hibát kezelje le, a jó karaktert tegye be a vételi bufferbe. A PC felől jövő karaktereket tedd az adási pufferbe, ha még beleférnek és engedélyezd az UART adási megszakítását. Az UART adási megszakítás kiszolgálója vegye ki a következő karaktert az adási bufferből és írja be a TXREG -be, ha nincs több adni való, tiltsa le a megszakításkérést. Természetesen kezelni kell a bufferekben levő karakterek számát. A kiolvasás és a beírás mindig előbb történjen, mint a darabszám módosítása, amit csak un. primitív művelettel (ne tudja a megszakítás szétválasztani a módosítás utasításait) oldj meg. -
Ezek már készen vannak két, külön projektben. Csak Pepebá össze szeretné kalapálni, egybe az egészet.
Szia!
Valamikor említetted, hogy nem sikerült összehozni pontos időzítést a USB HID kezeléssel. A Watt féle USB HID demoban sikerült elérnem: -- A keretprogram mindenáron a Timer0 -t akarja engedélyezni, ami a 4MHz (leosztott) quartz frekvenciával valóban nem pontos. -- Letiltottam a Perif_cfg -ben a Timer0 megszakítás kérését, a Timer2 -t felprogramoztam 200us -re, engedélyeztem a megszakítás kérését. Az USB megszakítási rutinban levő kiszolgálását áthelyeztem a Timer2 -t kiszolgálójába. Még nem végeztem hosszú (napokig tartó) mérést, de az óra program 10 perc (600s) alatt 10 percet (600s) ment előre... Idézet: Én nem emlékszem ilyenre. „Valamikor említetted, hogy nem sikerült összehozni pontos időzítést a USB HID kezeléssel.” USB CDC-t használok, s a számlálással volt gond, nem az időzítéssel (de lehet, hogy időzítési problémának látszott). Mint kiderült, Timer1-nél a 16 bites mód nem kompatibilis mindegyik beállítással (már nem tudom, hogy a szinkron vagy aszinkron móddal). Lehet, hogy az Errata is jelzi... Ja, én is Timer2-t használom időzítésre. Azzal nem volt gond.
Teljesen kezdő (leszek, ha megjön az égetőm), csak ismerkedem a témával egyenlőre.
Van arra lehetőség egy PIC programozása közben, hogy valahogy véletlen "szerű" számokhoz jussak?
Van. A bal kezeddel dobalsz kockat.
Viccet felreteve, nem egeszen ertjuk a kerdest. Talan valami sorozatszam kellene, ami minden PIC-nel mas, vagy miert lenne ra szukseg? Elvileg ha a HEX-ben modositod a CRC-vel egyutt, azt egy kulso program is megteheti.
Igen, ezt azért észre vettem. Én kis naív úgy gondoltam talán működni fog. Mivel az az UART-n csak venni akarok, (egy rádiós modul jelét akarom dekódolni, értelmezni) az USB-n meg adni (küldeni a PC-re, esetleg LCD-n megjeleníteni).
Az is megfordult a fejembe hogy talán nem is kellene bíbelődni a PIC-l, közvetlenül RS232-n kelllene lebonyolítani a vételt és VB6 progin meg feldolgozni. Viszont nem csak ez a feladat megoldása a célom, meg akarom ismerni az UART programozását. Ez a hurok teszt megoldás érdekes, nem tudtam hogy van lehetőség ilyen látszólag egyszerű megoldásra. Egyenlőre kíváncsian várom az eddigiek hardveres próbáját, csak a gyakorló panelom 'befogtam' öntözés vezérlésre (arra meg most szükség van) úgy hogy csinálni kell másikat.
A szitu:
egy eseményre, a chipnek be kellene kapcsolni egy ledet, 1-5 másodperc közötti valtozó időre. A kettő közötti idő hossza jó lenne ha véletlenszerűen lenne kiválasztva. ezt szeteném megoldani MAJD... CSak nem találkoztam még ilyen véletlen generátoros dologgál.. bár digitális kockát már láttam... gondolom az is hasonló lenne... (?)
Hali!
Igen a PICCOLO projektben az USB, a PICula-ban pedig az USART kezelése az általad ajánlott jintelemkkel meg van, icserny 'mester' jóvoltából. A kettőt próbáltam valahogy összehozni, de ahogy a szerző figyelmemet felhívta egyidőben nem lehet mindkét ouput-t, vagy input-t használni. Erre kell megoldást találni, amennyiben jól gondolom külön függvényeket kreálni. Üdv.
Ha a soros portot nem akarod matatni a magasságos printf, vprinf stb függvényekkel, hanem beéred az _usart_putc(c) és _usart_getc() függvényekkel, akkor az ütközéseket egyszerűen meg lehet szünteni, ha az ...usart.h-ból kiirtod az alábbi sorokat:
Az ...usart.c-ből pedig vedd ki a getc() függvény definícióját, valamint az alábbi sorokat:
A stdout és stderr valamint _user_getc() és _user_putc() kezelése ekkor teljes egészében a piccolo_usb.c-re marad.
Ha az esemény hossza, vagy az események közti idő véletlenszerű, akkor már el lehet indulni.
ööööö.. nem.
Röviden: Megnyomok egy gombot, mire egy LED véletlen másodpercig világít. Ezt lehet e valahogy programozni PICre.
Sziasztok!
Szerintetek ha ezt fölturbózom kb 20-30 cucc kapcsolására, tranyós erősítéssel, akkor elbirná egy pic mind a 20-30 kapcsolását?
Boocs, nem linkeltem semmit: Bővebben: Link
Sziasztok!
Meg szeretnék tanulni PIC-et programozni C nyelven is, eddig csak assemblyben csináltam. Láttam többféle fordítót is (úgymint CCS, Hi tech). Mi a különbség közöttük? Melyiket ajánlanátok? Köszi előre is
Szia!
Kibírná. A vezérlő kört fordítsd meg: A pic egy NPN tranzisztor bázisát vezérelje ellenálláson keresztül. A kollektor körbe mehet a visszajelző led, az optocsatoló és az áramkorlátozó ellenállás. Az optocsatolók két oldalán levő lábait minimum 4 raszteresre nyomtasd és a tokjuk alatt ne vezess át vezetéket. Az előírt minimális vezető nélküli kúszóút a panelen 7.5mm.
Oké, nagyon szépen köszönöm a segítséged!
A C nyelvet akkor lehet hatékonyan használni, ha a hardver is támogatja (mutatók, veremtár...). A gyártó a PIC18 családtól kezdve mondja, hogy a felépítés és az utasításkészlet a C nyelvet támogatja.
PIC18: C18 most a legelterjedtebb, de elavulóban van. Újabban van XC8, ami átberhelt Hitech C-nek néz ki. Ennek még be kell érnie... PIC24/dsPIC: C30 ajánlható, illetve jön az XC16... PIC32: C32 volt eddig, most jött az XC32... Fentiek közös előnye az ingyenes elérhetőség, mely csak az optimalizálásban van korlátozva és a gyártói támogatás. Nem utolsó szempont, hogy a nagy gyári csomagok (USB vagy TCP-IP stack) is ezeken vannak megírva.
Van arról bármi hírek, hogy MC dolgozna a 80 Mhz átlépésén? Igazán adhatnának legalább 133-at..
Esetleg próbálta már vki meghúzni a pic-et nagyobb frekire? Tapasztalatok?
Ezt a konkrét feladatot én így oldanám meg:
Konfigurálnék egy időzítőt (pl. TIMER0) 1s valahanyad részére (célszerűen talán 1...10ms közé), majd a gomb lenyomásakor kiolvasnám a számláló aktuális állását. A számláló TIMER0 esetében 0...255 között vehet fel értéket, nekünk viszont 1...5-ig kellene egy szám. Ezt többféleképpen el lehet érni, pl.: - maradékképzéssel (MOD művelet): a számláló állásának vesszük az 5-ös osztási maradékát, ez az érték 0...4 lehet, tehát még 1-et hozzá kell adni ahhoz, hogy a nekünk szükséges 1..5 kijöjjön; - összehasonlítással: megnézzük, hogy a számláló állása 256-nak melyik ötödébe esik, tehát pl. 0...51-ig 1s ideig késleltetünk, 52...102-ig 2s-ig és így tovább. A maradékképzéses módszer "véletlenebb" eredményt ad, hiszen a kapott érték minden "óraütésre" változik, míg az összehasonlításos módszernél csak kb. minden 51-ediknél. Ez a különbség azonban a konkrét feladat esetében elhanyagolható. Ha megvan a kívánt 1 és 5 közötti érték, akkor TIMER0-t tovább használhatjuk a késleltetés megvalósítására (ezért írtam, hogy 1s valahanyad részére érdemes választani). Ez az egyszerű véletlenszám-generálás természetesen nem alkalmazható olyan esetekben, ahol a generálást kiváltó esemény szinkronban van a választott időzítő órajelével, mivel ilyenkor értelemszerűen mindig ugyanazt az eredményt kapnánk.
Sziasztok!
Valaki tudna nekem segíteni hibát ír ki az MPLAB amikor az ICD3-hoz csatlakoztatok egy 16f628A PIC-et de 18f4550-el semmi baja. A hiba szövege: Target Device ID (00000000) does not match expected Device ID (00001060). If you experience persistent problems communicating, the ICD 3 test interface can be used to help diagnose the problem. Valaki meg tudja mondani, hogy mivel van a probléma ?
Hogy jelen esetedben mivel van a probléma, azt vakon szerintem senki sem fogja tudni, de két tipikus lehetőség:
1. Halott pic-et próbálsz vizsgálni. 2. Az ICD-nek milyen tápellátást állítottál be? USB-ről vagy áramkörről? |
Bejelentkezés
Hirdetés |