Fórum témák

» Több friss téma
Fórum » PIC kezdőknek
 
Témaindító: Placi84, idő: Okt 3, 2005
Témakörök:
- A PIC ÖSSZES Vdd és Vss (AVdd és AVss) (tápfeszültség) lábát be kell kötni!
- A táplábak mellé a lehető legközelebb 100nF-os KERÁMIA kondenzátorokat kell elhelyezni.
- Az MCLR lábat, 10kohm-mal fel kell húzni a Vdd tápfeszültségre.
- Külső kvarc használatakor 4MHz-ig XT, a fölött pedig HS konfigurációt kell beállítani.
- Stabilizált tápegységet kell használni, a kapcsoló üzemű "telefon töltő" adapterek okozhatnak hibákat.
- Programozáshoz, használj lehetőleg PICKIT2 vagy 3 programozót. Kerülendő a JDM (soros porti) programozó.
- A PIC adatlapja (PDF), tartalmazza a lábak kiosztását és a PIC minden paraméterét. Az adatlap ingyen letölthető!
- Egyes PIC típusoknál az RA4 nyitott nyelőelektródás (Csak lefelé húz L szintre, H szintet nem ad ki!)
- Ha a PGM lábat digitális ki-/bemenetnek használod, az alacsony feszültségű programozási lehetőséget le kell tiltani.
Lapozás: OK   1108 / 1147
(#) nedudgi válasza szucsistvan123 hozzászólására (») Feb 17, 2020 / 1
 
Bár nem értek a C-hez, de a .h kiterjesztés "header" (=fejléc) típusra utal, míg a .c a "C" a forrásnyelvi tartalmat, végrehajtandó utasításokat jelzi.
A hozzászólás módosítva: Feb 17, 2020
(#) benjami válasza Swarcy hozzászólására (») Feb 17, 2020 /
 
Én kipróbálnám virtuális gép alatt is, pl. Virtualbox-ban feltelepített XP alatt.
(#) benjami válasza szucsistvan123 hozzászólására (») Feb 17, 2020 / 1
 
A C fordítók úgy működnek, hogy első körben az előfordító végigmegy mindegyik C forrásfájlon, és az abban található #include hivatkozásokat copy-paste módon bemásolja a C forrásfájlba. Ezután a fordító minden C forrásfájlból csinál 1-1 object fájlt. Az object fájlok már bináris kódot tartalmaznak, de a memóriacímek még nincsenek benne véglegesítve. Ezután megy rá a linker az object fájlokra és azok összefésülésével készíti el a végleges bináris kódot. Na mármost: mivel a C forrásfájlból szoktunk olyan függvényt hívni (esetleg adatot felhasználni) ami a másik C forrásfájlban van kifejtve, kell egy összekötő kapocs, ami a fordítónak megmondja, hogy másik C forrásfájlban milyen függvények érhetőek el, és azok milyen paraméterezéssel rendelkeznek. Erre való a header. A függvény kifejtése pedig azért nem lehet benne a headerben, mert egy headerre több C forrásfájlban is hivatkozhatunk, így a függvény több object fájlba is belekerülne ami ütközést okozna (a függvény prototípusának többszörözése nem okoz gondot).
(#) pipi válasza szucsistvan123 hozzászólására (») Feb 17, 2020 / 1
 
A saját headerfájl értelme az, ha több C fájlból áll a projekted, akkor az egyik forrásból hivatkozva a másikban lévő függvényre változóra egyzserűbb hivatkozni, egyszer kell a headerba beírni a deklarációt, és ezt minden c forrás látja.
A gyári(lib) header fájl meg nyilván azért van, ne neked kelljen a deklarációt beírkálni, fejből tudni...
A headerfájlba "nem illik" programszöveget berakni, csak deklarációkat. Persze lehet, csak nem tesz jót , nem lehet akkor több fájlba behívni, mert duplikált függvények, változók lennének
(#) Tasznka válasza Swarcy hozzászólására (») Feb 17, 2020 /
 
Igen,ez már eléggé aggasztó...Próbáld ki,hogy virtual XP-alatt megy-e? ,talán ez segíteni fog.Sajna eléggé macerás kideríteni,hogy mi fogja meg(de próbaként ki kellene lőnöd egyesével mindent,hátha meglesz a mumus) .
(#) kissi válasza Swarcy hozzászólására (») Feb 17, 2020 /
 
Szia!

Nem véletlenül a TRACE funkció okozza ?! Ez a help szerint jelentős lassulást okoz ami gyengébb gépnél (szerintem főleg kis memóriával !), számottevő lehet !
(#) szucsistvan123 válasza pipi hozzászólására (») Feb 18, 2020 /
 
Köszi a válaszokat!
(#) Lamprologus hozzászólása Feb 18, 2020 /
 
PIC (18F4550, 20MHz kavarz) és ESP8266 (szoftveres uart) modul között hoztam létre UART kapcsolatot. PIC küld ESP felé.
Mitől van az, hogy nem minden sebességen hajlandóak kommunikálni egymással?
pl 57600-nál szinte hibátlan az adatátvitel, 9600-nál nem is fogad adatot az ESP, 115200-nál téves adatokat vesz.
Gondolom, hogy az átviteli sebességek nem passzolnak egymással ... de melyik oldal téveszt? Hogyan tudnám a megfelelő átviteli sebességet meghatározni, nem próbálgatós módszerrel?
A hozzászólás módosítva: Feb 18, 2020
(#) benjami válasza Lamprologus hozzászólására (») Feb 18, 2020 /
 
Első körben tegyél rá egy logikai analizátort és mérd meg mennyi az annyi (ha még nem lenne, akkor meg szerezd be ezt a pár dolláros hasznos kis szerkezetet).
(#) usane válasza Lamprologus hozzászólására (») Feb 18, 2020 /
 
Szinkronizációs problémának tűnik. A 2 oldal egyforma baudrate-re van konfigolva?
(#) nedudgi válasza Lamprologus hozzászólására (») Feb 18, 2020 /
 
Én PIC-ről 9xx kBd sebességgel, kvarc nélkül küldtem a PC felé adatokat - sebességeltérés nem okozott hibát.
AZ ESP oldalán szinkronizálási hiba szerintem elképzelhető, ha szoftveres soros porton veszel. A PIC oldalán érdemes lenne kipróbálni a lassítást, szünettel a karakterek között - az ESP8266 kezeli a WiFit is, így veszíthet biteket.
(#) asch válasza Lamprologus hozzászólására (») Feb 18, 2020 /
 
Érdekes állat a serial adatátvitel, mert elsősorban nem a sebesség a kulcskérdés, hanem az órák relatív pontossága. Ha egy konkrét BAUD értékkel van egy szisztematikus óra tévedés, és erre rájön az órák különbsége, az okozhet esetleg ilyet. Az órák közötti kb 10% eltérés már vételi hibát eredményezhet önmagában.

Amit mérni érdemes szkóppal:

* Jelforma a vételi oldalakon: ha túl nagy a vezetékek kapacitása, a soros ellenállás, stb akkor elképzelhető hogy a jelforma már nem elég jó. Szögletesnek kell lennie. Ha van egy görbülete a sarkoknál, pláne ha a két irányba nem egyforma, akkor adódhat ebből is tévesztés. A vevő többnyire a startbit éléhez szinkronizál, ha a fel/lefutás lassú, akkor bizonytalan lehet időben, hogy honnan veszi alacsonynak/magasnak. Ezzel rövid drótoknál és kis BAUD rate-nél ritka, de nem kerül semmibe ránézni azért erre is, ha már bekapcsoltuk a szkópot.
* Bitidő: olyan tesztprogramot érdemes írni, ami a kimeneti pufferbe azonnal beírja a következő bájtot, amint lehetséges. A bájt értéke pedig legyen 0xf0 vagy 0x0f. Attól függ, hogy a 0 vagy 1 oldalon van-e a startbit (nem emlékszem), de vagy az egyik, vagy a másik mintával teljesen szimmetrikus négyszögjelet kapsz. (AVR-es HW UART-tal számtalanszor csináltam, tényleg teljesen pontosan szimmetrikus négyszöget ad) Aminek a periódusa pontosan 10 BAUD lesz: start, 8 adata, stop. (Ha 1 start, 1 stopra van konfigolva az UART.) Ezt a jelet könnyű szkópon pontosan bemérni, élre triggerelve teljesen statikus képet ad.

(A 0b10101010 vagy 0b0101010101 mintákkal is szokás mérni, itt a jelváltás ideje 1 BAUD, a periódus 2 BAUD. Automatikus mérőjelnek a 0xf0/0x0f azért jobb, mert kevesebb él van benne, kevesebbszer kell leolvasni az órát. A mérés pontosságát azzal lehet növelni, ha több jelet mérünk egyszerre, mivel a leolvasási hibát nagyobb számmal osztjuk. Ez kézi szkópos mérésre, de bitidő mérésre is igaz.)

Ha mindkét adót bemérted, akkor jó esetben ebből a mérésből már látszani is fog, ha a bitidő eltér, vagy az is, ha a start/stop beállítások eltérnek. Ha nincs implementációs hiba a SW vevőben, akkor annak a bitideje egyezik az adóval. A vevőt úgye direktben nem lehet mérni...

SW vevőnél az is okozhat hibát, ha valami interrupt elrontja az SW vevő időzítését - ez nagyon implementáció függő. Ha a valódi program futása mellett ki tudod adatni az SW UART-tal a mérőjelet, és az a szkópon zizegő képet az, az utalhat arra, hogy valami interrupt vagy egyéb nem teljesen determinisztikus dolog rontja el az időzítést. De ha ilyen lenne, az tipikusan kisebb BAUD-okon lenne kevésbé zavarérzékeny. Ez ellen CHECKSUM+hiba tolerálással a kommunikációs protokollban lehet védekezni. Vagy kisebb BAUD-dal.
(#) usane válasza Lamprologus hozzászólására (») Feb 18, 2020 /
 
Most nézem, hogy szoftveres, de biztosan működik az is hiszen több éve használja az arduino kommunity. Viszont a blokkoló utasítások befolyásolhatják(pl.: delay()).
(#) Lamprologus válasza usane hozzászólására (») Feb 18, 2020 /
 
Köszönöm a válaszokat!
Egyelőre megkerültem a problémát, áttettem az ESP-nél hardveres portra, így 115200 BAUD-dal is hibátlanul megy a kommunikáció.
Analizátorral nézve a PIC jól küldi az adatot, valószínű az ESP oldalon van a gond... majd ha lesz rá időm azért megnézem hogy hogy néz ki a szoftveres porton az adás.
(#) don_peter hozzászólása Feb 18, 2020 /
 
Srácok, tudnátok abban segíteni hogy meg mondjátok mivel tudnék programozni dspic33fj64gs606 típusjelzésű MCU-t? Úgy fest mint ha PICKit2 és 3 nem tudja. Köszi előre is.
(#) usane válasza don_peter hozzászólására (») Feb 18, 2020 /
 
Pickit2-ről nem tudok nyilatkozni benne van-e a Hp41C által bővített típusokban de a PicKit3-nak tudnia kell az 100%. Legalábbis elméletileg. Most kreáltam egy új projectet és a Pickit3 teljes támogatottságot mutat.
A hozzászólás módosítva: Feb 18, 2020
(#) Swarcy válasza kissi hozzászólására (») Feb 18, 2020 /
 
Szia megnéztem most a TRACE funkciót kikapcsoltam és így is ugyanolyan lassú sajnos.
A virtuális XP re én is gondoltam már de még nem volt időm kipróbálni.
(#) Swarcy válasza Tasznka hozzászólására (») Feb 18, 2020 /
 
Szia
Már gondoltam én is a virtuális gépre de idő hiányában még nem próbáltam.
De ha van esetleg pici időd itt a progim hátha nálad fut rendesen , mert egy igen furcsa dolgot vettem észre ugyanis másik régebbi progimat visszatöltve és szimulálva ott megy viszonylag jól az F7 is de ebben másik PIC proci van. A kódban vannak hibák még nincs kész de már fut egy része.
Köszi a segítséget

relemod.zip
    
(#) don_peter válasza usane hozzászólására (») Feb 19, 2020 /
 
Kérdés, hogy ezt a projektet melyik programban nyitottad?
MBLAP X vagy esetleg a régebbiben?
Bele néztem a PK3DeviceFile.dat fájlba, ott tényleg szerepel..
A hozzászólás módosítva: Feb 19, 2020
(#) usane válasza don_peter hozzászólására (») Feb 19, 2020 /
 
Már nagyon rég az X-et használom. 5.3 verzió van fenn jelenleg.
A hozzászólás módosítva: Feb 19, 2020
(#) don_peter válasza usane hozzászólására (») Feb 19, 2020 /
 
Köszi a türelmed, megnézem hátha felismeri a PICKit3 saját programja az IC-t.
(#) usane válasza don_peter hozzászólására (») Feb 19, 2020 / 1
 
Nem tudom mit értesz saját program alatt, de ha a Pickit3 Standolne programmert akkor felejtsd el. Azt a Pickit2 programmerből buherálták össze. Az MPlab X-nek vagy IPE-nek látnia kell.
(#) don_peter válasza usane hozzászólására (») Feb 19, 2020 /
 
Pedig arra gondoltam.. Ezt felejtsem el?
MPLAB 8.91-et használok, X-et elég hamar töröltem mert nem működött anno.

pickit3.JPG
    
(#) Elektro.on válasza don_peter hozzászólására (») Feb 19, 2020 / 1
 
Ez vissza butítja az PICkit 3-at.
Használd az IPE -t. Tipp: megy portable módban. Én Mikropascalban írok kódot de IPE vel írom fel.

IPE.png
    
(#) don_peter válasza Elektro.on hozzászólására (») Feb 19, 2020 /
 
Köszi, emlékszem tényleg erre a programra, ezzel programoztam a PIC32-őt.
Nem is értem miért nem jutott eszembe.. Köszi..
(#) usane válasza don_peter hozzászólására (») Feb 19, 2020 /
 
Írtam én is az IPE-t, nem olvasol?
Ám az X IDE is "tökéletesen" működik. 32-est ne akarj a régivel programozni. Illetve akarhattsz, de nem fog menni. Meg debuggolni hogy debuggolod?
(#) Tasznka válasza Swarcy hozzászólására (») Feb 19, 2020 /
 
Szia!
Nekem megy folyamatosan,és lépegetve is(bár az asm nem az én világom,és így a hibákat nem látom ).
(#) don_peter válasza usane hozzászólására (») Feb 20, 2020 /
 
Újra olvasva már látom, és ment is a mancs.. Bocs, elsiklottam felette valamiért. Figyelmetlen voltam.. Köszi a segítséget.
(#) PDM hozzászólása Feb 21, 2020 /
 
Debugolok egy projectet (16F1824) MPLAB8.92 - PITKIT3 -mal ill. MPLABX - PICKIT4-gyel:
MPLABX alatt kb ötször lassabb a letöltés, a single-steppel is kínlódok.
Ez normáááális?
Előre kösz. a válaszokat.
(#) pipi válasza PDM hozzászólására (») Feb 21, 2020 /
 
Hali! Mplabx 5.1, XC8 2.0 -val szívtam pickit4 debug közben, a program lépésenként végrehajtva, össze vissza ugrált, bolondságot csinált, visszatértem pickit3-ra, azzal ugyanaz a progi változtatás nélkül korrektül megy. Gyanús hogy erősen bugos (még?). A sebességgel nem volt bajom,
Akkor lassulnak le ha pl SFR meg van nyitva, vagy watch ablakban sok változó van, ezeket minden lépés után visszatöltögeti a pic-ből ami idő.
Következő: »»   1108 / 1147
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem