Kicseréltem ezeket,bele is égettem. De nem változott semmi ugyan úgy játssza mind a 15 programot.

Van egy halvány emlékem, miszerint, ha a slave NAK választ adott a kommunikáció közepén, a driver elveszti a fonalat, és végtelen ciklusba kerül. Ezt valamelyik Errata, vagy Appnote leírásban említik is, vagy a Microchip fórumán olvastam? A megoldás az lehet, hogy minden feltételt vizsgálni kell.

Legközelebb megnézem, van még egy ötletem. De csak akkor jut rá idő, ha a mostani gondot letudtam.

Rendben! Ráér. Majd ha esetleg ide tennéd be,akkor dobj légyszi egy PÜ-et mert van amikor én sem vagyok itt sokáig. Köszi!

Sziaszok!
16F887-et programozok mikroc alatt és az lcd-re való írásra szóló utasítás fordíása után ez a figyelmeztetés íródott.
irp bit must be set manually for indirect access to variable
Utánnanézve a dolognak, olyat olvastam, hogy ezt a hibát a RAM túl sok igénybevétele okozza és kézi bank váltást kell csinálni (?), illetve van egy másik lehetőség, string konstanként kell tárolni a kiírandó karakter tömböt és a fehasználás előtt kell Ram-ba olvasni és akkor az ilyen hibaüzenet elkerülhető.
Kérdésem: hogy csinált e már valaki ilyet, ha igen akkor jó lenne ha el tudná magyarázni a dolog mibenlétét egy próbakód segítségével.

A 16F családban az utasítások a memória címének csak az alsó 7 bitjét, a FSR az alső 8 bitjét adja, de a memória 9 bites címzést használ. A direkt címzésnél a felső két bitet a STATUS regiszter RP1 és RP0 bitjei adják, indirekt címzésnél a legfelső bitet a STATUS regiszter IRP bitje adja.
Egy indirekten elérendő adatra vonatkozó művelet előtt nem csak az FSR regisztert kell beállítani, hanem az IRP bitet is. Ha az adat a 0. vagy 1. lapon van (RAM page 0, 1) akkor IRP -t 0-ra, ha a 2. vagy 3. lapon van (RAM page 2, 3) akkor IRP -t 1-re kell állítani.

Meg kell oldani azt is, hogy a megszakítási rutin a saját igényének megfelelően állítsa be az IRP bitet a STATUS mentése után. A visszaállítás a STATUS visszaállításával egyszerre megtörténik.

Nem is értem miért terjedt el a 16F széria, ráadásul most hogy írod az indirekt címzésnél is mókázni kell a bankokkal, ez már nevetséges.
Jó, valójában értem, a C és magasabb szintű fordítók leveszik ezt a terhet az ember válláról (mármint nem indirekt címzés esetén). Csak hát így plusz egy felesleges művelet.
Persze, 18F esetén is az egyre több periféria miatt bankolgatni kell, de ott legalább nem olyan sűrűn, illetve vannak rá alternatív megoldások (pl. core regiszterek, melyek minden bankból elérhetők), "ablakos" memória elrendezés, ráadásul az indirekt címzéshez nem kell bankolgatni.
Na ezért se használtam a 10 év alatt soha 16F-et.
Jó mondjuk hacsak nem kell USB-t programozni, én asm-t használok.

Üdv!

Megépítettem az ebben a CIKKBEN található kapcsolást. Sikerült életem első pic programozása is. Azonban olyan problémám adódott, hogy az óra fizikailag visszefele jár. Ezt a programban lehetséges valahogyan egyszerűen orvosolni? Vagy szerintetek mi lenne a megfelelő megoldás.

Előre is köszönöm!

A videó szerint jó irányba jár. Ha nálad nem, akkor a vezetékezés sorrendje lehet felcserélve a LED-ek és a NYÁK között.

A 16F indirekt címzés kezelését egy "jó" C fordítónak tudnia kellene.
Ami a család hátránya, azt ki is lehet használni. Pl. dupla bufferes megoldásnál a két buffert úgy lefoglalni, hogy köztük csak az IRP értékében legyen különbség - ugyan az a kódrészlet futhat.
Volt élet magas szintű nyelv nélkül 512 utasítással és 64 byte RAM -mal is.

Ne kezdjük el megint...
A sima 16F -eket jóval előbb tervezték (16C83 -16C84), vezették gyártásba, mint ahogy a hozzájuk tartozó C fordítók elterjedtek volna. Az enhanced 16F1xx sorozatot már a C fordítók igényét figyelembe véve tervezték.

Találtam egy megoldást.



Ennek alapján készítettem el saját kódot és hiba nélkül lefordult és a pic-ben is működik.

Miért ez a görcsös ragaszkodás a rejtélyes library -khoz? Miér nem írjuk meg azokat az eljárásokat, amiket nem találunk meg bennük? Mi a titok benne?

Semmi... Sőt még 16 byte RAM sem kell hozzá.

Köszönöm szépen!
Bár egy kicsit csípősnek éreztem az indítást, ez is működik, "sőt még 16 byte RAM sem kell hozzá."
Tudod azért szoktam kérdezni és válaszokat várni, mert mint a fórum címe mutatja "PIC kezdőknek". Én is kezdő vagyok, sokat kell még tanulnom és szeretnék is, bár nem hivatásszerűen foglalkozok pic programozással, különösen 70 közelében.
Minden esetre még egyszer köszönöm szépen a segítséget.

Üdvözöllek benneteket, olyan szakit keresek aki ért ehhez a programhoz MPLAB and HiTech C és ha szépen megkérem egy szervo motor picbe való felprogramozásához segitene leforditani a programot hex fájl formátummá. Előre is köszönöm

A fájl küldöm ha felvesszük egymással a kapcsolatot

Milyen típushoz kellene? Melyik is az a forrás?

Sziasztok!

A PIC32MM-ben szeretném használni a 12bit-es ADC modult.
Arra vagyok kíváncsi, hogy jól számoltam e ki az acquisition time-ot és a throughput rate-et.
Tehát:

ADC input clock = FRC 8MHz
Mivel a min tAD = 250ns az adatlap szerint, ezért ADCS<7:0> = 3, tehát tAD = 375ns (2.66MHz)
tCONV = 16 x tAD = 6us
Az ADC adatlapja szerint a tartó-mintavevő áramkör kondenzátora (Csh) 40pF, a kapcsoló ellenállása 3K + 250 ohm interkonnekt ellenállás = 3.25K
Ennek az időállandója: 130ns
Ha ezt megszorzom 9-el, akkor 1.17us alatt töltődik fel a Csh a maximális kivezérlés (FS) -0.5LSB értékre.
Vagyis elvileg a minimális acquisition time 1.17us.
SAMC<4:0> = 5 esetén ez 1.875us lesz, ami elvileg elég még ha az FRC -5%-on megy.
Az acquisition time tehát 1.875us, ha a forrás impedanciája kicsi. Én műveleti erősítő + RC szűrővel hajtom meg így azzal nem lesz gond.
A throughput rate pedig így 127ksps-re adódik.

Ez így OK?

Sziasztok, mi lehet az oka, hogy pickit3 nem látja a pic18f__k__ szériás piceket?
Táp, gnd, mclr, pgd, pgc, vcap bekötve.

Egyet sem, vagy csak néhányat? A kutya az utolsó két számjegy alá lehet elásva.
A másik lehetőség, hogy a program az elején átállítja a programozó lábakat, nincs beiktatva késleltetés, hogy a programozó idomíthassa az alkatrészt.

PICkit2 is csak módosított, illetve bővített "PK2DeviceFile.dat" fájllal látja a K család elemeit. Abban a családot többnyire kézzel kell kiválasztani, a kedvétől függ, hogy felismeri-e vagy sem. Ezek hog yműködnek PICkit3 esetén? Illetve milyen programmal kezeled a konkrét programozót?

Helo.
Van egy Pckit3 nevű kínai klónom és néhány PIC16F1615 ös kontrollerem. Korábban szórakoztam én 12f683 mal 18f4550 nel, csináltam néhány dolgot. Most visszatérnék részben a pichez mert van pár olyan periféria, amely semelyik másik gyártónál nincs. Milyen programmal tudnám őket programozni C ben és akár ha belekóstolnék ASM ben? Ha jólemlékszem nagyonrég az MPLAB X et használtam meg párhuzamos porti programozót.

Én a régi 12F, 16F de még a 18F szériához inkább az Mplab IDE utolsó verzióját használom, igaz csak assemblyben programozok.

PK3 al és IPE programmal...

A PIC16F1615 elég új típus, így csak az XC8 újabb verziói képesek rá fordítani kódot. Ezek pedig nem kompatibilisek már a MpLab 8.xx -el.
A közelmúltban a Microchip kivezette az MpAsm -et, helyette a pic_as nevű assemblert tette a csomagba. Sokan elég szomorúak lettek a változtatástól...

Ha lemondanék a c ről mert xc8 ból a normális gondolom egy vagyon és sehol sem fogom megtalálni, akkor az ingyenesen letölthető mplab x el és a kínai pickit klónommal menne a dolog assemblyből? Gondolom a régi IDE esélytelen még ha asm et is használnék, pedig az jobb szerintem is mint ez a java izé, emlékszem alig bírta a gép annyi erőforrást kért.

A Mikro Pascal és a MikroC elvileg tudja. Most a munkahelyi gépen nem tudom futtatni de a listában benne van.
2K fordítási határig ingyenes.

https://www.mikroe.com

Hát, lehet, hogy hülyeségeket fogok beszélni, de
Kényszerűségből fel kellett lépjek a legújabb MPLAB X 5.45-re
Ott - szintén kényszerből - át kellett térjek a piac_as-ra, ehhez fel kellett tegyem az XC8-at és semmit nem fizettem. És még talán a Pic_AS-t is külön fel kellett tennem, de erre már nem emlékezem. Kezeli a PICKit 3-t (Orig). Viszont annyit kellett az MPLAB-bal görcsölnöm (invalid toolkit meg miegymás), hogy fogalmam sincs már mi volt a nyerő lépés. Viszont nem fizettem semmit.
Emlékeim szerint, az a C compiler, ami hozzáfordítja a háború és békét, az ingyenes, ha okosabb kell, az fizetős.

Ott tartok hogy feltettem a legfrissebb MPLAB X et, a programozóm elvileg látja, az ipe dumált vele. Az ide viszont problémás, az xc8 on kívül más toolchain nem jelenik meg mikor új projektet csinálok, pedig fenn van a pic-as is vele. Hogy lehetne megoldani azt hogy lássa is? Semmi tallózás vagy ilyesmi lehetőséget nem látok. Szerk.: siker, options, embedded, build tools, add a megoldás ha valaki keresné.

A programban benne van, pickit3, de azt írja rá hogy no device ha rádugom

Jól értelmezem az adatlapot, hogy a PIC18F4550-nél nem lehet egyesével engedélyezni az analog bemeneteket? Csak AN0 tól indulva sorban, AN0, AN0+AN1, AN0+AN1+AN2 ... Tehát tehát nem
tudom használni pl. az AN3-at és az AN5-öt, miközben a többi láb digitális I/O marad?

Tartományt lehet csak analógnak állítani. A tartomány mindig az AN0 -val kezdődik, és az választható, hogy melyik legyen az utolsó analóg bemenet. Az analógra állított lábat olvasva mindig 0 -t kapunk. Ha a hozzá tartozó TRISx bit 0, akkor a logikai kimenet be lesz kapcsolva, a lábon a digitális kimenet szintje lesz mérhető, ha más meghajtó nem csatlakozik rá. Az A/D is ezeket a digitális szinteket méri meg.
Azaz digitális bemenetnek nem, de kimenetnek lehet az analógra kapcsolt lábat használni. Egy apró bökkenő van: Az analóg módra állított bit a LATx regiszterben is mindig 0. A LATx regiszterről másolatot kell tartani a RAM -ban, azon végezni a műveleteket és csak kimásolni az új értéket.
Digitális bemenetet szintjét meg is lehet mérni és az eredmény alapján lehet döntést hozni, hogy magas vagy alacsony szint van a lábon.
Ezenkívül a RA0, RA1, RA2 és RA3 lábon levő szintet a komparátor egységgel (CM2:CM0 = 110) is lehet figyelni.