-
IT café
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
its_grandpa
tag
válasz Janos250 #15192 üzenetére
Belenéztem a kódba kíváncsiságból. Abba most nem megyek bele mennyire szépen van megírva, én pár dolgot másképp csinálnék, pl. túl sok benne a "magic number".
A gond a delay-el van ami ebben az esetben vélhetően nem okoz gondot, azonban az ESP-n ellenjavalt ilyen hosszú delay-ek használata, számtalan helyen leírták, egy példa a sok közül: https://learn.sparkfun.com/tutorials/esp8266-thing-hookup-guide/using-the-arduino-addon
Nem kötözködésből írtam, a jobbító szándék vezérelt, peace. -
nagyúr
válasz its_grandpa #15203 üzenetére
Miért ellenjavallt? Ő esp32-re írta a kódot, ahol kimondottan elvárt a delay-ek használata, tekintve, hogy ott adja át a vezérlés a többi szálnak, pl. wifi.
-
bear_
aktív tag
Sziasztok!
Újra van időm mikrokontrollerezni, így szerettem volna tovább babrálni.
Az ADC-t szerettem volna kipróbálni és beolvasott értéket kiírni a kijelzőre, de nem tudom leprogramozni normálisan a kijelző léptetését.
0-9-ig tök jól elszámol az első helyiérték, a második helyiértéket jelző 7 szegmenses kijelző viszont 00-t jelenít meg x9 után 10 helyett.
A probléma okát értem mert a tömböm szerint a kikapcsolt szegmensek után a következő sor a 0 értéket tartalmazza, én viszont a második tömbből a második sort felhasználva szeretném bekapcsolni a második helyiértékű 7 szegmenses kijelzőt. Természetesen próbáltam ezerféleképpen, de vagy nem számol el az egész 19-től tovább, vagy 9 után 00-át jelenít meg.Hogy lehet ezt megoldani? Már a falat kaparom miatta.
Kód: [Pastebin]
-
bear_
aktív tag
Igen, az világos. A 0 indexű sor a kikapcsolja a kijelzőket ahogy a komment is mutatja mellette. És pont ez a probléma, ha egyel növelem a változót akkor az egyes indexre ugrik, ami ugye 0-t jelenít meg, és emiatt van az, hogy x9 után 00-ír ki a kijelző.
Haif(num1>10){
num1=1;
num2=2;
}feltételt szabok meg, akkor 19 után 10-re ugrik vissza, ami ugye logikus is.
Ha
if(num1>10){
num1=1;
num2++;
}
a feltétel akkor remekül működik a fentebbi problémát leszámítva. tehát x9 után 00-ra ugrik. Az x itt kikapcsolt kijelzőt jelent, csak a másik működik amíg 9 felé nem teker a változó.[ Szerkesztve ]
-
weiss
addikt
-
weiss
addikt
Ill. ez a fix hozzárendelés is fura. Jobb volna magát a számot feldolgozni, és abból generálni a digiteket.
Valami ilyesmire gondoltam. Nem teszteltem, csak fejből írtam.
void decomposition_to_digits(const unsigned int num, const bool with_leading_zeros, int *thousand, int *hundred, int *ten, int *one)
{
*one = num % 10;
*ten = (num / 10) % 10;
*hundred = (num / 100) % 100;
*thousand = (num / 1000) % 1000;
if(!with_leading_zeros){
if(0 == *thousand){
*thousand = 10;
if(0 == *hundred){
*hundred = 10;
if(0 == *ten){
*ten = 10;
}
}
}
}
}I did nothing, the pavement was his enemy!
-
bear_
aktív tag
Ha végére rakom az OFF-ot akkor ugyanúgy gond van a kezelésével, azt a kört már lefutottam
Nem vagyok egy C guru, megtennéd légyszi, hogy bedobod a kódomba az általad felírt függvényt? Nem vagyok benne biztos hogyan is működik pontosan, így nagy segítség lenne a megfejtésében.
-
nagyúr
Ez miért ennyi?
int digits1[11][16] = {{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, //OFF
Miért nemint digits1[11][16] = {{1,1,1,1,1,1,1,1,0,0,0,0,1,0,0,0}, //OFF
vagyint digits1[11][16] = {{1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0}, //OFF
?
A többi 3-ra is vonatkozik.
Végülis a futás szempontjából nem fontos, csak zavarja az OCD-met.Egyáltalán miért van szükség az off kódot kiíratni, egyszerűen csak ugorni kéne azt a szegmenst, ez egyszerű erőforráspazarlás.
[ Szerkesztve ]
-
bear_
aktív tag
Mármint mennyi? Ezt nem értem. A pastebinen mindegyik sorban 16db 0 az OFF.
2db sorba kötött shift registerbe tölti be az MCU a biteket, az első 8 bit a 7 szegmenses kijelző egy-egy szegmensét kapcsolja(+ a . ugye), a következő négy nem csinál semmit, a maradék néggyel pedig a szegmenseket lehet egyesével kapcsolgatni.Ha arra gondolsz, hogy miért 0 az active state: nem emlékszem pontosan miért, egy hónapja írtam a shift regiszterek vezérlését, de valóban fordítva működik, kijavítani meg lusta voltam
Szerk: "
Egyáltalán miért van szükség az off kódot kiíratni, egyszerűen csak ugorni kéne azt a szegmenst, ez egyszerű erőforráspazarlás. "Ezt megint nem értem. Ha nem mondom meg a shift registernek (nem töltöm fel 0-val ami kikapcsolja a kimeneteket), akkor hogy tudom kikapcsolni az adott szegmenseket?
[ Szerkesztve ]
-
nagyúr
Ha nem mondom meg a shift registernek (nem töltöm fel 0-val ami kikapcsolja a kimeneteket), akkor hogy tudom kikapcsolni az adott szegmenseket?
Hát úgy, hogy nem kapcsolod be.
Minden körben egymás után kapcsolgatod a szegmenseket. Amikor egy szegmenst vezérelsz, a másik 3-at lekapcsolod! Tehát amikor a következőt bekapcsolnád, egyszerűen csak nem kapcsolod be.
Ezzel:{{0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1}
minden számjegy minden szegmense egyszerre világítana (8888).[ Szerkesztve ]
-
weiss
addikt
Nem tudom bedobni a kódodba, mert nem teljesen értem mit csinál. Miért van a digits1/2/3/4, és miért különböznek, ha mindegyik egy sima 7 segmenses kijelzőt vezérel? Egyébként ennyi volna a használata:
unsigned int value = 1234; // ide az ADC olvasás vagy akármi
decomposition_to_digits(value, false, &num4, &num3, &num2, &num1);Már ha a num4 az ezres érték.
I did nothing, the pavement was his enemy!
-
bear_
aktív tag
Már értem, köszi a tanácsot.
@#15215 weiss neked is köszi, hétvégén kipróbálom.
"Miért van a digits1/2/3/4, és miért különböznek, ha mindegyik egy sima 7 segmenses kijelzőt vezérel? "
Mert nem egyesével vezérli a kijelzőket, hanem egyszerre. Itt van hozzá a kapcsolás: [link]
De az is lehet, hogy én gondoltam túl -
Janos250
őstag
válasz its_grandpa #15203 üzenetére
Igen, igazad van. Eredetileg valahogy - a nem megfelelő inicializálás miatt - a státus lekérdezés nem igazán jól működött, ezért került be a sok delay, és úgy maradt. Valóban ki is lehet belőle szedni.
delay: nem igazán tudom, mi a helyzet vele, ettől függetlenül. Van ahol azt írják, hogy vtaskdelay-t használjunk. Az biztosan átadja a vezérlést a többi tasknak az adott időre, de van ahol azt írják, hogy a sima delay-t is ugyanerre fordítja, tehát mindegy. Majd egyszer kipróbálom.
A sok magic number szándékosan van így: az Ada könyvtárban ott van minden részletesen, az nagyon univerzális, de igen hosszú is.
Szándékosan olyat akartam, ami rövid, tömör, és az SPI kezelését is megmutatja. Az SPI-ről is tervezem, hogy írjak pár sort egyszer, mert aki csak az UART-ot használta, annak elég szokatlan a filozófiája, hogy nincs benne "csak read". Helyette úgy működik, hogy ha küldünk egy byte-ot, akkor - akár kell, akár nem - jön be is egy. Tehát úgy olvasunk, hogy kiküldünk egy kódot (sorozatot), hogy mit akarunk olvasni, aztán küldjük sorra a haszontalan kódokat, hogy velük együtt jöjjön a hasznos adat.
Elég fura ez pl. amikor a hőelem hőmérsékletét olvasom, ahol a konverter panelnak semmi adatra nincs szüksége, mégis SPI-vel úgy olvasom, hogy KÜLDÖM a felesleges adatokat, mert ezekkel párhuzamosan jön a hasznos adat. (Ez utóbbit csak azoknak írtam, akik nem szokták az SPI-t használni.) Az esp8266-on korábban nem is használtam könyvtárat, hanem a chip select és a clk lábakat mozgattam programból, és a MISO-nak megfelelőt olvastam, a MOSI-nak meg nem is volt megfelelője, mert fölösleges az adott esetben. Azóta átáltam kényelemből az SPI-re annál is.Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
Janos250
őstag
"pl. wifi"
Konkrétan a wifit zavarja legkevésbé, mert az a 0-ás magon fut, a loop pedig (ha csak egy szál van) az 1-esen. Hogy delay, vtaskdelay, azt bizony nem tudom.Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
Janos250
őstag
A kijelzők kezeléséről jut eszembe:
Már terveztem korábban, hogy írok egy illesztést ESP32-re, hogy a kijelzőre sima fájl "C" művelettel (pl. fprintf) lehessen írni, mert az sokkal kényelmesebb, mindent, konvertálást, formázást, egyebeket elintéz magától, de eddig elmaradt. Tud esetleg valaki kész ilyen illesztést, mert ha valaki már megcsinálta, akkor fölöslegesen nem tökölök vele? Egyébként se használok kijelzőt , nálam a kijelző és a kapcsoló a mobiltelefon képernyője (Mindenkinek van valami dilije ) Korábban egyszer valamire másra nekiveselkedtem, de aztán abbamaradt, pedig definiált, hogy hogyan kell csinálni, hogy beilleszkedjen a fordítóba. Nagyjából ment is, de nem kijelzőre, csak hobbi próbaként.Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
Tomika86
senior tag
Sziasztok!
Segítséget szeretnék kérni, mert nem tudom hogy "szokás" ezt arduinónál.
Van pár adat ami jelenleg konstansként van kezelve, de szeretném ha Nextion kijelzőn lehetne módosítani. Jelenleg 2db float és 1db int értékről lenne szó, aminek van beviteli mezője a kijelzőn.
Ha beírok egy számot a megfelelő mezőbe, azt hogy tudom átvinni a programban egy változóba úgy, hogy ne legyen gomb hozzá ami elindítja az érték "átmozgatását", hanem beírom és megváltozik?
Amikor kikapcsolom az arduinot akkor a már meglévő EEPROM írás blokkal a változók értékeit lementem. Bekapcsoláskor a setup részben kiolvasom az EEPROM-ból az elmentett értéket.Köszönöm a segítséget!
-
its_grandpa
tag
válasz Janos250 #15219 üzenetére
Örülök, hogy átment az "üzenet". Arra próbáltam felhívni a figyelmet,hogy eredetileg arduinóra írt c kód esp-re fordítása nem csak annyiból áll, hogy átállítjuk milyen board-ra fordítson az ide.
Ne haragudj de a magic number nem lehet szándékos, a define ingyen van
Kicsit lerövidítve a programod egy sora,hogy elférjen:SPI.transferBytes(Target_response_out, Target_response_in, 21); /magic number /
Inkább így ....
#define Target_response_len 21
.
SPI.transferBytes(Target_response_out, Target_response_in, Target_response_len);Ugye mennyivel szebb a második ?
-
And
veterán
válasz Tomika86 #15222 üzenetére
Ennek a kivitelezése szerintem nem arduino-specifikus. Ha nincs egy 'send', 'ok' vagy hasonló gomb a kijelzőn, ami az értéket elküldené az MCU-nak, akkor szerintem kerülőúton juttathatod be a változót, például:
- rendszeresen, adott időközönként kiolvasod az értékét az MCU-val (get x0.val), vagy
- ugyanezt megteszi a HMI, timer-eseménnyel ciklikusan adatot küld az MCU felé (prints x0.val.0), vagy
- mint az előbb, de a timer event-hez felhasználsz egy temp változót, aminek csak az a feladata, hogy összehasonlítsa az előző értéket az aktuálissal, és ha utóbbi megváltozik, elküldi a beviteli mező értékét (a lényeg, hogy csak egyszer küldje, ne folyamatosan).
Arra ügyelni kell, hogy - mivel a HMI nem ismeri a natív float típust - "Xfloat" mezőből is mindig integer értéket kapsz, ilyen bevitt értéknél a tizedespont helyét és ezzel a kapott szám értelmezését az Xfloat-mező ws0 és ws1 attribútumai adják meg. -
Janos250
őstag
válasz its_grandpa #15223 üzenetére
Az alapfilozófiával messzemenően egyetértek.
Már az Algol 60-at is azért kedveltem a Fortran helyett, mert Algolban lehetett
sokkal strukturáltabb programot írni, Fortranban nem. A basic sem nagyon adott arra lehetőséget, a Pascal viszont részben igen. A visualbasic persze nagyon jó strukturált és objektumosított, de ott meg egy Országh nagyszótárnyi dolgot kell megjegyezni, propertyk formájában. A Cobol meg annyira szószátyár volt, hogy csak no. A C nyelvet én gyakorlatilag kihagytam, mert a pointerek miatt gyakran hibáztam benne. Ezért szeretem a C++ -t, mert ott már kényelmesen meg van oldva.Rövid nevek, hosszú nevek: ízlés kérdése. Én jobban szeretem a hangosan beszélő neveket a halkan beszélő helyett. Hogy miért InListPassiveTarget a target helyett? Mert a manualban is így nevezik. Ízlés kérdése. (Pap és papné esete)
Ugyanez igaz a konstansra is: Én úgy gondoltam, hogy jobb az, ha ránézésre látszik, hogy a wait4ready (readyToRead_out) hossza csak 2 byte, míg az ACK 7 byte, a többi meg hosszabb. Az ACK csak ACK maradt, mert azt azért általában tudják az emberek, hogy az mi.
Az ESP32 egyébként is jeleskedik a konstansok átdefiniálásában. A jómúltkor pl egy konstans (aminek a bitjei külön-külön jelentenek valamit) esetében már vagy az ötödik átdefiniálásnál tartottam, amikor kiderült a számértéke: 0 . Ha beírták volna oda a nullát, arról ránézésre tudná az ember, hogy minden bitje bulla, mint ha egy átdefiniált sor végén van.Egyébként nem az Ada programot kódoltam át ESP32-re, hanem írtam egyet, szándékom szerint úgy, hogy minél inkább passzoljon az ESP32-höz. Ez vagy sikerült, vagy nem. Ha megnézed az Ada programját, az azért elég más. Én megnéztem. Igaz, hogy ő is kiírja az elején a verzió számot, de ezt - gondolom - ő is a netem olvasta - ugyanúgy mint én - hogy nem nagyon tudjuk, hogy miért, de ez javítja a stabilitást.
Köszönöm a tanácsaidat, fontolóra veszem őket.
Hogy neked így nem szép a program, azt sajnálom, de lesz, ami így marad.[ Szerkesztve ]
Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
Janos250
őstag
Nem teljesen látom át a problémát, de az UNO-n nem működik az sprintf?
https://www.cplusplus.com/reference/cstdio/sprintf/Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
Tomika86
senior tag
Ha gombot rakok a mentésre akkor ezzel megtudom oldani?
Nextion mentés gomb megnyomási eseménynél:
print t0.txt
print "mentes#"Arduinoban pedig ez:
if (Serial.available())
{
String indata = Serial.readStringUntil('#');
if (indata.indexOf("mentes") > -1)
{
byte position_ = indata.indexOf("mentes");
arduino_adat = indata.substring(0, position_).toInt();
}
}
Annyi, hogy nem szám típusú a beviteli mező, hanem szöveg. De numerikus billentyűzet lenne megjelenítve.
Köszönöm!
[ Szerkesztve ]
-
Tomika86
senior tag
Van arra valami szabály hogy a nextion kijelzőnek, a folyamatos adatokat, hogyan kell küldeni? A lezáró 3db FF megvan, de mégis jönnek hibaüzenetek a nextion debugnál.
Buffer overflow és invalid variables is -
nagyúr
Tudna valaki segíteni?
Kellene nekem egy
- semiduplex
- 5V -> 3.3V szintillesztéses
- soros kapcsolatot létrehozni.A kapcsolás úgy néz ki, hogy a master oldalon 5V logic van, TX és RX kimenet, a slave irányába 1 vezeték, a slave pedig 3.3V logikát igényel. Ez lenne vázlatosan:
A level shift részére pedig ezt a kapcsolást találtam:
Hogyan kellene ezt a kettőt egy kapcsolásba összekombinálni, a lehető legkevesebb alkatrészszámmal?
Elvileg egyszerű feszültségosztóval is meg lehetne csinálni, de szeretném a lehető legstabilabb megoldást, a lehető legkisebb méretben megvalósítani (pl soklábú IC-k nélkül ).
A TX - RX irányban nem probléma a visszhang.A google nem volt a barátom.
[ Szerkesztve ]
-
And
veterán
válasz Tomika86 #15233 üzenetére
A Nextion felől visszaküldött üzeneteket bizonyos szintig be tudod állítani a bkcmd nevű belső változóval. Ha nullára állítod (default értéke: 2), az invalid variables üzenet elvileg nem jön többé, de a buffer overflow továbbra is megmarad. Ennek oka van, bár korábban szerintem már volt erről szó, hogy a debugger ilyen jellegű, soros átvitellel kapcsolatos szimulációja elég sok kívánnivalót hagy maga után. Vagyis a jelenség nem is feltétlenül valós. Azt is említettem, hogy a protocol reparse mode aktiválásával egy csomó probléma kiküszöbölhető, a rendkívül terjengős eredeti adatmennyiség a töredékére csökkenthető, cserébe neked kell a vételi pufferből kiszedni és a kívánt adatformátumra gyúrni a HMI-be beeső adatokat ( u[index] vételi tömb illetve ucopy függvény segítségével).
-
And
veterán
válasz Tomika86 #15236 üzenetére
Amúgy nem tudom, milyen mennyiségben és mekkora periódussal küldöd be az adatokat, de ha a hagyományos módban elég sok változót adsz a HMI-nek folyamatosan, nagy bitrátával, és nem hagysz elég időt a belső feldolgozásra, akkor biztosan ki lehet akasztani az 1kB-os puffert (parancs + adat + lezárás).
A reparse mode ezen úgy segít, hogy nem kell komplett parancsokat vagy értékadásokat a hagyományos módon beküldened, elegendő csak magát az értéket. Például: az "n0.val=123" parancs a lezárással együtt 13 byte hosszú, protocol reparse módban pedig egyetlen byte-on elküldhető az érték, amit egy script képes a megfelelő helyre / változóba tenni. De még nagyobb értéktartomány esetén sem lesz 2..4 byte-nál hosszabb az üzenet. Mivel ilyenkor adatokat küldesz, nem parancsokat, a visszirányú forgalom (HMI válaszüzenetek száma) is minimalizálható.[ Szerkesztve ]
-
Tomika86
senior tag
Hát ez a bajom. Egy oldalon van 3 mutatós műszer, aminek a mutatói nem szeretném, ha akadoznának. Illetve még van mellette 4 text mező és 3 szám mező. Text mezőkben float szám van megjelenítve.
Ezek érdekelnének, hogy mennyi időt kell hagynom a küldések között, hogy kell ütemezni.
Ha az értékek lassabban frissülnek nem gond, de a 3 mutató ne akadozzon.
[ Szerkesztve ]
-
And
veterán
válasz Tomika86 #15239 üzenetére
Ezt perpillanat csak te tudhatod. Natív adatmennyiségben a komplett képernyőn megjelenő input információ akár 16..18 byte-on is továbbítható. Hogy a lebegőpontos értékeket miért továbbítod text-ként, azt nem teljesen értem, de szerintem felesleges. Xfloat-ként (vagy akár szimplán ponttal elválasztott, byte-méretű értékpárokként) mondjuk 1..2 byte adattal megúszható lenne egy-egy ilyen mező. Ha a hagyományos módon, egyenkénti értékadással, parancsonként továbbítasz ennyi adatot, akkor a korábbi példa alapján az egyszeri frissítéshez is az említett hasznos adat minimum 8..10-szeresét kell karakterként a HMI-be küldeni, ami nagyságrendileg 150..180 byte. Az adatokat másodpercenként pl. 10x frissítve ez már bő másfél kilobyte, bár valószínűleg a számértékeket tartalmazó mezők frissítéséhez ez a ráta túl sok, a mutatós műszerekhez pedig esetleg kevés (bár itt már képbe jönnek a hardveres képességek, illetve hogy pontosan milyen módon animálod a mutatókat).
Én ezt úgy oldanám meg, hogy a szükséges frissítési gyakoriságok okán kétféle - egyenként fix hosszúságú - adatcsomagot küldenék az MCU felől, a HMI-t pedig protocol reparse-ba állítanám: az egyik típusú, ritkábban küldött csomagban lennének a numerikus mezők értékei pl. 16 byte-on (két bevezető + 7*2 byte), a másik, sűrűbben frissített csomagban pedig a mutatóké, mondjuk 6 vagy 8 byte-on.
Azt mindenképpen ki kell majd tapasztalnod (és nem a debugger-ben, hanem a valós kijelzőn!), hogy milyen frissítésnek van egyáltalán értelme a mutatós műszereknél, mert ez nagyon hardver- és megoldásfüggő. De ha jól csinálod, semmiképp nem a szükséges adatmennyiség vagy az átviteli sebesség fogja korlátozni a megjelenítést, mert másodpercenként erre 2-300 byte elég lehet, a 115.2 kbps-es portsebesség pedig adatkerettel együtt 11 kbyte/s hasznos átvitelt adhat. -
Hello,
Valakinek volt már olyan, hogy a szervó nehezen mozog, és hangosan sípol...?
Mi okozhatja ezt... ? Nekem most két Tower 9g SG90 is ezt csinálja.
Köszi minden ötlet[ Szerkesztve ]
Mutogatni való hater díszpinty
-
-
-
Istv@n
aktív tag
Sziasztok!
Milyen board-ot használhatnék akkor, ha "tudásban" kb. 1 wemos D1 mini szintjére lenne szükség, (wifi, memória), de több digitális I/O portot szeretnék?
-
Új hozzászólás Aktív témák
- Garanciális Thermaltake 1650W 80+ Gold Tápegység
- AIO Vízhűtéses NVIDIA RTX 2080 SUPER ?? Igen!! Igazi kuriózum eladó csak itt!! - Beszámítás: OK
- 7db Lenovo ThinkCentre M710s/M910s/M720t:i5 8400 (6mag)/i5 6500 (4mag) +AJÁNDÉK:ÚJ Lenovo bill.+egér
- NVIDIA GeForce RTX 2080 Ti Founders Edition 11GB GDDR6 - Beszámítás: OK
- MSI GeForce RTX 2070 SUPER VENTUS OC 8GB GDDR6 - Beszámítás: OK
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen