Fórum témák

» Több friss téma
Fórum » Arduino
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
Lapozás: OK   723 / 852
(#) mateatek válasza mateatek hozzászólására (») Jan 18, 2022 / 2
 
Az én enkóder kezelő kódom PCinterruptot használ. Azért ezt használom, mert sok esetben a megszokott megszakítás lábak másra vannak használva, illetve így több enkódert is tudok használni esetleg. Az enkóder lábain 47 nF kondi van.
A változók létrehozása, a pinek konfigurálása és a megszakítás beállítása után ez a kód:

Egyik enkóderre:
  1. ISR(PCINT2_vect) {
  2.   A = (A << 1) + ((PIND & _BV(3)) == 0);
  3.   A = (A << 1) + ((PIND & _BV(2)) == 0);
  4.   if ((A & 3) == 1) lepes++;
  5.   if ((A & 3) == 0) lepes--;
  6. }


Másik enkóderre:
  1. ISR(PCINT2_vect) {
  2.   A = (A << 1) + ((PIND & _BV(3)) == 0);
  3.   A = (A << 1) + ((PIND & _BV(2)) == 0);
  4.   if((A & 3) == 1 | (A & 3) == 2) lepes--;
  5.   if((A & 3) == 0 | (A & 3) == 3) lepes++;
  6. }


(Ebben a kódban már benne van sdrlab javítása is, az én eredeti kódom 5 soros volt.)
(#) Kovidivi válasza mateatek hozzászólására (») Jan 18, 2022 / 2
 
Sokkal átláthatóbb lenne a kód, a 3 helyett 0b0000011 lenne, stb.
A jelenlegi számok használata gyorsítani nem gyorsít a kódon, kevesebb helyet se fog a uC-ben használni (tehát előnye nincs), de cserébe megbonyolítja a hibakeresést, a program olvasását...
(#) mateatek válasza Kovidivi hozzászólására (») Jan 18, 2022 / 1
 
Gondolom, aki tudja, hogy mi van ott, az átírja, vagy nem zavarja. Aki meg nem tudja, annak meg mindegy. Részemről az a zavaró, hogy hosszú lesz tőle a sor. De kinek hogyan tetszik.
(#) Kovidivi válasza mateatek hozzászólására (») Jan 18, 2022 /
 
Legalább megtudtam, hogy az esztétika játszik szerepet. Így már más a véleményem. Először arra gondoltam, hogy a programot író a kezdőket direkt akarja félrevezetni. Mondjuk mindenki úgy írja a programját, ahogy neki tetszik.
(#) Josi777 válasza vargham hozzászólására (») Jan 18, 2022 /
 
Példaprogram, nem mondtam, hogy ezt kell használnia bárkinek. Üres a loop, semmilyen esemény nem marad le! Ez egy enkóder vizuális megjelenítésére írt megoldás, amire teljesen alkalmas. Amúgy meg tudom, hogy megszakításkezelő, én írtam
És nincs olyan, hogy mit szabad és mit nem szabad. Ajánlások vannak és optimalizálás, több szempont együttes figyelembe vételével és a programozók tudásának függvényében íródnak a kódok.
A hosszan blokkolásról meg annyit, hogy 1 karakter kiírása 115200-as sebességgel kb. 0,8 us ideig tart, 9600-as sebességgel 1 ms.
(#) sdrlab válasza Josi777 hozzászólására (») Jan 19, 2022 / 1
 
Szerintem sincs baj vele! Demonstrációs célból amúgy is minden megengedett, amit esetleg rendes kódba nem ildomos, még az is...
Ami a lemaradást illeti..., de, lemarad minden olyan megszakításról, ami azalatt esik be, míg az aktuális megszakítás fut! Az más kérdés, hogy jelen esetben ez ha be is következne(van rá kis esély), az kit zavar??! A nagyon gyors prellek kiszűrődnek hardveresen(még kondik nélkül is), a közepesen gyorsakra viszont már érkezik reagálni a megszakítás, főleg 115kbaud mellett... Többre itt nincs is szükség...
(#) Josi777 válasza sdrlab hozzászólására (») Jan 19, 2022 /
 
Nem marad le egyetlen megszakítás sem, csak nem az adott pillanatban hajtódik végre, hanem amikor befejeződik az éppen végrehajtás alatt álló. De jelen esetben meg nincs miről lemaradni
(#) sdrlab válasza Josi777 hozzászólására (») Jan 19, 2022 / 1
 
Ha ugyanabból a megszakítási forrásból jön(ne) egy újabb megszakítási esemény, amit éppen kezel a rutin, az bizony elvész...!
(#) Josi777 válasza sdrlab hozzászólására (») Jan 19, 2022 /
 
Na jó, úgy igen.
(#) vargham válasza sdrlab hozzászólására (») Jan 20, 2022 / 2
 
Így van. Ha tehát valaki elég nagy frekvenciás jelet generáló (pl motorra szerelt) enkódert próbál ki ezzel a kóddal, az fals eredményt kaphat.
Persze, bármit szabad. De egy ilyen fórumban hajlamosak az emberek magukkal vinni az ilyen demonstrációs megoldásokat, és elkezdeni használni... Persze, az ő bajuk. De én inkább nem mutogatnék nekik olyat, amit amúgy nem érdemes. Ne rögzüljön a fejükben a rossz minta.
(#) sdrlab válasza vargham hozzászólására (») Jan 20, 2022 /
 
Szerintem jelen esetben továbbra sincs baj azzal a kóddal, logikai szinten nézve...hiszen teoretikusan nézve ha "0" ideig tartana a megszakítás kezelő rutin, akkor is lesznek impulzusok, amire egyszerűen nem reagálhat már a hardver sem! Akkor ez rossz működés lenne?? Nem, korántsem, ez jellegzetesség csupán, paraméter. Ahogyan az is, hogy a usec alatti reakcióidővel az a kód sem ad rossz eredményt, csak lassít valamelyest a hardver adta lehetőségeken! Hogy ez jó, vagy nem jó....azt döntse már el mindenki magában, hogy legalább elementáris számításokat végez, amiből kiderül, hogy az még belefér, vagy nem, esetleg kapásból hibás elképzelés önmaga ez a proc is már...?!!
Jelen esetben az, hogy kihagy(hat) impulzusokat(mármint nem forgatási, hanem a rossz kontaktusból eredőeket) a megszakítás, semmilyen módon sem befolyásolja a forgatás tényének rögzítését, pláne hogy mindössze demonstrálás a cél...


Idézet:
„Ha tehát valaki elég nagy frekvenciás jelet generáló (pl motorra szerelt) enkódert próbál ki ezzel a kóddal, az fals eredményt kaphat.”

Ilyen alkalmazásban mechanikus enkódert használni kb a még nem ébredtem fel kategória! Oda optikai, vagy mágneses alapokon működő jöhet csak szóba. Azok pedig többnyire prellmentesek, és gyorsak....
(#) sargarigo hozzászólása Jan 20, 2022 /
 
Olyan jó hogy hasogatjátok a szőrt!
Tény hogy megszakításokban minél rövidebb ideig tartózkodunk, annál jobb! Ezt tekinthetjük ökölszabálynak. Azt is tudjuk hogy a szabályok arra valók hogy legyen mit megszegni. De csak az szegje meg, aki tisztában van a következményekkel, hiszen a törvény nem ismerése nem mentesít. Tehát ha valaki tudja hogy mit csinál, az csinálja! Aki meg nem, az tartsa be a szabályt, ha nem akar pórul járni (lehet hogy nem most, lehet hogy majd a harmadik alkalom után, de előbb utóbb biztos megfeneklik valamin).
Saját vélemény, de szerintem most már kezet kellene fognotok egymással, és koncentráljunk a felmerülő problémákra! Béke!
(#) sdrlab válasza sargarigo hozzászólására (») Jan 20, 2022 1 / 2
 
Idézet:
„Tény hogy megszakításokban minél rövidebb ideig tartózkodunk, annál jobb! Ezt tekinthetjük ökölszabálynak”

Ebből az következne, 0-hoz konvergáló megszakítási idővel rendelkező program a jobb, sőt, egyenesen a 0-ás, megszakítás nélküli program az igazi, portokkal Mekka felé...
Még szerencse, hogy ilyen meggondolatlan, személyes véleményt tényként beállító kijelentés a gyakorlatban éppúgy nem állja meg a helyét, mint az ellenkezője!
Szerintem mindenki úgy programoz, ahogy nem szégyell..., mert nem a kód szépsége, vagy az önjelölt ökölszabályok számítanak, hanem az, hogy a végtermék funkcionálisan azt teszi e amit kell?!!
(#) majkimester válasza sdrlab hozzászólására (») Jan 20, 2022 / 4
 
Ökölszabály helyett inkább hívnám követendő programozási gyakorlatnak, amit érdemes megfogadni. Kisarkíthatod a dolgot, hogy a megszakítás nélkül még jobb, de ez nyilván nem igaz. Itt a fórumon a minimális programozási tudással rendelkezőktől kezdve a profi programozókig sok ember megfordul, és ezt nyugodt szívvel javasolhatod bárkinek, bármilyen szinten is van, mint követendő programozási tipp. Aki nagy gyakorlattal rendelkezik az meg úgyis tudja mit csinál és tudja a dolgokat helyén kezelni.

Idézet:
„Szerintem mindenki úgy programoz, ahogy nem szégyell ...”

Otthon a sufniban ez igaz, de komoly helyen mindig vannak kódolási konvenciók és guideline-ok, amit követnek is. Ha valaki ír egy programot, és 1 hónap múlva előveszi és nem érti mit miért csinált, akkor gyanakodhat, hogy rosszul csinálja. Szerintem érdemes a jól bevált konvenciókat és programozási ajánlásokat használni és ajánlani másoknak is a sok flame helyett.

Egyszerű példaprogramokba bármi elfér, mint a IT-ben soros küldés, de ettől még nem ez a követendő, még ha az csak egy hobbi projekt is. Azért is mert a program sosem kész, mindig lehet továbbfejleszteni, javítani. És ha az elején rossz alapokra építesz, akkor azt később sokkal nagyobb ráfordítás bővíteni, újraírni.
(#) sdrlab válasza majkimester hozzászólására (») Jan 20, 2022 / 1
 
A konvenciók, amikre te gondolsz nem azért vannak, hogy minden szinten mereven kellene hozzájuk ragaszkodni, hanem ha többen dolgoznak egy projekten, akkor nem árt, ha valami szabványosnak(akár lokálisan) tekinthető dolog szülessen, amit bárki tud értelmezni, különösebb értelmezési nehézségek nélkül...
De az, hogy egyesek kijelentik, így, vagy úgy "illik" csinálni, az komolyan mondom egyre jobban megmosolyogtat már! Itt max az azt kijelentők szakértelmetlensége nyilvánulhat meg, amikor saját feltételezett tudásukra támaszkodva, másokat erővel bizonyos mederbe, korlátok közé akarnak kényszeríteni! Szerencsére nem mindenki követi vakon, önálló gondolatok híján a tömeget, hanem van aki újat is képes alkotni!
Annak, aki nem érti, hogy mit miért csinál, magyarázhatod napestig, miért jó szerinted a rövid IT, vagy fordítva, úgysem fogja megérteni, mert nincs rá igénye...., akinek pedig van, nos annak nagyon nem kell ezeket magyarázni, mert nincs értelme, akár hogy fogja megírni, a kódja jó lesz! Ja, hogy nem mindenki fogja megérteni az önjelölt nagytudásúak közül?? Kérem..., az élet nehéz...senki nem mondta, hogy egyszerű lesz... )
(#) Pethical válasza sdrlab hozzászólására (») Jan 20, 2022 / 1
 
Valóban mindenki úgy programoz ahogy nem szégyelli, de, ha nincs tisztában a hardver működésével, határaival, akkor nem lesz jó sehogy sem. Sok ilyen szabály, minthogy egy megszakítás kezelése minél rövidebb ideig tartson nem a kód szépsége miatt van, hanem azért, mert ez követeli meg a cucc, ha másképp csinálod, akkor egy idő után azt fogod tapasztalni, hogy nem mindig működik jól a dolog, mert mondjuk minden második megszakításra nem fut le a rutinod, mert még az előző megszakításon szöszmötöl valamit, vagy mindig jól megy, kivéve néha amikor a felhasználó mondjuk túl gyorsan nyomkod, teker, pislog... Ez nem szépség, szokás, megszokás kérdése, hanem egyszerűen így működnek a megszakítások.
(#) sdrlab válasza Pethical hozzászólására (») Jan 20, 2022 /
 
Még egy utolsó gondolat, aztán hanyagolom a témát!

Én kivétel nélkül minden egyes kicsit is kritikusnak számító megszakítást kiszámolok és/vagy letesztelek ciklusidőre, mert precíz vagyok e téren és az esélyét sem hagyom meg annak, hogy az általad leírt, elég kezdők hibájába essek! Aki ezt nem teszi meg, az ne verje itt a nyálát, hogy hogyan kell programozni, és mit miért illik!
(#) proba válasza sdrlab hozzászólására (») Jan 20, 2022 /
 
Nekem volt olyan programom, ami szinte csak megszakításban csinált valamit. A főprogram az init után egy üres ciklus volt.

Amúgy meg minden szabály azért van hogy megszegjék. Talán csak a természet törvényei vonatkoznak minden körülmények között mindenkire.
(#) asch válasza sdrlab hozzászólására (») Jan 20, 2022 /
 
Én is még egy gondolatot hadd tegyek hozzá! Végső soron a valósidejű programozás (real time) kulcskérdése az, hogy tudunk-e garanciát adni, hogy milyen időzítési körülmények között fog helyesen működni a programunk.

Például ebben az esetben meg tudjuk-e mondani, hogy milyen időközönként változhat a bemeneti PIN értéke ahhoz, hogy ne legyen számlálás tévesztés?

Ez akkor válik nehézzé, ha több féle dolgot is csinál a processzor, két különböző frekvenciával jövő interrupt esetén már azért gondolkodni kell, hogy mi lesz a legrosszabb válaszidő vagy a legnagyobb megengedett interrupt frekvencia.

Illetve ha annál sűrűbben jön, akkor mi lesz a hibajelenség? Például az interrupt kiéheztet minden mást, és a kijelző sem fog működni? Vagy pedig a kijelzés működik tovább csak hibás eredményt ad? Esetleg hibajelzést is tud adni a rendszer?

Látható, hogy a hibaágaknak is többféle specifikációja elképzelhető. A lényeg az, hogy tudjuk mik a rendszerünk határai, és mire számíthatunk, ha elérjük ezeket.
(#) HeZ válasza mateatek hozzászólására (») Jan 20, 2022 /
 
Itt is van egy millis()-en - tehát nem a programfutást megakasztó delay() függvényen - alapuló egyszerű, ötletes, tehát brilliáns megoldás rotary encoder kezelésére főciklusbeli folyamatos lekérdezéssel (polling), szoftveres pergésmentesítéssel, kétsebességes léptetéssel.
(#) morgo hozzászólása Jan 21, 2022 /
 
Sziasztok! Adott egy HC-05 bluetooth modul aminek telefonról küldöm a parancsokat, egyszerű karakterekkel. Az arduino sketchben változókat kapcsolok vele, amik különböző feladatokat hajtanak végre. A problémám az, hogy amikor a telefon és a bluetooth modul közötti kapcsolatot megszakítom, néhány változó állapota megváltozik. Például egy int típusú változó aminek az indulási értéke 0, az értéke 0 és 5 között lehet, minden esetben 4-re vált amikor a kapcsolat megszakad. Mi okozhat ilyen hibát, hogy lehet ezt orvosolni?
A hozzászólás módosítva: Jan 21, 2022
(#) pipi válasza morgo hozzászólására (») Jan 21, 2022 /
 
Passz... Ha nem gond, esetleg lehet kerülgetni a problémát...
pl. késleltesd a kapcsolást pl 1 sec-el, ha ezalatt megszakad a kapcsolat, akkor nem hajtod végre...
(#) morgo válasza pipi hozzászólására (») Jan 21, 2022 /
 
Nem végrehajtás közben jön a hiba, csak amikor kikapcsolom a a telefonon a bluetooth-t, vagy csak kilépek a vezérlő programból. De akkor minden esetben. Régebben egy másik kütyüvel is volt hasonló gondom.
(#) pipi válasza morgo hozzászólására (») Jan 21, 2022 /
 
Bocs figyelmetlen voltam, arra asszociáltam, hogy a kapcsolással van a gáz.
--
Mivel nem írtál/mellékeltél semmi konkrétat skubizd a kódodat, hol módosítod annak a változónak az értékét, esetleg valahol, valami tömb címzésnél "túlírsz", tedd tele a progidat valami nyomkövetéssel másik soroson, vagy led villogás... amúgy mi a jelentése a "4"-nek...
Esetleg ha valami kész libraryt is használsz, abban is lehet valami hiba...
(#) morgo válasza pipi hozzászólására (») Jan 21, 2022 /
 
Két napja túrom a kódot, de nem találok hibát ami ezt okozhatná. Ez konkrétan egy bemenetválasztó változója amit telefonról tudok megváltoztatni, vagy enkóderrel.
Az enkóder számlálója így néz ki:
  1. if ( M == 3 && but1 == 1) { //input
  2.     in += rotaryState;
  3.     if (in > 5) in = 0;
  4.     if (in < 0) in = 5;
  5.   }
  6. A bluetooth kódja:
  7. case 'Y':    //tv
  8.       in = 0;
  9.       break;
  10. A végrehajtás:
  11. if (in==0) {digitalWrite(xx);digitalWrite(xx);}
  12. máshol:
  13. if (in==0) {lcd-re írom a bamenet nevét}

Jó sok van belőlük, de csak két változó ami a kapcsolat megszakadásakor nem tartja az értékét.
A másik byte ami csak 0 vagy 1 lehet.
A hozzászólás módosítva: Jan 24, 2022
Moderátor által szerkesztve
(#) sargarigo válasza morgo hozzászólására (») Jan 21, 2022 /
 
Szerintem az egy karakteres parancsokat bővítsd ki több karakterre,mert lehet hogy a kapcsolat megszakadásakor valamit random kitesz még a portra,amit szerencsétlen módon még érvényes kódnak tekintesz.
(#) morgo válasza sargarigo hozzászólására (») Jan 21, 2022 /
 
Már nekem is megfordult a fejemben, hogy a kapcsolat megszakadásakor valamit még elküld a telefon. Most megváltoztattam az in=4 karakterét, ami "S" volt, "@"-ra. Láss csodát, ez megjavult!
A másik ami az "a"-t küldte, azt "&"-re cseréltem, továbbra is hibázik. Majd megtalálom a jól működő karaktert. Vagy átfaragom, hogy több karaktert is tudjon fogadni. Köszi az ötletet!
(#) Pethical válasza morgo hozzászólására (») Jan 21, 2022 /
 
Azt próbáltad, hogy megnézed mit küld ki hc-05 a kontrollernek amikor lekapcsolódik a telefon? Érdemes lenne ránézni arra a kimenetre.
(#) Régi motoros válasza morgo hozzászólására (») Jan 21, 2022 /
 
Talán foglald "keretbe" azt az egy karaktered, mert egy karakteres vezérlés elég zavarérzékeny lehet.
Az ilyet úgy szokás megoldani, hogy van egy vezérlő karakter, ami jelzi a programodnak,
hogy adat jön, aztán maga az adat (ez a te karaktered) és ez után jön egy lezáró karakter is.
A vezérlő karakter mindig ugyan az pl legyen most @.
A záró karakter szintén lehet ugyan az, akkor a küldendő kódod: @x@

Tehát első kukac a startjel (innen tudja a program, hogy adat jön), iksz az adatod,
második kukac a stop jel (innen tudja a programod, hogy vége az adásnak).

Na ezt aztán lehet szépen variálgatni, pl hogy más a start és stop karakter, vagy hogy a stop karakter akár hibaellenőrző paritást is tartalmazhat, vagy akár azt is be lehet írni a keretbe, hogy hány adatot tartalmaz. Ezt aztán a végtelenségig lehet még ragozni...
A hozzászólás módosítva: Jan 21, 2022
(#) GPeti1977 hozzászólása Jan 21, 2022 /
 
Tegyük fel hogy van egy esp modulom, a programok úgy vannak megírva hogy a
  1. // Replace with your network credentials
  2. const char* ssid     = "*";
  3. const char* password = "*";
a program elején kell megadnom ahol a globális változókat.
Ha megváltozik a hálózatom akkor át kell flesselnem az esp-t az új ssid, password-re.
Meg lehet úgy csinálni hogy ezeket void setup() -ban adom meg, így egy hozzárakott sd kártyán tudnám ezeket változtatni?
A hozzászólás módosítva: Jan 24, 2022
Moderátor által szerkesztve
Következő: »»   723 / 852
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