forum.hwkitchen.cz

Pokud prez Serial komunikujes s tim grafickym rozhranim a zaroven si prez nej posilas nejake vypisy na PC tak ti tam muze "behat kde co".

Seriova linka je pouzita, pokud ji pouziva aspon jedna strana, jinak by po ni nemelo behat nic.

Pokud tam mas nejaky zajimavy zdroj ruseni, tak muze byt ta linka nespolehliva.

Konec koncu ten display by mohl posilat naraz vic stejnych/podobnych zprav a tobe by stacilo odchytit spravne aspon jednu. A cim delsi zpravy posila, tim je vetsi samce, ze se mu povede preplnit buffer, pokud ten buffer ctes pomalu (tedy mezi ctenima delas vic dlouhych veci - proto jsem psal o nepouzivani delay() a o co nejrychlejsi loop() - Arduino si mimo loop() samo dela neco se Serialem).

U každé komunikace se předpokládá vznik chyby a musí se řešit. Chyby můžou mít technickou podstatu (rušení a výpadky na lince) a nebo logickou (komunikace s uživatelem např. přes klávesnici). Při komunikaci dvou zařízení je někdy velmi obtížné zjistit, kde vzniká chyba (rušení, můj kód, knihovna, chyby v kódu druhé strany, chyba v dokumentaci atd.). Projekt Arduina má jednu velkou slabinu, minimální možnost debugování kódu. Vpodstatě jediná možnost je posílání zpráv přes sériovou linku. To je pro řešení situací v komunikaci málo a tak nezbývá, než sáhnout po externím řešení. Pokud tě práce arduinem baví, pořiď si logický analyzátor. Já si bez něj už nedokážu představit ladění jakékoli komunikace. Mohu doporučit jednoduchý, levný a přitom geniální.
https://www.laskarduino.cz/sl-usb8ch-lo ... gJGH_D_BwE
Ta genialita spočívá v analýze různých komunikačních sběrnic a pak je o dost jednodušší nalézt zdroj problémů a vymyslet nějaké řešení. V Tvém případě je opravdu obtížné zjistit,kde je problém a zvláště jen nějakou radou přes fórum, protože možností je příliš mnoho a univerzální rada neexistuje.

Hmmm,tak to mám radost....!
To,že mi to může něco rušit mě také napadlo.
1.Zkouším to na "krysím hnízdě",což nevím jestli je při takovéto komunikaci zrovna ideální.
2.používám mikrovlnný snímače pohybu,ale ty jsem zkusil odpojit a jedu jen na PIR a žádná změna.
3. No právě..., zatím tam mám nastrkanou jen část kodu,takže mám obavy z toho co se bude dít až tam toho bude v loop běhat víc!
Z mé strany tam v tuto chvíli posílám pouze to kliknutí. Samozřejmě opačným směrem mi tam chodí
data z čidel(to je právě to, co tam začne dělat neplechu),ale ty chodí zase přece po druhé lince,to by snad nemělo ovlivňovat,nebo jooo?
Noo ještě se s tím pokusím poprat. A nemůže pomoc,že dám nějakou prodlevu po odeslání zprávy v displeji???
Ono ta komunikace s těmi tlačítky není v tom projektu tak častá,jde tam spíš o prvotní nastavení všeho okolo,ale samozřejmě mou snahou
je, aby to běhalo tak jak má. A hlavně musím tedy hold provádět zpětnou kontrolu v jaké stavu jsou některé události.
Káždopádně všem děkuji za rady, snahu a trpělivost....,možná(spíš určitě

) se ještě s něčím ozvu

Ahoj
Předem přeji všem hezké a klidné vánoční svátky....,
Nooo já je teď zrovna tak trochu klidné nemám

!
Trápím se už pár dnů s jedním problémem a doufám ve vaší pomoc.
V příloze je přiložená část programu,která mi v určité fázi dělá problém(původně jsem měl za to,že je vše OK).
Z praktického hlediska mi to až tak nevadí,ale spíš mě zajímá proč se tak vlastně děje???
Osekal jsem z něj pro "přehlednost" co se dalo.
Jde mi o to,že hlídám po Seriové lince stisknutí tlačítka na disleji(první smyčka),ta mě dostane do druhé smyčky
(záložka Setting) a tam se rozhoduji do jaké další "třetí smyčky"(záložka PageC,PageD,PageE) se dostanu.
Po toto vše 100% funguje. Problém nastává v okamžiku,kdy se chci vrátit o jednu smyčku zpět.....(//zpět)
Podaří se mi celkem pravidelně co se týče počtu pokusů mezi druhou a třetí smyčkou se pohybovat (oběma směry)bez problému.
Potom ovšem mi přestane fungovat komunikace po S.lince. To co mi mimo jiné ovlivňuje ten pravidelný
počet úspěšných pokusů(a bezproblémový chod S.linky) je počet podmínek ve funkci 'nacti_zpravu()'.Pokud tam nechám jen tu první "n1" a zbytek
zakomentuji,tak se mi počet úspěšných pokusů cca zdvojnásobý???? Přijde mi to jako,když se někde něco zaplní a konečná...!!!
Protože ten počet pokusů je víceméně vždy stejný!?!?!
Pokud se vracím až na tu první smyčku(//domů) vypadá,že je vše OK a nikdy se mi to zatím neseklo.
Takže víceméně jenom chci poprosit jestli tam nemám někde nějakou viditelnou blbost při návratu z té třetí smyčky(záložka PageC,PageD,PageE)
a nebo už nějakou blbost,když vyskakuji z té první do druhé.
Děkuji za případnou pomoc a snad jsem to popsal srozumitelně a předem se omlouvám za asi i hrozný kód

(jsem jen kutil)

M.

Ahoj mato, vypil jsem něco štědrovečerního sherry. To mi sice brání zahloubat se do tvého úžasného programu, na druhé straně některé nedostatky ještě vidím

Tenhle kód není úplně správně. Netvrdím, že je příčinou tvých problémů, ale dobře to není.

// funkce pro zápis do EEPROM
void eepromIntWrite(int adresa, int hodnota)
{
byte byte1 = hodnota;
byte byte2 = hodnota >> 8;
EEPROM.write(adresa, byte1);
EEPROM.write(adresa + 1, byte2);
}

// funkce pro čtení z EEPROM
int eepromIntRead(int adr)
{
int hodnota = EEPROM.read(adr) + ((EEPROM.read(adr+1)) << 8) ;
delay(10);
return hodnota;
}

Asi bude fungovat pro parametr hodnota<256, ale pro větší čísla nejspíš ne. Tahle sekvence ((EEPROM.read(adr+1)) << 8) říká rotuj bajt o osm bitů doleva. Výsledkem je podle mého názoru zákeřná nula.
Podívej se na příkazy
EEPROM.put(address, data);
EEPROM.get(address, data);
a použij je místo EEPROM.write a EEPROM.read. Nejen že zjednodušíš program, ale ještě dík implicitní funkci EEPROM.update snížíš opotřebení EEPROM.
Vypadalo by to asi nějak takhle:

Kód: Vybrat vše

// funkce pro zápis do EEPROM
void eepromIntWrite(int adresa, int hodnota)
{
  EEPROM.put(adresa, hodnota);
}

// funkce pro čtení z EEPROM
int eepromIntRead(int adr)
{
  int hodnota
  EEPROM.get(adr, hodnota)
  return hodnota;
}

Přeji hezký zbytek večera.

Ahoj podruhé...,
děkuji za reakci. Noo ono tam těch blbostí bude asi víc, jak jsem po návratu od štědrovečerní večeře a pivka zjistil

!!
Jsem to překopával,překopával až jsem asi ukopal!!!
Ale zrovna ta EEpromka bych řekl,že funguje jak má....dokáže mi uložit i větší čísla než 256.
Na ty příkazy EEPROM.put(address, data);EEPROM.get(address, data); jsem už také narazil a uvažoval o nich.
Ale právě,že jsem zatím nezhledal žádné komplikace se stávajícím řešením jsem to nechal.
Ono totiž s tou pamětí zase víceméně až tak moc často nepracuji.Jde o to, že to teoreticky jednou nastavím a hotovo.
To že to tady tím mým testováním drtím je věc druhá

Dávám odkaz na část videa.

https://youtu.be/aqPbjPGMNAM

Předem se omlouvám za příšernou kvalitu videa,ale ten problém je na konci poznat.....
V tomto případě kdy používám ve třetí smyčce(záložka Page C)pouze tlačítko <ZPĚT> se to vždy kousne na osmém opakování
bez ohledu na pořadí těch tlačítek i když budu používat jenom to jedno(např.Kuchň)....PROČ????

Docela mě překvapil ten podprogram "nacti_zpravu()".

Nextion by přece měl při dotyku odesílat jen několik bajtů s identifikačními čísly právě dotknutého elemenu.
Takže je mi divné, že ti vůbec funguje testování řetězců jako "n1", nebo "home".

Tady je popis odeslané sekvence bajtů při dotyku:

Zdroj:
https://nextion.tech/instruction-set/

V mém programu hlídám sériovou linku a když se na ní objeví číslo 0x65 tak chvilku počkám a načtu ještě další dva bajty.
První bajt je index stránky a druhý bajt je index dotknutého objektu (tlačítka / obrázku) na stránce.
Zbytek komunikace ignoruji (vyprázdním buffer).

Podle těch dvou indexů pak provádím příslušné operace.

Zjednodušený příklad (Serial2 je druhá sériová komunikační linka, kterou používám pro displej):

Kód: Vybrat vše

    byte page;
    byte objekt;
    if (Serial2.available())
      {
        if (Serial2.read() == 0x65)   // na neco bylo kliknuto
          {
            delay(20);                // chvili pauza na prijem zbytku komunikace (3 bajty s identifikaci stisknuteho objektu + 3x 0xFF)
            page = Serial2.read();    // prvni bajt je index stranky
            objekt = Serial2.read();  // druhy bajt je index objektu
                                      // treti bajt by byla informace o stisknuti, nebo uvolneni, ale to nepouzivam

            //-------------------------------------------------------------------------
            //  vyhodnoceni stisknutych objektu            
            //===================   prvni stranka   ===================
            if (page == 1 and objekt == 15)        
              {
                // tlacitko s indexem 15 na 1. strance bylo stisknuto nebo uvolneno

              }

            if (page == 1 and objekt == 20)        
              {
                // tlacitko s indexem 20 na 1. strance bylo stisknuto nebo uvolneno

              }


     
            //===================   druha stranka   ===================
            if (page == 2 and objekt == 8)        
              {
                // tlacitko s indexem 8 na 2. strance bylo stisknuto nebo uvolneno

              }
            //-------------------------------------------------------------------------

          }


        while (Serial2.available())   // zbytek komunikace z Nextionu do Arduina se v kazdem pripade jen na prazdno nacte (vymaze buffer)
          {
            Serial2.read();
          }

      }

Ne nee,já to řeším jinak, posílám text z displeje příkazem print viz. příloha
a v Arduinu si tu příchozí zprávu třídím.Nevím jestli je to tak úplně správně nebo ne,
ale tohle funguje celkem bez problémů.
Problém je někde mezi tím,když se vracím ze třetí smyčky do druhé a nebo pokud chci jít z druhé do třetí
po několikerých správných pokusech se to prostě nějak kousne.
Zajímavé je,že pokud se vracím ze třetí smyčky rovnou do první(loop),tak to funguje (zdá se) naprosto v pohodě
neomezeně dlouho,to je to čemu nerozumím.Samozřejmě....,můžu to takto v případě nouze řešit,že pokaždém nastavení
se vrátím rovnou až do smyčky loop,aleeeee....!!!
Právě nevím zda někde špatně tu smyčku opouštím a nebo do té další špatně nastupuji,ale to by se zase snad projevilo hned
v prvním průchodu.

Aha.

Tak v tom případě bych se podíval, jestli ten displej do Arduina opravdu odesílá při stisku tlačítka to, co je očekáváno a jestli v té komunikaci nejsou nějaké nesmysly.

Když jsem to ladil ve svém programu, udělal jsem si "odposlech" toho vysílání z displeje do druhé sériové linky.
Na PC jsem si pak nechal veškeré vysílání z dipleje vypisovat pomocí nějakého sériového terminálu.

Připojení:

: odposlech.gif (8.1 KiB) Zobrazeno 5434 x

Výsledek při postupném stisku tří tlačítek:

Ty bys tam měl mít nějaké ty texty "n1", "n2", "home" ....

U displeje pozor na značení. Já mám nějakou čínskou kopii a ta má opačně popsané vývody Tx a Rx.
V terminálu bys to ale na první pohled poznal, protože by se vypisoval opačný směr komunikace (z Arduina do displeje).

Jo joo,takhle to nějak kontroluji přes ten serial monitor.Akorát já jedu jen přes jednu linku,protože všechny piny mám už využitý jinak(UNO).
Jede to v pořádku,až potom najednou buď to, to přestane komunikovat
úplně a nebo jen část znaků,(proto jsem to eliminoval z původních asi 5 znaků na dva),ale rozhodně to nevypadá,že by tam lítali úplné nesmysli.
Teď jsem i zkusil ze založky PageC umazat těch prvních asi osm podmínek,nechal jsem jen ty podmínky
//zpět a //domů a rázem jsem z 8 úspěšných pokusů na nějakých 10-11.
To mi hlava nebere

.
Docela se mi zamlouvá ten Tvůj postup se čtením těch bajtů. Vyrážím na oběd,potom to asi vyzkouším
Prozatím děkuji.....

forum.hwkitchen.cz

Komunikace Arduino-Nextion

Re: Komunikace Arduino-Nextion

Re: Komunikace Arduino-Nextion

Re: Komunikace Arduino-Nextion

Re: Komunikace Arduino-Nextion

Re: Komunikace Arduino-Nextion

Re: Komunikace Arduino-Nextion

Re: Komunikace Arduino-Nextion

Re: Komunikace Arduino-Nextion

Re: Komunikace Arduino-Nextion

Re: Komunikace Arduino-Nextion