"elég csak hozzáadni a Github repo linkjét az IDE-hez"
Link?

Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.

[link]

Én itt láttam először.

Путин, иди нахуй!

Most jutottam oda, hogy talán kész a schematic az egyik panelhez. Programozáshoz +5/3.3 V regulátor függően, GND, UART0 RX, és TX pin-re van szükség nem? Nálad ahogy nézem több minden is be van kötve. Pl kék, fehér vezetékek amiket látok pin-ek szerint. Uart pineket viszont nem látom.

Lehet te más miatt kötötted be azokat a bizonyos vezetékeket? Ha csak programozni szeretném külsőleg, akkor Vcc, GND és az UART0 RX, TX pineket kell csak csatlakoztatni egy olyannal mint amit te használsz panel vagy egy [link] CP2102 USB TTL modullal?

Hello,

Vagy felprogramozod előre és utána beforrasztod... Utána meg OTA ha működik....

Vagy a másik módszer hogy tesztpontokon keresztül, vagy közvetlen pogopineken keresztül letölteni.....

Release the Beast....

Nincs programozóm külön, OTA-n se szeretném, inkább vezetékkel beforrasztott állapotban, tüskesort kivezetve.

Viszont a kérdésem továbbra is kérdés. Jó-e az a módszer, amit leírtam?

RX, TX, IO0, EN, Vcc, GND.
Már ha kell az auto download. Kézi reset esetén az EN és IO0-ra nyomógomb kerül ugye.

Igen, nálam még van itt egy kis extra - bár nem hiszem, hogy látszik a képen. UART0-ra csatlakozik ugyanis a gps modul is majd normál üzemmódban. (Majd idővel ha eljutok odáig, akkor kikísérletezek egy bluetooth programfeltöltést a gps modulon keresztül. Az úgy sokkal kényelmesebb lesz, mint vezetékezni állandóan.)

[ Szerkesztve ]

Köszi, így gondoltam én is.

Automata feltöltés nem lesz, bízok benne elsőre minden rendben lesz így csak 1x kell feltölteni Na meg akkor plusz 2 tranzisztor is kellene. BOOT és RESET gombot tettem rá és majd nyomom amíg rátölti a programot.

Nem kell tranzisztor, ezért vettem programozót. Azon rajta van minden kiegészítő áramkör, ami egy devkit-en is rajta van. Viszont akkor kell rá tervezned legalább egy mikrokapcsolót az IO0-ra (de inkább még egyet az EN lábra a reset-hez, különben kapcsolgathatod a tápot), különben gyakorlatilag nem fogod tudni download módba tenni.

[ Szerkesztve ]

A te esetedben megoldható a programozóval, nekem nincs csak a linkelt CP2102-es USB TTL átalakító, ha ezt használom, akkor kellene mert azon nincs tranzisztor. Egyébként BOOT és RESET gomb ugyan úgy lesz mint egy dev modulnál, mindent ugyan úgy csinálok csak lehagyom róla a CP2102-es IC-t és a tranzisztoros automata programozó részét.

[ Szerkesztve ]

Sziasztok! Ebay-en tudnátok wemos d1 mini vagy nodemcu-hoz javasolni valami jó kis kínai 230v/microusb adaptert? Köszönöm!

A kínai mérnököknek néha sajátos fogalmaik vannak az érintésvédelemről vagy a hőre méretezésről. Ha van olyan választási lehetőséged, szerintem inkább egy levitézlett (Európában forgalmazott) mobiltelefon töltőjét válaszd.

Több ezer telefonszámot tudok fejből, csak azt nem tudom, hogy melyik kié.

Köszönöm, csak itt régebben olvastam, hogy az intelligens telefon töltők akár 12V-ot is képesek kiadni magukból, és a fene tudja melyik "intelligens"...

[link]

"Csak úgy" egyik okos töltő sem fog 12V-ot kiadni magából, ahhoz az usb másik végéről erre vonatkozó utasítást kell kapnia. D+ és D- vonalakat megfelelő feszültségre kell hozzá kapcsolni.

A gyorstöltők mikroprocesszor vezéreltek mindkét oldalon (telefon, töltő), oda nem elég egy feszültségosztó. BC 1.2 szabványban van 5V 2A, amit feszültségosztóval lehet beállítani.

[ Szerkesztve ]

Akkor én ezt a cikket félreértettem?

WOW! Még nem láttam példát QC töltő hack-re.
Még nem tudom mire lesz ez jó, de könyvjelzőzve.

Azt nem látom leírva benne, hogy continuous mód-ban hol és milyen impulzusokkal lehet vezérelni a feszültséget?

[ Szerkesztve ]

Koszonom, egy Nokia630 tolojevel hibatlanul mukodik a NodeMcu.Akkor ha jol ertem a gyors tolto akkor emel feszt, ha kap ra jelet, igy barmelyik jo lehet...

A Nokia töltők nem stabilabbak (Kivéve amin USB aljzat van meg az USB-C kábeles. Ezek nagyon jók). Nem a kimenő feszültség van visszacsatolva hanem a trafón található segédtekercs feszültségét figyeli. Nem ajánlom semmilyen célra használni.

Próbáljuk meg a mondatokat NAGYbetűvel kezdeni

Köszönöm

[link] Ez esetleg jó lehet?

Passz, nem látok bele. Annó dolgoztam Nokia garis melóba és ott sok probléma volt emiatt, Gondolom AC-18e amid van. AC-50 és AC60 nagyon jó.

[ Szerkesztve ]

Próbáljuk meg a mondatokat NAGYbetűvel kezdeni

Van valakinek jól működő prellmentesítő rutinja?

A jelgenerátoros projektemben eljutottam oda, hogy KY-040-el lehetne szabályozni a frekvenciát.
Ehhez ESP32-vel az egyik PCNT unit 0. csatornáját használom. Az encoder CLK-ja megy ctrl_gpio_num-ra a DT meg pulse_gpio_num-ra (vagy fordítva, elég sok kombinációt próbáltam).
A szuper ebben a dologban az lenne, hogy a számláló szépen számlálgat a háttérben a program másik része meg 1-2ms-onként ránéz, és ha van valami (0-tól eltér), akkor változtatja a frekvenciát (ill. alapállapotba teszi a számlálót).
A prellmentesítésre gondoltam jó lesz, ha valamit beállítok a pcnt_set_filter_value hívásnál.
Aztán rádöbbentem, hogy a filter csak 10 bites (0-1023) és mivel ABP clock-ban mér (80MHz) a max az kb. 12.5us. Ami édeskevés prellmentesítésre...
(Ugyanígy akartam használni a nyomogatás részét is, szóval a SW egy másik unitra ment volna).

Ami kül. bosszantó, hogy a PCNT rém egyszerű megoldás lett volna, majdnem mindent a HW csinál, a felprogramozás után.

Sajnos a forgatásnál is hibázik (néha a másik irányba ugrik) az SW nyomogató meg totál használhatatlan, mert 0-5 között kellene állítható legyen (ez lenne az encoder frekvencia lépésköze), de egyszer megnyomva a kapott eredmény szinte egy 0-5 közötti véletlen szám.

Elkezdtem nézni az irodalmat.
Talán ez a legjobb leírás:
https://www.best-microcontroller-projects.com/rotary-encoder.html

Végül-is az állapotugrásos megoldás megoldható (persze ehhez teljesen dobni kell a PCNT-s totál egyszerű megoldást), de így nem lehet megoldani a gombnyomós részét (SW).

Ott arra gondoltam, hogy az első él után (interrupt) egy ideig nem lenne nézve a gomb (interrupt tilt). Viszont azt is olvastam, hogy a forgatásnál is képes lehet 1 nagyon rövid SW impulzust generálni, szóval jobb lenne azt nézni, hogy mennyi időt tölt el H ill. L szinten. Viszont ez meg amellett, hogy nem egyszerű, nyomogatásnál tolni fogja a megszakításokat és az időmérés meg extra logika miatt az időt is rendesen viszi.

A furcsa az egészben, hogy a fórumok tele vannak ezzel a problémával és megoldási ötletekkel (van aki a HW-es kondist nyomja,van aki a SW-re esküszik én is jobban kedvelném ezt) de jó megoldást még nem láttam.
A legbosszantóbb persze, hogy a 10 bites PCNT filter totál meg tönkre vágja azt amit egyébként tudhatna a HW...
Na most jól kibosszankodtam magam.

Aktuális ötletem prellmentesítésre:

Külön threadben (thread nem gond, frekvenciát is így mérem) X millisec-enként beolvasom a pint. Gombra X mondjuk 5ms.
Ha változott (L lett) akkor Y microsec-enként megmintavételezem (Y microsec-enként beolvasom Z alkalommal). Gombra Y mondjuk 100us, Z mondjuk 20 alkalom. Ha a Z alkalomból W alkalommal tartja a változást akkor elfogadom. Tehát 20-ból mondjuk legalább 6 szor (W) L akkor meg lett nyomva a gomb (Az encoder forgatásnál keletkező nagyon rövid virtuális nyomást ez szűri.)

Ez után pedig egy hosszabb várakozást (csendes időszak) után (mondjuk 200-500ms) újraindul az egész.

Gombra ezt elég biztosra lehet hangolni (sőt ebben az esetben külön előny, hogy tartva magától lép, nem kell több lépéshez extra nyomogatni), a rotary részre meg vsz. marad az állapotváltozás figyelés...

Persze, ha valakinek van jobb ötlete szívesen olvasnám

Nem volna egyszerűbb valami kondi a lábakra?

I did nothing, the pavement was his enemy!

Bár lehet jó eséllyel meg tudnám csinálni (legalábbis az esetek egy részére), de ez nem annyira triviális mert a kondi a jelalakot is torzítja.
Szóval méretezni kell zavaró és kívánatos jeltől függően stb. A zavaró jel meg gombtól, öregedéstől stb. is függhet (meg encodernél forgatás sebessége miegymás).
A SW-ben 1 változót sokkal gyorsabban változtatok mint a kondit újraforrasztom.

Példának okáért gyorsan összedobtam a gomb kódját a lenti logikának (mivel most per pill. még fordítani sem tudom, szóval lehet nemcsak hibás is, hanem esélyes, hogy már a fordító sem eszi meg), nekem ez sokkal gyorsabb mint forrasztgatni, tárolós szkópon nézegetni a lehetséges hibákat stb.

(Alsó rész init-be megy, meg GPIO-t változókat stb. be kell állítani).

#include <pthread.h>
#define ROTE_SW GPIO_NUM_xx
#define RENC1_STPLIM 6

typedef struct {
gpio_num_t swpin;
uint16_t step;
} roteswT;

roteswT rote1par;
pthread_t rotethrdsw1;

void* roteswbgrd(void* pars){
roteswT* swpar = (roteswT*) pars; // switch parameters
gpio_num_t swbut = swpar->swpin;
uint32_t bcount;

while (1){
if(digitalRead(swbut) == LOW)
{
bcount = 0;
for(int i=0; i<20; i++){
delayMicroseconds(100);
if(digitalRead(swbut) == LOW) bcount++;
}
if(bcount>=6){
swpar->step = (swpar->step +1) % RENC1_STPLIM;
delay (300);
}
}
delay (5); // could pthread_cond_wait() for interrupt from pin
}
} // roteswbgrd

pinMode(ROTE_SW, INPUT);
rote1par.swpin = ROTE_SW;
rote1par.step = 0;
pthread_create(&rotethrdsw1, NULL, roteswbgrd, (void*) &rote1par);

Az encoder számláló része persze kicsit húzósabb és ami dühítő, hogy a HW akár tudhatná is (nagyon közel van hozzá)...

Nem olyan nagy dolog az! Írsz egy integrátort, meg egy hiszterézises komparátort és kész.

"Mindig a rossz győz, és a jó elnyeri méltó büntetését." Voga János

Nem kérdés, sok mindent tudok írni ld lentebb. A kérdés az volt, kinek milyen bevált módszere van készen.

Meg ugye az sem mindegy hogy 5 SPI cucc vezérlése (többek közt TFT kijelző), meg AD bemenet (jelszint mérő), meg frekimérő meg 2 rotary encoder meg stb. stb. mellett pont az integrátor+hiszterézises komparátor (klasszikus HW megoldás) a legjobb módszer (egyszerűségben, gyorsaságban), ha meg akarom őrizni az interaktivitást ill. a kód átláthatóságát.
(OK, kicsit bonyolultabb lett ez a hobbi project mint eredetileg indult, de evés közben jön meg az étvágy...)
Nekem pl. a megengedett állapotváltozás nézése sokkal egyszerűbbnek tűnik.

Azt írtam le, amit én használok.
Amit írsz, azt nem értem. Az a második mondat olyan... se füle, se farka.
Nekem ez a megoldás tűnik egyszerűnek, a tiéd meg bonyolultnak. De mások vagyunk ugye... szerencsére!

[ Szerkesztve ]

"Mindig a rossz győz, és a jó elnyeri méltó büntetését." Voga János

Jelenleg 160x128 színes TFT (Bangood, 6 USD alatt), de már tervezem, hogy áttérek 320x240-re, mert egyre csak hízik ez a projekt aztán mindig kicsi a kijelző...

tvamos
Nincs időm arra, hogy mindenkinek mindent részleteiben elmagyarázzak. Vsz. elég jól leírtam a problémát meg az ötletet is, sőt adtam kódot is. Ennyi mindent meg kell magyarázzon.
A kód amit lent leírtam nem mellékesen (most próbáltam ki öt perce) nemcsak hibátlanul fordult, hanem hibátlanul is fut (csak a az encoder nyomógombjára). Nem tudom ki hogy van vele, de nekem nem mindig megy elsőre...
Amit meg kell oldjak még az a számláló.

Ja akkor az még mindig kicsi. Én nagyot kerestem, 3.5 colosat vagy 4 colosat végül 3.5 colosat találtam. Sajnos a betekintési szöggel vannak bajok, szerencsére projekt szempontjából meg tudom oldani, hogy ne legyen ez hátrány, de azért nem egy laptop/monitor szintű sajnos.

[ Szerkesztve ]

Helló, az ESP32-n levő USB csipnek /cp210x/ el kellene menni magától suspendbe, vagy ki lehet lőni valahogy?

I did nothing, the pavement was his enemy!

Az egy 5V-os chip és a devkit nyákterve alapján csak 5V-ról kap áramot (usb vagy külső stabilizált táp). Ha áramtalanítani akarod, akkor 3V-ról kell betáplálni a modult.

Egyébként magát az IC-t lehetne altatni, de nem értem a nyákterven hova van kötve az a láb. Vmi "active" net label van rajta, de nem látom sehol máshol ezt a címkét. Lehet fixen fel/le van húzva.

[ Szerkesztve ]

Lassan kezd összeállni.

jól néz ki.

Nem követtem nyomon mi is lesz ez a végén?

Release the Beast....

Ezzel szeretnék vezérelni minden elképzelhető dolgot a motoromon.

3,3 V-ra van kötve sajnos. A 3,3 V-os pinen tápláltam meg, és deep sleepben is evett 10 mA-t a nyák Most rendeltem egy Huzzah klónt, remélem abban jobban fog működni.

I did nothing, the pavement was his enemy!

A kimeneteken tranyók vagy mosfetek vannak. A bemeneteken mosfetek. Az analóg az egyetlen, amit egyszerű ellenállásosztóval készítettem. De arra nincs is jobb módszer tudtommal. Mit értesz az alatt, h tönkreteheti? Nem optimális működést vagy meghibásodást? A digitális jelszintek miatt nem aggódok. A bemenetek zener-rel védve vannak, ahol indokolt. A fet-es szintillesztéseknél meg a modul saját tápját kapcsolom. A táp meg mindenhol szűrve van.

A gyroszenzort szerintem be fogom forrasztani fixen. A female tüskesor tényleg elég laza. Illetve még azon filóztam, hogy a doboz tetejére csavarozom és a tetejével együtt kerül csatlakoztatásra.

[ Szerkesztve ]

Jól néz ki Mekkora kondit-ellenállást használtál? 0603?

A szenzorra én is azt mondom, amit korábban is és amit Tankblock is ír. A vibrációra érdemes figyelni, mert az el tudja vinni a mérést sajnos.

[ Szerkesztve ]

Ügyes!

A dobozt vetted, vagy nyomtattad?

Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.

Én teljesen elégedett vagyok a betekintési szögével (arra amire használom tökéletes).
Fektetve használom, alul-felül nézve hibátlan, oldalra képes romlani. Ahhoz képest milyen olcsó volt több mint jó.

Viszont ha te ilyen nagyban utazol akkor biztos számít a sebesség. Itt (is) keresek valami megoldást. A változásokat elég lassan frissíti a kijelző, de vsz. ez nem a kijelző hibája, hanem nem tudom, hogyan kellene rávenni az Adafruit ST7735 könyvtárat, hogy HW SPI-t használjon (ESP32). Én a jelgenerátor chipet már rég így használom és tökéletesen megy.

Szóval, ha így indítom akkor megy de láthatóan lassú:
Adafruit_ST7735 tft = Adafruit_ST7735(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);

Az irodalom szerint a HW SPI-hoz így kellene:
Adafruit_ST7735 tft = Adafruit_ST7735(TFT_CS, TFT_DC, TFT_RST);
Viszont így egyáltalán nem megy.

Nem mellékesen nem is értem honnan tudja a fenti hívásból melyik SPI-t kell használni (VSPI vagy HSPI) . Amikor a generátorhoz csinálom az inicializálást ott meg kell adni, melyiket hozza létre...
hspi = new SPIClass(HSPI);
(A VSPI is hasonló).
Az SPI könyvtár viszont automatikusan tudja, hogy pl. HSPI esetén ezek a pinek:
CLK 14
MOSI 13

Autóhoz vagyok inkább szokva, ott indításkor simán lehet zaj felextraponálhat a vonalra, és ha a jel több mint 3,6 [V] akkor bármi történhet. Ezért van azz autókban CAN hálózat, az analog jelek meg ha vannak akkor a legkisebb vezetéken, de inkább digitális mind.

Kérdés h mire akarod használni. Üres vezeték ne maradjon, mert antennaként viselkedik.

Release the Beast....

Mi olyan különleges a CAN buszban? Nem csak egy egyszerű adatbusz?

Amúgy nem akkora nagy gond ha bejön egy-egy tüske. Max ügyesen írom meg a szoftvert.

[ Szerkesztve ]

Szépen haladok előre, a ledszalag vezérléssel.
Webes felület kész. Mint kiderült van sokkal egyszerűbb megoldás, mint a taskok szeparálása cpu magra, meg saját ledszalag vezérlés írása.

Fastled library tökéletesen működik. Az, hogy fordításkor megjelenik egy warning nem probléma.

Az espasyncwebserver library segítségével tök egyszerű megjeleníteni a weboldalt. Már csak annyit kell megírnom, hogy a weboldalon kiválasztott színt jelenítse meg a szalagon. De ennek is meg van a mintakódja.

Már csak 1 dolog kell. Akarok egy fizikai nyomógombot is a szalag kikapcsoláshoz. Ez lényegében úgy működne, hogy fekete szín küldene ki a szalagra.
A nyomógomb bekötéséhez azonban amit eddig találtam nekem nem szimpatikus. Lényegében az esp32 egyik pin-je egy ellenállással gnd-re van kötve. Ugyanerre a pinre van kötve a nyomógomb, a pin és az ellenállás közé. A nyomógomb másik lába pedig 5v-ra van kötve. Így ha megnyomom a gombot, az ellenálláson keresztül záródik az áramkör. Nem tudtok olyan megoldást, ahol nincs így összekötve a gnd és az 5v?

Most kezdődjék a tánc! - mondta a papagáj és berepült a ventilátorba.