Hello,

A MikroC-t csak 16Fxxx és 18Fxxx kontrollerekhez lehet használni? 24Fxxx kontrollerekhez milyen programot tudnátok ajánlani amit be is lehet szerezni?

A dsPIC-eknél keresd a 24F-es PIC támogatottságot.
Egyébként meg alternatíva az MPLAB/MPLAB X XC compiler-ekkel.

Sziasztok!
Mit jelentenek a idegennyelvű rövidítések a láb kivezetésnél?
Van erre valami általános leírás a jelentésére,
vagy minden pic-nél más jelent?

Vannak altalanosak, pl. a portok jelolese RA1,RB4,stb, az analog bemenetek ANx, A soros vonal TX,RX, a kristaly ki-bemenet, az SPI, az IIC busz, stb.
Es vannak ertelemszeruen specialis volnaka, amik csak bizonyos csaladokon vannak, Vbat pl.

A PIC adatlapjban mindig le van irva, melyik lab mit jelent, illetve a limitaciokat is megtalalod valahol (altalaban a lab mellett kek felso index), a lap aljan meg leirja, hogy milyen korulmenyek kozott.

Ne hagyatkozz a megszokasra, mindig olvasd el a leirast is, mert a MC csunya meglepeteseket tartogat.

Sziasztok

Egy Pic18f4550-es uC-re töltöttem fel bootloadert ez alapján a kapcsolás alapján: Link de ezt a hiba üzenetet kapom a Windowsban(csatolva). próbapanelen van összerakva bar win8.1 alatt működött most meg win10 alatt nem akar. Elméletileg jól van összekötve minden.... szerintetek mi lehet a gond?

Előre is köszönöm

A VUSB lábon ott van a kondenzátor? A D+ és D- lábak nincsenek felcserélve?

MikroC vel lehet mindent.
A mikroe.com -on van külön a 8, 16 és 32 bites PIC-hez fejlesztő környezet. MikroC, MokroPascal és MikroBasic is.

Szia

Igen, fel volt cserélve a két láb de valamiért azt hittem, hogy jól állnak.

Köszönöm a segítséget

Elakadtam egy PIC24FJ128GC006-oson az AD konverzioval.
Egy olyan nagyon egyszeru dologra volna csak szuksegem, hogy csatornat beallit, adc indit, var, beolvas es kesz. De nem akar mukodni.
Egy 24HJ-s peldanyon jol fut, de ott eltero az AD kezelese. probalkoztam az adatlapon leirtakat betartani, de nem es nem.
Egy touchscreen beolvasoja lesz.

Ha esetleg lenne valakinek egy egyszeru kis mintakodja, orommel fogadnam tanulmanyozni. Masfajta, interruptos, stb. mar van.

Esetleg nézd meg a Reference Manualt, hátha segít.

Koszonom, mar be van vezetekezve az AN17/AN16 vonalra a NYAKon sajnos.
Probaltam nezni az adott lapon, hatha van a sima ADC-re is, de nem talaltam.

PICkit 3-mal lehet debuggolni valós időben? Változók értékeit szeretném megfigyelni "valós időben", úgy mintha kiküldeném soros porta azokat. Lehetséges ez? Mert jelenleg csak akkor olvassa ki a változót ha szüneteltetem a debuggolást.
Vagy, hogy lehetne használni a programozó által lefoglalt PGC, PGD lábakat soros portként a programozón keresztül?

Nem, sajnos a valós idejű debug-hoz ICD3 kell, az hogy a pgd pgc lábakat lehet e soros portként használni, azt nem tudom, de a Pk3 óta erre külön ott van a Serial Analyzer(ami gondolom sokakat zavar, ha a Pk2-be belefért akkor a többibe mért nem).

PIC24FJ64GA002 -t használok I2C master buszhoz.



Hiába küldök ki bármilyen busz jelet a vonalak meg sem mozdulnak "H" tól. Felhúzó 2K2 értékűek.
Ha teszt célból szoftver hurokban az SCL / SDA lábat General I/O nak használom és 0 - 1 billentgetem szkópon látom a négyszögjelet, tehát a port elvileg működőképes.
Ha úgy próbálkozom hogy az SDA/SCL portokat kimenetként definiálom és nullára állítom, majd ezután meghívom az I2C_INIT függvényt a I2C enable -val elengedi a lábakat és azok "H" ba mennek. Ez megint az támasztja alá hogy minden rendben működik.
Ugyanakkor busz aktivitás egyáltalán nem figyelhető meg. Egyszerűség okán a Start és Stop feltételt küldöm némi időzítés után periodikusan, (ezek nem várnak ACK -t) de ebből már semmit nem látni a buszon. Nagyon nem tudom mi lehet vele.
( A procinak 2 darab I2C portja van, ez nem csap be sajnos egyiken sincs adatjel, órát a tesztelési módszer alapján nem várok)




Van esetleg valami ötlet, mit próbáljak még ki?

A Section 19. Inter-Integrated Circuit™ (I2C™) -t használtam, mely dsPIC33F/PIC24H Family Reference Manual.
Meglehet a 24FJ nek kicsit más a programozása, de a gyári adatlap mellett tévesen 32 bites I2C adatlap jelenik meg, az MPLAB pedig simán elfogad minden utasítást felismerve a regiszter bitjeit hasonlóan a 24HJ hez. Ebből gondoltam nincs eltérés a kettő közt......

Üdv !
Keresnék itt egy szakembert, aki egy rövidke assembler fájlt le tudna fordítani PIC12F683-ra.
PicKit2 vel írnám.
Kösszi

Üdv!
Tessék a fájl!

Jól látom, hogy ezeknek (ICD3, Real Ice) a kapcsolási rajza már nem publikus?

A soros portot úgy gondoltam, hogy ne kelljen a PIC-re külön csatlakoztatnom pl. egy RS232(TTL)-USB konvertert, hanem a PICkit 3-an keresztül tudnám olvasni a PGC(TX2) lábon lévő adatokat, ami tulajdonképpen a jelenleg használt PIC-nél az EUSART2-es modul kimenete.
(Nem próbapanelen bűvészkednék, így nem tudok csak a PGD, PGC lábakra csatlakozni és kényelmetlen váltogatni a PICkit-et az RS232 konverterrel vagy párhuzamosan rákötni mindkettőt, már ha ez utóbbit szabad csinálni).

Nem publikus...

PICkit3 -mal is lehet debuggolni. MpLab -ban a Debug módot kiválasztani, debuggernek a PICkit3 -at beállítani. Képességei kicsit gyengébbek, mint az ICD3 -é, de biztosít lehetőséget adatok megtekintésére és beállítására.
A PGC ill PGD lábakon kereszül történik a nyomkövetés, amelyik típuson több pár is van, a debug konfigirációs regiszterben megadott páron megy a nyomkövetés, de programozni mindegyiken lehet.
Az uart -tal való kapcsolathoz használj más lábakat. Oda rákötheted a konvertert - nem kell cserélgetni.

Tudom, de nem real-time módban debuggol.

Ha lenne más szabad láb...

Sziasztok!

Egy érdekes hiba történt egy 18F4431 piccel. Elszállt a teljes D port, pedig csak ledek voltak rákötve 470 ohmos ellenállások keresztül, kb 6-7mA áram folyhatott csak. Bár én még ilyet sose tapasztaltam, volt hogy kisebb piceknél véletlenül rövidzárat csináltam egyik lábánál, de az egész portot sose tudtam kinyírni. De most egyszerűen nem tudok rájönni mi okozhatta, átnéztem a kapcsolást semmi hiba, semmi rövidzárlat, szóval tanácstalan vagyok. Annyi előzmény volt, hogy pár ledet megcseréltem tehát kiforrasztottam őket és megcserélve vissza, de elég messze vannak a ledek a pictől is és ezt követően még működött is, majd módosítottam a programot aminek semmi köze nem volt a D porthoz csak egy időzítést állítottam át és azóta semmi. Próbáltam az előző progival, vagy csak a D portot kipróbálni de semmi. Így csak 3 dolog jut eszembe, 1 vagy a programozó csinált valamit ami eléggé elképzelhetetlen, mert a D porthoz eleve semmi köze, vagy ESD problémák voltak, ami szintén fura, mert kisebb piceket mindig tapogattam és sose haltak meg, ez meg eleve egy nyákon, vagy gyári hibás volt.
Ötletek?

Szia!

Szerintem nézegesd még, egyáltalán nem valószínű, hogy tönkrement ( nekem még soha nem ment tönkre egy teljes port ), inkább valami kontakthiba !

Sajat magamnak valaszolok. Meglett a hiba, nagyon duhito - foleg, hogy nem az en hibam.
A .gld file-ban ossze voltak keverve a regiszterek, hibas szam volt hozzarendelve.
Egy uj .gld-vel mar helyes regiszterekre fordult. (2014 febr-i az uj gld, a regi 2010-es volt)
A microchipnek a jo edes....!

Hát... csatoltam amit logikai analizátorral látok, az sajna nem ezt mutatja.

Kipróbáltam mindent, de semmi, közvetlen a pic lábán mérek és a földhöz képest 0V a kimenet, pedig beírtam, hogy LATD=0xFF; még egy végtelen ciklust is tettem mögé nehogy valami más lelője az aktív kimeneteket. Táphoz képest pedig megvan a föld potenciál szóval olyan mintha leragadtak volna föld potenciálon.

"Nem publikus", de kis keresgéléssel meglehet találni, de ha csak nem valami apró hiba javításáról van szó, otthon utánépíthetetlen, és még program sincs hozzá.

Szia!
A TRIS regisztert is nulláztad?

Kedves brato !
Nagyon köszönöm önzetlen és gyors segítséged.
Arany kehelyre vésetem azok nevét, akik hajlandók hasonló tettekre.
Azután majd "Az elveszett ereklyék fosztogatói" nál talán unokáitok láthatják a nickneveket.

Remélem moderátor Úr megenged egy köszönetet.
Szerintem a segítő még rosszallaná, hogy segít és nem köszönik meg,
majd máskor meg nem fog ez benne a kockázat.

még mindig küzdök az I2C jeleivel.
Sokkal többet tudok a jelenségről, de még mindig nem értem azt.
Tapasztalat a következő:
Ha a szkóp tapintócsúcsát többször hozzáérintem az SDA/SCL vonal valamelyikéhez teljesen random módon néha megjelenik a kimeneti jel. Ez átlagosan kb 10 - 20 próbálkozás után sikerül is. Eleinte praktikusan KH ra gyanakodtam, de azzal zártam ki hogy mindkét lábon ugyanaz a tünet (SDA/SCL), táp elvétele és visszaadása után soha nem indul el magától (a megmozdított táp csati távol van a paneltől), valamint ha SDA elindul akkor SCL is megy és fordítva.
Kimértem az órajelet az 100 KHz en fut. Jelalak tökéletes, kapacitások nem látszanak benne. Az I2CBRG beállítás tehát jónak tűnik. DISSLW -t 1 be állítottam a 100 KHz hez ajánlott értékre. (Igaz 0 ban is pontosan ugyanúgy viselkedik)
Most úgy tűnik hogy a port számára kell valamilyen minimális terhelés változás hogy Open Collectoros kimenet tranzisztora elkezdjen kapcsolgatni.
Hát ez nagyon érdekes fejlemény számomra, örömmel venném ha valakinek lenne ötlete mi lehet a magyarázat.

Helló!

Igen, de ugyan azzal a progival még működött aztán már semmi, eddig a többi része működik normálisan legalább is az adc, a pwm és a C port, plusz még egy lcd is rá van akasztva az is működik, csak a D szállt el teljes egészében. Létezik hogy gyári hiba lenne?

Töltsd le az Errata doksit, van benne pár bejegyzés az I2C-vel kapcsolatban.