OK Mégsem
Fórum témák

» Több friss téma
Fórum
Keresés
Lapozás: OK   1 / 1225
(#) Laja1 válasza Laja1 hozzászólására (») Márc 27, 2026
Amit még nem írtam le, hogy a rádió előtt közvetlenül van a tápon egy 100nF és egy 10µF kondi is. A kijelző és az érintés is ugyanezen a SPI kommunikáción megy és azok jól működnek. Kipróbáltam azt is, hogy ha az nrf-t használom, akkor először (bolondbiztosan) a TFT és az érintő CS vonalát 1-re állítom. De nem okozott változást.
(#) Laja1 hozzászólása Márc 27, 2026

NRF24 inicializálás

Sziasztok!
Tudna valaki segíteni, hogy mi lehet a gond? A rádiós (nRF24L01 modul nyák antennával 2.4GHz) modul nem működik. Figyelem szkóppal a MOSI, MISO jeleket. A MOSI jelek szépen kimennek, az első byte-ra a modul szépen válaszol 0x0E jellel, de a második byte-ra már 0x00 a válasza! És ez minden byte-párosnál így van. Ahol pedig egymás után 6 byte-t kell küldeni, ott az elsőre 0x0E a válasz és az összes többire 0x00. Így nem tudom a modult inicializálni, tehát nem is működik. Hol lehet a hiba? Ez a kódrészlet:
  1. #include "nrf24.h"
  2. #include "spi.h"  
  3.  
  4.  
  5.  
  6. static void csn_low(void)  { NRF_CSN_LAT = 0; }
  7. static void csn_high(void) { NRF_CSN_LAT = 1; }
  8. static void ce_low(void)   { NRF_CE_LAT = 0; }
  9. static void ce_high(void)  { NRF_CE_LAT = 1; }
  10.  
  11.  
  12.  
  13. static void nrf_write_reg(uint8_t reg, uint8_t val) {
  14.    
  15.     csn_low();
  16.     __delay_us(10); // Várunk egy kicsit az ébredésre
  17.    
  18.     SPI_Transfer(W_REGISTER | (REGISTER_MASK & reg));
  19.    
  20.     __delay_us(10);
  21.    
  22.     SPI_Transfer(val);
  23.    
  24.     __delay_us(10); // Biztonsági szünet a lezárás előtt
  25.     csn_high();
  26.    
  27. }
  28.  
  29.  
  30. static void nrf_write_regN(uint8_t reg, const uint8_t *buf, uint8_t len) {
  31.    
  32.     csn_low();
  33.     SPI_Transfer(W_REGISTER | (REGISTER_MASK & reg));
  34.     for (uint8_t i=0; i<len; i++) SPI_Transfer(buf[i]);
  35.     csn_high();
  36.    
  37. }
  38.  
  39. static void nrf_command(uint8_t cmd) {
  40.    
  41.     csn_low();
  42.     SPI_Transfer(cmd);
  43.     csn_high();
  44.    
  45. }
  46.  
  47. void nRF24_init(bool tx_mode, uint8_t channel) {
  48.     // A TRIS beállításokat a SystemInit vagy SPI_Init már elvégzi,
  49.     // de a CE és CSN lábakat itt inicializáljuk:
  50.     TRISAbits.TRISA1 = 0; // CSN kimenet
  51.     TRISAbits.TRISA2 = 0; // CE kimenet
  52.    
  53.     csn_high();
  54.    
  55.     ce_low();
  56.     __delay_ms(100);
  57.  
  58.     uint8_t addr_tx[5] = {'M','A','S','T','R'};
  59.     uint8_t addr_rx[5] = {'S','L','A','V','E'};
  60.  
  61.     nrf_write_reg(EN_AA, 0x00);
  62.     nrf_write_reg(EN_RXADDR, 0x01);
  63.     nrf_write_reg(SETUP_AW, 0x03);
  64.     nrf_write_reg(RF_CH, channel);
  65.     nrf_write_reg(RF_SETUP, 0x06);
  66.     nrf_write_reg(RX_PW_P0, 2);
  67.  
  68.     if (tx_mode) { //Amikor a display parancsot küld
  69.         nrf_write_regN(TX_ADDR, addr_rx, 5); // A cél a SLAVE
  70.         nrf_write_regN(RX_ADDR_P0, addr_tx, 5); // A válaszokat a saját (MASTR) címén várja
  71.         nrf_write_reg(CONFIG, 0x0E); // TX
  72.     } else {
  73.         nrf_write_regN(TX_ADDR, addr_rx, 5);
  74.         nrf_write_regN(RX_ADDR_P0, addr_tx, 5); // Saját maga (MASTR) után fülel
  75.         nrf_write_reg(CONFIG, 0x0F); // RX
  76.     }
  77.  
  78.     nrf_command(FLUSH_TX);
  79.     nrf_command(FLUSH_RX);
  80.     nrf_write_reg(NRF_STATUS, 0x70);
  81.     if (!tx_mode) ce_high();
  82.    
  83. }
  84.  
  85. void nRF24_setMode(bool tx_mode) {
  86.    
  87.     ce_low();
  88.     if (tx_mode) nrf_write_reg(CONFIG, 0x0E);
  89.     else { nrf_write_reg(CONFIG, 0x0F); ce_high();
  90.    
  91.     }
  92. }
  93.  
  94. void nRF24_send(uint8_t value) {
  95.    
  96.     ce_low();
  97.    
  98.     csn_low();
  99.     SPI_Transfer(W_TX_PAYLOAD);
  100.     SPI_Transfer(value);
  101.     csn_high();
  102.  
  103.     ce_high();
  104.  
  105.     __delay_us(20);
  106.     ce_low();
  107. }
  108.  
  109. bool nRF24_dataReady(void) {
  110.     uint8_t status;
  111.    
  112.     csn_low();
  113.     status = SPI_Transfer(NOP);
  114.     csn_high();
  115.    
  116.     return (status & (1<<6)) ? true : false;
  117. }
  118.  
  119. void nRF24_powerDown(void) {
  120.    
  121.     ce_low();
  122.     nrf_write_reg(CONFIG, 0x0C);
  123. }
  124.  
  125. void nRF24_powerUp(bool rx_mode) {
  126.     if (rx_mode) {
  127.         nrf_write_reg(CONFIG, 0x0F);
  128.         ce_high();
  129.     } else {
  130.         nrf_write_reg(CONFIG, 0x0E);
  131.     }
  132.     __delay_ms(2);
  133. }
  134.  
  135. bool nRF24_getData2(uint16_t *value) {
  136.     uint8_t msb, lsb;
  137.     if (!nRF24_dataReady()) return false;
  138.    
  139.     csn_low();
  140.     SPI_Transfer(R_RX_PAYLOAD);
  141.     msb = SPI_Transfer(NOP);
  142.     lsb = SPI_Transfer(NOP);
  143.     csn_high();
  144.    
  145.     *value = ((uint16_t)msb << 8) | lsb;
  146.     nrf_write_reg(NRF_STATUS, (1 << 6)); // STATUS regiszter törlése
  147.     return true;
  148. }
Köszönöm szépen!
(#) kissi válasza kaqkk hozzászólására (») Márc 23, 2026
Ja, úgy nem...azt hittem az ICSP-hez gondolkodsz feltétben !
(#) kaqkk válasza Bakman hozzászólására (») Márc 23, 2026
Köszönöm . Ámbár jobban átgondolva butaság volt megkérdezni is
A hozzászólás módosítva: Márc 23, 2026
(#) Bakman válasza kaqkk hozzászólására (») Márc 23, 2026
Csak annyi nem elég, tápfeszültség is kell a kontrollernek.
(#) kaqkk válasza kissi hozzászólására (») Márc 23, 2026
Az lenne a kérdés hogy a gnd és az mclr elég e az égetéshez ..... Be kell e kötni a vdd lábat-lábakat ?
A hozzászólás módosítva: Márc 23, 2026
(#) kissi válasza kaqkk hozzászólására (») Márc 23, 2026
Szia!

Ha kap a PIC a panelről tápot (persze!), akkor nem kell, hogy azt is bekösd ( nem fogja érzékelni, a PK2 kiadja, a PIC nem kapja meg, de az tud válaszolni, mert van tápja, csak legyen közös GND!)!
A hozzászólás módosítva: Márc 23, 2026
(#) pipi válasza kaqkk hozzászólására (») Márc 22, 2026
Táp kell, meg föld is
(#) kaqkk hozzászólása Márc 22, 2026

Égető adapter

Csak egy gyors kérdés . A pic beégetéséhez szükség van a + tápfeszre ? A gnd az mclr a pgd pgc lábak bekötése mellett még a vdd-t is be kell kötni ? Agyalok most egy "félautomata" égetőfeltéten a pickit2 höz és szeretném ha minél kevesebb pin bekötésével (kapcsolásával) meg tudnám oldani a dolgot .
A hozzászólás módosítva: Márc 22, 2026
(#) benjami válasza Laja1 hozzászólására (») Márc 11, 2026
A teljes képernyő újrarajzolásához 320*480*24 = 3686400 bitet kell a kijelzőre írni (sajnos az ILI9488 nem tud SPI módban 16 bites színmélységben működni, pedig azzal lehetne gyorsítani egy kicsit). Ha 5-6 másodpercig tart a feltöltés, akkor az SPI-t 700000 bit/sec sebességgel járatod. Ez mehet feljebb, szerintem a kijelző tudni fogja azt amire ez a PIC maximális sebességgel képes. Ha ez is kevés, akkor nem marad más lehetőség, mint másik mikrovezérlővel megoldani. Menet közben már nem kell az egész képernyőt irogatni, elegendő csak a megváltozott karaktereket.
(#) Bakman válasza Laja1 hozzászólására (») Márc 11, 2026
Kontrollert 64 MHz-en járatni, SPI-t felhúzni annyira, amennyire a kijelző engedi.

Esetleg más kijelzőt használni, ameliyk nem foglalja le ennyire a kontrollert, pl. Nextion valamelyik változata. Egyszerűen ehhez a kijelzőhöz kevés az a PIC, amelyiket használnod, lásd itt: Bővebben: Link.
A hozzászólás módosítva: Márc 11, 2026
(#) Laja1 válasza István_2 hozzászólására (») Márc 11, 2026
Abban tudtok segíteni, hogy hogyan lehet gyorsabban képernyőt frissíteni? Mivel pixelenként rajzolja át a színeket, így nagyon lassú. Kb. 5-6 másodpercig tart. Nincs erre egy gyorsabb függvény?
PIC18F25K22 mikrovezérlőt használok és egy rezisztív érintőképernyőt (ILI 9488+XPT2046, 320x480). Jelenleg így színezem át a képernyőt:
  1. void TFT_FillScreen(uint16_t color) {
  2.  
  3.    // isSpiBusy = true;
  4.     TFT_SetAddrWindow(0,0,TFT_W-1,TFT_H-1);
  5.  
  6.     TFT_Command(0x2C);
  7.  
  8.     TFT_DC_LAT = 1;
  9.  
  10.     TFT_CS_LAT = 0;
  11.  
  12.     //SPI_Write(0x2C);
  13.  
  14.  
  15.    
  16.  
  17.  
  18.     for(uint32_t i=0;i<(uint32_t)TFT_W*TFT_H;i++)
  19.  
  20.     {
  21.  
  22.         TFT_WriteColor(color);
  23.  
  24.     }
  25.  
  26.  
  27.     TFT_CS_LAT = 1;
  28.  //   isSpiBusy = false;
  29. }

  1. void TFT_SetAddrWindow(uint16_t x0,uint16_t y0,uint16_t x1,uint16_t y1) {
  2.    // isSpiBusy = true;
  3.  
  4.     TFT_Command(0x2A);
  5.  
  6.     TFT_Data(x0>>8); TFT_Data(x0 & 0xFF);
  7.  
  8.     TFT_Data(x1>>8); TFT_Data(x1 & 0xFF);
  9.  
  10.     TFT_Command(0x2B);
  11.  
  12.     TFT_Data(y0>>8); TFT_Data(y0 & 0xFF);
  13.  
  14.     TFT_Data(y1>>8); TFT_Data(y1 & 0xFF);
  15.  
  16.     TFT_Command(0x2C);
  17.    // isSpiBusy = false;
  18.  
  19. }

  1. void TFT_WriteColor(uint16_t color) {
  2.    // isSpiBusy = true;
  3.  
  4.     // RGB565 (16 bit) -> RGB666 (18 bit kiterjesztve 24-re)
  5.  
  6.     SPI_Write((color & 0xF800) >> 8); // Piros (R5 -> R8-nak látszik)
  7.  
  8.     SPI_Write((color & 0x07E0) >> 3); // Zöld (G6 -> G8-nak látszik)
  9.  
  10.     SPI_Write((color & 0x001F) << 3); // Kék (B5 -> B8-nak látszik)
  11. //isSpiBusy = false;
  12. }
(#) Laja1 válasza István_2 hozzászólására (») Márc 10, 2026
Igen, minden rendbe jött! Frissítette magát, csak én nem frissítettem, hogy írja is ki ezt az új időt.
Köszönöm! És azóta nem is akadt meg!
(#) István_2 válasza Laja1 hozzászólására (») Márc 10, 2026
A cím biztos "0x68" ? Nem 0xD0 , vagy 0xD1 ?
A címzés képe az előző hozzászólásnál.
A hozzászólás módosítva: Márc 10, 2026
(#) István_2 válasza Laja1 hozzászólására (») Márc 10, 2026
Sziv SN !
"Csak nem frissít valami miatt" -> Esetleg a DS3231-nek az oszcillátora nincs-e letiltva ?

DS3231_EOSC.jpg
DS3231_CIM.jpg		   
(#) Laja1 válasza István_2 hozzászólására (») Márc 10, 2026
Köszönöm! Ezzel most az összeomlás (eddig) megszűnt. És mintha az adatok is a helyére kerültek volna. Csak nem frissít valami miatt. De ez már más miatt lehet.
Köszönöm szépen!
(#) Tasznka válasza Laja1 hozzászólására (») Márc 10, 2026
Szia!
Amit javasolt István_2 az sem árt,de be kellene tenned 1 flag-et a
  1. PIR3bits.SSP2IF = 0;
  2.     SSP2CON2bits.RCEN = 1;
  3.     uint16_t timeout = 5000;
  4. while(!PIR3bits.SSP2IF && --timeout > 0);

után,hogy tudd,hogy jött-e tényleg valami,mert így nem tudod,hogy a timer limit,vagy az IF járt le,vagy váltott.Talán ez segít:
  1. if(PIR3bits.SSP2IF){
  2.     PIR3bits.SSP2IF = 0;
  3.     data = SSP2BUF;
  4.     flag = 1;
  5. }
  6. else
  7. {
  8.     flag = 0;
  9.     return 0;
  10. }
  11.     I2C_Wait();
  12.     SSP2CON2bits.ACKDT = (ack ? 0 : 1); // 0=ACK, 1=NACK
  13.     SSP2CON2bits.ACKEN = 1;
  14.      while(SSP2CON2bits.ACKEN);
  15.     return data;

És ezt a flag-et figyelve láthatod,hogy tényleg megjött -e a jó adat. Bár az I2C nem a kedvencem,de talán tudtam segíteni.
(#) Laja1 válasza Bakman hozzászólására (») Márc 10, 2026
Az SDA-n és az SCL-n is 4k7 ellenállás van. Szkópon az látszik, hogy az inicializálás (általában ) rendben lefut (cím: 0x68; 0x0E--0x04; 0x0F--0x00), mindig van ACK válasz. De néha az időolvasásnál (nagyon ritkán az inicializálásnál) az SDA vonal 0 V-on ragad. Ekkor mindent lekapcsolok és direktben adok az SDA lábra 3,3 V-t. Ekkor észhez tér és egy darabig működik, majd megint beakad. A NYÁK nyomvonalvezetéssel hol lehet gond? Ha közel megy a SPI adatforgalomhoz az SDA vonal? De ott is mit jelent a közel? Erre is érzékeny lehet?
(#) István_2 válasza Laja1 hozzászólására (») Márc 10, 2026
Sziasztok !
Esetleg ezt próbáld ki : ( Beszúrva egy flag törlést )
3. I2C_Wait();
PIR3bits.SSP2IF = 0;
4. SSP2CON2bits.RCEN = 1;
A hozzászólás módosítva: Márc 10, 2026
(#) Bakman válasza Laja1 hozzászólására (») Márc 10, 2026
Biztos, hogy nem zavarja egymást, legalábbis logikailag. Ha olyan a NYÁK és/vagy a vezetékezés, akkor zavarhatják egymást, leginkápp az SPI zavarhatja az I2C-t. Utóbbi jóval érzékenyebb jószág. Oszcilloszkóppal ellenőrizhető. Felhúzó ellenállások értékei az I2C vezetékeken?
(#) Laja1 válasza Bakman hozzászólására (») Márc 9, 2026
Itt inkább az volna a kérdés, hogy a két kommunikáció zavarja-e egymást, vagy elvannak egymástól függetlenül. Mert ha nem zavarják egymást, akkor más irányba megyek el a hibakereséssel.
(#) Laja1 válasza Bakman hozzászólására (») Márc 9, 2026
Nálam így néz ki:
  1. uint8_t I2C_Read(uint8_t ack) {
  2.     uint8_t data;
  3.     I2C_Wait();
  4.     SSP2CON2bits.RCEN = 1;
  5.     uint16_t timeout = 5000;
  6.     while(!PIR3bits.SSP2IF && --timeout > 0);
  7.     PIR3bits.SSP2IF = 0;
  8.     data = SSP2BUF;
  9.    
  10.     I2C_Wait();
  11.     SSP2CON2bits.ACKDT = (ack ? 0 : 1); // 0=ACK, 1=NACK
  12.     SSP2CON2bits.ACKEN = 1;
  13.      while(SSP2CON2bits.ACKEN);
  14.     return data;
  15. }
(#) Bakman válasza Laja1 hozzászólására (») Márc 9, 2026
Erre a kérdésre így nem lehet válaszolni. Mit tartalmaz az I2C read rutin? Nálam ez jól működik:

  1. uint8_t i2c_read(void) {
  2.     SSP2CON2bits.RCEN = 1; // Enable to receive data
  3.     while (!SSP2STATbits.BF);
  4.     return SSP2BUF; // Return received byte
  5. }
(#) Laja1 válasza benjami hozzászólására (») Márc 9, 2026
Igen, ezt megcsináltam. Most már jó az érintés. De az óra továbbra sem működik. Mintha mindig szemetet írna ki egy-egy újrarajzolás után. PIC18F25K22 mikrovezérlőt használok. A képernyő rajzolás, érintés SPI kommunikációval megy az óra I2C-vel. Lehet, hogy ezek összeakadnak? Bár itt két MSSP modul van és a hardveres verziót használom. Az egyiken a SPI-t, a másikon az I2C-t. De lehet, hogy ennek ellenére összeakadnak? Nagyon sokszor lefagy az óra itt: while(!PIR3bits.SSP2IF). (I2C Read). Egyszerűen nem tudom, hogy mi a baj. Tudnátok ebben segíteni? Köszönöm!
(#) tki válasza Laja1 hozzászólására (») Márc 3, 2026
// formátum: "2025 Március 15"

Ez egyébként így fest helyesen:

2025. március 15.
(#) benjami válasza Laja1 hozzászólására (») Márc 3, 2026
Szerintem nem túl szerencsés egy gyakorlatilag RAM nélküli és DMA lehetőséget is nélkülöző mikrovezérlőre ekkora felbontású és színmélységű kijelzőt kötni. Ha mégis meg akarsz küzdeni vele, akkor fel kell bontani a megjelenítést rövidebb idő alatt lefutó részekre (pl, egyszerre, csak egy betűt kirajzolni), utána lehet a touchscreen-t lekérdezni. A másik dolog, hogy csak a megváltozott karaktereket kellene kiiratni, nem pedig az egész szöveget.
(#) Laja1 hozzászólása Márc 2, 2026

Érintőkijelző programozás

Sziasztok!

Két kérdésem lenne, az egyik elméleti, a másik gyakorlati.
1. Adott egy rezisztív érintőképernyő (ILI 9488+XPT2046), egy DS3231 RTC óra és egy PIC18F25K22. A kijelző és érintés SPI-vel, az óra I2C-vel kommunikál a PIC-cel. DE ha az órát másodpercenként kiíratjuk, az SPI-vel történik és ha eközben történik egy érintés is, azt hogy látja a mikrokontroller? Szinte folyamatosan foglalja a TFT a SPI vonalat. Pláne, ha még a századmásodperceket is kijeleznénk? Mi az elméleti megoldás erre? Mert nálam az érzékelést nem látja. Azt gondoltam azért, mert folyamatosan frissítettem a képernyőt (mindig újrarajzolt), de ezt megszüntettem. De az időkijelzést nem tudom megszüntetni, mert az mindig frissül. Sajnos a NYÁK úgy készült, hogy a T_IRQ kivezetés nincs kihuzalozva.)
2. Az óra kijelzése valami miatt el van csúszva: az óra helyén a perc jelenik meg, a perc helyén a másodperc. A dátum jól nézett ki. De vártam vele egy napot, a nap valóban ugrott egyet, de a hónap is. Valami nagyon szét van esve, nem tudom ezt mi okozza. Tudtok ebben segíteni? Mellékelem az óra header és c fájlját és ide beszúrom a kiírást is. Köszönöm szépen!
  1. void DrawClockBar(const DS3231_Time *t) {
  2.  
  3.     char buf[32];
  4.  
  5.     // --- Óraerc középen, felül ---
  6.     // Középre 480 px szélességhez, nagy betűméret (3)
  7.     sprintf(buf, "%02u:%02u", ido_most.hour, ido_most.min);
  8.     // Szöveg kb. 6×8×3 = 144 px széles, ezért (480-144)/2 ≈ 168 px
  9.     TFT_DrawString(168, 45, buf, COLOR_WHITE, COLOR_BLACK, 3);
  10.  
  11.     // --- Dátum (Év Hónap Nap) ---
  12.     uint8_t m = (ido_most.month >= 1 && ido_most.month <= 12) ? (ido_most.month - 1) : 0;
  13.     const char *month[] = {
  14.         "Január","Február","Március","Április","Május","Június",
  15.         "Július", "Augusztus", "Szeptember", "Október", "November", "December"
  16.     };
  17.     // formátum: "2025 Március 15"
  18.     sprintf(buf, "%04u %s %02u", ido_most.year, month[m], ido_most.day);
  19.     // 2-es méret → kb. 8×16 px/karakter, szélesség kb. 200–220 px
  20.     TFT_DrawString(140, 80, buf, COLOR_WHITE, COLOR_BLACK, 2);
  21.  
  22.     // --- Hét napja (a dátum mellett, jobbra) ---
  23.     const char *days[] = {"Hétfő","Kedd","Szerda","Csütörtök","Péntek","Szombat","Vasárnap"};
  24.     uint8_t di = (t->dayOfWeek >= 1 && t->dayOfWeek <= 7) ? (t->dayOfWeek - 1) : 0;
  25.     // kis betűméret (1), a dátum mellett, kissé jobbra eltolva
  26.     TFT_DrawString(340, 80, days[di], COLOR_WHITE, COLOR_BLACK, 2);
  27. }

ds3231.c
ds3231.h		   
(#) albinolynx válasza bbatka hozzászólására (») Feb 26, 2026
Chipcad-től megrendeltem a raktári kettő darabot. Köszönöm mindenkinek a segítséget! Jövök, amint megérkeznek.
(#) bbatka válasza albinolynx hozzászólására (») Feb 26, 2026
A PICKItminus-al is tudod használni a PICKit3-at is.
(#) kissi válasza albinolynx hozzászólására (») Feb 26, 2026
Szia!

Szerintem innen tudsz: Bővebben: Link

Régebben rendeltem tőlük, ráadásul utólag kellett kifizetnem !
Következő: »»   1 / 1225
Bejelentkezés

Belépés
Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem