- Olcsó Galaxyk telepíthetik a One UI 7-et
- Android alkalmazások - szoftver kibeszélő topik
- Fotók, videók mobillal
- Mobil flották
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Samsung Galaxy A54 - türelemjáték
- Google Pixel 9 és Pixel 9 Pro összehasonlító gyorsteszt
- Motorola Moto Tag - nyomom, követ
- Milyen okostelefont vegyek?
- Xiaomi 14 - párátlanul jó lehetne
-
Mobilarena
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
-
-
Teasüti
nagyúr
válasz
JAGER 10
#9234
üzenetére
Én úgy tudom ezeket a NEMA motorokat minden további nélkül lehet üzemeltetni nagyobb feszültségen. Én ebbe az irányba mennék, hogy beférjen a 2A-es korlátba. 24V-on legalább. Vennék hozzá egy dugasztápot, ahhoz egy DC-DC konvertert a mikrokontroller számára és az egészet beépíteném egy IP védettségű kültéri szerelvény dobozba.
Nem tudom milyen motor az amit linkeltél, gyártói adatlap kéne hozzá, h okosabbak legyünk.
Azt lehet tudni milyen mechanikát fogsz nyitni és zárni? Automata bukóablakokat én többnyire pneumatikus dugattyúkkal láttam működni. Ha ezen az elven maradunk, akkor a csavarorsó kézenfekvő megoldás lehet. Akár egy hosszú menetes szár is lehetne.
Azt azért nem igazán hajtogatja a szél és még kellően merev is az ütköztetéses nullpontfelvételhez. -
Teasüti
nagyúr
válasz
JAGER 10
#9230
üzenetére
TMC2130-at mondtam volna, de az 2A-t tud csak leadni (2,5A csúcsáram). Ha be tudod állítani akkora feszültségre a motort, hogy beleférjen ebbe az áramfelvételbe a specifikált nyomaték, akkor jó lehet.
Motorokhoz nem értek, nem tudom mit kell nézni az adatlapján. Amit linkeltél ott 3,2V-ot írnak, az mit jelent? Minimális feszültség? Láttam már embereket ilyen NEMA motorokat hajtani 12V-ról és 24V-ról is. De ez a vezérlő elvileg meg tud hajtani bármit 5-46V között.(#9233) weiss
Egyébként meg igen. Kétlem, hogy számítana bármit is, ha mondjuk 1+ percig tartana egy teljes nyitás.
És amúgy léptetőmotorokat feszültség alatt kell tartani, hogy meglegyen a pozíció tartásához kellő nyomaték. Ez viszont áramfelvétellel és melegedéssel jár. Nem arra vannak kitalálva, hogy 24/7 tartsanak vmit. Ha meg lekapcsolod, akkor elenged és könnyű elforgatni.
Vmi olyan mechanikát kell kitalálni, amihez nem kell sok nyomaték, hogy megtartsa a pozíciót. Ugyanakkor nem akkora nagy áttétel, hogy ne legyen elég érzékeny a szenzor nélküli nullpontfelvételhez. Például egy csigahajtásnál nem biztos, hogy működne a StallGuard2™ technológia ezen a Trinamic driver-en, vagy ha működik is lehet nagyon megfeszítené a mechanikát. Többnyire szíjas hajtáshoz és csavarorsóhoz van kitalálva ez. Egy csigahajtáshoz - ahol lehet nincs merev ütközési pozíció és akár sok-sok lépés is lehet mire megfeszül a mechanika - inkább a végálláskapcsolót választanám. -
Teasüti
nagyúr
válasz
JAGER 10
#9224
üzenetére
3D nyomtatókon használnak olyan stepper driver-eket, amik a motor áramfelvételéből állapítják meg a végállást, megcsúszást, step skipping-et, stb. Nullpontfelvételnél egyszerűen csak ütköztetik a motort. Kapcsoló helyett a pillanatnyi áramfelvétel megnövekedése trigger-el. Ennyi.
1:40-től beszél a szenzor nélküli nullpontfelvételről.
Drágább a vezérlő - 2500 Ft kb -, mint két mikrokapcsoló, meg a FW is komplikáltabb az SPI busz miatt mint két bemenetet figyelni, de minimális alkatrészből megoldható.
Valószínűleg nem indokolt a te felhasználásodra ekkora befektetés...
-
Teasüti
nagyúr
Vannak rá open source firmware-ek, amiket webserver-en keresztül lehet konfigolni és beszélnek MQTT-ül is.
És mivel egy kutya közönséges ESP8266-ról beszélünk, ezért semmi nem akadályoz meg benne, h írj rá akár saját FW-t is, akár Arduino alapon.
Ezeket a kapcsolókat elég könnyű hack-elni, a gyártó kicsit se nehezítette meg a dolgunkat. Az a jack kimenet rajta gyakorlatilag az I2C portra kapcsolódik, szóval gyakorlatilag bármit rá tudsz kötni különösebb barkácsolás nélkül, ami I2C buszon kommunikál. Illetve ugye működik sima GPIO-ként is. És a 230V-os relé meg alap adottság, ami nem tudom fejből melyik lábra csatlakozik. A táppal nem kell törődni, integrált az egész. Csak bekötöd a 230-ba és örülsz. -
Teasüti
nagyúr
Fura, amiket kaptam még a Starter Kit-ben fotórezisztorok, azok elvileg 10k-sak. Tutorial szerint 10k-s ellenállással párosítottam és nekem tök jól működött. Nyilván volt egy kis zaj, mondjuk +-5 az ADC értéke szerint, de szépen érzékelt majdnem a teljes tartományban.
Mekkora a fotórezisztor, azt tudod? -
Teasüti
nagyúr
válasz
ZTE_luky
#9184
üzenetére
Ha elkezdesz NYÁK-ot tervezni, akkor elég hamar képbe kerülnek a bypass kondik, gyakorlatilag az egyik leggyakrabban előforduló alkatrész és egyben a leginkább félreértett is - állítólag.
Elméletileg minden egyes betáplálási pontba illő volna pufferelni. Gyakorlatilag elég egy is a szalag és a táp között. Ha többet használsz, akkor nem muszáj nagy méretűt lerakni mindenhova. Össz. kapacitásban szerintem elég az 1000 uF. Ha két ponton, akkor fele-fele. Így talán tovább csökkentheted a tok méretét, ha kisebbeket választasz. Gondolom szempont, hogy elrejtsd az alkatrészeket.
-
Teasüti
nagyúr
válasz
ZTE_luky
#9181
üzenetére
Nem-nem, párhuzamosan kell kötni ahogy a képen látható. Puffer kondenzátor néven ismeretes, ha rákeresel meg fogod érteni.
Ilyeneket használunk az IC-k Vcc lábai előtt is, ahogy a Nano-n is kell legyen egy 10 uF a proci lábánál. Ezek elsimítják a tápfeszültség ingadozásokat. Egy PWM vezérlőnél ez az ingadozás elég látványos lehet, gyakorlatilag rail-to-rail szaggatják a tápot (400 hz-en WS2812b esetén) és így a tápfeszültség is több voltos eséseket produkálhat akár. Ezeket a pillanatnyi feszültségeséseket hivatott kiegyenlíteni az eltárolt energiával. Gyakorlatilag egy low-pass filter.
A kapacitással változik a szűrési frekvenciája is, a kisebbek (<1 uF) hatékonyabbak a magasabb frekvenciákon, azokat meg konkrétan az AC komponens szűrésére használjuk és decoupling vagy bypass kondi néven ismeretes. -
Teasüti
nagyúr
válasz
ZTE_luky
#9177
üzenetére
1000 uF-től bármi megteszi. 6,3V-osat vegyél ha van, az a legkompaktabb méret. Ugye a kapacitás feszültségfüggő, így a nagyobb névleges feszültségűek nagyobb méretűek is azonos kapacitás értéken.
Nem kritikus az elhelyezés, csak "legyen közel" a szalaghoz. Berakhatsz többet is, ha szeretnél. Ártani nem fogsz vele. Azt is megcsinálhatod, hogy csak a csomóponthoz raksz egyet, vagy akár az egyik pixel elé és a másik ág meg innen fogja meghúzni a kondit visszirányban. Tök mindegy, amíg a pufferkondi "közelebb van", mint a táp. -
Teasüti
nagyúr
válasz
ZTE_luky
#9175
üzenetére
Igen, lehetőleg a mikrovezérlő lábához közel.
Kondiból - nem tudom hány pixeled van összesen - én 2200 uf elkót szoktam használni több méter szalaghoz, de 1000-et ajánlanak az Adafruit-os Neopixel útmutatóban.
Igazából itt nem kritikus a kapacitás, olyan mint a RAM: a nagyobb sosem árt, csak a túl kicsi. Ezt meg pufferkondi lévén az első pixelhez kell közel rakni. Ez jóval fontosabb, mint a védőellenállás. Ez az első pixelt védi a bekapcsoláskori túláramtól (a pontos fizikai okát én sem értem, csak papagáj módjára ismétlem az útmutatót). -
Teasüti
nagyúr
válasz
ZTE_luky
#9169
üzenetére
330-as ellenállás is jó? pontosan hova rakjam? DIgitális Out után, tehát a zöld, adatkábelre?
330 is jó, emlékeim szerint az Atmel328-asok 50mA-t tudnak leadni a GPIO-n. Az ellenállás azért kell, hogy ez alá korlátozd a leadható (és felvehető) áramot a porton. Jelátvitelnél általában 10 mA-re szokás beállítani a korlátot a port védelme érdekében. -
Teasüti
nagyúr
válasz
ZTE_luky
#9167
üzenetére
WOW, ezt nagyon igényesen összeraktad!
Hogyan tudtad így befaragni a fa elemeket? Asztalos vagy talán?
A videót is megnézhetjük?Oh, wait... Ez nem is a tied, ugye?
![;]](//cdn.rios.hu/dl/s/v1.gif)
Tehát akkor nem probléma hogy arduinón fut a szalag árama is? tehát hogy csak usbről kap áramot az arduino, is minden azon fut át? mert ugye a rajz elcsal annyit hogy a szalag nem közvetlen az áramforráshoz van kötve hanem az arduinóról kapja az 5V-ról
Nem, nem gond. Én egyetlen ledszalagos projektemnél sem használtam külön tápot a vezérlőnek. 5V-os szalagoknál legalábbis. Legyen elég bika a táp, ennyi. Viszont pufferkondik azok kellenek a szalag(ok) elé!
Az nem lenne szerencsés, hogy a táp kimenetét közvetlenül szaggatnák meg a pwm ledek. Ezt lehet megérezné a vezérlő is.Földet minden esetben közösíteni kell a szalag és a vezérlő között (ha egy tápról megy mindkettő, akkor nyilván ez adott). Különben lehet nem lesz jó az adatbusz jelszintje. Rosszabb esetben akár tönkre is mehet egyik vagy a másik a GND potenciálkülönbségek miatt, de minimum zajos lesz*. Egy 480-as ellenállást is illik berakni a vezérlő kimenetére, épp a túláramokat elkerülendő.
*Van is ezzel tapasztalatom: féklámpám kapcsán mikor 12V-os tápról teszteltem, a külső pwm vezérlő meg a laptop usb portjáról üzemelt. Elsőre nem volt közösítve a föld, csak egy szálon ment a pwm jel a panelre a vezérlőből és konkrétan üzemképtelenné tette a lámpát. Össze-vissza kapcsolt. GND közösítés után varázsütésre jó lett minden.
(Ilyen kísérleteknél ha usb-ről táplálom a mikrovezérlőt, akkor általában akkuról megy a gép. Bár elvileg nem lehet baj több dugasztáp közösítéséből, de biztos ami biztos. Drága volt a laptop.
) -
Teasüti
nagyúr
C++ kérdés.
Ez miben különbözik attól, mintha new nélkül hoznám létre egyszerű helyi változóként a példában lévő számlálót? Most tekintsünk el a kivétel kezeléstől, csak arra vagyok kíváncsi miért kéne ezt alkalmaznom (vagy milyen esetekben):int i;
int * p;
cin >> i;
p= new int[i];Mondjuk e helyett:
int i;
cin >> i;
int p[i] = {};A másodikat is futási időben hozom létre dinamikusan az adatbevitelt követően. Mi a különbség?
Ráadásul a helyi változókat úgy tudom magától feltakarítja a program, szóval még nem kell foglalkozni külön a felszabadításával sem.
(Gondolom globális tömbként nem lehet deklarálni változóval a paraméter helyén. Viszont lokális változóként úgy tudom semmi akadálya.) -
Teasüti
nagyúr
A megoldás az volt, hogy nem elég a két ESP-t 1-es csatornára tenni, hanem még a routert is 1-es csatornára kellett állítani. Más kombinációval sajnos nem működött.
Igen, azt hittem ezt már megbeszéltük korábban. ESPNow adhoc hálózatának és a WLAN-nak is egyazon csatornán kell lennie!
Így akkor ez most jó? Működik? Kipipálva ez a rész?Kíváncsi lennék egy BLE vs ESP-Now összehasonlításra, melyik lehet az energiatakarékosabb vajon.
-
Teasüti
nagyúr
Úgy értettem, hogy egy ESP32 duóval megoldani a gateway-t. Szenzor alatt meg a vezetéknélküli másik ESP-t értettem. Vagy használhatsz egy külső BT modult a gateway-en, pofon egyszerű programozni sima UART-vel kommunikál. A belső wifi-t meg netre ráállítani. Így nincs RAM limit se, mivel sima UART használat van csak, nem kell betölteni a BT könyvtárat. Igaz ez már nem BLE, hanem classic BT.
(Ha meg BLE modult használsz, annak meg lesz saját könyvtára amit megint csak be kell tölteni és vagy befér a ram-ba, vagy nem.)
Passz. BLE+Wifi ram korlátba ütközik, ez nem működik még natívan sem jelenleg.
ESPNow+Wifi viszont érdekes, annak elvileg mennie kéne. -
Teasüti
nagyúr
válasz
Tankblock
#9080
üzenetére
Nem figyeltem erre, viszont úgy veszem észre lassan a beágyazott rendszereknél is kezdődik, hogy egyre olcsóbbá válik az erőforrás, ami a programozás rovására megy. Pl egy Uno esetén a 32KB Rom-ot és 2KB Ram-ot alaposan be kellett osztani, viszont egy ESP32-nél azért a 4MB flash-nél és az 512KB Ram-nál annyira mindegy szerintem, hogy használunk-e String-eket, vagy sem.
-
Teasüti
nagyúr
Tudnátok segíteni kicsit, hogy library írásnál, hogy tudnék átadni egy Stream osztályt paraméterként?
Megnézve egy példát ezt látom, de nem tudom értelmezni. Nem láttam még ilyen szemantikát:class TinyGsmSim808: public TinyGsmSim800
{
public:
TinyGsmSim808(Stream& stream)
: TinyGsmSim800(stream)
{}Ez most mit jelent?
A TinyGsmSim808 osztályban a TinyGsmSim808 konstruktor alatt mi az a kettőspont és utána a TinyGsmSim800 függvény? A függvény meghívást nem a kapcsos zárójelek közé kéne tenni?Aztán tovább menve arra a függvényre ezt látom:
public:
TinyGsmSim800(Stream& stream)
: stream(stream)
{
Olyan függvény viszont nincs sehol definiálva, hogy stream().
Ez az egyetlen előfordulása így ebben a formában.Viszont nem értem mi történik itt pontosan a stream objektummal, amit egymásnak adogatnak át a függvények.
Ugyanitt lejebb a library függvényeiben viszont már ilyeneket látok, hstream.readStringUntil(',')Nem látom illetve nem értem hogy jutottunk el a konstruktortól odáig, hogy már hivatkozunk a konstruktornak átadott objektumra.
Szóval hol kerül definiálásra a "stream" objektum, amit a függvénymeghíváskor használunk? Vagy amikor lefut a konstruktor és a benne lévő (Stream& stream), akkor ezzel már definiálva is van? Nem kellene vmi parancsot használni külön a kapcsos zárójelben? A (Stream& stream) nem egy helyi változóként működik? Elérhető marad a teljes library-ben? -
Teasüti
nagyúr
Ahogy nézem már írnak ezekről a Serial osztályban is. Hmm, meg mernék esküdni rá régen nem volt ennyi függvény ebben. Viszont üdvözítő újítások! Ha már úgyis Stream osztályt kell használni String-ekkel, akkor legalább natívan oldja meg a feladatot, ne kelljen külön ramot foglalni a saját függvényekhez!
-
Teasüti
nagyúr
Ti tudtátok, hogy a Stream osztályban ilyen függvények vannak, hogy readStringUntil(), parseInt(), stb?
Én meg egészen idáig char változóba olvastam ki mindent és magamnak szenvedtem össze ciklusos függvényeket az adatok értelmezésére amikor az egészet le lehet rendezni pl. ennyivel:stream.readStringUntil('\n').toInt();. Timeout meg astream.setTimeout()-tal állítható. Mondjuk azt nem tudom ez kód blokkolja-e a futtatást.
Bezzeg a Stream osztállyal eddig egyetlen egy Arduinós példa megoldást sem láttam, mindenki csak aSerial.available()ésread()függvényeket használja vmilyen char változóval az adatfogadásra.
-
Teasüti
nagyúr
válasz
Tankblock
#9069
üzenetére
Szerintem itt te vagy az egyetlen, aki natívan programozza az ESP-t.
Annó én is csak azért akartam megpróbálni, mert akkoriban az Arduino Core-ban még nem volt benne, ami nekem kellett. Viszont én már megakadtam a programozó környezet beállításánál. Arduino IDE után egy Eclipse nekem kínai. Hobbi szinten nem is tartok rá igényt. Persze gondolom más lenne a helyzet, ha lenne IT végzettségem. -
Teasüti
nagyúr
ESPNow miért nem jó? Úgy olvastam, ha ugyanazon a csatornán megy, mint a normál wifi, akkor tud párhuzamosan mindkettőn kommunikálni.
Amúgy BLE-re nem gondoltál még? Sztem adja magát, gyakorlatilag erre van kitalálva, hogy szenzor adatokat küldözgessünk vele elemes kis fogyasztású eszközöknél. Mondjuk azt nem tudom, hogy a BT és a Wifi együtt működik-e. Wifi-s projektem még nem volt.Amúgy Core 0-s hibákat nálam a nagyobb delay() oldotta meg, de újabban inkább csak olyan műveleteket indítok azon a magon, ami egy meghívásra csak egyszer fut le. Minden ciklikus folyamat az 1-es magon van.
-
Teasüti
nagyúr
Innen:
(#9043) xboy89
Meg, megoldható. Ha rákeresel a témára, akkor rendre ilyen 2-3 méter limitekről számolnak be, ami még üzembiztosnak mondható a célnak megfelelő kábelezéssel.(#9044) Janos250
Hantek 6022BE.
De van egy kézi DIY szkópom is, ha csak gyorsan meg akarok lesni vmit, vagy nem tudom vinni a laptopot és az usb-s szkópot. Ez is tök jó cucc az áráért (feléért is meg lehet találni), bár csak 10 uS-ig tud lemenni, ami a több száz Khz-es jelekhez már kevés. -
Teasüti
nagyúr
A jegyzőkönyv kedvéért: ESP8266 és az ESP32 is 5V toleráns a GPIO lábakon.
A mikrovezérlő mondjuk ha 8266-ot használsz és bírja az 5V-ot, akkor úgy leosztani hogy az AD konverterre max 5 V kerüljön de inkább kevesebb.
Erre írtam, hogy bírni bírja, de az AD konverter 3,3V felett nem mér. GPIO használatban nincs különbség a 8266 és 32 között.I2C kapcsán meg mérés nélkül nem lehet rá mondani semmi értelmeset. Amiben biztosak lehetünk, hogy abban a beállításban nem működik. Nekem úgy tűnt tényszerűen kezelted, ezért ugrottam rá.
Korábban is azt hiszem az én esetemben került szóba a dolog, azóta kellően utánajártam a dolognak. Főleg ha már 2 méteres buszt tervezek rajta 6 slave-vel. -
Teasüti
nagyúr
Már ne haragudj, de honnan veszed ezeket a blődségeket?
ESP32 és ESP8266 portjai 5V toleránsak, ez igaz. De ez nem azt jelenti, hogy üzemszerűen rá kell küldeni az 5V-ot egy 3,3V-os logikára. Az meg hogy éppen egy ADC-re kötnél be 4V-ot, az meg külön vicces: ugye az tiszta, hogy 3,3V-ig tud csak mérni az ADC?I2C-hez visszatérve: I2C amúgy nem igazán plug&play protokoll, a buszt minden esetben méretezni kell egyrészt vezetékezés szempontjából, másrészt a buszon lógó eszközök szerint.
Az, hogy próbapanelen random összedugdosol vmit random felhúzókkal, random vezetékekkel az vagy működni fog, vagy nem. Az meg hogy mérés nélkül egyből konklúziót vonsz és olyan kijelentéseket teszel, hogy 10 cm felett nem működőképes az I2C, az még jóindulattal is megmosolyogtató.Mellékesen nekem sikerült értelmezhető jelet kicsikarnom egy SI1145-ös szenzorból 10 méter vezetéken keresztül.
A SCL-re kellett berakjak külső felhúzót, ami kb 3k-s eredővel rendelkezik. SDA-ra nem is kellett külső felhúzó, illetve inkább csak rontott a jelen, mint javított volna.
Ami viszont fura, hogy 1k-s felhúzóval meg se mukkant a busz.Ha vki hozzáértő megnézi az alábbi képet, akkor a sárga jelnél mi az a két lépcsős emelkedés? Ha erősebb felhúzót rakok rá, akkor magasabb feszültségre fut ki a feltölés. Aztán vmiért meredeken ugrik fel a tetejére. Ezt a hirtelen ugrást nem értem. Lehetséges vmi áthallás a két csatorna közt? Mintha az SCL húzná magával az SDA-t, úgy tűnik.
-
Teasüti
nagyúr
Akkor vmit rosszul csinálsz szerintem.
Több beszámoló szerint is működik néhány méterig, ha a busz kapacitása határértéken belül marad.
Csináltam egy gyors mérést 10cm-es és 10 méteres vezetékkel, 100 Khz-en. Felhúzó mindkét esetben az Uno belső ellenállása volt (50k körül, ha jól emlékszem).10 cm:
10 méter telefon vezeték (ez már nem működik):
Próbaképp beraktam egy-egy 10k-s külső felhúzót. Nem igazán láttam különbséget a felfutási és lecsengési időkben. Nem teszteltem sokáig, mert már késő van. De majd lesz kedvem játszadozok vele egy kicsit.
Mindenesetre nem tűnik annyira vészesnek, egy feszesebb felhúzóval talán életre kelthető.Ami nekem fura ezen, hogy a hosszú vezetéken hogy tud megjelenni 5,6V az 5V-os Unóról USB-ről táplálva?
Talán vmi indukció a vezetékben? Fel van tekercselve. -
Teasüti
nagyúr
Még véletlenül sem kéne felhúzni a portot az akku feszültségére!
Az egy dolog, hogy 4,1V-os akkunál és 3,3V-os vezérlésnél a Q2 PNP fet talán kapcsolható*, de ettől függetlenül a mikrovezérlő lábát nem lehet felhúzni 4,1V-ra!
Ráadod a HIGH értéket, kap a port egy visszirányú áramot és pápá mikrovezérlő.
Ebben az esetben az R54-et el kell hagyni!*Ami egyáltalán nem garantált, hisz az IRLML6302 Vgs(th) feszültséget -0,7 és -1,5V közé írja, a 4,1V-os akkuval és 3,3V-os mikrovezérlővel meg ugye -0,8V-ra lehet csak beállítani a Gate-et ami még nem biztos, hogy elég a teljes nyitáshoz. Ha 4V alá merül az akku, akkor már elvileg jó lesz.
Konklúzió: PNP tranyóhoz kell a driver.
-
Teasüti
nagyúr
Kell oda az az NPN meghajtás. PNP fetet nem tudsz vezérelni mikrokontrollerrel, mivel az pozitív feszültségre nyit és az akku kapocsfeszültsége nagyobb, mint a GPIO-é. Ha azt közvetlen gpio-ra kötnéd, akkor folyamatosan zárná az áramkört és így merülne az akku, amíg el nem éri a Vcc+küszöbfeszültséget, ha jól tévedek. Mondjuk ahogy nézem a küszöbfeszültség -2 és -4 V közt van IRL9530-nál, így még az is lehet, hogy talán még működne is valamennyire a 4,1 V-os akku esetében.
-
Teasüti
nagyúr
válasz
Janos250
#8982
üzenetére
Tudnál mutatni egy képernyőmentést egy ilyen logic analyzer kimenetről? Kíváncsi volnék miben más, mint egy oszcilloszkóp.
Köszi!Amúgy jól értem, h ezzel a fogadó eszközt helyettesíted? Ugye szkópnál csak belehallgatsz a csatornába nagy impedanciás bemenetekkel, de a dupoint arra enged következtetni, h ezt meg direktbe kell kötni a portra. Milyen bemenetek vannak ezen? Open-drain, open-collector?
-
-
Teasüti
nagyúr
Azt tegyük hozzá, hogy a LAN oldalon a kliensek gateway címnek a router LAN oldali címét látják, vagyis a router címét kell megadni, ugyanazt amin a webes felületet nyitod meg.
Ezt is minden eszközön be kell állítani a saját IP cím és subnet mellett, ami nem dhcp-vel kapja meg a kapcsolati adatokat.
Egyszerűbb lenne az életed, ha olvasgatnál kicsit a helyi hálózatokról, ahogy korábban javasoltam.
-
Teasüti
nagyúr
Megérkezett ez a Sim808-as modulom, azzal játszogatok most.
Azt kell mondjam nagyon király kis cucc ez!
Egy UART kell hozzá, meg egy-egy gpio port a be-/kikapcsoláshoz, valamint az alvó üzemmódhoz (ezeket fel/le kell húzni és tartani egy kis ideig, kvázi gombnyomást szimulálva).
Powerkey gombbal kézzel is lehet kapcsolni. De ha fixen földre húzzuk ezt a lábat (vagy áthidaljuk a gombot), akkor automatikusan boot-ol amint tápot kap és parancsra le is lehet kapcsolni. Megspórolva egy portot. Akkus üzemhez ez szerintem nem ajánlott, hisz Vbat-ról húzza fel ezt nem tudom mekkora ellenállással. De akkus üzemnél e nélkül is boot-ol magától, ha az akkufesz elég magas. CV/CC töltőáramkör integrálva a modulba.
BT3.0-át tud a modul, külső antenna kell hozzá.
És mindent AT parancsokkal lehet elérni, a BT SPP profilnál van transzparens kapcsolati mód is, amikor nem kellenek az AT parancsok, hanem egyszerűen fogad és küld UART portra mindent, mint egy sima HC-06 modul.
Előnye az ESP32-vel szemben, hogy beállítható pin kód a csatlakozáshoz és ugye sima UART, vagyis nem kell betölteni 800 KB-nyi library-t programozáskor. Valamint az erősebb antenna.
GPS-t rém egyszerű használni, igazából van rá kb kettő AT parancs ami sűrűn kell (bekapcs, pozíció lekérdez), NMEA mondatokkal próbáltam, de többféle protokoll szerint tud kommunikálni. Tökéletesen működik, még az USB portról is az ESP32 mellett (elvileg 2A-es táp kéne neki). GSM részét nem próbáltam még, kéne vennem egy feltöltős kártyát bele.
Valamint kéne szerválnom hozzá egy mikrofont és egy hangszórót.AT parancsfeldolgozásra tudtok vmi könnyű módszert? Sima text parsing jut csak eszembe.
Jah és Janos250 köszi a hardware serial tippet, valóban odatehető a port arra a lábra, amelyikre tetszik.
-
Teasüti
nagyúr
válasz
Tankblock
#8936
üzenetére
WOW, ez tök jó!!
Gondolom ugyanúgy ki van vezetve rajta minden tüskére is mint a devkit-en, szóval a beültetett modulhoz is jó kettő az egyben.
Annyi, hogy ezen sincs rajta az auto program áramkör. Vagy nem látom sehol. Nyomni kell a gombot feltöltéshez?
Köszönöm a tippet! -
Teasüti
nagyúr
De, ugyanaz a kiosztás. Csak nyilván olyan panelt nem használhatsz külső modulhoz, amin már rajta van egy.
Az UART busz hülyét kap, ha két modult kötsz rá.
(#8934) Janos250
A linkelt programozón nincs rajta az a két tranyó, ami kell az invertált logikához. Így az auto letöltés bukta.
Valamint ránézésre a 3,3 voltot valszeg feszültségosztóval állítja elő egyéb hijján, ami meg hááát...
Azok a 0603-as ellenállások nem úgy néznek ki, amire szívesen rákötnék akár csak 100 mA-t.
Az 1/10W-os korlátjukba legfeljebb 68 mA fér bele 1,7V-os drop-nál, ezzel meg nem biztos, hogy meg lehet hajtani egy ESP32-t. (Nem jártam utána.)
Szóval az UART kommunikáción kívül konkrétan semmire nem jó.
A devkit panelje meg semmivel nem kerül többe, vagy talán még olcsóbb is mint egy tisztességes FTDI programozó. És szerintem bekötni is ugyanannyi, mint egy FTDI programozót: usb az egyik végén, dupoint a másik végén.
-
Teasüti
nagyúr
Nálam nem gond, egy egyszerű áramtalanítás megteszi reset-nek.
A devkit panellel meg a NYÁK-ra ültetett modult gondoltam programozni.
Nem kell a devkit-re beültetni semmit, csak a megfelelő tüskéit rákötni a NYÁK-on lévő modulra és voilá: éppen úgy programozod, mintha devkit-re lenne beültetve. Talán még eddig ez a legideálisabb megoldás - automatikus letöltés és nagy sebesség -, ha nem is a legpraktikusabb. -
Teasüti
nagyúr
Nem tudom ez a programozó mennyivel jobb mint egy FTDI
Ha megfigyeled az ESP32 programozót, akkor azon rajta van az auto letöltéshez szükséges két tranyó is, ami lehúzza az EN és IO0 lábakat. Gyakorlatilag a Devkit áramköre egy az egyben CH340g-vel. Így mint írtam volt megspórolható még a két gomb is a NYÁK-ról.
Ezzel konkrétan nem kell semmi kiegészítő a modul mellé az EN felhúzó ellenállásán kívül. Kivezeted 6 tüskére a Vcc, GND, RX, TX, EN, OI0 lábakat, rá erre a programozóra és uccu neki!
Mondjuk a CP2102-es programozó szimpatikusabb lenne, ilyen van a devkit-en is, de az mellé kell egy auto-program áramkör még pluszban vagy a NYÁK-ra, vagy vhova (vagy hát különben nyomogatod a gombokat).
Talán az volna a legideálisabb, ha gyorsan összeraknék magamnak egy ilyen programozót a fenti mintájára CP2102-vel.szerk: hmm ami azt illeti nem is kell saját, találtam hozzá "eredeti" devkit programozót!
(#8925) tvamos
Nem lehet, hogy a fura program nyelv miatt?
Állítólag nem rég jött hozzá ki egy C fordító.
8 független mag azért elgondolkodtató.
De tényleg nincs elterjedve egyáltalán. Teljesen véletlenül találtam rá. -
Teasüti
nagyúr
100u lesz az inkább, 0,1u-ból a modulon belül is van egy maréknyi.
Én ezen a programozón gondolkozom még, ehhez elég csak kivezetni tüskére azt a 6 lábat, nem kell se gomb, se semmi. Egyedül az EN-re a felhúzó és egy bypass kondi az üzemszerű működéshez.
Mondjuk sebességben csak 115200-at tud, ami elég karcsú: a devkit-en lévő chip 8x ekkora sebességet biztosít.
Ha generic FTDI csatolót használok, ahhoz meg kellenek a gombok is. Bár lehet ez a programozó meg jó lenne más 3,3V-os chipekhez is, mint pl a 8266.A második részében azért elég vicces miket bénázik. Nem egy idegbeteg állat. Én már kivágtam volna az ablakon.
Erre lesz jó a forró levegős forrasztás, ez az egész megvan vele 2 perc alatt sokkal szebben.
Én már próbáltam pákával alulról beforrasztani hűtőpadot, nekem nem működött a dolog. Az a fránya ón sehogy se akart felszívódni a másik oldalra. Mondjuk nálam 0,7 mm-es via-k voltak, nem tudom amúgy mekkora átmérőnél életképes a dolog. Én mondjuk tuti ezzel kezdtem volna a többi láb előtt, ha sikerül akkor erősen megtartja a chip-et, ha meg nem sikerül akkor könnyen le lehet szedni. A kontinuitás vizsgálat nem elég, ahhoz néha még forrasztani sem kell. -
Teasüti
nagyúr
Elültetted a bogarat a fülembe:
Azt nézem, hogy a wroom32-höz tényleg nem kell semmi külső hardver a működéshez. A gombok is csak a programfeltöltéshez max.
A devkit-en lévő rakás kondi és ellenállás is mind a táphoz van és az usb-ttl chip-hez.
Hmmm, készítek egy barebone nyáktervet is, úgy is tervben van egy levegős forrasztóállomás, azzal szépen be lehet ültetni mindenféle IC-t.
Mondjuk a modul alján lévő hűtőpadot nem tudom hogy lehetne reflow kemence nélkül, te azt hogy fogod megoldani? Lehet egy bazi nagy via-t kéne odarakni és "felforrasztani" a lyukat. -
Teasüti
nagyúr
válasz
Tankblock
#8914
üzenetére
Nem, ez megdöglött. Piros Led folyamatosan villog rajta, kivéve USB-re kötve.
Se 3V3-ról, se 5V-ról nem megy. Az UART0 nem válaszol se boot-oláskor a Serial monitoron, se a program feltöltésnél nem kapcsolódik (EN és IO0 vagyis a Reset és Boot gombok lenyomva előtte). Jah és melegszik az ESP modul maga is USB-ről. Ez kuka.Amúgy nem értem miért, a DevkitC tervrajzán rajta van a védődióda a Vbus-on ( D3 1N5819), így elvileg nem kellett volna tönkremennie. Hacsak a kínai nem spórolta le róla. Nem igazán tudom visszakövetni a vezetősávokat a panelen. NYÁK tervet meg nem találok róla.
-
Teasüti
nagyúr
válasz
Tankblock
#8914
üzenetére
Nem tudom, vmelyik melegszik a három közül (dióda, ch340g, ldo), nem érzem melyik. Gépre kötve a Windows meg nem reagál rá.
Lehet javítható, ha csak a dióda vagy az LDO. Ha az usb vezérlő ment ki, azt az isten nem cseréli ki ezzel a QFN tokozással.
Esetleg az LDO-t még bevállalom, lehet ki is próbálom 3v3-ról betáplálni hátha úgy még megy.
Ruggedunio-ból kiindulva mind az LDO, mint a mikrovezérlő megdöglik, ha GND felől jön a ménykű. -
Teasüti
nagyúr
A Z tengely körüli kúszás/forgás engem nem érdekel (Amúgy miért nem használsz 9 tengelyes szenzort? Az iránytűvel szerintem a yaw is korrigálható.). Az X és Y tengely kell csak a dőléshez és az egykerekezéshez.
Nekem ehhez elég a Teapot demo program, négy értéket használok csak amiből kettő nyers adat (X gforce, temp), kettőt pedig a DMP számol (roll, pitch). Alvó üzemmódban meg bármilyen tengelyen bármilyen gyorsulás felébreszti a vezérlőt.Amúgy nem, nem igazán van vele tapasztalatom. Úgy 2 éve szórakoztam ezzel utoljára. Azóta várja jobb sorsát. Amúgy fura, hogy még mindig nincs "hivatalos" library a DMP-hez, amikor már 2012-ben kiadták hozzá a dokumentációt.
-
Teasüti
nagyúr
Most minden funkciót beletenné legszívesebben, de annak meg nem sok értelme van
Már hogyne lenne értelme?! Nálam ez úgy nézne ki, hogy ma még kínai mutatós óra kicsi képernyővel, holnap már smart mirror digitális órával a felső sarokban.
Így vagyok a saját projektemmel is. Amit lefényképeztem nyákot már megterveztem egy jó ideje, de a múlt héten láttam mit lehetne még belepaszírozni és azóta 3x újraterveztem már. GPS tracker se volt betervezve eredetileg, de aztán megláttam mennyibe kerülnek a kész termékek, aztán megnéztem mennyibe lenne csak a modul. Ekkor már nem volt visszaút. -
Teasüti
nagyúr
Na várj csak, ez nem is vezérelt mechanika! Legalábbis semmi jelét nem látom, hogy bármihez kapcsolódna egy elemen kívül.
Azt hittem motoros mutatókat tervezel, amit természetesen az mcu vezérelne.
Akkor ez egy időjárás állomás lesz, kínai analóg órába építve?Ami a hálózatot illeti, kifelé egyszerűbb a helyzet, mert a router ezt megoldja alapból.
Külső kérés a belső hálózatra nem működik publikus IP cím nélkül.
De nem látom semmi okát mi értelme volna közvetlenül az órára kapcsolódni, ha egyszer amúgy is az már tölti fel az adatokat vhova. Szóval ez a része szvsz tárgytalan. Én tuti szerverre küldeném ki, ahhoz nincs szükség közvetlen hálózati kapcsolatra az óra és a felhasználó között. -
Teasüti
nagyúr
LOL, kicsi a világ.
A hajlik résznél kicsit ráncoltam a homlokom. Mekkora nagyságrendekről beszélünk? Század, tized milliméter? Van ennek jelentősége? Tudnál mutatni ilyen automotive előírásokat? Én csak AS szabvány szerint készítem a dolgokat, de ha volna ilyen támpontom, az biztos javítana rajta.Amúgy ahogy nézem van egy rakat ilyen mini barebone ESP. Még válogatni is tudsz.
Úgy tűnik mindnek a 8266 az alapja.
Hogy oldod meg a mutatók működését? Jó nyilván léptető motorral, de honnan tudja majd hogy áll a mutató? Mi lesz a nullpont? -
Teasüti
nagyúr
Az egy accelero + gyro szenzor. Egy gyorsulásérzékellő önmagában tényleg szar erre a felhasználásra. Eleinte a féklámpát szerettem volna működtetni vele, de megtapasztalva mennyire szarul működik más termékekben ez a koncepció éppen az általad felsorolt problémák miatt, így azt inkább a sebességszenzorból okoskodom ki. Ebben az accelero csak segéd szenzor lesz, a kettő adattal együtt már lehet érzékelni hiba nélkül az intenzív gyorsítást és lassítást. (Többek közt ezzel válik majd interaktívvá a ledszalagos világítás is.) Önmagában egyik sem ideális - előbbi a megcsúszó kerék miatt adhat fals adatot, utóbbi meg a zaj miatt.
Amúgy a nyers G erőt csak egy tengelyen olvasom, a rázkódás meg általában nem a motor hosszanti tengelyén keletkezik. Persze hatásosan lehet szűrni is a jelet.
Amúgy menet közben inkább a DMP-t fogom használni, a gyro-t meg nem zavarja a rázkódás a pontos szögelfordulásoknál. Ez wheeli és stoppie érzékeléshez, valamint dőlésszög monitorozáshoz lesz használva.
Álló helyzetben meg nincs rázkódás, ekkor a nyers szenzor adatok tökéletesek védelmi funkciókra, DIY riasztóként. Ezt megtámogatva a GPS+GSM modullal telefonra kapom majd az értesítést, ha vmi történik. Ekkor ez a szenzor megint csak fő szerepet fog játszani, hogy meg lehessen állapítani viszik-e a gépet vagy csak meglökte vki. A beavatkozás is ez alapján történik majd.Az meg hogy a nyák rezonálni fog... Azért egy tüskesor elég stabilan tud tartani. Az alaplap meg le lesz csavarozva. Ennek a merevsége meg nem is kérdéses. Főleg, hogy relatív kicsi méret és 1,6 mm vastag üvegszálas lap.
De ha nagyon megerőltetem magam, akkor olyan burkolatot nyomtatok neki, hogy a szenzor a fedlaphoz lesz hozzácsavarozva, ha muszáj.Az órához kapcsolódóan:
Gondolom NTP szerverről veszed majd a pontos időt. Ehhez nem volna célszerűbb egy ESP-01? -
Teasüti
nagyúr
Persze, simán. Egyszerűbb beültetni egy tüskesort, mint kézzel beforrasztani azokat az oldallábakat. Na meg így megvan minden alkatrész, ami kell a működéshez. Nem kell baszakodni usb porttal, meg a QFN tokozású USB-Serial konverterrel. (Ezt reflow nélkül konkrétan fel se lehet rakni. Talán esetleg gázzal?) Meg ott van az a rakás kondi és ellenállás, ledek, reset gomb, LDO, FET-ek, stb. Mit nyerek vele? Sok szopást. Azon kívül max egy letisztultabb arculatot. Ugyanannyi helyet foglal a PCB-n a hozzá járó alkatrészek miatt, ha meg shield formátumban használom, akkor tudok pakolni egyéb dolgokat a tüskesorok közé is.
Majd ha lesz reflow kemencém, akkor elgondolkodok rajta. De addig hobbi szinten meg szerintem teljesen felesleges miniatürizálni. Ez már ipari kategória, amihez ipari eszközök kellenek. SSOP-24 chip-et se élveztem beforrasztani, abból is nagyobbat vettem volna ha van. -
Teasüti
nagyúr
válasz
Janos250
#8891
üzenetére
EasyEDA.
Jobban mondva a JLCPCB, mivel hogy azóta külön váltak. Már a második csokor NYÁK-ot rendeltem tőlük, az igényeim 99%-ához tökéletes választás. A maradék 1% az a thermal via volna, amit nem tudnak elkészíteni. (Ezt én hővezető pasztával orvosoltam.) Illetve az alapértelmezett NYÁK opciókkal kedvező az ára, ha van vmi extra igényed, mint mondjuk 2 oz vezetőréteg vastagság, vagy 1,6 mm-től eltérő PCB vastagság, esetleg a zöldön kívül másik színben, vagy egyéb spéci dolgok, akkor már nem annyira kedvező.
Az első 5-10 db-os tételt kis méretű PCB-k esetén gyakorta megcsinálják 2 $-ért. De teljes áron sem vészes, a féklámpámat ami 168x56 mm-es egyedi formával, megcsinálták 12 $-ért /5db. A szállítás 6 $ légi postával és 24 $ DHL Express-szel (nekem).
Batch order esetén érdemes játszadozni melyik tételt rakod be először a kosárba, arra jár a 2$-os spéci ár. -
Teasüti
nagyúr
válasz
Janos250
#8873
üzenetére
Nem egészen. Hanem, hogy a flash memóriának fixen le vannak fogva azok a portok, amin pl az UART2 is van. AZ UART3 használata adott, csak azt hittem a feladathoz kettő UART port fog kelleni külön a GPS-nek és külön a SIM-nek, plusz a programozó port ugye. De ez a 2in1 modulokkal nem játszik szerencsére.
Apropó, kinyírtam az egyik vezérlőmet fordított usb polaritással, így felmerül a kérdés ki honnan veszi az ESP32-ket? Ali-n a legolcsóbb rev1-es lap amit eddig találtam 7 font.
Mindenképp ez a WROOM32 DevKitC-vel megegyező lábkiosztás kell, vagyis a kevesebb lábú NodeMCU jellegű ESP32S lapok nem jók.
(Hmm vagyis hát már van kész nyák tervem és legyártott nyákom a DevKitC-hez, de nagyon szemezek a Wemos Lolin32-vel is, amin van Lipo akku töltő és keskenyebb is. )
Köszi! -
Teasüti
nagyúr
Nekem ez alapján úgy tűnik, hogy éppen a PLC az ami eléggé korlátolt. És ha én többször szeretnék írni/olvasni egy portot a loop() egy átfordulása alatt?
Amúgy meg nem egészen értem a dilemmát a sorrend vezérlésnél. Azt írtad nem mindegy melyik gombot milyen sorrendben olvassa be a program. Na egyrészt ez a te programodtól függ, hogy mit milyen sorrendben kezelsz, másrészt viszont (nem tudom egy PLC hogy működik) itt amíg te megnyomsz egy gombot, addig a loop() nem túl komplex programok esetén több ezerszer lefut.
Mit számít az hány nanoszekundum telik el két port írása/olvasása között??
PLC-vel amennyire én tudom általában amúgy is automatizált gépeket vezérelnek, és nem hiszem, hogy a mechanikus, pneumatikus, hidraulikus, stb. aktuátorok akár csak milliszekundomos késleltetéssel dolgoznának.
Itt max akkor lenne jelentősége a sorrendeknek, ha a program feltételes várakozással tölti az ideje nagy részét és megvárja míg a perifériák befejezik amit csinálnak. Ha ekkor ugrik a következő sorra, akkor nyilván számít mi a következő sor. Lehet olyan programot írni, aminél egy program ciklus konkrétan megegyezik az adott gép feladatának egy ismétlésével. De a lineáris programozás nem erről szól, optimális esetben nincs várakozás. Itt a loop() folyamatosan fut és csak akkor lép be a feltételekbe, ha történik vmi érdemleges. Vagyis itt amíg a gép elvégez egy feladat ciklust, addig a program ciklus több ezerszer is lefuthat. Arduinon nincs blokkolás a programban, az egy magos processzorokon még a delay() használata se követendő példa. -
Teasüti
nagyúr
Viszont a minden periféria "erre" az mcu-ra lesz bekötve, így nem volna praktikus egy másik vezérlőre kötni a gps-t. Azon filózom kihagyom a külső akkut és inkább a jármű akkujáról oldom meg vmi programozható öntartó relével.
ESP8266 nem játszik, a wifi ide haszontalan.(#8869) Tankblock
Használatban; de nem lesz szükség a második UART portra végül. Így hogy vannak 2in1 modulok, így elég egy port is. -
Teasüti
nagyúr
Jó reggelt! Szeretnék egy gps és gsm modult, viszont csak egy UART portom van szabad (minden egyes egyéb port felhasználva az ESP-n). Van ilyen 2in1 modul, ami képes egy csatornán kommunikálni mindkét egységgel?
Mondjuk esetleg ez?Illetve filózok még azon, hogy akkuval kéne megtámogatni a projektet éppen a tracking miatt (amúgy gyújtásról megy a táp), ebben tudnátok segíteni? Ez lenne az első akkus kísérletem, se hardver terén, se programozásban nem ismerem a feltételeket.
Köszönöm! -
Teasüti
nagyúr
válasz
Janos250
#8861
üzenetére
Táp szűrő kondikként is szoktak rá hivatkozni. Igen, a Vcc és GND közé rakott kondik a chip Vcc lába előtt.
Ha ezt nézem, akkor e szerint tele van bypass/táp kondikkal a devkit az LDO előtt és után, az usb-uart chip-nél és az esp modulnál.
Viszont ránézésre a kéznél lévő modulomon és a rajzon nem egyenlő számú kondit vélek felfedezni.
És be se tudom azonosítani a Vdd33-on lévő kondikat. -
#8857
Teasüti
nagyúr
dangerzone
#8854
Teasüti
nagyúr
válasz
dangerzone
#8854
üzenetére
Szerintem én vagyok az egyedüli itt, aki ezzel a kezdőcsomaggal indított.
Általában Ebay-es Kit-eket szoktak ajánlani töredékáron. Az egyedüli dolog ami azokban nincs benne, az az eredeti Arduino Projekt könyv, ami végigvezet az elektronikai és programozási alapokon úgy, hogy még egy 8 éves gyerek is megértse. Valamint jól illusztrált beszédes kis tutorial-ok a dobozban található alkatrészekhez.
Ha nulla elektronikai ismeretekkel vágsz bele mint én annó, akkor ez jó kiindulópont. Én nem bántam meg, megint megvenném ha elölről kéne kezdenem.
De ha megvannak a fizikai alapok (áram, feszültség, ellenállás, Ohm törvénye, soros/párhuzamos kapcsolás, stb), akkor szerintem felesleges kiadás.Mondjuk elsőre én maradnék az Uno-nál és arra épülő bevezetőknél.
De ha bevállalósabb vagy, akkor mehet az amit (#8856) aryes írt, de ott meredekebb a tanulási görbe és azt is figyelembe kell venni, hogy az 3,3V-os lap, míg az Uno 5V-os. -
Teasüti
nagyúr
Ez egy 4 MB-os ESP8266 usb csatlakozóval és ch340 vezérlővel? Hmm, tetszik.
Nem találok infót, hogy miben különbözik a V2 és V3. Nem feltételezem, hogy más lenne a lábkiosztás, de azért ellenőrizd, hogy az adatbusz ugyanúgy van-e bekötve! Van másik eszköz is az adatbuszon, vagy csak a hőmérő? A felhúzó ellenállásokban talán lehet eltérés, meg kéne nézni szkóppal milyen minőségű jelet ad az egyik és a másik. Ha programozható, akkor kikapcsolnám és csak a külső felhúzókat használnám. Ha több eszköz is lóg a buszon, akkor ott lehet, hogy túl feszesek a felhúzók így együtt. Vagy pont ellenkezőleg. Mérés nélkül nem fog kiderülni.
Esetleg próbáld meg 100 kHz-en járatni a buszt! -
Teasüti
nagyúr
Hát ha vki webszerver-t szeretne beállítani otthon, akkor szerintem eléggé alapvető, hogy tudja mik azok a számok amikről screenshot-ot mutattál.
De fogalmazhatnék úgy is, hogy ha nem értesz hozzá, akkor ne babráld a router és a Windows hálózati beállításait!
...mert egyszer csak azt fogjuk látni, hogy xbox89 utoljára bejelentkezve 3 nappal ezelőtt. -
Teasüti
nagyúr
Na várjál az más téma! Én ott végfelhasználó voltam, én ott letojtam hogy milyen SDK-t ad kicsoda. De azért a játékfejlesztőknek már a kezükben kellett legyen a cucc előre, különben hogy érkeznek rá a címek? Mi itt kérem szépen "fejlesztők" vagyunk (muhahha).
Miért nincs teljes körű SDK-nk?
(Nem Arduino Core, hanem még az ESP IDF se támogat mindent, amit a hardver tudna.) -
Teasüti
nagyúr
válasz
Tankblock
#8774
üzenetére
Wow, azt se tudtam, hogy van ilyen BT szabvány.
Amúgy annyira természetellenes nekem, hogy terveznek egy hardvert és nincs teljes körű támogatás hozzá évekig.
Mintha az nVidia kiadna egy új GPU-t, de azt mondaná a fejlesztőknek, hogy a hardver tudja a dx12-t, de majd csak jövőre készül el hozzá az SDK... -
Teasüti
nagyúr
Egyenes arányosság. Általános iskolás matematika.
A max kimenő feszültséget meg értelemszerűen a várható max bemenő feszültséghez kell igazítani.
Én GPIO bemenetekre amúgy mindig rakok Zener-t, úgy nem okoz problémát a túlfeszültség se (meg a negatív feszültség se). Persze nyilván a diódát a feszültségosztó áramához kell méretezni. Általában én mikroamperes tartományban szoktam mérni (R1+R2 = 10-100 kOhm) és 1/2 wattos furatszerelt diódákat pakolok mellé. Bombabiztos. Mondjuk elemes üzemnél lehet lejjebb is menni, pár száz kOhm-os osztó és smd dióda.Amúgy ha az akku kapocsfeszültségére méretezel és aztán ráadod a töltőfeszültséget, akkor lehet ott túlfeszültség.
-
Teasüti
nagyúr
válasz
Janos250
#8754
üzenetére
Lehet az a parancs nem bonyolultabb, mint egy Serial.print().
De a wifi konfigurálása igen. Az adhoc hálózat telefonon meg körülményes ha közben nem akarsz lecsatlakozni a router-ről sem - nem is hiszem, h ez megoldható Android-on. Illetve a mobilnethez is konfigurálni kell a telefont, mert amúgy az ESP-n keresi a netet. Nem az ESP-n kényelmetlen, hanem a telefonon.
Amíg BT-t megkeresem csatlakozok és örülök (és párosítás után mindez az alkalmazásból történik pár pillanat alatt), addig a wifi nem ilyen felhasználóbarát. Wifi az csak úgy jó, ha router-re csatlakozik az eszköz. Peer-to-peer csatlakozásra szerintem nem való.
Ez majd a Wifi Direct-el változhat - az nem dob le a csatlakozott hálózatról sem a telefonon -, de addig is a BT az egyetlen kényelmes megoldás csatlakoztatott eszközökre*.*Wiki szerint az IOT is ebbe a kategóriába esik, de amit ezalatt én értek, az inkább a hordozható eszközök amik közvetlenül kapcsolódnak a vezérlő eszközhöz, nem hálózaton keresztül. Pl egy okosóra, az a legjobb példa a csatlakoztatott eszközre az én értelmezésemben.
A Classic BT Serial teljes mértékben implementálva lett tavaly óta, így már én sem a BLE könyvtárat erőszakolom meg erre a feladatra. Classic BT Serial-ra meg van egy rakás alkalmazás is Play-en, de én pl MIT App Inventor-ban kalapálok hozzá sajátot.
Van hozzá beépített példa is, tutorial se kell.
Ennyi az egész zanzásítva:#include "BluetoothSerial.h"
BluetoothSerial SerialBT;
SerialBT.begin("ESP32test"); //Bluetooth device name
SerialBT.write();
SerialBT.read();De valóban olyan egyszerű az egész, hogy be is másolom ide:
#include "BluetoothSerial.h"
//#if !defined(CONFIG_BT_ENABLED) || !defined(CONFIG_BLUEDROID_ENABLED)
//#error Bluetooth is not enabled! Please run `make menuconfig` to and enable it
//#endif
BluetoothSerial SerialBT;
void setup() {
Serial.begin(115200);
SerialBT.begin("ESP32test"); //Bluetooth device name
Serial.println("The device started, now you can pair it with bluetooth!");
}
void loop() {
if (Serial.available()) {
SerialBT.write(Serial.read());
}
if (SerialBT.available()) {
Serial.write(SerialBT.read());
}
delay(20);
} -
Teasüti
nagyúr
válasz
Janos250
#8733
üzenetére
Mindkettőnek megvan a maga szerepe. IOT-re és önálló eszközökre egyértelműen wifi. A csatlakoztatott eszközökre viszont inkább a BT. Wifi nem igazán helyettesíti a BT-t (Wifi Direct-re meg még nem láttam példát ESP32-n, az még várat magára), az adhoc AP üzemmód meg a legkevésbé se ideális megoldás peer-to-peer használatra, az túl kényelmetlen és kompromisszumos a vezérlő eszközön, valamint bonyolultabb is a BT-nél: BT egyszerű mint az UART, wifihez meg kell először is egy konfig, aztán lehet tartalmat gyártani a webes letöltéshez - na inkább hagyjuk.
Ár/értékben meg lehet hogy a legjobb az ESP, de akárhogy is nézem annak az áráért egy maréknyi Atmel-t lehet venni. És nagyon sok feladathoz amúgy is overkill egy ESP32. -
Teasüti
nagyúr
Én nem elektronikát tanultam, így onnan kezdtem, hogy mi az az áram. 6 éveseknek való illusztrációval és hozzá egy nagyon egyszerű szemléletes magyarázattal.
Viszont végig vittem azóta a majdnem 3 év alatt több saját projektet. Ebből lehet szerintem tanulni, meg a rengeteg kérdésből amik menet közben felmerülnek.
Ha elektronikát választottam volna egyetemen, szerintem már a mateknál kibuktam volna.
És működő dolgokat alkotok úgy, hogy régen se ment már az integrálás és nem oldottam meg komplex egyenleteket már évek óta. Viszont vannak kalkulátorok, amiket segítségül szoktam hívni és ez úgy tűnik szinte mindenre elég. Kit érdekel pl hogy kell méretezni egy vezetősávot, amikor a gyakorlatban csak beírom a kalkulátorba mekkora áram és hőmérséklet, aztán kidobja hogy mekkora szélesség kell.
És szerintem a legbonyolultabb része a tervezésnek, az az alkatrészek illesztése.
De ez meg lényegében csak manual olvasás.
És mióta átlátom a teljes képet, azóta mondhatni nem is bonyolult megtervezni egy saját NYÁK-ot.Az a baj a sulival szerintem, hogy nem gyakorlatias az oktatás. Nagyon erőltetik a régi papíralapú számolást.
Oké, ha visszamegyünk a kőkorba és papíron kell levezetni, akkor hasznos ez a tudás. De amúgy nem.
Az egyszerű mérnökök meg nem alkotnak saját képleteket, a professzorok meg úgyis levezetik papíron/táblán ha újat találnak ki.
Szerintem. -
Teasüti
nagyúr
válasz
vargalex
#8629
üzenetére
Úgy tűnik éppen ez a hiba forrása.
Nem tudom mi történik pontosan mikor a j átfordul nullán, de olybá tűnik felülír vhol vmit, amit nem kéne.
Ezt alátámasztandó a hiba elhárul ha az elemek számát 255-re emelem vagy megakadályozom, hogy átforduljon.
Ahogy tanulmányozgattam a C string-eket, ezek csak pointerek és nincs megkötve az elemek száma. Ezért is nem panaszkodott, mikor a data[8]-ba beraktam vagy háromszor annyi elemet.
ESP32-nél talán azért nem jött elő, mert szimplán mocskosul sok memóriája van az Uno-hoz képest. -
Teasüti
nagyúr
válasz
vargalex
#8629
üzenetére
Igen, azt már átrágtam párszor. Fordított sorrendben rakja ki a kijelzőre azt a 4 bájtot, amire a j számláló hivatkozik. Tehát max 4-ről indul - buff[4] - és eltárolja csökkenő sorrendben a következő 4 karaktert (vagy hát amíg kifut a számláló az értelmezhető tartományon - a nulladik elem az meg úgyis felül lesz írva később, 255-ről átfordulva meg már nem érdekes) amit kirak a kijelzőre.
Kicsit baltával faragott módszer, de így nem kell külön tükrözni a tömböt.
És a cikluson belül csak ez a sor lépteti a j változót a következő számjegyre, de csak ha nem pontot kap a bemeneten, amit speciálisan kell címezni az MSB-vel a bájtsorrendben.Nálad produkálja a hibákat?
-
Teasüti
nagyúr
Az nem automatikusan kerül lefoglalásra?
Úgy tudom a globális változók kerülnek a ram elejére. A fent maradó terület úgy tudom a stack, amit a lokális változók használnak. De ezen mit növeljek, amikor a fordító szerint 1500 bájt szabadon van hagyva a memóriából?
Ez egy igen primitív program, futtattam már olyanokat is, amik a tár 100%-át foglalták és több mint kétharmad ram-ot és vígan futottak.Amúgy volt egy szemantikai hiba:
char data[8];tömb méretét megnöveltem, de még így is produkálja a hibákat. -
Teasüti
nagyúr
válasz
vargalex
#8621
üzenetére
Épp a Serial.print parancsokkal küzdök, ugyanis rendre megváltoztatják az adatot és teljesen kiszámíthatatlan hibákat okoz.
Van vmi ötlet miként lehet ennek a végére járni?
Megkérhetlek benneteket, ha van egy kis szabadidőtök, hogy lefuttatjátok ezt a programot?
A könyvtár elvileg bugmentes, azt csinálja amit szeretnék, stb.
Eredeti Uno R3-ason futtatom. (Mondjuk lehet ki kéne próbálnom másik lapon is.)
A setup()-ban a for ciklussal játszadozok most és teljesen inkonzisztens eredményeket ad nekem.
1. ha nem ismétlem a sprintf parancsot, akkor már a második alkalommal korrupt adatokat ad át a függvénynek.
2. A Serial.print(data) hibásan működik.
3. Ha a ciklus paramétereiben a temp változóhoz hozzáadok egy számot - hogy tovább fusson -, akkor az első pár ismétlés után egyszercsak azt írja ki a konzolra, hogy a ciklusszámláló értéke 132 és kilép a ciklusból.
Bárkinek bármi ötlete mi az ördög folyik itt?
3+ Ez esetben ha a temp változót volatile-nak deklarálom, akkor nem akad ki 132-vel.
Én ebből semmit nem értek. -
Teasüti
nagyúr
-
Teasüti
nagyúr
Srácok!
Olyasmibe botlottam amit egyáltalán nem értek hogy lehetséges, soha nem láttam még ilyet és semmivel sem tudom magyarázni.
Az alábbi kód részletben a debug kiíratás megváltoztatja a kiírni szánt adatot!!!void TubeDisplay::display(char *buf) {
uint8_t buff[5];
if (_debug) {
Serial.print(F("Data size: "));
Serial.println(strlen(buf));
Serial.print(F("Data: "));
}
for (uint8_t i = 0, j = 4; i < strlen(buf); i++) {
if (_debug) {
Serial.print(buf[i]);
Serial.print(F("="));
}
if (buf[i] != '.') buff[j--] = encode(buf[i]);
else buff[j + 1] += 128;
if (_debug) {
Serial.print(buff[j]);
Serial.print(F(" "));
}
}
if (_debug) {
Serial.println();
}
buff[0] = REG_DAT;
if (_debug) {
Serial.println(F("Displaying data:"));
for (uint8_t i = 0; i < 5; i++) {
Serial.print(buff[i]);
Serial.print(F(" "));
}
Serial.println();
}
Wire.beginTransmission(_addr); // transmit to device #8
Wire.write(buff, 5);
Wire.endTransmission(); // stop transmitting
}Ha
_debug = falseakkor más értékeket kapok a tömbben, mint hatruelenne.
Vagy ha kikommentelem a vége felé aSerial.print(buff[i]);sort, akkor megváltozik a tömb.Hozzá kell tennem, hogy egy 4 digites I2C numerikus képernyőt hajt meg ez a függvény, és most épp azt tesztelgetem mi történik, ha kevesebb adatot kap a bemenet, mint amennyi bájtot küld a Wire.
Szóval a paranormális példában azok a bájtok változnak meg a kiíratásra, amiknek nincs értéke.
Ez jelent vkinek vmit?szerk: A megoldás pedig
uint8_t buff[5] = {0,0,0,0,0};De nem értem az okát.
-
Teasüti
nagyúr
Azért kell reset-ben tartani az Uno-t, mert ugyanazon az UART porton van ilyenkor az Atmel328 és az ESP8266. Soros buszon meg nyilván nem lóghat egyszerre három eszköz.
Mondjuk szerintem az is jó, ha kikapod az IC-t a helyéről, de akkor már egyszerűbb bedugni egy darab vezetéket a reset-re.(#8605) aryes
Prózai oka van: nincs usb-soros konverterem. És miért vegyek külön, amikor van belőle minden usb képes lapon? A Nano-kon ott a CH340g, az eredeti Uno-mon meg tököm tudja mi. De működik szuperül.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ráadod a HIGH értéket, kap a port egy visszirányú áramot és pápá mikrovezérlő.
Új hozzászólás Aktív témák
Hirdetés
ekkold- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Formula-1
- alza vélemények - tapasztalatok
- Képregény topik
- eBay-es kütyük kis pénzért
- Gigabyte alaplap topik
- NBA és kosárlabda topic
- Olcsó Galaxyk telepíthetik a One UI 7-et
- Teljes verziós játékok letöltése ingyen
- Android alkalmazások - szoftver kibeszélő topik
- További aktív témák...
- Megaport gaming pc + billentyű
- Csere-Beszámítás! Ryzen 9 9950X3D Processzor! 16Mag-32Szál!
- Csere-Beszámítás! Intel Core I9 14900KS 24Mag-32Szál processzor!
- Csere-Beszámítás! Asus Rog Strix GTX 1080Ti 11GB GDDR5X Videokártya!
- Csere-Beszámítás! Asrock Challanger B580 12GB GDDR6 Videokártya! Bemutató Darab!
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9700X 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i3 10105F 16/32/64GB RAM RX 6600 8GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! ASUS H610M I5 12400F 32GB DDR5 512GB SSD X 4060 8GB SPIRIT OF GAMER CLONE 3 Chieftec600W
- BESZÁMÍTÁS! ASUS ProArt Z790-CREATOR WIFI alaplap garanciával hibátlan működéssel
- Azonnali készpénzes Microsoft XBOX Series S és Series X felvásárlás személyesen/csomagküldéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged