Egy kis eligazítást szeretnék kérni.
plib.h - mi a különbség az alábbiak közt? (Legyen pl. B regiszter.)
egyik:
másik:
Mondjuk az első tiszta, '1'-be állítja a port megadott bitjeit. De mit csinál a másik? Az alig angolommal próbáltam megfejteni, ez talán írja az egész regisztert? Akkor miért lehet biteket megadni, mire állítja az adott biteket?
A doksiban az utóbbira van más példa is, az azt sugalja, az adott értéket beírja az adott regiszterbe. De akkor az előző példa szerint mit jelent ha biteket adok meg?

Hát nem sok infót adtál meg...
De egyébként végtelenül egyszerű szerintem. Egyszerűen a portra (ami ha jól látom, 16 bites) kiírja a paraméterben megadott értéket. Az, hogy van köztük egy VAGY művelet, nem jelent semmi extrát, elvégzi a műveletet, és kész. Gondolom a "BIT_1" értéke (decimálisan) 2, a BIT_3 értéke 8 .. és így tovább. Ezek VAGY művelettel 26-ot adnak, vagyis binárisan: 00011010 (jobbra az LSb). Kvázi ugyanaz lesz az eredménye, mint a setbites műveletnek.
De lehet rossz a gondolatmenetem.
Viszont ha meg tudod nézni a dissasembly részt, akkor abból abszolút kiderül.

A port setbits 1 be allitja a biteket (lennie kell clear bitsnek is)a port write egyenlővé teszi a LATB/PORTB az adott értékkel (szerintem).

Valóban van PORTClearBits is.

Kiépített regiszterek vannak ezen műveletek elvégzésére:

Egy kérdésen töröm a fejem, és kicsi tapasztalati segítséget szeretnék kérni hozzá.

A 32 bites pic családokban van egy periféria, ami a controller area network nevet viseli. Látta már bárki bárhol bármire felhasználva azt a perifériát? Mire jó a gyakorlatban?

Ez a CAN busz, főleg a gépjárműiparban leginkább elterjedt kommunikációs szabvány. A 8 bites 18F-nél is van. Elég bonyolult, elsőre kb. átláthatatlan, viszont nagyon megbízható rendszer, ezért is használják a gépjárműveknél. Olvasnivaló.

Most nem tudom, hogy nézted-e, összeolvasva ez a CAN vagy a LIN(LocalIntercorrectNetwork) autókban használják főleg és a CAN-ről úgy emlékszem gyárakban is ezt használják kommunikációra.
Hobbi szinten szerintem csak érdeklődésből van értelme vele foglalkozni (nem biztos).
De mind két bus async diff bus tehát egy RS232-nél jóval zavarmentesebb, megbízhatóbb.
Szerk.:
Elnéztem a LIN nem diff bus

A tippeket köszönöm, az absztrakt olvasnivalókat már megtaláltam. A fizikai réteg konkrétumaiból viszont nem sokat. Amit mégis sikerült találni, abból úgy tűnik, hogy egy egyvezetékpáros rs485-höz hasonlító valamire raktak rá absztrakt rétegeket, és mellé raktak opcionálisan távoli perifériáknak tápfeszültség ellátást is. Mennyire vagyok eltévedve a lényeget illetően?

Amit linkeltem, ott ez is le van írva. Egyébként igen, az RS485 protokoll is használható.

Talán a legfontosabb, hogy be van építve hardveres hibakezelés és javítás. Legalább is ezt olvastam, de még nem használtam. Az RS485-ből ez hiányzik, még is ipari szabvány, igaz, rajta keresztül nem vezérelnek semmit, csak alapjeleket és monitorizálást végeznek rajta keresztül, valamint adatbegyűjtésre használják. A fő szabályzó rendszereket hardveresen oldják meg, legalább is a komolyabb szállítók esetében. De ez érthető is. A CAN próbál túllépni ezen, de valójában itt se bíznak rá életet veszélyeztető beavatkozó rendszereket. Az most is hardveres egy autóban. A CAN legfeljebb összegyűjti a megjelenítéshez az adatokat illetve lámpák, ablakvezérlések, és hasonló körök vezérlésében kap szerepet.

Az RS485 pusztan a legalso szinu HW atvitelt definialja, semmi mast.

A HW-es megvalositasban van egy oriasi kulonbseg a sima differencial atvitelhez kepest. A CAN buszon ugyanis a CANH jel csak +tapra mehet, a CANL jel pedig csak GND-re. Es a vonal le van zarva mindket vegen 124 Ohm-mal. Ezert, ha meghajtod, akkor ~5V van a ket er kozott, ha nem hajtod meg, akkor 0V. Ez kicsit olyan, mintha open kollektoros megjatas lenne (valojaban az is), de egyszerre ket vonalon, csak ellentetes iranyba. Es vagy mindketto vonalat meghajtja, vagy egyiket sem. Felallapot nincs. A lenyeg, hogy adas kozben az ado folyamatosan figyeli a vonalat es ha nem az van rajta, amit ratett, akkor azt eszreveszi, es ezzel pl. arbitraciot valosit meg. Merthogy a CAN busz alapvetoen egy multidrop busz, es egyszerre tobben is elkezdhetnek adni rajta. Eleg bonyolult protokoll.

Sziasztok!

Egy kis segítségre lenne szükségem, mert nem bírok a linkerrel.
Mplab x és c18-on írom a programot. Létre szeretnék hozni egy char mmcadat[512] tömböt.
Ez még sikerül is.

DATABANK NAME=large_udata START=0x200 END=0x3FF PROTECTED
//DATABANK NAME=gpr2 START=0x200 END=0x2FF
//DATABANK NAME=gpr3 START=0x300 END=0x3FF

#pragma udata large_udata
unsigned char mmcadat[512];
#pragma udata

Rendesen működik.

De ha pickit2-vel debugolni akatok akkor a szimulátorba lépéskor a linker hibát ír.

Error - section 'large_udata' has a memory 'large_udata' which can not fit the section. Section 'large_udata' length=0x00000200.

Hogyan tudnám ezt megoldani? Lehet már annyi változót deklaráltam, hogy nem fér már el a debugoláshoz szükséges rész a memóriában? Hol tudnám megnézni, hogy mennyi helyem van még?

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

Nem adtad meg a PIC típusát, így magadnak kell utánanézni, hogy a linker hová helyezi el a debugoláshoz lefoglalt memóriát, illetve a C runtime STACK területet.

Az a gyanúm, hogy DEBUG opcióval fordítva ezek valamelyike belelóg a tömbödbe. A linker állományt kellene gondosabban tovább szabni a probléma elhárításához.

Köszi a gyors választ! Pic18f4550 a típus. A linket a gpr2-be akarta rakni a debug változóit. Én átraktam a gpr1be. De csak azért így próbálom,mert a large-udata-t valamiért nem tudom máshová rakni. Ha gpr3-4 próbálom összevonni azt sem fogadja el. Ugyan az a hibaüzenet.

A 4550-nel az a baj, hogy a RAM második felét az USB buffereknek rezerválja, az első felében meg verseng az összes többi.

Ha jól olvasom az adatlapot, akkor az a baj, hogy rendelkezésre áll 2048 byte RAM terület. De ha usb-t használ a program, akkor a felső 1024 byte a kapcsolathoz automatikusan lefoglalódik. Ehhez jön még a debugger változói. Így már valóban nem fér el az összes változó.
Szerintetek ki lehet ezt játszani valahogy? Gondolom az usb területet valahogy felül lehetne írni futás időben. Arra gondoltam, hogy lokális változót hozok létre abban a függvényben ahol kell az 512byte-os változó. Csak hogy adhatnám meg, hogy az az usb-nek lefoglalt területre essen?

Egyszerre írtuk.
Szerinted lehetséges amit írtam? A lokális változónak futás időben kellene lefoglalódni.

Workaround:

1. Ne használd az usb perifériát és nincsen gond.

2. Ha bekapcsoltad, de átmenetileg nem kell, kapcsold ki. Persze akkor usb init meg minden újra fog majd futni, megszakad a kapcsolat a számítógéppel, és az neked vagy elfogadható, vagy nem.

3. Az usb használat ping-pong buffereléssel zajlik, ami azt jelenti, hogy van az usb periféria memória területén is mindig olyan terület, amit éppen használhatsz. De nagyon ki kell centizni olyasmivel vacakolni. Csak akkor kotorássz az után, ha fixa ideás mazochista vagy.

4. Miért is ragaszkodsz egy kicsi pic-hez, amikor a nagyobb sem jelentősen drágább? Van élet a 4550-en túl is.

Workaround 2:

5. Hány USB adatpontot használsz? Ha nem használod mind a 16 -ot, a nem használtak bufferét más célra fel lehet használni.

Üdv! Sajnos már megint elakadtam.
C++-t eddig csak az Arduino környezetben használtam, a c++ tudásom csak ami ott rámragadt. Most MPLAB X 3,10, XC32 1.40 alatt próbálkozom.
A "LiquidCrystal.h" file-ban:

A "LiquidCrystal.cpp" file-ban:

Az rB0-rB15 nem c++-ban már kipróbálva, működik.

A "main"-ben a hibajelzést kiváltó sor:


A hibajelzés:
"/home/andras/MPLABXProjects/LCD_170_cpp.X/LCD_170_cpp.cpp:46: undefined reference to `LiquidCrystal::LiquidCrystal(unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int)'"

Valamit kihagytam, rosszul írtam? Nem tudom, ez elegendő infó e a probléma kitalálásához, nekem sajnos nem sikerült.

A fordító nem feltétlen olyan sorrendben megy a file-jaidon, ahogyan a függvények prototípusát felsoroltad. Olyan helyen hivatkozol a függvényre, ahol a prototípus nem ismert. Header file problémába ütköztél.

Általában megoldás az összes header file-t #ifdef / #define /#endif burokba csomagolni, behúzni mindet egy újabb header-be, és azt beinclude-olni minden file-ba a legelején.

Köszi a gyors választ!
Az #ifndef/#define/#endif eddig is benne volt minden header forrásomban. Most megcsináltam az egybegyűjtő header file-t, de továbbra is maradt a hiba.
Viszont egy kósza ötlet folytán include-oltam az LCD cpp-jébe is a plib.h-t, és ez megoldotta a kérdést. Eddig azért nem gondoltam rá, mert az LCD cpp-jébe be van include-olva olyan header, ami include-olja a plib.h-t, mert arra épül.
A lényeg, hogy most OK!

(Javítani már nem tudom az előző hozzászólásomat.)

Sajnos tévedtem, nem lett hibátlan. Csak valamiért kikomenteztem a konstruktor hívását, azért fordult hibátlanul.
Egész délután próbáltam guglizni valami XC32-es c++ mintát, de sajnos nem találtam.

A ctor-al szerintem semmi baj nincs.
Valami include probléma lesz. A projektben, hogyan van elhelyezve a LiquidCrystak.h?

Épp most kezd tiszta lenni, hogy valami beállítás. Csináltam egy baromi egyszerű c++-os programot include-olt header és cpp forrással. Addig jó volt, míg ezek is a projekt könyvtárában voltak. Sima c esetében már sikerült jól beállítani a saját forrást tartalmazó saját library könyvtárat, de úgy látszik, c++ esetében még valahol máshol is be kell írni.

Ne a GCC-t állítsd be hanem a G++-t.

4 helyen van beállítva a saját include könyvtár:

Project Properties:
- General / Source folders
- xc32-gcc / Preprocessing and messages / Include directories
- xc32-g++ / Preprocessing and messages / Include directories
- xc32-ld / Libraries / Library directories

Hol kéne még beállítanom?

És a *.cpp file a projektbe be van húzva?