- Okosóra és okoskiegészítő topik
- Honor 400 - és mégis mozog a kép
- Hónap végén érkezik a Xiaomi Band 10, ára is van
- Térerő gondok, tapasztalatok
- Android alkalmazások - szoftver kibeszélő topik
- Netfone
- Fotók, videók mobillal
- Tokba kerülnek a Pixel 10 mágnesei
- Milyen okostelefont vegyek?
- Igazi csúcskészülék lett a Poco F7 Ultra
-
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
-
ecaddsell
aktív tag
válasz
Tankblock
#16642
üzenetére
Lassan FPGA is olyan olcsó lesz h csak na és abban meg mindent is lehet csinálni még Linuxot futtató ARM magokat is lehet szimulálni.
Ilyet csak elborult elméleti (szak)emberek meg retró bolondok csinálnak amikor a soft core helyett ott van a zynq 7020 két arm maggal.
A C++ design patternek tényleges használatához is kell némi elborultság.
Egyébként mivel nálunk komoly elektronikai fejlesztés nem folyik tényleg nincs igény FPGAs dolgokra, hobby szinten meg a BGA tokozás meg a 4 rétegű nyák megint okoz némi természetes szelekciót...
-
ecaddsell
aktív tag
Ha 1mp-en át 3W, majd utána 0W(közeli), szintén 1mp-en át, akkor átlagban 1,5W-t kell eldisszipálnia, nem?
Ez nem így működik, a hővezetésnek is van egy ellenállása és ha rövid időre is sokkal több hőt teszel rá a termál gradiens akkora lesz, hogy vagy megrepeszti a chipet vagy hőmegfutásba viszi a magját.
Egyébként lehet más magyarázata is a hibának pl. ha induktív fogyasztó és nincs megfelelő védelem a visszarugáskor keletkező tüske is átütheti a félvezető gyengébb részét stb. -
ecaddsell
aktív tag
válasz
Dißnäëß
#15631
üzenetére
Ahol elrontottad az az, hogy a Graetz is ejt, ha nem Schottky nem is keveset ugye normál dióda 0.6-0.7Vx2 (tehát másfél volt környékén). Ha ez van akkor még tudod menteni a helyzetet Schottky diódákkal (0.2-0.3x2 azaz fél volt környékén fog ejteni a másfél helyett).
Ez is necces persze, nagyobb terhelésnél. -
ecaddsell
aktív tag
Én anno a Banggoodon vettem amikor nagyon akciózták a többes csomagot (meg más kapcsán tapasztaltam, hogy ér valamit az ügyfélszolgálatuk, ha hibás cuccot kapsz, bár itt nem jellemző), mostanában nem vettem semmi ilyesmit.
Tutoriált kell nézegetni (keresni), külön van arra, hogy az Arduino után még hogyan kell feltenni az ESP32 specifikus dolgokat.
Viszont ha ezt feltetted rengeteg példaprogram is megy vele amit csak le kell fordítani és feltölteni (menüben megkeresed, tényleg mindent alád tolnak). Ezek közt vannak netes is pl. RTC clock-NTP client stb (ehhez jó ha van 1 OLED modulos ESP32, de sokat ne vegyél mert ezek viszik a IO pineket meg irreálisan drága és annyira nem jó az OLED). Ezekből érdemes kezdetben kiindulni.ESP32 hiányosságok/zavaró tényezők:
- Gyenge (zajos) az ADC, jó ha 7 bitet el lehet érni vele ha nem lehet több mintát használni
- Nagy az interrupt latency (kb. 500 utasítás/2us amíg a pin-től az első utasításig eljut)
- Nem lehet külső órajelről járatni (ez mondjuk inkább nekem lett volna érdekes)
- Nincs több pines verziója (ez megint haladó téma, az STM32 ebben jó), kevés IOCserébe viszont olcsón van WiFi/net, rengeteg memória és flash ill. gyors proci (FPU is).
-
ecaddsell
aktív tag
Az Arduinó az 1 IDE (fejlesztői környezet + alapkönyvtárak), használható ESP32-vel is meg STM32-vel is (bár itt csak a kisebbekkel meg eleve túl sok variáns van ezekből). Ezek mind 32 bites cuccok komolyabb teljesítménnyel.
Ha valami nincs meg bennük akkor SPI vagy I2C-vel ugyanúgy bővíthető stb.
Azaz érdemes még megnézni az SMT32 blue pill cuccokat is. Kb. a nano árában van (vagy kicsivel felette) de nem annyira korlátos memóriában/flashben. Nagyon sok hobbi elektronikás cuccban ugyanaz a chip van, szóval érdemes megismerkedni vele. Az ESP32 ott jobb ha sok memória flash vagy WiFi kell (vagy bluetooth bár azzal voltak gondok) viszont azt kevésbé fog hobbielektronikás cuccokban visszaköszönni. -
-
ecaddsell
aktív tag
válasz
gyapo11
#12562
üzenetére
ESP32
#include "xtensa/core-macros.h"uint32_t start, stop;...start = xthal_get_ccount();<kód amit mérni akarsz>stop = xthal_get_ccount();A különbséget meg kiírod soros porton, USB-n stb.
Hiába mutatod meg a forrás valami programnak, ha a háttérben az interruptok viszik az időt, meg néha cache miss van a nagyobb kód miatt, ez lehet csak ESP32, vagy mondjuk STM32-nél meg pl. bus matrix hozzáférés korlát van (az STM32 bus matrixot érdemes kicsit megnézni, tanulságos, hogy működik egy modern MCU).
A profilerek is tényleges futást mérnek és sok esetben egyszerűbb tickcount-ot nézni (ez majdnem mindenütt van) mint a toolokkal (ha van egyáltalán) küzdeni.Egyébként az iopin toggle is ugyanez. Az állapotváltás közzé teszed a kódot amit mérsz és szkópon vagy multiméteren nézed az eredményt. Itt is a HW bütykölés csupán a pin váltás nézése.
De felőlem azt csinálsz amit akarsz, elég sok infót bedobtam már, lehet többiek tudnak olyan progiról amit keresel, nem hiszem, hogy olyan egyszerűen működik mint gondolod, legalábbis ha tényleg komoly időzítési kritériumok vannak.
-
ecaddsell
aktív tag
válasz
gyapo11
#12555
üzenetére
Ha semmi mást nem csinál csak direktbe pineket matat az arduino is gyors (nem 100kHz), nézd meg itt (korábban is javasoltam, hogy keress rá a pin toggle-re):
https://arduino.stackexchange.com/questions/24452/pin-toggle-speedAz ESP32 10 MHz (tegnap rosszul írtam):
https://www.esp32.com/viewtopic.php?t=15952.75x gyorsabb, ami nem annyira sok.
STM32F103-nál 18MHz-et lehet elérni, de mondjuk az a kód nem hasonlítható a többihez, mert nem fordított kód, hanem assembly-ben megírt, előre feltöltött regiszterekkel operál.
https://stackoverflow.com/questions/59708656/stm32f103c8-gpio-speed-limit
Vsz. az ESP32 meg az arduino is gyorsabb lenne, ha így lenne megírva.Összességében azért ezek az értékek jól mutatják kb. mit lehet várni. Az STM32 egy nagyon flexibilis rendszer, de hobby szinten nehéz használni, az arduino a másik véglet, az ESP32 meg valahol a kettő között (csak ne kelljen assembly-ben használni, ne legyenek idő kritikus részek benne...).
Viszont az órajelen felül a nagyobb adatoknál is hátrányban van az arduino rövid proci szóhossz miatt.
-
ecaddsell
aktív tag
válasz
gyapo11
#12551
üzenetére
Csak az ESP32-ről vannak ilyen téren tapasztalataim, ami gyors de van néhány buktatója.
Ha csak output pin-t váltogatsz akkor azt akár 4MHz-el is meg tudja tenni, azaz a loop idő microsec alatti (nem mértem meg, a neten megtalálható már mások megtették).Számomra az első pofon amibe beleszaladtam az ESP32-vel az az interrupt latency volt. Ugye ez az az idő ami eltelik a között, hogy valami input pin-re jelet adsz és a kód eljut odáig, hogy elkezdi futtatni az első általad kért utasítást. Ez pedig nagyságrendileg 2 microsec. Ha nincs semmi kritikus időzítésed akkor nem hangzik soknak, de ha kiszámolod, hogy egy 240 MHz-es magnak ez hány gépi kódú utasítás akkor kijön 1 döbbenetesen nagy szám, kb. 500 utasítás (ennek nagy részéért az RTOS felel, ha ez vigasztal).
Ebből talán már látszik, hogy maga proci gyors, elég komplex műveleteket végezve (ezt nem megszakításban) 64 bites ill. double számokkal (sima float van HW-esen), nagy tömbökben stb. sosem volt gondom ezzel. Viszont a nagy interrupt latency az azt jelenti, hogy ha nagyon sok a megszakítás az nagyon vissza tudja fogni és kevésbé kiszámíthatóvá teszi.
Ebbe sajnos akkor futottam bele amikor a 10 digit/s-es frekimérő felbontását szerettem volna javítani, amihez 10 000 mérés kellett volna másodpercenként (ha a jelnek van ennyi periódusa).Az STM32-vel ilyen gond nincs (mondjuk egy F103-ra eleve aligha varázsolsz valami oprendszert ami bezavarjon) viszont a blue pill-t leszámítva nincs értékelhető Arduino támogatása (vagy legalábbis amikor néztem nem volt) és pl. a nagyobb F407-nek (ebben már van float) már nem mellékesen a legkisebb tokozás is a már nem éppen barátságos 100pin (akkor sem barátságos amikor gyártatod a NYÁK-ot, részletek eléggé off).
Nálam a megoldás az volt, hogy még egy CPLD-t teszek a már eleve külön panelen lévő CPLD mellé ami a gyors logikát kezeli, ha már az ESP32 ebben nem jó. Ennek a VHDL kódját már meg is csináltam és működni látszott amikor parkolópályára került egy kicsit ez a projekt (sőt most per pill. felújítás miatt minden ami ehhez kell le van fóliázva...).
Az igazi az lenne, ha lenne kis pin számú (nem BGA) CPLD nagyobb logikával megfizethető áron (sajnos a gyártók ezen a vonalon alig fejlesztenek, nekik ez nem business). Az arduino/ESP32 tök jó arra, hogy user interfész logikázzon és azt gyorsan össze is lehet dobni, de ha valami tényleg gyors kell legyen ahhoz HW logika kell.
Egyébként ha rákeresel arra, hogy pin toggle majdnem minden infót készen kapsz, de 1 blue pill. (meg programozó ha nincs) nem akkora befektetés és ha nincs is szkópod a legtöbb multiméter sokkal többet tud mint amilyen sebességgel ezek tudják a pint módosítani (pl. az elég olcsó ANENG AN8008 10MHz-ig).
-
ecaddsell
aktív tag
válasz
gyapo11
#12509
üzenetére
Olyan nincs, hogy feltörhetetlen, csak olyan, hogy sokáig tart és nem éri meg vele foglalkozni.
Ha a vevőben van óra akkor lehetne nyilvános kulcsos rendszer.
Az adóba be kell írnod az óra percet, hozzáadsz még két random számot és a titkos kulccsal titkosítottan elküldöd.
A vevőben a nyilvános kulccsal kibontod. A két random számot eldobod az óra percet meg hasonlítod és ha hibahatáron belül van (mondjuk 2 perc) akkor elfogadod. -
ecaddsell
aktív tag
válasz
zsolti_20
#11599
üzenetére
Hatótáv mondjuk 400-500m jelerősség pedig olyan legyen hogy egy fal ne legyen probléma neki.
Ott vanank pl a walkie talkie. Ezeket használnak a security-k a kommunikációhoz. Van köztük kb 1km, teljesen fém az egész épület és mégis tudnak egymással kommunikálni, pedig jelerősítő sincs köztük.Eléggé kevered as dolgokat. Ha normál walkie-talkie-ról (446 MHz-es PMR) beszélünk az már alapból 500mW (és nem max. 100mW mint ezek a távirányítós cuccok) egy viszonylag jó nyereségű antennával (az USA-ban ezt másképp hívják ott FRS=Family Radio Service a neve és ott a szabvány limit is 2W (persze ott kevésbé begyöpösödött emberek szabványosítanak mint az EU-ban).
Amit a biztonságiak használnak az meg mindezeken is jó eséllyel túlmegy simán kb. 5W környéke (USA megfelelője GMRS, megint gyakorlatiasabb hozzáállással szétválasztva a hobbi meg az ipari kategóriát).
Ennek ellenére ha sok a zavaró tereptárgy inkább néhány száz méter az a km.
Nyílt terepen persze simán megvan az 5-10km is...Bár nem fogom minek egy távirányítós hajónak több száz méter (ahova már eléggé nehezen látsz el), de ha ez kell akkor az antennára érdemes fókuszálni. Szóval jó ha a vevő IPEX vagy SMA csatlakozós és e-miatt le lehet árnyékolni és ki lehet venni mint zajforrás az antenna meg lehet irányított (ez az adónak sem árt)...
Egyébként bár nem érint a modellezés téma azt hinném a hajó a legegyszerűbb mert nyílt terep és jól irányítható antenna. -
#11429
ecaddsell
aktív tag
tonermagus
#11421
ecaddsell
aktív tag
-
ecaddsell
aktív tag
válasz
gazso75
#11175
üzenetére
Tipikus kommunikációs hiba. Vagy robusztusabbra csinálod vagy ezeket az adatokat ahol ugrás van elfejeted.
Robusztusabbra pl. úgy tudod csinálni, hogy ha van lehetőség újraolvasásra, akkor kitakarítod a puffert dummy olvasásokkal majd újra olvasol.
Nem olvastam bele a kódba, de sajnos sok könyvtár pont ezért használhatatlan (komolyabb célokra) mert csak a hibátlan esetekre van felkészítve. -
ecaddsell
aktív tag
Használ itt valaki Arduino alatt blue pill STM32-t (STM32F103...) Linuxon (Fedora29)?
Windows alatt (W10) minden frankón megy, Linuxon meg mintha nem látná ugyanazt a kártyát.
(Windowson is Mapple Miniként látja.)
Mi lehet a gond?lsusb:
/etc/udev/rules.d/45-maple.rules:
Arduino:
-
ecaddsell
aktív tag
-
ecaddsell
aktív tag
Nem azonnal megy tönkre, de nem mindegy mondjuk, hogy 1-2 évig használható vagy 3 hónapig.
Szóval igen, hideg helyre kell tenni, de ne fagyjon meg és használat előtt meg jó ha nem túl hideg...
Nem mellékesen nyáron sem rendelnék ilyet, mert ki tudja ezek a cuccok hol ácsorognak napokig.Más
Korábban említettem a rézharisnyát a fölös ón leszedésre, aki még nen látott ilyet erről van szó (nekem nem ilyen van, fogalmam sincs ez jó-e és több méret is van belőle).
A használata: alulra egy kis folyasztószer felülről meg melegíted a pákával.
Beforrasztásnál mondjuk előnyösebb nem túladagolni a pasztát, mint utólag korrigálni a hibát... -
ecaddsell
aktív tag
válasz
gyapo11
#10931
üzenetére
Igen ez tisztán folyasztószer.
Amit te keresel az a solder paste.
Pl. alacsony olvadáspontú (nekem olyan helyre kellett, ahol a gyártó max. 145 fokot írt elő mikrohullámú keverő chipnél).
Pl. normál ólmos.Nyilván máshol is lehet venni, ill. más is jó ezt tekintsd csak példának.
Minden ilyen cuccnál komolyan kell venni a hidegen tárolást. Ha elveszti azt a hígabb folyékony állapotát (ilyenkor a fényét is elveszti) akkor onnantól lényegében használhatatlant mert nem tapad oda a forrpadhez,
-
ecaddsell
aktív tag
válasz
t72killer
#10904
üzenetére
Rengeteget használok pasztát és ahol a chip-ek alatt is forrpad van (RF cuccok szinte mind ilyen) más nem is nagyon opció, de idővel kialakult az a véleményem, hogy soklábú chipek esetén (stencil nélkül) ill. ólommentesről átrakott cuccok esetén kell a páka (nekem a kis laposcsavarhúzós hegy jön be már évtizedek óta) és extra folyasztószer mivelhogy a forrasztóónból ill. a pasztából is gyorsan kiég a gyanta és akkor az ón összefolyik a kivezetések között (ha nagyon túladagolja az ember az ónt persze rézharisnyával le kell szedni, ekkor a folyasztószer sem elég önmagában).
Páka nélkül nagyító alatt nézve is hibátlan lehet a pasztás cucc, de mégsem működik esetenként (nem egyszeri tapasztalat).
Tapasztalatom szerint a legjobb a cipőpasztás dobozban árult és állagában is ahhoz hasonló cucc. Költséghatékony és jól adagolható. Korábban sokat használtam stiftes anyagot is, de az alkohol miatt elég híg és képes össze-vissza elfolyni ill. kintről rendeltről az út során lelazult a kupak és alig marad benne valami.
Nem mondom, hogy más esetleg ne lenne jó, de nekem ez van (kb. 3 USD Banggoodról).
Kinyitva sárgás puha anyag van benne.
A stiftesnél még azzal is jobb, hogy nincs meg az az émelyítő szaga felvitelkor ill. forrasztáskor.Röviden: A paszta szükséges, de nem elégséges, kell az extra folyasztószer és nem mindegy milyen kiszereléseben...
-
ecaddsell
aktív tag
válasz
Gergosz2
#10686
üzenetére
Mit jelent az, hogy nem akarja megcsinálni? Ha nem tartja meg a beállítást akkor az normális, mert nincs benne flash. Többek közt ezért érdemesebb Neo-7N-t venni, még ha egy kicsit drágább is.
(Nekem 7N van, de nem tudom a kínai panelon miért van gombelem ha van rajta flash
.) -
-
ecaddsell
aktív tag
Pénteken megjött a PCF8574-es kijelzőm amivel kapcsolatban volt itt kérdés ill. válaszoltam.
Mint azt sejtettem is simán megy 3.3V-ról.Nem tudom kinek volt az az idióta ötlete, hogy ezeket teljesen letekert kontraszttal szállítják, jó ideig azt kerestem miért nem megy...
Nem vagyok lenyűgözve se a láthatóságával (szemből még OK, de oldalról nézve gyorsan invertálódik), se a frissítés sebességével (ami vsz. még gyengébb is mint ami az I2C-ből követezik).
Ár értékben nem rossz, de még mindig keresek valami jobbat (legfőképpen olyat ami nem ennyire feleslegesen nagy).
A képen a 10 digit/s-es frekimérőm kimenete látható.
-
ecaddsell
aktív tag
válasz
tvamos
#10586
üzenetére
Ha javítgatni kell (ami hobbinál azért nem ritka, nekem pl. legutóbb egy sima pasztázott VQ44 tokos chipet kellett lecserélni, panel is jó volt másik chippel, másik panelon a chip is) lehet jobb a sima HASL.
Az ENIG oda kell ahol követelmény az ólommentes cucc meg mondjuk valami szívatós BGA vagy QFN tokozás kell aminél minimális felületi egyenetlenség is zavaró lehet (ilyet hobbinál aligha fogsz használni). -
ecaddsell
aktív tag
válasz
Gergosz2
#10562
üzenetére
Nem tudom az ESP-ből, hogy lehetne klónt használni
Persze már ma is vannak területek, ahol kínai másol kínait...
Egyébként érzésre az ESP mintha nyugati cég lenne, van rendes doksi, van rendes fórum ahol ha értelmesen kérdez az ember gyakran válaszolnak is. Szokatlan. -
ecaddsell
aktív tag
válasz
Atamano
#10523
üzenetére
Pont nemrég vettem én is ilyesmit, sajnos még nem jött meg, szóval konkrétan nem tudom megnézni, de ha ez az a verzió ahol az LCD panelre rátettek 1 PCF8574 vezérlő panelt akkor sima ügy mert te döntöd el milyen tápfeszt adsz neki (3.3V ha ilyen rendszerben használod), ui. adatlap szerint 2.5 és 6V között lehet neki adni.
Kockázat abban van, hogy ha a kontroller panel 5V-járol hajtod, mert ha véletlenül lejön a föld vezetéke ott biztosan vége a kontrollerednek (mert visszamegy az LCD panelen keresztül az 5V a kontroller IO pinjére és azt nagyon nem szereti).
Ha lehet ilyen kérdéshez dobj be képet is mert majdnem mindenből több verzió van és a kép sokat segíthet eldönteni neked mi van.
Szerk: Ha 3.3V-os a kontroller akkor jobb, ha a kijelzőnek nem 5V-os, hanem 3.3V-os tápfeszt adsz.
-
ecaddsell
aktív tag
válasz
rsanya87
#10356
üzenetére
Melyik kristály (merthogy több van belőle; van az USB soros konverternek ill. a kontrollernek is) ill. melyik panel (szintén több verzió).
Egyébként miért kell cserélni? Biztos ez a megoldás, ha nem nagyon van felszerelésed hozzá?Egy forrólevegős páka viszonylag olcsón beszerezhető, töredéke egy normális hagyományos pákának. Viszont ha a kontroller kristályát cserélnéd azt zéró tapasztalattal én sem ajánlanám.
Mivel a komolyabb cuccok mind SMD-sek, ha ilyesmivel akarsz hobbizni, jobb ha erre készülsz. Normális padek esetén (sokat ezért használnak saját alkatrészt NYÁK tervezőkben) ill. normális méretű alkatrészeknél még hobbi szinten is előnyösebb az SMD (ipari szinten meg ahol stencillel viszik fel a pasztát ill. géppel pakolják fel az alkatrészeket komoly árelőnye van, azaz erre kell számítani).
-
ecaddsell
aktív tag
válasz
Teasüti
#10238
üzenetére
Vsz. nem tévedek túl nagyot, ha a Robin Scheibler FFT tesztjének összes float igényét N*log2(N) + 2*N-el közelítem ami 4k FFT esetén kb. 57k float művelet 7ms alatt, azaz per float kb 120ns. Ebből a tényleges float mindenféle overhead nélkül jóval kevesebb (lehet fele se). Persze ez még mindig jópár órajel ciklus nem úgy mint a float DSPknél ahol 1 float 1 órajel, szóval aki nagyságrendi ugrást akar az megy DSP-re.
Röviden: abban a tesztben amit linkeltél vagy valamit nagyon elrontottak, vagy valami olyat néz ami az itt felvetett és tárgyalt FFT szempontjából teljesen irreleváns, szóval kár volt ide hozni.
-
ecaddsell
aktív tag
válasz
Amarton
#10225
üzenetére
Pedig tényleg nagyon kicsi a valószínűsége, hogy hibás legyen, különösen nagy szériás cuccnál ahol minden automatizálva megy beleértve a tesztelést.
A chip-eket pl. a legtöbb esetben gyári szalagból kivágva kaptam.
Pl. DC-DC konverternél meg a panelizált (géppel) beültetett NYÁK-ból nem törték szét az egyes darabokat, hanem egyben küldték a min egységet amit árultak.
Persze nem mindig ez van, pl. csatlakozósoros panelt sose kapsz panelizáltan.Egyébként ilyen esetek elkerülésére (különösen, ha nem túl drága) min. duplán szoktam venni. Amellett, hogy lesz tartalék (és nem kell hónapot várni míg megjön a másik ha valami gond van), ilyenkor megnézem, hogy minden darab ugyanúgy működik és ha igen élek azzal a feltételezéssel, hogy valahol máshol van a gond.
Nem mondom, hogy sose fordulhat elő, hogy hiba van és ha valami akkor az ESD bárhol tönkre tudja vágni a cuccot.
Egyébként az ESD az egyik legalattomosabb hiba, mert ez az ami nem feltétlen teljesen teszi tönkre egyből a cuccot és ez ami nagyon rossz mert nehéz észre venni, mert pl. SPI még simán megy, de valahol már nem tudja a speckót a CMOS chip.
Pl egyszer ESP32 valamelyik pinjére véletlenül 5V jutott. Egyből tönkrement és annyira nagy áramot vett fel, hogy a stabi IC majdnem kiégett. Rögtön látszott kuka. Másik ESP32 egyik pinjénél meg azt vettem észre, hogy nem bírja a nagyobb frekvenciás jelet. Vsz. olyan ESD-t kapott amit már nem teljesen kezelt a védelem (valami minimális védelem van ezekben) és az a pin bizonytalanná vált. Legalább fél órám ment rá (de lehet jóval több), csere más pinre, csere más ESP32-re stb mire megtaláltam mi lehet a gondja.Szóval lehet a cuccod pont ott ment tönkre amikor bekötötted.
Aztán még van olyan storym is amikor a CMOS chip (ADF4351) EN pinje nem lett felhúzva, de csak 1 másképp tervezett panelnél vettem észre a hibát (bizonytalanná vált a lock), mert az elsőnél olyan volt az elrendezés, hogy annyi áram odakúszott, hogy elég volt neki (ugye CMOS bemenet több 10 MOhm tip.). Ha nem kapok egy másképp tervezett panelt, lehet sose veszem észre...
Röviden: El lehet hobbizni ezekkel az Arduino kompatibilis cuccokkal, ahol a hibák/veszteségek nem nagy ügy (pláne, ha rátolod az eladóra), de az ipari kategória nagyon más. Nem véletlen, hogy nagy-szériás gyártás ma már szinte csak Kínában fordul elő. Nem mellékesen szokás szidni a minőség-ellenőrzést. De azért nézzük meg, hogy pl. a jlcpcb-nek 20 cent/hobbi paneles árba (szállítás nélkül értendő) belefér automatizált optikai és elektromos ellenőrzés. Ezek után nem csoda, hogy ennek a szakmának se nálunk se nyugaton sem rózsásak a kilátásai. Hobbizni persze OK.
-
ecaddsell
aktív tag
válasz
Amarton
#10201
üzenetére
Bár nem is használtam, és nem is különösebben érdekel, de ha már ennyit írtatok róla gondoltam megnyitom az adatlapot és gyorsan átfutottam.
Bevezetőként annyit, hogy bár nem sokat és gyakran, de bőven 10+ éve vásárolok ebay-ről, és nem nagyon tapasztaltam, hogy rosszat küldenek (OK, alapból megbízható eladót választok, néhány cent nekem nem éri meg, hogy kb. 1 hónap vagy még több és refund után újabb kb. 1 hónapot várjak).A bekötésre a kulcsszó a 8.3.1.3 fejezetben van (ha a 10-oldalon lévő bekötési rajzról nem lenne eleve világos): high-side shunt.
Szóval a terhelés a föld és a - ág közé kerül a sönt ellenállás meg a - és a + közzé a + meg a pozitív betápra.Tovább nem mennék bele, de cserébe googliztam neked 1 maxim tutoriált (a találatok legelején) amiben minden benne van.
Szóval butaság össze-vissza kötözgetni.
Azt, hogy a SW mit, hogy csinál nem tudom, de ami még eszembe jutott, hogy minden mérésnél rögtön tisztázni kell mit mérünk és hogyan és nem árt 1 másik módszerrel is ellenőrizni (pl. multiméter vagy oszcilloszkóp az eszköz bemenetére). Itt pl. nekem totál nem világos, hogy a LED tiszta DC-ve van hajtva vagy PWM-el és ez utóbbi esetben egyáltalán ez az eszköz alkalmas-e a mérésre (szinte biztos nem, mivelhogy semmi ilyesmiről nincs szó az adatlapon, szintúgy effektív érték sincs megemlítve).
-
ecaddsell
aktív tag
válasz
Teasüti
#10193
üzenetére
Lehet, hogy egyszerű, de pont azt a módszert követi ("megszakítást használni és programból számolni") amire korábban azt írtad, hogy lehetőleg ne.
Amit korábban linkeltél PCNT-s rotary encoder dekódolás szintén nem működik, ha nincs prellmentesítve a dekóder (ami túlárazottá teszi az egészet), ezt a kört már korábban lefutottam és itt leírtam.
Nekem úgy tűnik szisztematikusan megtalálod (előnyben részesíted) a rossz módszereket, csak azért mert az egyszerű.
Nem saját saját microchipet tervezek, hanem a gyártó által tervezett, utólag meghatározható logika összeköttetéseket határozom meg (ami tudtommal tényleg hasonló a digitális microchip-ek tervezéséhez).
Lelkes hobbisták így szokta retro gépeket/procikat összedobni (nem érdekel a téma csak érdekesség).
-
ecaddsell
aktív tag
válasz
Teasüti
#10184
üzenetére
Az első az ESP-IDF-hez íródott, miközben én Arduino IDE-ben vagyok.
Nekem még soha nem okozot gondot ESP-IDF-et használni az Arduino IDE-ből...
Többek között a második kód esetén sem.
De mindegy, te tudod mire kell és mit vállalsz be ehhez.Én elég sokat vállaltam ebben a témában (talán túl sokat is) pl. VHDL kód írása és tesztelése (működni látszik) Xilinx CPLD-re, nyáktervezés (kétfajta progit is bevetettem) stb. Nagyon sokat tanultam belőle, annak ellenére, hogy lehet ez is a befejezetlen projectek sorát fogja gyarapítani.
-
ecaddsell
aktív tag
válasz
Tankblock
#10148
üzenetére
Ha csak ez az egyetlen gondja lenne az ESP32 ADC-jének, akkor igen, de sajnos több sebből vérzik.
A nemlinearitás egyébként máshol jobban vesézve van:
https://github.com/espressif/esp-idf/issues/164Amit linkeltél meg van említve a zaj is, amibe már korábban is belefutottam és amit sokkal nehezebb kezelni.
Amit ajánlgatnak az vicc, 100nF-os kondit csak az tehet oda, aki valami lassú szenzort olvas. Eleve az ESP32 ADC-je nem valami gyors, szóva tipikusan a multisampling se opció.Visszatérve a zajra: A zaj forrása tipikusan a digitális kapcsolási zaj és erősen függ attól, mennyi kimenet változik szimultán módon. Na erről nem szól az ábra.
Ma (meg már 1 ideje) a komolyabb analóg és digitális részt is tartalmazó chipek több tápfeszt igényelnek. Azaz külön kellhet szűrni és stabilizálni a digitális mag tip. alacsonyabb tápfeszét (1V tól 1.8V környéke), a digit interface-t (tip. 1.8-3.3V) ill. az analóg részeket. Ez persze megdrágítja a dolgot és ott spórolnak ahol tudnak.
Kb. ennek az eredménye, hogy a spec szerint 12 bites ESP32 ADC kb. 7 vagy max. 8 bites valójában...Amivel ezzel kapcsolatban mostanában küzdök: Miután az ESP32-vel a 8 digit/s reciprok freki mérőt megcsináltam, elkezdtem áttérni a 10 digit/s-es interpoláló reciprok freki mérőre. Ennek az a lényege, hogy nemcsak azt mérjük, hogy a jel egy adott egész számú periódusára hány egész referencia jel periódus tartozik, hanem a referencia jel tört periódus idejét is mérjük.
Ez úgy történik, hogy a tört periódus ideje alatt 1 kondenzátort töltünk konstans árammal és a töltés végén megmérjuk a kondenzátor feszültségét (ennek a digitális részét CPLD adja nem az ESP32).
Mivel nálam a referencia periódusa 10ns (100MHz) max. ennyi ideig tölt a kondenzátor, ami túl nagy nem lehet, mert akkor nagyon nagy tötlő áram kellene. Szóva a kondenzátor kb. 1 nF, és 30mA körüli töltőárammal kb. 280mV feszültség emelkedést lehet elérni max (azaz normálisan 0-280mV emelkedés, ami nem nulláról indul, szóval lényegtelen, hogy kis értékeket nem tud az ESP32 mérni).
Azaz a két digithez kb. 3mV felbontással kellene mérni. Viszonylag gyorsan, mert a kis kondenzátor gyorsan veszti a töltést még nagy impedancián is.
Na itt az ahol az extra 100nF nem opció.
Oszcilloszkópon frankón látszik a jel. A filléres Aneng 8008 multiméter is konzisztensen tudja indikálni az feszültség emelkedést.
Csak az ESP32 küzd a jellel a saját maga által generálta zajban...Szóval messze nem csak a linearitás a gond. Zajos és a sebessége is megérne 1 külön github részt, hogy mi a teendő, ha normális sebességet szeretnénk (erre is elég sok fórumbejegyzés van már). Talán mégsem véletlen a sok panasz.
-
ecaddsell
aktív tag
válasz
kbhuinfo
#9998
üzenetére
A kérdés pedig: mire van szükség (ellenállás, kondenzátor, stb.), hogy jól működjön az áramkör? Feltételezem, hogy valami hiányzik és a mérés az, ami ezt az űrt betölti
Jó eséllyel árnyékolás az ami hiányzik. De ha nem is ez kellene legyen az első lépés. Az ESP32 nekem pl. bezavarta a GPS vevőt amíg jó távol nem tettem a GPS vevő antennáját.
-
-
-
ecaddsell
aktív tag
Ugyan nem mikrokontroller, de nem találtam jobb topikot, és talán itt van a legjobb esélyem, hogy választ kapjak.
Szóval van egy VHDL kód amit nem teljesen értek aminek az oka (azon felül, hogy ebben a témában nem vagyok jó) az, hogy ugyanahhoz a jelhez több értékadás történik a processen (folyamaton) belül.Egyszerűsítve:
process(sck,index)
begin
if RISING_EDGE(sck) then
index <= index + 1;
end if;
if clear='1' then
index <= "1111";
end if;
end process;Az első if az ugye triviális, az órajel felfutó élére növeli az indexet (ami egyébként a teljes kódban sehol máshol nincs módosítva). Viszont a másik if-ben ugyanahhoz a jelhez van még 1 értékadás. Nem mellékesen a process érzékenységi listáján is ott van az index.
A kérdés az, hogy mi lesz az index értéke, ha a clear input be van állítva?Tippem szerint "1111". A miértre is fel tudok állítani valami teóriát (a folyamat újra indul az index változása miatt ahol már csak a második if fut), de szívesen olvasnám valakinek a véleményét aki jobban ott van ebben a témában.
Bónusz kérdés: Jól értem-e, hogy ha van egy másik folyamat aminek az érzékenységi listáján csak az index van akkor ha a clear értéke be van állítva akkor az nem fog elindulni?
-
ecaddsell
aktív tag
válasz
Johnny_vT
#9942
üzenetére
Nekem CO2 szenzor (MH-Z14A), ami a mai napig megy és napi szinten használjuk. Nem mellékesen az egyetlen amit rendesen bedobozoltam (mini OLED kijelzőre írogatja az aktuális értéket meg a trendet).
Viszont mivel elsődleges, hogy ne veszítsd el a motiváltságot, lehet maradnod kellene a drón témában, amihez talán kevesebbeknek van itt ötlete (viszont a súly miatt kezdésnek húzós lehet mert paneleket építeni 0603-as meg 100 lábú CPLD alkatrészekből mint pl. a XC2C128 teljesen más mint evaluation bord-okból valamit összehuzalozni). Szóval nem árt a realitások talaján maradni, hogy ne legyen kudarc.
-
ecaddsell
aktív tag
válasz
ecaddsell
#9932
üzenetére
Szóval ha fix szélességű impulzusokat ad akkor valami ilyesmi kellene (tudni kellene, hogy HIGH, vagy LOW a pulzus értéke):
#define MINPLENGTH 15000
void szamlalo(){
volatile static uint32_t thi = 0, tlo=0, tm = 0;
uint32_t td, ctm = micros();
td = ctm - tm;
tm = ctm;
if (digitalRead(PULSE_ENC)) tlo += td;
else thi += td;
if(thi > MINPLENGTH){
thi = tlo = 0;
currentpulse++;
}
else if (tlo > MINPLENGTH) thi = tlo = 0;
}Ha nem, akkor a túl gyors változásokat figyelmen kívül kellene hagyni (olyan kód kellene).
Szóval látszik jó lenne tudni milyen annak a jeladónak a jele, kisebb meg nagyobb forgási sebességnél.
De innen már vsz. te is meg tudod oldani.
Arra figyelni kell a kódolásnál, hogy ha LOW értéket olvasunk a megszakításban akkor az előző időszak HIGH volt... -
ecaddsell
aktív tag
Ja bocs, akkor amit írtam nem lesz jó (de mintha valami rotary encoder leírást linkeltél).
Ha valami pulzusos jeladó az sem nehezebb.Ugyanúgy minden élre kell interrupt és mérni kell a legutóbbi interrupt óta eltelt időt.
Két összegző kell (static volatile) ami minkét állapotban eltöltött időt összegi. Ha pulzus ideje meghaladja az elvárt időhossz mondjuk kétharmadát (vagy 3/4-ét ez jelalakból vagy próbával) akkor elfogadjuk, léptetjük a számlálót és mindkét idő összegző nullázva.Szóval amit lent írtál még így nem elég.
-
ecaddsell
aktív tag
Na akkor rotary encoder prell mentesítés még egyszer.
Az alapötlet innen:
https://www.best-microcontroller-projects.com/rotary-encoder.html
Én KY-040-el használom (sokat), hibázni még nem láttam. A logika megszakításban megy, a lekérdezés poll.
A speed control arról szól, hogy ha gyorsabban tekered akkor nagy ugrásokkal megy. Frekvencia beállításnál igen hasznos, máshol ahol fontos, hogy az elmozdulással legyen arányos az érték meg nem kell (ki kell kapcsolni).
Mivel ez is olyan téma, hogy jó megoldást még nem láttam (ezért voltam kénytelen egyet írni), hibásat annál többet, érdemes eltenni a linket.
Kommentelni akkor szoktam kódot, ha nagyon kell. Sorry./*
This code is free software; you can redistribute it and/or
modify it under the terms of the CC BY-NC-SA 3.0 license.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND...
*/
#define ROTE_CLK GPIO_NUM_xx
#define ROTE_DT GPIO_NUM_xx
#define ROTE_SPCTM 50000 // speed control time limit, not defined no speedctrl
volatile int32_t rotval = 0;
void IRAM_ATTR isrrot() {
volatile static uint8_t pinsta = 0x3, cwi = 0, ccwi = 0;
volatile static uint8_t cwexp[] = {0xD, 0x4, 0x2, 0xB};
volatile static uint8_t ccwexp[] = {0xE, 0x8, 0x1, 0x7};
int32_t rvchg;
#ifdef ROTE_SPCTM
volatile static uint32_t tc = 0, tm = 0;
uint32_t ctm, td;
#endif
pinsta = (pinsta << 2) & 0xf;
if (digitalRead(ROTE_DT)) pinsta |= 0x2;
if (digitalRead(ROTE_CLK)) pinsta |= 0x1;
if (pinsta == cwexp[cwi]) cwi++;
else if (pinsta == ccwexp[ccwi]) ccwi++;
if (cwi == 0x4 || ccwi == 0x4)
{
if (cwi == 4) rvchg = 1;
else rvchg = -1;
pinsta = 0x3; cwi = 0; ccwi = 0;
#ifdef ROTE_SPCTM
ctm = micros();
td = ctm - tm;
tm = ctm;
if (td < ROTE_SPCTM / 2) rvchg *= 7;
else if (td < (ROTE_SPCTM * 2) / 3) rvchg *= 4;
else if (td < ROTE_SPCTM) rvchg *= 2;
#endif
rotval += rvchg;
}
} // isrrot
int16_t getrotv() {
static int32_t lval = 0;
int32_t cval = rotval;
int16_t rotc = 0;
if (lval != cval) {
rotc = cval - lval;
lval = cval;
}
return (rotc);
} // getrotv
void inirotein(gpio_num_t clk, gpio_num_t dt) {
pinMode(clk, INPUT);
pinMode(dt, INPUT);
attachInterrupt(digitalPinToInterrupt(clk), isrrot, CHANGE);
attachInterrupt(digitalPinToInterrupt(dt), isrrot, CHANGE);
} // inirotein
...
inirotein(ROTE_CLK, ROTE_DT);
... -
ecaddsell
aktív tag
Ne viccelj ilyen könnyen feladod?
Pl. megnézted, hogy kompatibilis a jeladód szintje a kontrollerével? Az, hogy a jeladón villog a LED semmit sem mond arra vonatkozólag, hogy tényleg megtörténik-e az interrupt.
Pl. a loop-ból kiírathatnád a számlálót ha az változik. stb.Emlékszem rád a Fedorás topikból, olyan dolgokban tudtál segíteni nekem (meg kb. mindenki másnak) amit már rég feladtam(unk), itt meg hozzá sem kezdtél a debughoz... Ki kell íratni dolgokat a soros porton.
ESP32-vel még az interruptból is kiírattam, pedig elvileg azt nem szabad (lehet itt nem is menne) mert mi történhet alapon, max újra fel kell töltenem a módosított kódot.
Ha nincs soros portra lehetőség akkor rá teszel valamelyik pinre egy ellenálláson keresztül 1 LED-et amit ki be kapcsol az interrupt stb.Kevesebből mint az általad írt összeg tervezek 10digit/s-es frekvenciamérőt csinálni, Arduino környezetben ebből a pénzből már egy egész hobbi labort lehet építeni. Persze, ha eléggé motivált vagy...
-
ecaddsell
aktív tag
válasz
fpeter84
#9675
üzenetére
A kulcs az amit korábban is írtam:
GPIO.out_wlts = <set for lower 32 pins>
GPIO.out_wltc = <clear for lower 32 pins>
GPIO.out1_wlts = <set for higher pins>
GPIO.out1_wltc = <clear for higher pins>Persze ügyesen is kell maszkolni, hogy csak azokat a pineket módosítsd amit kell, ill. ha jól értem két írás kell a set ill. clear miatt (közte meg kizáró vagy/bit invertálás).
-
ecaddsell
aktív tag
Mert ipari használatra minden amit ki lehet hagyni kihagynak (extra költség) azaz direktbe hajtják a kijelzőt.
Nekem meg hobbizni (ami leginkább a prototípus készítéshez hasonlatos) sokkal fontosabb, hogy felesleges dogok nem viszik az időm, pl. úgy használhatok 3 fajta kijelzőt, hogy mikor most rá akartam keresni a kijelző kódra, hogy hány % rájöttem, hogy tűt keresek a szénakazalban... -
ecaddsell
aktív tag
OK, de fogadjuk el, hogy lehet olyan nagy felbontású kijelző sok gyors változással ahol ez szükséges lehet.
Neked meg nekem nem, de másnak esetleg igen (én erre annyi pint ami ehhez kell nem áldoznék be, meg mivel ez nincs offloadolva a procit is megfogja kicsit, de ha valakinek ez a legfontosabb rész miért ne). -
ecaddsell
aktív tag
válasz
fpeter84
#9637
üzenetére
"azt keresem hogy egy adott LCD-t mivel tudnék a létező leggyorsabban meghajtani"
HW referencia regiszterekkel:
https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdfMivel az EP32 nem tartalmaz kijelzőt (a kijelzős board-ok is tipikusan valamilyen soros protokollal vannak hozzákötve tip. SPI) ezért soros protokol esetén HW SPI-t kell használni, vagy ha direktbe van a GPIO pinekhez kötve a kijelző akkor a pineket írva.
A direct GPIO-ra meg ezt a fórumbejegyzést találtam, szóval mennie kellene.
Most, hogy látom, így esetleg több pint is lehet írni (remélhetőleg tökéletesen egyszerre), lehet engem is fog érdekelni a dolog...
Viszont ha jól látom ennek a sebessége a HW SPI alatt van (valamiért), szóval a soros protokolhoz képest nem biztos, hogy akkora a nyereség.
Még 1 link:
GPIO.out_w1ts = (1 << TogglePin);
GPIO.out_w1tc = (1 << TogglePin); -
ecaddsell
aktív tag
válasz
gyapo11
#9603
üzenetére
A NiZn felejtős, nagyon hamar tönkre megy (még hideg sem kell hozzá) és a kapacitása is gyatra (mindig a teljesítménnyel marketingelik). Próbáltam (szerencsére az őrült drága töltő jó a NiMH-hez is, azaz legalább azt nem buktam).
Szóval vonzó a nagyobb feszültség, de nem 1 hosszú távú megoldás...Szerk: A NIZn-nek nagyon gyors az önkisülése is...
xboy89
Ezek a boost konverterek ha még deep sleep-be teszed az ESP32-öt, akkor is fognak fogyasztani. -
ecaddsell
aktív tag
válasz
MrChris
#9576
üzenetére
Az UNO-t nem ismerem, de vsz. pont ugyanolyan quartz kristály van benne mint a többibe, pl. ESP32-be amit jobban ismerek. Szóval ezek simán kell hozzák az 5 digitet ami nemhogy 30 percre, hanem akár 1 napra is elég jó esetben (1 másodperces eltéréshez). Ami esetleg gáz lehet az az alapból meglévő offset, az hogy nem pontosan annyi mint kellene legyen a kontroller órajele (kifogsz egy ilyen szempontból gyengébb példányt). Ezt is simán lehet kompenzálni, de itt már timer-t kell használni (timer interrupt).
A drift, az hogy hőmérséklettel változik az órajel frekvenciája kevésbé zavaró, ez még relatíve nagy változások esetén is tudja hozni az 5 digitet.
Viszont az nem kérdés, hogy a GPS 1pps (pulse per second) kimeneténél házi barkács szinten aligha van olcsóbb megoldás, mert ez alapból kb. 7-8 digit és stabilan tartja (sőt mivel alapvetően a jitter rontja, a hosszútávú átlag még jobb is).
Pont ezért tervezem, hogy a frekvenciamérés pontosságomat erre a szintre emelem (most ha megvárom a bekapcsolás utáni bemelegedést kb. 2*10 exp -7 et tudtam elérni, de ezzel az a gond, hogy az aktuális hőmérséklethez kell kompenzálni, mármint kontroller quartz kristály hőmérsékletéhez...)
-
ecaddsell
aktív tag
válasz
Teasüti
#9562
üzenetére
Már rég nem foglalkozok HW cuccokkal (amikor csak lehet készen vett modulokat huzalozok össze), de két videót tudok ajánlani a témában (amibe akkor is érdemes belepörgetni, ha valaki nem érti teljesen):
EEVBlog #1116 - How to Remove Power Supply Ripple
https://youtu.be/wopmEyZKnYoEEVblog #859 - Bypass Capacitor Tutorial
https://youtu.be/BcJ6UdDx1vgA "capacitance multiplier" különösen ajánlott, mert sokkal hatékonyabb lehet táp felelő jövő kapcsolási zaj szűrésére adott esetben mint kis zajú stabilizátor chip-ek (pl. LT1763 sorozat vagy LM1117 stb).
-
ecaddsell
aktív tag
Lehet van valami speciális funkciójuk, mindenesetre én nem tudok róla, szimplán csak több pint szeretnék.
Pl. mostanában kezdtem el foglalkozni az AD9959 (DDS) kártyával ami elég sok pint igényel...Ami nekem furcsa az egészben, hogy rengeteg olyan kártya van ahol ki van vezetve a pin 6-11 amit a belső flash használ és még azokon sincs meg a 37-38 pin. Nekem úgy tűnik a pin 37-38 tök általános input pin lenne, ehhez képest meg a belső flash pineket meg nem tudom mire használják (bootloader HW debug?) ahhoz képest elég sok kártyán ott van...
A Wemos amit írtál elég közel van ahhoz amit keresek. Köszi a tippet.
-
ecaddsell
aktív tag
Ennek van OLED nélküli változata is? Úgy egész szimpatikus lenne, pláne ha még valamivel olcsóbb lenne OLED nélkül...
Nekem olyan OLED-es ESP32 van, amin az OLED által használt összes pint lehagyták és az az OLED eléggé felejthető (a mérete sem túl nagy, de mellé a fényereje sem túl acélos), szóval az végül csalódás volt.
Mostanában nekem inkább a TFT a cél. Az OLED-el az a bajom, hogy annyira nem jó mint amennyire drága pláne nagyobb méretben.A gyári support nem annyira érdekes, annak ellenére, hogy doksi eddig sem nagyon volt, még mindig mindent megtaláltam.
-
ecaddsell
aktív tag
Létezik valami módszer arra, hogy az ESP32 GPIO34-GPIO39 pinjeit outputként használjam?
Ezen oldal szerint:
https://github.com/makeitlabs/ratt/wiki/ESP32-Pin-MappingEzek a pinek "GPIO input only/no internal pullup".
Gondoltam ha csak annyi a gond, hogy nincs internal pullup akkor teszek egy ellenállást kivűlre és kész, de nem megy (nem kizárt valamit elrontottam persze).Arduino IDE simán megeszi a pinMode(pin, OUTPUT);-ot ill. még a digitalWrite(pin, HIGH);-ra sem volt panasz...
Ha ezek tényleg input only pin-ek akkor számolásom szerint összesen 21 pin marad kimenetre (és ebben már az USB serial pin is benne van).
Egyébként van olyan (olcsó) board amin GPIO37 ill GPIO38 ki van vezetve mert azokon amik nekem vannak nincs is ilyen pin?
-
ecaddsell
aktív tag
Sikerült a 160x128-as TFT-n 4 sorra préselni ami eddig is 4 soron volt. Nem lett túl szép, mert nem tudtam semmi szeparátort tenni a MHz és a KHz közzé (a vessző már a kétszínű OLED-en sem működött, mert átlógott a sárga sorból a kékbe, de ott legalább volt hely egy szóközre), szóval marad a különböző színre színezés.
(A színek valójában sokkal szebbek mint a fotón, ami nem adja vissza az igazi színeket.)
Az alsó sor a ténylegesen mért frekvencia, amit az ESP32 mér (egy Fujitsu mb506 előosztó után mert ugye az ESP nem tud 40MHz felé menni mérésben). Nemcsak ezért nem kerek, hanem az ADF4351 itt már csak kb. 6KHz-enként léptethető (25 MHz/4096).
A jobb zöld meg a jelszint amit 1 AD8318 mér. Mivel ennek az érzékenysége meg kb. 25mV/dBm ez is ingadozik némiképp még átlagolás után is (itt sokkal stabilabb tápfeszek kellenének).Idővel át kell térjek a 320x240-es kijelzőre, amíg nem jön meg van még 2 sorom. Meg egyre kevesebb időm erre a projektre.
-
ecaddsell
aktív tag
Fogadd meg a lenti tanácsot. Én is használtam Nano-t, kedveltem is mert a kis méret miatt gyors fordítások ill. feltöltések voltak, de mikor 128x64-es kijelzőt kezdtem el használni nekem is kevés lett a memória.
Nem mellékesen a Nano nem 3.3V kompatibilis és a legtöbb cucc amit használok meg igényli a 3.3V-ot.Szóval ha nem tömegével kell, ahol számíthat az ár akkor ESP32 (relatíve persze sokkal drágább, de absz. értékben még mindig megfizethető kategória). Ott sokkal nehezebb belefutni a korlátokba, és ha mégis, könnyebb a kiút. A környezet meg lehet tök ugyanaz.
-
ecaddsell
aktív tag
Nekem méretileg elég lenne az 1.8-as kijelző is, ha kiférnék rá, lévén a nézési táv max 1m.
Egyébként megoldottam a ST7735-el a HW SPI-t is.
Mint sejtettem is fogalma sincs a könyvtárnak mit kellene használni ezért a default-ot használja.
Innen már csak az SPI default-ot kellett megkeressem és meg is lett az SPI.cpp-ben:if(sck == -1 && miso == -1 && mosi == -1 && ss == -1) {
_sck = (_spi_num == VSPI) ? SCK : 14;
_miso = (_spi_num == VSPI) ? MISO : 12;
_mosi = (_spi_num == VSPI) ? MOSI : 13;
_ss = (_spi_num == VSPI) ? SS : 15;Ezek meg a HSPI pinek amit a generátor chip-re használok, nem csoda, hogy összeakadt.
Áttettem a generátort VSPI-ra a TFT-t meg a HSPI pinekre és láss csodát megy a HW SPI és relatíve gyors is lett a frissítés (de még van mit javítanom).Na szóval összegzésnek ezek az SPI pinek ESP32-n:
HSPI
CLK 14
MOSI 13VSPI
CLK 18
MOSI 23A TFT HW SPI meg szépen lefoglalja a HSPI-t, szóval nekünk marad a VSPI...
Azért túl nincs dokumentálva a dolog...
-
ecaddsell
aktív tag
Én is újraírással frissítem. Korábban a kék háttérszínnel írtam újra, de nem volt jók a színek, szóval most nálam is fekete (de #define mondja meg mi a háttérszín szóval flexibilis).
Csak string-et használok, sprintf formáz.
Az alakzatokból max a filled rect lehet érdekes, ha az gyorsabb mint a háttérszínnel újraírás...Nem mondanám, hogy könnyebb kezelni az OLED-et, csak más. Sajnos könyvtáranként lehet más az inicializálás, kurzor kezelés (vagy nem kezelés), font méret beállítás (konstans, font nevében a méret stb), színbeállítás stb. Ezek egy része jól makrózható (én is ezt tervezem, ha eldől mik maradnak), más része nem annyira.
-
ecaddsell
aktív tag
Azt vettem észre a mérettel nagyon meredeken emelkednek az árak, szóval még akár reális is lehet amennyiért vetted. Én se vennék mást csak soros interfészes kijelzőt (hiába olcsóbb az ilyen-olyan shield).
A könyvtár linkjét köszi, ezt láttam is, csak annyi a könyvtár mint csillag az égen...
Viszont jó eséllyel megvárom amíg megjön a nagyobb kijelző, mert nemcsak a frissítéssel van gondom.
(A frissítéssel is azért inkább, mert jó pár adatot kell kiírni és ha 1 változik, akkor jó eséllyel az összes megy utána, szóval több részletben lényegében teljes újraírás van).
Minden kijelző, könyvtár variáns stb., pár extra #ifdef-t indukál és már most is rontja a kód minőségét a sok #ifdef, szóval most inkább még várok.Eredetileg 128x64-es OLED-el indult ez a projekt (dual color monochrome, felső 1/4 sárga, többi kék), aztán mikor kitaláltam legyen még ez meg az akkor láttam, kevés lesz a kijelző és megvettem a 160x128-as TFT-t.
Viszont ennél meg kiderült, hogy a textsize() az 10, 20, 30 stb. pixelt állít. Az 1-es méret az még nekem is kicsi, a 20-as mérettel meg nem fér ki az eddigi 4 sorból 2 (pl. frekvencia 9 digiten amit azért ultra gáz lenne több sorra osztani). Szóval hiába lett most 6 sor a 4 helyett, ha vízszintesen meg nem férek el (újabb tapasztalat: érdemesebb 1-el nagyobb kijelzőt venni, mint amiről azt gondolja az ember hogy elég lesz).Egyébként egy hasonló óra progi volt vsz. az első progi amit futtattam az EP32-n, ott volt a példaprogramok között és gond nélkül felment. WiFi-n szedi le a pontos időt. Nem is akartam WiFi-t használni (azóta se használtam), de pont ez esett kezem ügyébe.
-
ecaddsell
aktív tag
É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 -
ecaddsell
aktív tag
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ó. -
ecaddsell
aktív tag
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. -
ecaddsell
aktív tag
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á)...
-
ecaddsell
aktív tag
válasz
ecaddsell
#9425
üzenetére
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
-
ecaddsell
aktív tag
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.htmlVé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. -
ecaddsell
aktív tag
Vsz. kétszer gondold meg mielőtt beleugrasz ilyen nagyon olcsó cuccokba.
Én nemrég szívtam meg freki mérővel.
OLED kijelzős, vámhatár alatt 2.4GHz-ig mér. Ez kell nekem. (Ne legyen teljesen off, ESP32-ről vezérelt ADF4351-hez).Valóság: Valóban mutat valamit, sőt ha elég nagy jelet kap elmegy egészen kb. 3 GHz-ig is.
Viszont a pontossága nulla. Alapból van kb. egy fix 0.5%-os eltérés (normális mérő 10^-6 tól indul). Nem mellékesen nagy ugrásokkal változik a mutatott érték. A számláló mintha kb. csak 10 bites lenne.Na most mivel nekem is hobbi, kicsivel többért sokkal jobbat tudtam volna építeni (persze még szétszedhetem azt is amit vettem, de nem hiszem, hogy sokkal többet ki lehet belőle hozni).
Az ESP32-vel simán lehet akár 40 Mhz-ig tudó freki mérőt csinálni (15 bites PCNT, ablakozás RMT-vel van rá netes példa). Még hozzá téve egy előosztót akár feljebb is tudtam volna menni frekiben mint amit vettem (és úgy már nemcsak CMOS jelszintekkel megy).Visszatérve a szkópra: Kicsit alul specifikált. Mennyi a mintavételezés sebessége? Digitális (négyszög) jeleknél a mintavételezési sebesség tizedével kell számolni mint (felső) határ. Milyen a tárolás mélysége? Milyen érzékenységi tartományban használható? Milyen triggerek vannak?
(A dekódolást nem említem, bár pl. ami nekem van tudja, sosem használtam, annyira nehézkes a beállítás. Simán fe/lelfutó élre triggerelve megnézem a lényeget, sokkal gyorsabban így.)
Egyéni igény az, hogy a jel spektruma FFT-vel megnézhető legyen. Nem feltétlen a készülékben, hanem pl. offline PC-vel. Viszont az FFT freki felbontása függ a mintaszámtól, szóval van helyzet ahol simán kellhet 1M minta...
Sajnos konkrét cuccot, pláne ennyiért nem tudok ajánlani. Viszont saját tapasztalatból kiindulva, nem érdemes a nagyon olcsó cuccokba gyorsan beleugrani.
.)
Új hozzászólás Aktív témák
Hirdetés
ekkold- Path of Exile (ARPG)
- Okosóra és okoskiegészítő topik
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Formula-1
- Honor 400 - és mégis mozog a kép
- A fociról könnyedén, egy baráti társaságban
- Gurulunk, WAZE?!
- Nagyrobogósok baráti topikja
- Mozgásban a METAL GEAR SOLID Δ: SNAKE EATER
- ASZTALI GÉP / ALKATRÉSZ beárazás
- További aktív témák...
- Alkatrészt cserélnél vagy bővítenél? Nálunk van, ami kell! Enterprise alkatrészek ITT
- Realme C30 32GB, Kártyafüggetlen 1Év Garanciával
- Okosóra felvásárlás!! Samsung Galaxy Watch 5 Pro, Samsung Galaxy Watch 6 Classic
- BESZÁMÍTÁS! Dell Precision 5820 XL Tower PC - Xeon W-2123 112GB RAM 512GB SSD 1TB RX 580 8GB Win 11
- ÚJ Lenovo Yoga Slim 7 - 14.5" 3K OLED Érintő 90Hz - Snapdragon X Elite - 32GB - 1TB - 2,5+év gari
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest