Azt nem írtad melyik fordítóhoz (mert eltérnek egymástól a megvalósíthatóság szempontjából).

Köszi, kielemzem.

Amit én raktam össze, az is működik, csak paraméterként nem lehet használni. Nem tudom, az általad beírtat lehet-e?

Valóban nem írtam a környezetet, mert úgy gondoltam, a makró kérdés minden C-re vonatkozik, nem csak PIC fejlesztő környezetre.

A konfig A-Z-ig: Lenovo T400 notebook, Debian 10 oprendszer, MPLAB-X V5.25, XC32 V2.30 rátöltve a PIC32 Legacy Peripheral Libraries a PIX32MX procikhoz. De ezzel a makro szöszöléssel már régebben is próbálkoztam.

XC32-t nem használtam (és a közeljövőben jó eséllyel ne is fogom, mert áttértem ARM-re), de az XC8 és az XC16 (meg az ARM GCC is) megeszi a fenti paraméterezési módszert (az kimaradt, hogy a 13-15 sor már valamelyik függvényen belüli felhasználását mutatja). Ha a példában szereplő LED-et pl. az RA3 helyett az RC7 lábra szeretnéd kötni, csak az 1. sort kell megváltoztatni:

Igen, ezt értem. Csak játszogattam arduinoval is, nem tudom, használtad-e, (ha nem,) ott a pinek kaptak egy-egy számot, azt paraméterként át lehet adni a konstruktornak. Az általad adott szerint persze meg tudom oldani, csak amilyen lökött vagyok, szeretném paraméterként, ahogy az arduinoban. Próbáltam visszakövetni, hogyan működik az I2C1, I2C2, de nem tudom teljesen visszakövetni. Belefutok olyan makróba? változóba? amit sehogy nem találok meg, azt nem tudom a környezet mi módon hozza létre. Sem *.h.ban, *.c-ben, *.cpp nem találom meg.

A do while re egyszerű a válasz így nem tudod beírni feltétel vizsgálathoz.

Annyira nem foglalkoztam arduino-val, de azt tudom hogy sima számokkal lehet megadni a lábakat. Ha nagy és lassú kódot akarsz gyártani magadnak, akkor PIC-re te magad is megvalósíthatod. Amúgy táblázatban vannak a lábszámokhoz tartozó PORT és láb összerendelések (pins_arduino.h), amit a wiring_digital.c-ban levő pinMode, digitalWrite, digitalRead függvények fognak majd felhasználni.

Nem szeretnék nagy és lassú kódot, épp azért gondoltam makróra. Más módon már megoldottam, de az tényleg behozott plusz kódot, ezt szeretném elkerülni.

Sziasztok!
Lehet hogy volt már kérdés, de nem találok rá választ. Hogyan lehet egy tömbben tárolni a PIC I/O lábaira való hivatkozást tömbelemként?
pl.:
Ha ez így menne és el tudnám érni a pineket mint tömbelem, vagyis a tömb[n] egy i/o lábnak felelne meg sokat lendítene a helyzetemen és a kód újrahasznosíthatóságán is
Nem tudok rájönni hogy mi a megoldás. (XC8 és az igazi az lenne ha egy heder fileban tudnám megoédani a tömb definiálást)

Ez az oldal pont erről szól, olvasd el. A kérdés az, hogy lassú és nagy kódot szeretnél futásidejű láb hozzárendeléssel (mint az arduino esetén), vagy gyors kódot fordításidejű láb hozzárendeléssel (ez utóbbihoz ott példa az oldal tetején, de így nem tudod tömbbe tenni, hanem #define -t kell használni az összerendeléshez).

Csak egy észrevétel... Az hol van?
Mos épp egy hibrid megoldás lenne az aktuális. Lehetőleg gyorsnak kéne lennie. Ha nem tudom tömbbe rakni hát egye fene megoldom define-al, csak úgy valami ronda lesz a kód. De ha nincs más.... PIC16-al közdök és a modulok ki/be menetei ragaszkodnak az adott ládhoz. Ezért gondoltam hogy leteszen egy tömbbe, és a tömb indexe átlátható és kezelhető is.
Ugyan a define sem rossz, de azt kicsit macerásabb ciklusba kezelni, agyonmakrózni meg szintén nem akartam.
Azért "azt az oldalt" közkincsé tennéd? Köszi!

Az "ez az oldalra" alatt a "PIC programozása C nyelven, C-Compiler" topic 144. oldalára gondoltam (vagyis arra, ami éppen előtted van, illetve a kezdeménye visszanyúlik az előző oldalra is).

BOCS!!

A C nem ad igazi lehetőséget erre.
PIC16-on ez azért mindenhogyan érdekes játék mert nem egy "erőgépről" beszélünk.

Itt a define a legjobban járható út mert azzal is tudsz dinamikus hozzárendelést csinálni csak kell egy config header ami projekt függően configurálható.
(ez C++ nem igazán járható)

A ciklus fogalma arra utal (számomra), hogy mondjuk egy párhuzamos bus szerűséget vezérlenél arra a legjobban perifériával jársz.

Pár software-es megoldás:






Az utolsó eset persze csak akkor működik, ha a LAT register-ek címfolytonosak a memóriában.
Valamint a bank váltás is be zavarhat a képben rég forgott a kezemben 16F nem tudom, hogy ő pointerről tudja e hogy melyik bank-ban kel turkálnia.

Sziasztok szakértők!
Alakul a project (legalábbis vannak modulok amik működnek vagy igen igéretes) de egy "apróság" nem hagy nyugodni. Nem hiszem el hogy az XC8 (lehet hogy a többi is, eddig nem prábáltam csak a 8 bitestt) fordítóban ne lehetne valahogy eltüntetni a felesleges warningokat amik a karakter kódolás miatt vannak (kép).
Hiába állítom be a projectnej hogy ISO-8859-2 kódolású, nem érdekli.
Már felmerült bennem az is hogy az unsigned char 7 bites....
Tényleg érdekel hogy van e rá valami emberi megoldás hogy aforrás is olvasható maradjon és a fordító se dödörögjön.
Most épp az LCD-nél tartok. Szeretném az üzeneteket legalább közel helyesen megjeleníteni, de ehez saját karakterekre van szükség. Azt szeretném megoldani hogy futás időben cserélje le az ékezetes karaktereket a GGRAM-ra, de a fordító hisztis tőle (és més stringektől is amik ékezetes kaaktereket tartalmaznak).
Ha beírom pl az Ű helyett hogy 0xFB azzal nincs baja a fordítónak, de ember legyenaki el tudja olvasni a forráskódot. Megcsinálni ugyan megcsinálja, de ha valahol maradt egy hiba, azt a sok warning közt nem egyszerű megtalálni, és ahogy a project fejlődik egyre csak szaporodnak a gyakorlatilag információ értékkel nem bíró warningok.
Hogyan tudnám ezt kikapcsolni? Nincs száma, csak úgy van, az összes warningot pedig nem akarom elnyomni, mert van ami sokat segít.
Osszátok meg velem az okosságot, mert nem hiszem el hogy nincs, legfeljebb tudatlan vagyok.

Köszönöm! Ígéretesnek tűnik, de csak később térek rá vissza.

Üdv!

Tömböt szeretnék létrehozni változókból. Régen csináltam, már nem emlékszem hogy oldottam meg.
Tehát van a_1, a_2, ... a_n
ebből valami[n] = {a_1, a_2, ...a_n)
Régen megoldottam, de nem tudom már hogy mutatókkal, vagy u nionnal vagy hogyan.

szerk: U_nion miért tiltott? Ha egybeírom üres üzenetet ad....

Szia!

Ezek a változók hogyan helyezkednek el a memóriában és milyen típusúak ( egyformák vagy nem ?!
Ha egymás után és egyforma típusúak, akkor az már egy tömb, csak az első változóra kell egy megfelelő típusú pointert csinálnod, ha nem, akkor egymás után kell őket elhelyezned, egyforma típusra hozva és utána ugyanaz szerintem !
Vagy egy új tömbben tárolod mindegyiknek a címét és azt veszed elő egy-egy pointerrel...

Szia!

Köszönöm a válaszod.
Két tömböt kellene kreálnom. Mindkettő 7 elemű. Az egyikben bool elemek vannak(nem tudom ezt, a másikban int vagy uint, még nem döntöttem el engedek e negatív értékeket.
Igaz nem egészen ide illik ugyanis nem PIC-re megy, de sima "C" téma nincs és feltételezem a fordítók hasonlóan működnek(nagyrészt).
ESP-re megy majd Arduino IDE alatt ami ugye C++ -t használ.
A PIC-en is úgy emlékszem pointerrel csináltam meg anno, de ahhoz most nem férek hozzá.

Arduino array

Köszönöm, de a sima tömbökkel eddig sem volt bajom.
Mint írtam a legelső hozzászólásomban, változókból akarok tömböt készíteni.

Na. Úgy látom az Arduino IDE lekezeli azt amit a PIC-en mutatóztam. Még nem tudom hogy fog működni, de elfogadja a változókat tömbelemekként.

Ok! Bocsánat, én nem figyeltem eléggé!

Arra viszont kíváncsi lettem hogy ez mire is jó?

Olyan változókat tömbbe rendezni amik valamilyen okból alapból nem deklarálhatóak egybe, hogy később pl ciklusokban könnyű legyen őket kezelni. Nálam pl az arduino ide mextion könyvtára nem hiszem hogy tudná tömbelemekként kezelni a Nextion touch event elemeit, viszont ha az egyes változókat tömbbe rendezem, akkor for ciklusokban tudom őket kezelni.

Nem teljesen értem a kérdést eddig.
De a nextion-ból kb értem mit szeretnél.
A nextion-nál ugye mindig van egy header ami specifikálja, hogy milyen adattípus érkezik.
Csinálsz egy struct-ot a touch event-re (a packed csak akkor kel ha nem 8 biten vagy)



majd olvasod a byte stream-et (a buffer méret és a körkörös olvasás nincs a példába kezelve)


A kérdésed amiért nem értem én nem tudok róla, hogy ne lehetne típust egybe deklarálni így nyugodtan megteheted:


És az inicializálása


Remélem valamelyik megközelítés választ ad a kérdésedre vagy teljesen félre értettem

Szerintem félreértetted, de nem baj. Én sem voltam érthető valószínűleg.
A kérdés ez volt:
plp:

Akarmi is legyen a paros, pratlan es prim valtozo értéke amit pl egy-egy külön funkció generál vagy akár egy bemeneti analóg jel, tudjam őket kezelni egy for ciklusban. Igaz, a külön-kkülön függvényeknek is megadhatnám a tömbelemet vagyis hogy ne a paros, paratlan es prim szamoknak adjakt at az erteküket hanem a tömb elemeinek, de ha az már egy meglevő kód, vagy esetemben egy Arduino library elemei akkor az nem olyan egyszerű. Mindenesetre ha feljebb olvasol ez megoldódott, mert az Arduino IDE elfogadja a változókat tömbbelemekként. A MC "C"0 fordítói ugyebár nem

Így világos, pöppet elnéztem.
Amúgy ARM-ra GCC fordítja és az XC32 (aszem az is GCC "alapú") is probléma nélkül, ha XC8-at használsz arra nem tudok mit mondani elég rég nem láttam már.

Üdv!

Ismét egy tömbös kérdés. Bár nem PIC-re megy, hanem Ardura, de C, C++.
Szabályszerűtlenül ismétlődő elemet, vagy elemeket fel tudok tölteni a tömbbe for-if kombináció nélkül? Tegyük fel van egy 100 elemű tömböm: uint8_t tomb[100]
Ezt mondjuk fel akarom tölteni a következővel. Akár ez is lehet egy tömb: uint8_t segment[4]={0, 100, 30, 0}
A feltöltést pedig úgy szeretném, hogy ez legyen mondjuk tomb[0-3, 16-19, 40-43, 84-87].
Kicsit bonyolultabb lesz, mert 6000 byte-os tömböt kell feltöltenem és lesz vagy 8 szegmens, (nem biztos, hogy 4 elemű), de a folyamat időkritikus ezért nem biztos, hogy a for ciklusba ágyazott milliónyi if, vagy switch case megfelel a követelményeknek. Még valami memcpy-s megoldáson gondolkodom, de még nem ötlöttem ki az hogy tudna jól működni.

Gugli a barátod Keresendő szöveg: "C array random fill"
Ha van random szám generátor a chipben akkor egyszerű a dolog.
Kicsit gugliztam és Arduino alatt is van random szám generátor.
Méghozzá pont ami neked kell:
random(max)
random(min, max)
https://www.arduino.cc/reference/en/language/functions/random-numbe...andom/
8 for ciklusban megtudod csinálni vagy egyben és 7 if feltétel.

Elolvastad amit írtam? Értelmezted?
Vizualizálom neked. Maradjunk a 100-nál mint tömb. Van mondjuk egy 100 LED-es LED-sor. Ebből mondjuk a következőket akarom
zöldre: 1. csoport: 1,7,10,18,20,37,50,72,95
kékre: 2. csoport: 3,5,12,26,38,41,63
pirosra: 3. csoport: 2,6,17,29,43,59,76,88,98
És akkor van jónéhány szín, valamint a csoportok nem fixek, hanem változtathatóak egy bemeneti adathalmazzal, de ez már egy más téma.
Na valmi ilyesmit kell elképzelni, csak az elemek nem színek hanem bájtok, (byte tömbök), stb.
Na ezt oldd meg for-al meg if-el.

Mi a bajod a for használatával?
Egyébként memcpy, memcpypgm2ram, memcpy_P
----
Azt hiszem sejtem mit akartál kérdezni. A fent írt rutinokat tudod használni.