Nekem ez a kód működik az SW spi részt megoldható úgyis ahogy te csináltad, ez kicsit hw közelibb.

Header:


Source:


Szerk:
Az init kód lemaradt.


Ja és mint látod ez a kód alkalmas több max7219-es kezelésére is.
Ja és az uint8_t, ha esetleg nem ismerős unsigned char.

Köszi!
Az első verzió volt nálam is a kiinduló ... csak több hőmérsékletet kell beolvasni és a 3. sorban lévő if-nél is több feladatot kellett végrehajtani. Ezért kellett egy külön függvény ...

Második verzió: lassan azt hiszem meg kell barátkoznom a mutatókkal is ... idáig még megúsztam a használatukat! Még nem teljesen világos a dolog, valahol a mutató mutatójára mutató mutatónál elvesztettem a fonalat!

Pedig a C csodálatossága a mutatókban az indirekt címzésben rejlik. De azért nem kell mindenképpen ilyen végeláthatatlan mutató fonalat létrehozni, valahol szükséges lehet, de szerintem egyszerűbb és közép szinten nem szükséges.

Nem kell félni a mutatóktól Ez olyan, mint amikor a feleségednek nem azt mondod meg, hogy mi van a fiókban, hanem azt, hogy melyik fiókot nyissa ki. Ha ezt egy papírra írva adod át, akkor a papír egy mutató típusú változó, amire egy cím van felvésve. A változó típusa a fordítónak fontos, a tartalma (a cím, amin az érték van amit keresel) neked.

Rossz hozzáállás!
A mutatókhoz nem úgy kell viszonyulni hogy örül az ember amíg nem használja őket merthogy valamiféle nyűg lenne. Épp ellenkezőleg, majd azt fogod bánni hogy miért csak most barátkoztál meg a mutatókkal és nem jóval korábban, mivel brutálisan meg tudják könnyíteni a programozást.
A mutatók a legcsodálatosabb dolgok a világon, közvetlen a p*na után. A C-ben csodákat lehet velük művelni de nagyon bele is lehet gabalyodni sajnos. Néha már nekem is zavaros egy bizonyos szint után...

Ezt mivel lehet lefordítani?

XC8 ban írtam, ha sw SPI-t használsz
akkor a header-ben

A hw SPI-hez meg kell egy inicializálás.

Sikerült működésre bírnom. Köszönöm a segítséget. Egy utolsó kérdésem lehet? A 18-as láb mirre való? Nem igazán értem, amit az adatlap ír.

Az ISET, az adatlapban le van írva, hogy milyen ellenállás értékkel, mekkora lehet a maximális átfolyó áram a LED-eken.

Nem teljesen értem. Hogy a félkövérrel szedett rész mi? Ha 40mA folyik be, akkor 12.2mA-t enged a ledekre 1,5V mellett?

Az nem mA, a táblázaton belül az van, hogy a 40 mA szegmens áramhoz 1.5V LED-el az ISET lábat 12.2kOhm-al kel felhúzni.

Köszönöm!

Sziasztok!

XC16 fordító, 24EP512.. család.
Erre a sorra:

miért mondja a fordító hogy:


miközben így teljesen ok:


emCANrecAdd1 egy uInt kétdimenziós tömb egy eleme #define-al "elnevezve", de ez irreleváns, mert az alsó verzióval tökéletes. A kérdés inkább az, hogy mit nézek el, miért nem ugyan az a kettő?

Az & akkor kéne ha, pl.: int*/int** lenne hanem mondjuk egy int változó és annak a címét szeretnéd megkapni pl.:


így jónak kell lennie:

emCANrecAdd1 egy uInt tömb egyik eleme, és abban, illetve a tömb következő elemeiben most éppen egy - egy memóriacím van. Én az emCANrecAdd1 -edik tömbelem után i-vel következő tömbelemben lévő memóriacímre kell hogy írjam DataWord -őt.
Tehát a tömbben emCANrecAdd1 után i -vel van egy mutató, ahová az mutat, oda kell hogy kerüljön DataWord. Működik is rendesen a 2. verziómmal, csak nem értem mi baja van a fordítónak az elsővel.

Ha egy uInt tipusu valtozoban cimet tartasz (de miert?), akkor azt cast-olas nelkul nem hasznalhatod cimnek. Igy lesz jo:

A változók CAN buszon érkeznek külső egységektől, ezek kerülnek a tömbbe. Csak később, futási időben derül ki, hogy ami érkezett az mutató, adat, vagy kiskacsa.

Igen, kipróbálhattam volna a cast-otlást, csak gondoltam hogy egyértelmű kellene legyen a fordítónak hogy mit akarok. Köszi!

Az volt a furcsa, hogy ilyenkor megoldotta a fordító magától:

Ha CAN buszon memoriacim erkezik, akkor ott valami mar regen rossz...Mert sz@r az IDE es nem kapcsolja be az erre vonatkozo Warningot. Esetleg kikapcsolja, mert ez default-bol Warning a gcc-n.

Szerintem az a cím nem olyan cím, amilyenre te gondolsz.

Hat milyen cim? Ha egyszer dereferencialja, akkor az olyan cim. Pointernek hasznalja, adatot tesz arra a cimre.

Ok, de miért lenne ez rossz?

Mert egy pointer az az adott program legbelso maganugye. Barminek megvaltozhat a cime egy ujraforditasnal, ezert kulso eszkozok nem tudhatjak, hogy neked a memoriaban hol mi talalhato. Hacsak nem debugger vagy esetleg firmware upload a kerdes targya, nem hiszem, hogy nincs ra jobb megoldas, mint memoriacimeket kuldozgetni CAN buszon.

Mindig van jobb megoldás, de nem mindig vagyunk elég okosak hozzá...

Uraim, lenne egy kérdésem, vagy is segítséget kérnék, mert kicsit beragadt most az agyam.
Van egy szöveg, (string) tömb, amelyben egy szöveg van.
pl.: "Valami Amerika"
Ezt a szöveget kellene nekem teljesen nagybetűssé alakítani.
Tehát a végeredmény: "VALAMI AMERIKA"

Erre hoztam létre 2 tömböt, egyet kicsi betűkkel, egyet pedig nagybetűkkel.


Az elméletem az lenne, hogy a tömb tartamát egyesével vizsgálom, majd ha egyezést észlelek kisbetűnél, akkor kisbetűt cserélem a nagy párjával..., és így tovább.

Miközben írtam ezt a bejegyzést eszembe jutott egy alternatív megoldás, ami szintén nem jött be most:
Így próbálom nagyra konvertálni, ami működik is, csak az a baj, hogy ha nagy 'A' betű kerül bele akkor is lefut a feltétel és vissza konvertálja kicsire..
Kérném a segítségeteket.

Közben rájöttem, hogy hiányzik a zárójel.
Így már működik..

Szia!

Teljesen igazad van. Tulajdonkeppen csak az if(...) es n ^ 0x20 helyett hasznalhato standard C fuggvenyekere akartam felhivni a figyelmet.

Sziasztok!

Egy 18F4431-es picre írok programot C-ben C18 fordítót használok, a pic 40Mhz-ről futna. Egy olyan problémám van, hogy a beállított megszakítás ideje nem annyi, mint amennyinek kiszámoltam. Biztos, hogy jól számoltam, és sehol máshol nem változtatok a timer1 értékén csak a megszakítás elején kapcsolom ki egy rövid időre amíg pár feltételt vizsgálok, majd megkapja az új értéket és elindítom.
A kérdés az, hogy hol lehet olyan rész ahol a timer1 nem számol. Amikor túlcsordul a számláló belép a megszakítás rutinba ez nem tudom mennyi időbe kerül, illetve amíg beírom az új értéket addig is vesztek időt. Sajnos az mplabban nem jöttem rá, hogy hol lehetne lemérni azt az időt amíg a számláló túlcsordul és az új érték belekerül a timer1-be és ismét elindul.
Proteusban annyi le tudtam szimulálni, hogy a megszakításban amíg belekerül az új érték a timer1-be és elindul kb. 4usec, de kb. 20usec csúszásom van összesen. Jó lenne megtalálni az okát.
A program megszakítás része ami a timer1-et érinti:

#pragma code high_vector=0x08
void interrupt_at_high_vector(void){
_asm goto Timer1_ISR _endasm
}
#pragma code
#pragma interrupt Timer1_ISR

//HIGH Priority Interrupt
void Timer1_ISR(void){

//TIMER1 INTERRUPT
PIR1bits.TMR1IF=0;
T1CONbits.TMR1ON=0;

if(switch1==0 || switch1==1 && run!=9){
TMR1H=(Timer_low_freq[POT2]>>8);
TMR1L=Timer_low_freq[POT2];
}

else{
TMR1H=(Timer_high_freq[POT2]>>8);
TMR1L=Timer_high_freq[POT2];
}

T1CONbits.TMR1ON=1;

Ez a rész kb 4-5usec alatt lefut, ha az if feltétel teljesül, ha nem akkor kb 2usec, de ezt is csak a proteusban szimuláltam egy kimenet be-ki kapcsolásával. Márcsak a maradék hiányzó 16-18usec okát kellene megtalálni. maga az idő amit beállítok mindig változik, de kb. mindig 20usec-ig tovább számol, szóval ki lehet kompenzálni, csak kíváncsi lennék mit nem vettem figyelembe.

Szia!

Az MPLAB-ban nagyon jó a szimulátor, melyiket használod ( IDE vagy MPLABX ) ?!