- Mini-ITX
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Házimozi belépő szinten
- Házi hangfal építés
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen billentyűzetet vegyek?
- Kettő együtt: Radeon RX 9070 és 9070 XT tesztje
- Kormányok / autós szimulátorok topikja
- HiFi műszaki szemmel - sztereó hangrendszerek
-
PROHARDVER!
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
-
fpeter84
senior tag
válasz
csubuka
#7228
üzenetére
úgylátszik a fotodióda nem elég érzékeny hozzá, akkor lehet meg kéne próbálni egy fototranzisztorral is - az optocsatolókban is ez van, ami lényegében véve az amit szeretnél: egy led rávilágít egy fototranzisztorra és ez adja a galvanikus leválasztást...
milyen hosszú felvillanásokat kellene érzékelni? pontosan még nem sikerült értelmeznem a sok adatot a lux érzékelő doksijában, de mintha akár hosszú tizedmásodpercekig is eltarthat egy egy konverzió, ami meg már lehet túl sok adott esetben...
-
fpeter84
senior tag
válasz
csubuka
#7219
üzenetére
Ha loggolhatóan kell, akkor a fenti RS485-re köthető, ha elég csak a kijelzőn számlálás akkor teljesítménytől függően 10-20$ körüli megoldások is vannak. Aktív energiafelhasználást számol, kapcsüzemű tápegység/motor/stb is ráköthető, nem csak fűtőtest, lámpa...
Kevésbé pontos loggolás az olcsóbbak pulse kimenetével is megoldható
-
fpeter84
senior tag
válasz
gyapo11
#7162
üzenetére
Bele kell nézni, rámérni, mert nyákterv függő... A CY7C68013A fő csipp doksija szerint 3.3V tápfesze mellett is 5.25V a Vin max. Viszont ha van mellette egy 74HCT24x is akkor annak rá kell mérni a tápfeszére, mert az enyémen pl az is a közös 3.3V-ról megy ami kiszúrás, mert a csipp doksija szerint a Vin nem haladhatja meg a tápfeszét... Persze a gyakorlatban bírhatja - mire ez feltűnt nekem, sztem párszor már én is megkínáltam 5V-os logikai jellel is és nem ment tönkre - de azért jobb tisztában lenni vele. Esetleg át is lehet kötni kis gányolással a tápfeszét a bejövő 5V ágra, és az akkor kiterjeszti a biztonságos működési sávot...
-
fpeter84
senior tag
válasz
dave0825
#7155
üzenetére
Rákötheted közvetlenül is az 5V lábra az 5V forrásodat, a kínai klón nano alapból is úgy oldja meg a közösítést, hogy az USB felől az 5V egy diódán keresztül van egyirányúsítva, illetve vele párhuzamosan van egy 1117-es feszstab - tehát normál esetben USB-re kötve is szembe kapja az álló LDO az 5V-ot a kimenetére. Probléma esetleg ott lehet, ahol a mikrokontrollernek natív USB funkciója is van (Leonardo, Due, stb), mert akkor ha kívülről erőszakolod bele az 5V-ot akkor nem biztos hogy a belső kapcsoló mechanizmusok úgy működnek majd ahogy várod...
Az eredeti nano limit és terhelhetőségi információira ne alapozz! Az eredetin az 5V LDO egy 78M05-ös aminél az absolute maximum rating bemeneti fesz ~35V, az ajánlottat most nem találom de terheléstől függően 20-24V lehet és a terhelhetősége 0.5A, amit teljesít is annyi hűtéssel amit ad neki a nyáklap ha 10-12V-nál nem több a bemenő fesz. A 3.3V-ot is egy LDO adja, mégpedig az LM6206-os 0.25A terhelhetőséggel. Mivel ezek sorba vannak kötve ezért természetesen az össz áramfelvétel nem haladhatja meg a 0.5A-t.
Ezzel szemben a kínai klónokon az 1117 családba tartozó (AMS,LM - egyszer összeszámoltam, van vagy 15 féle) LDO dolgozik ami bár papíron 1A-t is tudna, de a gyakorlatban a kis tokozása miatt attól is max fél ampert várnék el, többre nem terveznék. Ezek az 1117-ek igen sokfélék. A doksikat böngészve találtam olyat is aminél 12-15-18V az ajánlott max bemenő fesz. Mindenesetre nálam már szállt el nano/uno pár nap üzem után ~12.6V-ot adó DC tápra kötve, ezért 9-10V fölé nem mennék a VIN-en... A 3.3V-os ágat pedig LDO helyett a CH340g-ből nyeri gány módon, aminek most nem találom a terhelhetőségét - de lévén hogy ezt valójában belső célra szánták, nem LDO forrásnak így 50mA-nél többel nem terveznék vele...
-
fpeter84
senior tag
válasz
dave0825
#7151
üzenetére
VIN-re kell kötni a betápot. Ha eredeti az UNO/MEGA, akkor köthetsz rá 12V-ot. Ha kínai klón amin AMS1117 feszstab van akkor bár elméletben mehetne az is 12-ről, de nekem már sült meg ilyen > a 9-10V a biztonságos. Ha autós felhasználásra kell, akkor mindkettő elé ajánlott táp, mert az autóban bármikor kaphat 14V felett is, ami már mindkettőnek sok. Ha Due, akkor abból nálam a kínai klón is 100%-ig megegyezik az eredetivel és mehet rá ~20V tápfeszig bármi. Ha kínai nano/micro, akkor meg kell vizsgálni, mert van olyanom amire olyan táp IC került amire abszolút max 6.5V-ot szabad ráengedni, de inkább csak szűk 6-ot ajánlott...
Az 5V már kicsit kevéske a VIN-nek, mert akkor az 5V-ból csinálna az onboard LDO 5V-ot ami a gyakorlatban már csak 4-4.5V lesz. Valószínűleg erről is elmegy stabilan, de jobb ha min 6-6.5V-ot adsz a VIN-re...
-
fpeter84
senior tag
válasz
Tankblock
#7106
üzenetére
Én inkább a CH340g csippeseket ajánlanám, nekem ez tűnt eddig a leginkább problémamentesnek! Ha eredeti lenne az FT232 az persze szintén jó lenne, de kínából 99% hogy hamisított érkezik, ami hajlamos eldobálni az USB azonosítóját - helyreállítható, de idegesítő jelenség. A PL2303-t szintén orrba-szájba hamisítják a kínaiak - bár a hamis is megbízhatóan megy, viszont csak 8-10 éves driverrel, amit a win10 erőszakosan lefrissít ha nem irtod ki a win update-et és akkor letilt. Még népszerű a CP2102 is. Ezzel nem volt semmi negatív tapasztalatom, de mivel a CH340g messze a legolcsóbb (5db ~800 pénz) ezért ezt javaslom...
-
fpeter84
senior tag
válasz
H3inike
#7059
üzenetére
I=P/U vagyis ~0.33A áramigénye van akkor a szivattyúnak. Relé helyett inkább egy N MOSFET-et javasolnék:
A fet mindenképpen legyen túlméretezve hogy ne legyen probléma a melegedése. TO92 tokozásban akár több amper terhelhetőségűt is kapsz és azt még rá tudod építeni levegőben a mini pro-ra... Azért tapizással ellenőrizd majd a melegedését és ha erősen melegszik akkor egy lemez hűtőfület érdemes lehet ráapplikálni...
-
-
fpeter84
senior tag
Mi értelme ennek az RF-es túlbonyolításnak? Miért nem külső RTC ami az INT lábával adott időben ébreszti? Egy DS3231 fillérekből kijön, a fogyasztása cirka zéró, évekig elmegy egy 2032-es elemről - adott esetben az elem akár el is hagyható, a cellára közvetlenül rá lehet kötni a vbat bemenetét...
(Mondjuk ezt alapból tudnia kellene az ESP-nek a belső RTC-vel is - tartok tőle csak szoftveres oldalról nincsen meg hozzá a megfelelő támogatás)
-
fpeter84
senior tag
válasz
csubuka
#7010
üzenetére
Kapcsrajz tervező programtól függően van ahol rejtett módon van bekötve a vonatkozó táp ágra - látni nem látod alapból - vagy a 2-4 opamp-ot tartalmazó toknál csak az elsőn van ábrázolva, vagy külön mozgatható elemként pl... Természetesen a gyakorlatban mindig kell neki tápot adni...
Ha single supply / rail-to-rail típussal építed akkor tökéletes lesz, pl MCP6H01-2-4. Ha 3.3-5V-ból akarsz 10-12-t akkor 1 opamp fokozat is tökéletes, ha 10-20x faktornál nagyobb erősítésre van szükség akkor már több lépcsőt szoktak használni.
Vagy egy jóval egyszerűbb verzió - talán kevésbé precíz, picit nagyobb a torzítása de ez leginkább csak műszerrel mutatható ki, még primitív audio célra is jó lehet: PWM analóggá filterezése, kiegészítve egy félvezetővel ami a nagyobb tápfeszt kapcsolja...
-
fpeter84
senior tag
Játszott e már itt valaki valamelyik bluetooth 4.0 modullal BLE observer módot? Hiába guglizok, nem találtam egyelőre olyat hogy bármelyik modul/chipset speciális firmware nélkül egyszerű AT paranccsal BLE observer módba váltható lenne és ha broadcast-et hall akkor kiírja amit vett... Nincsen párosítás, oda-vissza kommunikáció. Az adó időnként küld egy broadcast-et és ha valaki hallja akkor azt tesz vele amit akar...
Vettem egy ilyen TPMS készletet (beépített verzió) és ennek a működését térképezem fel, hogy ne csak a saját androidos szoftverével lehessen használni, hanem pl egy otthoni szerver tudja venni a riportjait induláskor/érkezéskor, és küldhessen egy figyelmeztető emailt ha anomáliát érzékel...
Linux alól bluez stack-el már sikerült megoldanom. Találtam egy python wrappert a bluetoothctl-hez, amivel tökéletesen sikerült dekódolnom a mért nyomás, hőmérséklet, elemállapot és hirtelen nyomásvesztés adatmezőket, de ha lenne olyan pár $-os BT 4.0 modul amivel meg tudom ugyanezt valósítani AT parancsokkal, akkor lehet megírnám ESP-re is ugyanezt...
Vagy lehet rossz kulcsszavakkal keresek? Az observer/broadcaster helyett más kifejezésre kellene vadásznom?
-
fpeter84
senior tag
Erre lehet jó pl egy saleae klón (vagy eredeti, ha valakinek az van): a kapcsoló lába egyrészt diódán keresztül mehet az első csatornára, valamint egy másik diódán keresztül a kondis prell mentesített a másodikra. A felvett mintán pedig lehet látni egyrészt az első csatornán az első tüskét valamint hogy hányszor rezgett ide-oda, másrészt a második csatornán hogy mekkora késést okozott a kondi az első váltáshoz képest...
-
-
fpeter84
senior tag
válasz
Janos250
#6892
üzenetére
LVCH245A Octal bus transceiver; 3-state
Inputs accept voltages up to 5.5 V
In accordance with the Absolute Maximum Rating System...
VI input voltage [1] 0.5 +6.5 V[1] The minimum input voltage ratings may be exceeded if the input current ratings are observed.
wikipedia.org/wiki/RS-232#Voltage_levels
RS-232 logic and voltage levels
Data circuits Control circuits Voltage
0 (space) Asserted +3 to +15 V
1 (mark) Deasserted −15 to −3 VSemmiképpen nem ajánlott közvetlenül rákötni, mert a pozitív irány is bőven túllépheti a tolerált tartományát, de a jel negatívba is megy ugyanannyit... Fizikailag lehet kibírná, működne, de inkább ne kockáztass ha nem az életed múlik rajta
A leg elegánsabb megoldás természetesen egy MAX232/MAX3232 alapú illesztés, de ha elég alacsonyabb sebesség (félvezető típustól függően akár 19200-38400 baud, de a 4800-9600-ra garantáltan elég) akkor ezt a tranzisztor+dióda+2 ellenállásos kapcsolást másolva is meg lehet oldani:
A negatív jelet levágja a dióda, a pozitívval pedig egy ellenálláson keresztül le-lehúzza az NPN tranzisztorral a felhúzott RX lábat. Ha az általános diódát egy ~3-5V-os zener-re cseréled, akkor akár a tranzisztort is el lehet hagyni! Elég felhúzni a bemeneti lábat 3-5V-ra és azt lerángatni a bejövő negatív jellel földre a másik ellenálláson keresztül... (a zener a negatív és a pozitív túlfeszt is lenyesi, csak az analizátor programban a serial async kiválasztásakor az invertált jelet is be kell pipálni, mert ugye a tranzisztor ezt is biztosítaná)
-
fpeter84
senior tag
válasz
Janos250
#6880
üzenetére
Feltételezem a rajta lévő kapcsüzemű táp + AMS1117-nél lehet sokkal jobb üresjárati áramú tápot kreálni hozzá. Azt még nem álmodtam meg, hogy 2xAA elemről vagy 1x3.7V Li akkuról menjen e... Annak még utána kell nézni/ki kell próbálni hogy mit szólna az ESP a táp nélkül közvetlenül két AA elemről járatáshoz - gondolok itt a kicsit gyengülő elem állapotra, hogy meddig képes stabilan elindulni még róla. Ha pedig Li akku, akkor kell elé egy 1 fokozatú táp (nem kell 5V), aminek a létező legkisebb az üresjárati pazarlása...
Közben már keresgélek, de konkrét választ még nem találtam a mAh/várható készenléti állapot kérdésre... Régebbről rémlik egy videó, ahol az illető gombelemről járatta az ESP-t, és mintha közel 1 hónapos készenlét lett volna a konklúzió. No ezzel ki tudnék egyezni, akkor két AA-ról járatva nem kellene túl gyakran elemet cserélni
-
fpeter84
senior tag
Köszönöm a tippeket!
tvamos: úgynézem ez a Ti platform elég borsos árú - jobban preferálom a filléres kínai megoldásokat - ahogy nézem a kész dev cuccok 30-40$-tól tartanak a csillagos ég felé... A referencia nyákterve pedig elég összetett ráadásul QFN IC-vel, így a hobbi projektekből kiesik...
ESP: no erre nem is gondoltam alacsony fogyasztású alternatívaként... Van Wemos D1 R2-ből és több - ez gondolom kevésbé alkalmas a célra - de van natúr ESP12 modulból is pár itthon. Meg van OpenWrt-s routerem is a házban, szóval adhatja magát a dolog, hogy az legyen a szerver... Milyen készenléti időt sikerült eddig elérni vele, ha csak pár percenként jelentkezik be? Interrupt-ra fel tud éledni alvásból, ha esemény van körülötte és jelentenie kellene?
-
fpeter84
senior tag
Sziasztok!
Ugyan nem közvetlenül Arduino-s a kérdésem, de erősen köthető ezért azhiszem itt érdemes bedobnom: az NRF24L01 -nél van jobb platform alacsony sebességű, multipoint-képes (egy központi "szerver" és körülötte a "kliensek") kommunikációra? Nagy sávszélesség nem kell, épp csak pár byte közvetítése, és mindezt minél alacsonyabb fogyasztással mert elemes/pici akkumulátoros megoldás lesz, viszont pár téglafalat azért át kellene vinnie...
Tudtok jobbat ajánlani a célra, vagy ilyen modulokat szerezzek be?
Előre is köszönöm a válaszokat!
-
fpeter84
senior tag
Azért mert a linkelt stackoverflow-s szösszenet tesztelésen kívül nem sokra jó - csak a magnetometert olvassa ki, cirka annyi mintha nem is a 9DOF MPU9250-et vetted volna csak egy alap HMC5883L-t. Önmagában nem sokra mész ezekkel a mért adatokkal mert nincsen viszonyítási pontod a térben (ehhez kell az acc) valamint nincsen korrekció az elmozdulásra és elforgásra (acc+gyro).
Ha tökéletesen vízszintesen tartanád a modult és nem mozdítod/forgatod akkor elég lenne, de ahogy elmozdul ahhoz már mind a 9 adat kell hogy értelmes irányadatot kapj bonyolult matekozással - de ezt elvégezi a library
-
fpeter84
senior tag
tölsd le az RTIMULib csomagot, a libraries könyvtár tartalmát másold át az arduino-ban beállított lib könyvtárba, a többi pedig a példaprogramok. A lib-ben a RTIMULibDefs.h -t szerkeszd át, a 32-es sorral alapból a 9150 van kiválasztva - ezt kommenteld ki és aktiváld helyette valamelyik 9250-et - a címet most így nem tudom hogy a kettő közül melyik lehet, de látni fogod ha egyikkel olvassa, a másikkal pedig nem...
Először a magcal programon kell végigmenni és s-el lementeni a kalibrálási értékeket, utána lehet használni az arduimu-t
-
fpeter84
senior tag
válasz
czupy84
#5097
üzenetére
Javaslom hogy darabold fel a témát és részleteiben próbálj meg nekifutni, ismerkedni a lehetőségekkel, akkor tudod legjobban megfogalmazni utána a végleges eszközhöz az igényeidet. A legjobb kiindulási alap egy olcsó kínai MEGA2560-as - ugyan van nála 100x modernebb és gyorsabb, de ennek van a legnagyobb támogatottsága (az Uno-val egyetemben), ezzel tudod a tanulást jól elkezdeni. Ugyanaz mint az uno, csak több lábbal, rammal, programterülettel...
Páratartalom/légnyomás/hőmérő kombó célra talán a BME280 a legjobb választás - szintén filléres kínából modul formájában.
Kijelzőből nagyon nagy a választék de készülj arra hogy ha nem valami méregdrága adafruit/sparkfun/stb forrásból veszed akkor jó macerás lesz éleszteni, mert sokszor még a vezérlőcsipp sem az rajta a gyakorlatban, mint amivel a kínai hirdeti - ne ez legyen az első, mert igényel némi library vadászat és finomhangolás gyakorlatot... Első körben tökéletes az is tökéletes ha sorosra iratod ki a PC képernyőjére hogy mit mér, mit küldene, stb...
Az ethernet és a kijelző lehet összeveszős hardver és library szinten is - közösen használt lábak anomáliája, stb - ezeket átrendezni máshová szintén nem a legegyszerűbb feladat. Jobban jársz első körben egy filléres bluetooth modullal - a soroshoz hasonlóan ugyanúgy tudod nézni a gépeden a kimenetet csak már vezeték nélkül...
-
#5069
fpeter84
senior tag
vitezlejszlo
#5068
fpeter84
senior tag
válasz
vitezlejszlo
#5068
üzenetére
Biztos vagy benne, hogy a kazánod analóg vezérelhető? Én is tervezek hasonlót, de a miénk az egyértelműen "digitális" - vagy fűt, vagy nem a termosztát jelétől függően. A bimetálos termosztátnak van egy apró mechanikából adódó hiszterézise is, így nem rezeg oda vissza.
Egyébként az említett esp+relés megoldás még olcsóbb is - nekem pont a napokban érkezett egy SONOFF kísérletezésre - még csak kipróbáltam, de szét nem bontottam mert így is millió a projektem. Pl vettem nemrég 3D nyomtatót is, többek között az említett meggondolásból
-
fpeter84
senior tag
válasz
Janos250
#5064
üzenetére
Nekem is volt olyan cuccom ami november elején indult és egy hete érkezett meg, de azért a nagy tömeg megjött átlag 2-4 hét alatt a karácsonyi időszakban is
A modemek különösen sokat tudnak zabálni csúcsokban. Az alap GPRS online állapotuk ugyan megelégszik 1-200mA-el, de pl a simcom modemek doksija kiemeli hogy térerőtől függően csúcsokban akár 2A-t is képesek kirántani a tápból - ezért kell sok elkó vagy akku mellé
Nekem legjobban az MP1584/GW1584 csippes kínai kis tápmodulok váltak be eddig. Valós 2A terhelhetőség, csúcsra járatva sem igazán melegszik, de terhelés nélkül/minimális terheléssel sem instabil, ha kell akár kapcsolható is (ehhez a modulb bele kell nyúlni), és 2x V betápig el lehet vele menni, tehát autóban is biztonságosan használható. Szűk fél dolláért szórják modul formájában, így még saját nyákon is inkább pár tüskével szendvicsbe rárakom minthogy küzdjek a körülötte lévő alkatrészek elhelyezésével...
-
fpeter84
senior tag
Én az A7 néven futó GPS-el kombinált nagytesójával dolgoztam már, és abszolút elégedett voltam vele - nem sms hanem adatkapcsolatra használtam. Pár furcsaság volt a viselkedésében - jobban mondva a doksijától való eltérések - de ezt feltérképezve utána abszolút megbízhatóan tette a dolgát... Azthiszem ebben a topikban is írtam róla előbbre, ha visszanézel 2-3 hónapot biztosan meglesz, összefoglaltam hogy hogyan viselkedett nálam...
-
#5054
fpeter84
senior tag
vitezlejszlo
#5053
fpeter84
senior tag
válasz
vitezlejszlo
#5053
üzenetére
win vagy linux? win alatt nekem is látványosan sokkal lassabb a fordítás mint linux alól, és több gépen is hasonlóan viselkednek...
-
fpeter84
senior tag
Nem szerencsés, a legtöbb félvezető max tápfesz+0.3V-ot tolerál hivatalosan a bemeneti lábain - kivéve ha kifejezetten le van írva hogy "5V tolerant" a 3.3V-os mikroproci egyes lábain... Tegyél rá ellenállás feszosztót amit ~3V környékére be tudsz lőni, akkor garantáltan nem okoz károsodást...
-
fpeter84
senior tag
-
#4999
fpeter84
senior tag
Speeedfire
#4998
fpeter84
senior tag
válasz
Speeedfire
#4998
üzenetére
AVR-el, soros (USB) bootloaderrel max magadnak tehetsz a kódba debug funkciókat, hogy kiírja sorosra pl a változók értékeit. De ha átnyergelsz pl STM32-re, akkor egy filléres STLink programozóval kiegészítve a sokkal mélyebb debug is lehetségessé válik!
-
#4997
fpeter84
senior tag
Speeedfire
#4994
fpeter84
senior tag
válasz
Speeedfire
#4994
üzenetére
igen, arra jó hogy megejelnítse hogy mi megy ki/be a digit vonalakon
sokféle protokolt képes maga is dekódolni, de a jelformából/időzítésből magad is tudod ellenőrizni hogy tényleg az megy e ki aminek kell - programkód oldalon lehet e a hiba, vagy tényleg a fogadó oldal nem reagál rá
-
fpeter84
senior tag
A teljesség igénye nélkül pár perces ebay kereséssel ezeket találtam 1117 utótaggal: AMS, AP, AZ, L, LM, LT, NCP, REG, TLV, TS, ZLDO
És van amelyik mindenféle gyártók kínálatában megtalálható ugyanazon a néven eltérő specifikációkkal... A "leggyengébb" is meglett ami rémlett TS1117 néven, de van mindenféle abs.max rating köztük: 12,15,18,20V...
Túl biztosan nem terheltem, mert csak egymagában hajtott valami mikrokontrollert egy 12V DC fali tápról, és pár óra után azt vettem észre hogy kis amperszag és többé nem jön ki belőle semmi - a kontroller túlélte, utána ment időtlen időkig másik táppal. A fali tápot azóta is használom mindenfélére és másnak még nem ártott meg...
Továbbá kínai nano is ment már tönkre az autómban 1117-el, pedig 14.1-2V felett még sosem láttam a töltőfeszt akkor sem ha lehúzta kissé az állófűtés, normál esetben meg bőven 14V alatti az alap töltési állapot - bár ez tény hogy már erősen a határfeszegetés volt...
Azóta csak az említett 78Mxx családot használom autóban ha füstölős LDO, vagy más kapcsüzeműt ha nagyobb áramról van szó - igyekszem 1.5-2x túltervezni nehogy gond legyen hosszútávon...
-
fpeter84
senior tag
Most azt pont nem találom, de határozottan úgy rémlik hogy a sokféle gyártó sokféle doksijából az egyikben még 12V-os absolute max rating-et is láttam, de van 15 meg 18-at emlegető is - lehet az nem AMS1117 doksi volt hanem valami más 1117 - sok csippre úgyis csak ennyi van ráírva... Mindenesetre azóta hogy mindennemű túlterhelés nélkül egyszer alig több mint 12V-tól leégett nálam egy, azóta nagy ívben kerülöm ha 10V feletti betápról kell üzemeltetni valamit, akkor inkább egy 78Mxx amit akár 35V-al is meg lehet küldeni... 7.2V akkus vagy 9V fali tápos környezetbe már ok az 1117 is persze...
-
#4973
fpeter84
senior tag
Speeedfire
#4971
fpeter84
senior tag
válasz
Speeedfire
#4971
üzenetére
A tápcsati melletti 3 lábú hűtőfüles LDO-ra mi van írva? AMS1117? Sajnos nem egy csúcsminőség, a gyártó szerint a Vin absolute maximum rating 12V, és nekem tényleg sikerült is megfektetni pár órányi 12.6V-al. Órákig ment, aztán egyszercsak feladta... Mondjuk ez valami kicsit egyedibb nyákterv, de döglött külső LDO-val is USB-ről nekem ment egy Nano meg egy Uno is, csak a külső tápra csatlakoztatva kezdett izzani füstölni a csipp... Ha óvatosan végigtapizod ujjal az IC-ket, nem érzel valahol feltűnő melegedést? Ha valami forró az nagyon nem normális, egy ilyenen alapból nem vesz fel jelentős áramot semmi... Ha van multimétered akkor méregesd végig az ismert feliratozott tápfesz pontokat!
-
#4970
fpeter84
senior tag
Speeedfire
#4969
fpeter84
senior tag
válasz
Speeedfire
#4969
üzenetére
Teljes gép kikapcsolást próbáltál? Nem sima újraindítást, nekem a T400-al fordult már elő hogy valamivel túlterheltem, rövidre csuktam egyik portot, és az azon az oldalon lévő portok többé nem működtek egy teljes kikapcsolásig, úgy letiltottak... A LED-ek világítanak, az 5V-ot nem veszi le a gép a portról?
Ezt egy másik gépre dugva, illetve ugyanazon a porton más eszközt próbáltál már?
-
fpeter84
senior tag
Kínai klón is van olyan ami nagyon hasonlít vagy tényleg 100%-os másolata az eredetinek. Pl a Due-kat 99%-ban tényleg egy az egybe újragyártják mindenféle váloztatás nélkül...
16U2 vs. CH340g: a klasszikus 328-as procinak csak hardveres sorosport támogatása van, USB nincsen (szoftveres megoldások vannak az emulálására, de azt most hagyjuk). Ezért hogy USB felől lehessen programozni, tettek a nyákra plusszban egy USB>soros illesztőt, ami az eredeti Arduino esetében nem egy célcsipp mint a CH340g, FT232, PL2303 vagy CP2102, hanem egy hardveres USB támogatással rendelkező 16U2-es (ugyanolyan AVR proci mint a 328) megfelelő firmware-el ellátva, amitől transzparens USB>soros adaperként látszik az oprendszer felől. Nem igazán tudom hogy miért ezt a drágább változatot választották annó - lehet még kisebb volt a kínálat dedikált célhardverből, lehet akkor még ez volt az olcsóbb. Mindenesetre mivel ez a társcsipp is tulképp csak egy mezei AVR proci, ezért pár egzotikusabb projektben külső programozóval átírva a firmware-t befogták egyéb célokra is... Utána megjelentek a 16U2-vel gyakorlatilag azonos, ugyanúgy hardveres USB támogatást adó (vagyis nem kell semmi társcsipp) csak picit több lábbal, memóriával, funkcióval bíró 32U4-es Leonardo és Pro Micro, így végképp értelmét vesztették ezek a trükközések az eredeti UNO-val...
-
fpeter84
senior tag
A kínai klónokon többnyire nem 16U2 felel az USB>soros illesztésért hanem egy CH340g csipp - de ez mostanra ugyanolyan jó mint az eredeti, nincsen probléma se a win, se a linux alatti stabilitásával - max pár perverzebb egyedi projektről csúszik le az ember, ahol ezt a kiegészítő csippet hekkelik meg ilyen olyan célból. Bár igazából elesni attól sem fogsz, csak arra meg egy Leonardo-t vagy Pro Micro-t kell venni 32U4-el...
-
fpeter84
senior tag
Meghozta a ződmikulás a BME280 párost. Első nekifutásra sokkal szorosabban mozognak együtt a páratartalom értékek - ráfújva, legyezve, kéközlítve stb ugyan van hogy látványos egy pillanatra a különbség, de ha kapnak 5-10-30mp-et a kiegyenlítődésre akkor szépen beállnak fél-1 %-on belüli értékre
Nem tudom hogy a HTU21-nél miért volt akkora szórás - lehet hamisítják a kínaiak, lehet a forrasztásnál vagy szállításnál sérült meg, passz - konkrétabb következtetést akkor lehetne levonni ha 10-20 darabot üzemeltetne egymás mellett az ember belőlük...
-
fpeter84
senior tag
válasz
Janos250
#4917
üzenetére
Mono 8x8-as mátrixot MAX7219-el még nem használtam, csak 8x8-as RGB mátrixot DM163-al, de a sorba fűzést azon sem próbáltam még ki... Lehet normális ez a viselkedés, a második/harmadik/n-dik csippet úgyis a chip select-el kell megszólítani akkor, amikor a rá vonatkozó információt küldöd éppen, szóval úgy mindenki csak arra és akkor reagál amikor kell neki
-
#4869
fpeter84
senior tag
szabieable
#4868
fpeter84
senior tag
válasz
szabieable
#4868
üzenetére
Az ebay tele van arduinohoz kész kijelzőkkel, ha pár kulcsszóval nekiindulsz meglátod mi a kínálat méretben és felbontásban. Viszont minél nagyobb a felbontás, annál nagyobb probléma lesz megfelelő framerate-et tartani az animációdban - részben ezért jutott eszembe a raspberry és klónjai mint alternatíva. Szóval kb mekkora méretben képzeled el a kütyüt? Ha hozzáveszed a tapasztalataidat telefonokkal/tabletekkel, akkor azt is meg tudod saccolni, hogy mekkora felbontásban szeretnéd mindezt látni, hogy ne legyen nagyon pixeles...
A pixelesség ellen persze lehet küzdeni valamiféle anti-aliasing algoritmussal, de akkor ahhoz kellően túlméretes erőforrás is kell, mert akkor már nem úszod meg a helyi framebuffer memóriát... 320x240 16 bites színmélységgel már 150KB, 480x240@16b az 225KB, 640x480@16b módhoz már 600KB memória kellene csak a képnek, ami uC világban már elég combos eszközt jelent...
-
#4867
fpeter84
senior tag
szabieable
#4866
fpeter84
senior tag
válasz
szabieable
#4866
üzenetére
Akkor először a kijelző méretét/felbontását kell behatárolnod pontosan, mert van egy bizonyos határ ami fölé arduino/mikrokontrollerrel nem igazán lehet/célszerű menni - viszont pl egy raspberry-vel vagy egyéb kínai klónnal könnyen megoldható... Utóbbival akár TV-re is kötheted ha úgy tetszik...
-
#4846
fpeter84
senior tag
DrojDtroll
#4845
fpeter84
senior tag
válasz
DrojDtroll
#4845
üzenetére
Valami olyan matekot próbálnék ki hozzá, hogy bufferelném a mintákat, és ha pl az előző 10 érték fix, akkor csak akkor mozdítom el róla a kimenő értéket ha 1-2-nél nagyobbat mozdul... Esetleg utána még az átlagát is lehet venni az utóbbi néhány értéknek és az ebből jövő kimenőértéket lehet map-elni valami tetszőleges páratlan számú lépcsőre ahol a középső a nulla - alaphelyzet sávja... A buffer és az átlagolási méretével és az elmozdulási érzékenységgel lehet játszani persze - meg kell találni az egyensúlyt a stabilitás és reakcióidő között... Mintavételezési tempótól függően lehet hogy nem 10 hanem 100 vagy 1000 az ideális bufferméret... Viszont ehhez az is fontos lehet hogy fix ütemben mintavételezd és töltsd a buffert lehetőleg megszakításokkal...
-
#4842
fpeter84
senior tag
DrojDtroll
#4841
fpeter84
senior tag
válasz
DrojDtroll
#4841
üzenetére
Próbáltad már a poti helyett egy fix ellenállás értékkel is, hogy valóban összeszedett/mérési zajról van e szó? Mert szerintem akkor tökéletes nyugalmi állapotba kell kerülnie, ha nincsen valami látványos bug a tápban... Nem lehet pl hogy a joy-on nyugvó újadban lüktető vér okozza azt az apró "zajt"? Valami szoftveres algoritmussal kellene megszabadulni tőle, pl "érzékelni" a nyugalmi állapotot és onnan csak akkor elmozdulni ha számottevő a változás (nem 1)...
-
#4811
fpeter84
senior tag
DrojDtroll
#4807
fpeter84
senior tag
válasz
DrojDtroll
#4807
üzenetére
Azt hittem csak centikre - akkor ahogy tvamos írja, RS422 differenciálisra alakított mezei soroson is átmehet ennyi, vagy ha biztosra akarsz menni akkor a CAN (szintén differenciális) többet is átvihet, illetve a címzést (ha több eszköz van) és hibajavítást is lekezeli hardver szinten... STM32-ben vannak ilyenek, illetve a Due is jó hozzá többek között...
-
#4804
fpeter84
senior tag
DrojDtroll
#4803
fpeter84
senior tag
válasz
DrojDtroll
#4803
üzenetére
Talán az SPI master/slave viszony lehet az egyik leggyorsabb, de elég macerás leprogramozni megbízhatóra... Viszont ha kellően közel vannak egymáshoz, akkor akár a sorost is fel lehet tolni megabit szintig, vagy CAN bus
-
fpeter84
senior tag
Ok, tehát van vele rendes tapasztalatod is... Szépséghiba hogy csak "horribilis" áron látok vele kész modult - az is elég túlméretes - és házilag nem igazán vállalható a forrasztása... Kíváncsi vagyok a BME280-ra hogy azok hogyan teljesítenek, ha megjönnek akkor majd megírom azt is...
-
fpeter84
senior tag
válasz
Teasüti
#4766
üzenetére
Még arra is gondoltam, hogy esetleg a lib csinál valamit nagyon rosszul, lehet majd beleásom magam a doksiba és megpróbálom magam kiolvasni...
(#4767) tvamos
A "teljesen jól működött" mit jelent? Ki lehetett olvasni? Mert ezeket is ki lehet... Vagy volt belőle 2-3 egyformád és hibaszázalékon belül ugyanazt az értéket adták? -
fpeter84
senior tag
válasz
szaszyka
#4762
üzenetére
Itt is kb 20% a differencia, csak nem szám szerint +/- 20 hanem a százalék +/-20 százaléka - csak azért furcsa még ez a relatív nagy szórás is, mert a doksija szerint +/- 3%-nak kellene lennie a pontosságának...
Egyébként egyáltalán nem nagy mutatvány a párhuzamos olvasásuk, csak némileg erőforrás-pazarló és lassabb is mint ideális állapotban - saját kóddal természetesen lehetne maximalizálni a sebességét - de percek alatt össze lehetett kalapálni ezt is így... Érzékelőnként kell 2-2 digit láb (lehet az órajeleket össze lehetne vonni, de azzal nem foglalkoztam), ha a kék illesztett HTU-ból rendelsz akkor azokat a MEGA-ra vagy később egy NANO/MICRO-ra közvetlenül is rákötheted...
-
fpeter84
senior tag
válasz
szaszyka
#4753
üzenetére
Hát akad némi különbség a két HTU21 között, pedig adtam nekik időt a kiegyenlítődésre mindenhol...
szobahőmérsékleten
Temp1: 21.58 Hum1: 49.77 Temp2: 22.34 Hum2: 41.67
Temp1: 21.60 Hum1: 49.77 Temp2: 22.34 Hum2: 41.65
Temp1: 21.55 Hum1: 49.73 Temp2: 22.27 Hum2: 41.64radiátoron
Temp1: 29.76 Hum1: 33.49 Temp2: 30.40 Hum2: 26.63
Temp1: 29.77 Hum1: 33.50 Temp2: 30.41 Hum2: 26.63
Temp1: 29.77 Hum1: 33.50 Temp2: 30.41 Hum2: 26.63nyitott ablakban
Temp1: 7.57 Hum1: 44.38 Temp2: 7.86 Hum2: 37.16
Temp1: 7.55 Hum1: 44.37 Temp2: 7.78 Hum2: 37.19
Temp1: 7.54 Hum1: 44.41 Temp2: 7.74 Hum2: 37.24Az egyik egy ilyen piros amin csak felhúzó van, a másik pedig ez a kék modul, amin viszont van 3V3 feszstab és jelszintillesztő is, így nyugodtan rákötheted a MEGA-ra is!
(mintha a kékből annó 2-t is rendeltem volna, ha előkerül akkor őt is bevonom a kapcsolásba)
-
fpeter84
senior tag
őőő, nekem I2C-vel sem volt soha timeout gondom akkor sem ha KHz alá vittem a softi2c órajelét
sikerült élesztenem egymás mellett a 2 HTU21 modult 2 független SlowSoftWire buszon az Adafruit HTU21 lib áthekkelésével: csináltam belőle 2 független példányt, egyik Wire1 néven a 10-11 lábakon, a másik pedig Wire2 néven a 12-13-as lábakon keresi a maga érzékelőjét. Természetesen tetszőleges számú HTU-ra copy-paste-elhető a dolog amíg van elég láb, csak némileg pazarló, de a DUE-n így is csak 3% programterületet foglal egy alap sorosportra kiiratás... most hagyom egy darabig hogy aklimatizálódjanak aztán majd megírom hogy mekkora differencia van az olvasások között...
-
fpeter84
senior tag
előkerül a 2 HTU21-es és egyből problémákba futottam...
Csak a 3.3V-ot komálja csak, az IO lábain is, úgyhogy az UNO/MEGA-hoz szintillesztésre volna szükség
Úgyhogy túrtam egy DUE-t gyorsan és arra dugtam rá. Viszont az adafruit-os lib-nek nem tudom hogyan lehetne megadni több instance-hoz különböző I2C buszokat - valószínűleg nem is lehet... Így 2 lehetőség marad: vagy maga olvassa ki az ember saját feldolgozó rutinokkal, vagy marad az 1 buszon tápcserélgetős eljárás. Ezzel viszont az a gond, hogy a nyákon lévő felhúzók miatt hiába próbálok váltani a 2 modul között - ha az elsőre tápot adok az ugye megpróbálja felhúzni az I2C buszt, viszont azzal hogy a másodiknak viszont lehúzom a tápját 0-ra, így annak a felhúzói így lehúzókká válnak, és meghülyül tőle a busz...
A megoldás az lenne, hogy leszedem mindkét modulról az onboard ellenállásokat, de nem akarom összegányolni őket mert más projektben meg megvan így a helyük...
-
fpeter84
senior tag
válasz
szaszyka
#4753
üzenetére
Ha nem kell légnyomás, akkor az olcsóbb HTU21D is megfelelhet a céljaidra. Gondolom egy ilyen szellőztetőnél nincsen szükség túl magas frissítési frekvenciára - akkor a 3 külön szoftveres I2C busz verzióval próbálnám meg, az a legegyszerűbb... Egyébként a 2560-as feleslegesen nagy és drága ide, egy nano vagy micro is bőven elég lehet a célra, vagy egy ugyanolyan árú STM32 mini
-
fpeter84
senior tag
válasz
Tankblock
#4749
üzenetére
Hmm, no ez a távolság kérdés is okozhat gondot. Már próbáltam 30m-es UTP kábel végére akasztott I2C érzékelőket olvasni és nem volt probléma velük, de ha ennél nagyobb távolság is előfordulhat akkor lehet én is a vezetéknélküli irányba tartanék... Bár én a filléres ESP8266-ot választanám, és ezeket állítanám hálózatba - akkor akár még a távmonitorozás, logolás, vezérelhetőség is kényelmesen megoldható velük...
-
fpeter84
senior tag
válasz
szaszyka
#4748
üzenetére
Jaja, a DHT-re értettem hogy butuskábbak, de azt hogy stabilabb e még nem tudom. Mindenesetre 2 darabbal mindjárt megnézem hogy melyik mit olvas, csak elő kellene kerülnie valahonnan a második modulnak is...
Ha neked nem kell légnyomásmérés csak páratartalom, akkor a HTU21 is jó választás lehet. Viszont a 3 darab párhuzamos olvasása tényleg felvet némi problémát! Ezek az I2C eszközök max 2 címet tudnak kezelni, a HTU csak egy fixet... A BME-ből van olyan modul is ami I2C-n 2 cím közül választható, vagy van olyan ami SPI-t is tud, ahol a CS láb kezelésével ugye tetszőleges számú eszköz olvasható párhuzamosan.
Szóval a köv verziókat tudom elképzelni a párhuzamosításra:
- I2C eszközök azonos címen egyetlen buszra felfűzve, de a tápot 1-1 dedikált GPIO biztosítja a moduloknak (kicsi áram, max 0.5mA), és mindig csak egyik modulnak adsz tápot és adsz neki pár mp stabilizálódási késleltetést
- I2C eszközök azonos címmel külön szoftveres I2C buszon, vagy olyan uC aminek ennyi külön hardveres busza van
- I2C eszközök azonos címmel olyan uC-n ami rendelkezik valamiféle pin-remap funkcióval, hogy lehessen váltogatni a végpontok között az 1 hardveres buszt
- SPI eszközök külön CS-elViszont ha az utóbbit választod akkor jól nézd meg melyiket veszed, mert szerintem az olcsóbb kínaiak keverik a BME-t a BMP-vel! nagyon hasonló a 2 tokozás, de a BME fémsapkája négyzet forma, a BMP meg kisebb téglalap, és az olcsóbb BME-nek árultakon én a téglalap formát látom... Persze lehet a "kép csak illusztráció" és tényleg BME-vel küldi...
-
fpeter84
senior tag
válasz
szaszyka
#4743
üzenetére
Szerintem kevered a típusokat... A DHT11 és 22 az (butuska) páratartalommérő, a BMP180 és BMP280 viszont légnyomásmérő. Ha okosabb páratartalommérő kell, az pl a HTU-21 lesz, vagy ha egyszerre szeretnéd a két funkciót akkor az a BME280 lehet pl...
HTU-21 -ből van 2db 2féle modulom, de eddig még nem jutott eszembe egymás mellett olvasni őket hogy mennyire adják ugyanazokat az értékeket - mindjárt ki is próbálom...
BME280-ból is a napokban rendeltem egy párt, de az még jó egy idő lesz mire ideérnek rizsföldről...
-
fpeter84
senior tag
Nézem az L9110 doksiját, és igazából nem kell se felhúzó, se jelszintillesztés... A test conditions rovatban 9V tápfeszhez azt írja, hogy a bemenő HI jelszint min 2.5V, tehát bőven elégnek kell lennie annak amit a uC tud adni neki - biztos ami biztos alapon egy soros ~1K-t azért odatennék, de más nem kell, az onboard felhúzókat el kell távolítani, nem is értem hogy mi a fenének tették oda őket...
-
fpeter84
senior tag
A PWM frekvenciájával még nem kezdtem el játszani, de a motorok erőtlensége, nyomatéktalansága nekem is feltűnt mint említettem... Mire elkezd forogni, már alig változik valamit a fordulatszáma maximumig. Nem igazán volt időm többet játszani vele, de előbb utóbb talán sikerül...
illesztésre nem kell IC, bőven elég csatornánként 1-1 tranzisztor, vagy vannak I2C-hez szánt level converter modulok kompletten, az is jó lehet...
-
fpeter84
senior tag
Most ezt mire érted, hogy "és ez az ajánlott?" ? Csak leírtam hogy nekem ez a 2 rokon típus picit furcsán viselkedik, mert annak ellenére hogy azt írja a doksija hogy L+L és H+H az mindig L kimenetet ad, valahogy mégis sikerült rövidzárlatba kapcsolnom... Plussz a modulon lévő felesleges felhúzó ellenállás miatt megütheti a uC kimeneti lábát, ha nagyobb tápfeszre van kapcsolva a motor mint a vezérlő...
-
-
fpeter84
senior tag
Nekem eredetileg a 4 csatornás modulon HG7881 volt, mentek is vele az ugyanilyen motorok mint a Tiéd de valahogyan mégiscsak sikerült leégniük... Elméletben pedig a csippek vezérlő lábait akár egyszerre is lehet fel/lehúzni, ignorálja és nem csinál rövidzárat - elvileg, nálam mégis megtörtént. Utána rendeltem egy marék L9110-et, lecserélgettem őket, ezekkel ismét megy de már volt rá példa ismételten hogy azt vettem észre hogy a motor nem forog és jön az amperszag a csippek felől. Szerencsére nem égett le ismét, utána ment vele a motor megint de lehet károsodott is közben... Szóval nem tudom hogy mi okozhatja ezt az összeakadást, de vannak furcsa dolgai ennek a HG7881/L9110 párosnak
És nekem sem sikerült lassan mozgatnom vele a kerekeket - egy bizonyos kitöltést megkövetel, utána meg már nem sokat változik a fordulata a maximumig... Opto kapu még nincsen hozzá, de tervben van az is...
-
fpeter84
senior tag
"de(!) a giro-nak is van slip-je, amit meg gyorsulasmerovel szoktak kompenzalni, ami eleg bonyolult, szoval, hobbistaknak a legegyszerubb a compass."
A compass önmagában szintén nem elég... Amíg tökéletesen függőlegesen fix pozícióban forgatod a Z tengelye körül addig elméletben oké lenne, de a legkisebb elmozdulás is felborítja a működését, ezért a jó e-compass-nak szüksége van egy gyorsulásérzékelőre és egy giroszkópra is! Szerencsére egyetlen csippben meg lehet kapni, nekem eddig az MPU-9250 vált be a legjobban RTIMULib-Arduino lib-el...
(azóta hogy próbáltam már van RTIMULib2 is, ezzel nincsen tapsztalatom)Előbbre próbáltam mindenféle kombókat, lib-eket és kész modulokat de minddel szívtam - alapból bekalibrálva mintha jó lenne, de kis döntögetés és már meg is bolondul az egész vagy elkezd magától lassan körbeforogni. Az MPU-9250 a fenti libbel viszont stabilan teszi a dolgát...
Jó is hogy feljött ez a téma, nekem is van egy ilyen 4WD szettem. Van hozzá joystick shield is színes LCD-vel, master-slave kékfog modul páros, L9110-es 4 csatornás motor driver, stb. Már csak kis idő és ihlet kellene hozzá
-
fpeter84
senior tag
Nagy valószínűséggel az lesz a problémád, hogy hiába rajzolsz egymásra körről körre különböző méretű téglalapokat, attól még a régi is ott marad - ami ha "magasabb" mint a következő, akkor természetesen a kijelzőn az előző fog látszani. Vagy minden újrarajzolást egy clear-el kell kezdened - de ettől lehet vibrálós lesz a kép - vagy egy a háttérrel azonos színű téglalappal "le kell törölni" a túllógást. Ha az oszlopdiagrammod háttere nem egyszínű hanem pl osztásos, akkor persze még összetettebb matekozást kell csinálnod hozzá...
-
fpeter84
senior tag
Nem is igazán értem, hogy miért ilyen ESP-01 minimál modult kezdtél el átgányolni - megölhetted magával a forrasztással is, vagy amiket írtál extrém tápfeszek is megárthattak neki, ha esetleg méregettél rajta multiméter ellenállás/szakadásvizsgáló móddal, attól is megsérülhetett... Mindenképpen valamelyik nagyobb modullal állnék neki a helyedben mint az említett 07, 12, vagy akár ez...
2 AA elem alapból is alig bő 3V-ot ad, de ahogy merülnek hamar úgy leesik hogy biztosan az is stabilitási gondokat okoz! Olvass utána az elemek merülési karakterisztikájának, nagyon nem ideális ez így. Ellenben ha fogsz egy Li-Ion vagy Li-Po cellát és azt rákötöd a fenti D1-es 5V lábára, vagy a 07/12 előtt lévő low-drop LDO-ra, akkor azzal jól el kell lennie. A cellát pedig töltheted egy filléres TP4056 modullal (fontos, ha a cellában nincsen belső védelem akkor azt a modult keresd amin ott van mellette a DW01 chip is)
-
fpeter84
senior tag
Egy MAX7219 összesen 8 szegmenst (7+1 pont) és 8 karaktert képes megvezérelni, tehát 1 IC elég lenne a céljaidnak... A DIG 0..7 lábak mennek a kijelző karakterek common-cathode lábaira, a SEG 0..7 pedig a szegmenseket hajtja párhuzamosan kötve...
Viszont ennyit vezetékezni nettó önszivatás, ha alig tobb mint 1$-ért megkapod készen is amit már csak be kell kötni és programozni... [link]
-
fpeter84
senior tag
És tényleg, ez a legegyszerűbb megoldás, kész modulként is kapható akár kijelzővel együtt...
Valamiért nem találtam rá pár gyors kereséssel, ezért írtam a másik alternatívákat... Csak ahogy nézem elég átabotán forrasztják rá a kijelzőket, azzal lehet lesz még egy kis utómunka, dehát ezért óccó, nem dlága 
-
fpeter84
senior tag
-
fpeter84
senior tag
válasz
Akos_512
#4427
üzenetére
Én pont most alapozok rá egy hasonló projektet, kifogástalanul működik a GPRS és GPS része (hangot, SMS-t nem próbáltam még) - csak nem teljesen meglepő módon a kínai doksik nem tökéletesek
- a RST nem resetel hanem kikapcsolja a modult, és ha nem húzom fel a lábat VBAT-ra egy nagyobb ellenállással akkor megbízhatatlan
- a PWR_KEY csak bekapcsolja, ki nem - arra a RST-et lehet használni, tehát min 2 GPIO kell hozzá
- az INT alvó módja mintha nem működne, nekem csak a soroson nem reagál többé, de fel sem éled reset nélkül és fogyaszt addig is. Szoftverből ki lehet kapcsolni/altatni, de akkor a PWR_KEY kell az élesztéshez.A fentiekkel együttélve/tervezve tökéletesen megbízhatóan teszi a dolgát instabil táp mellett is. Nálam egy TP4056-os töltő etet egy kis akkut, és erről megy a modem is, tehát a tápfesze össze vissza ingadozik akár 3.5-4.2V között ha merül/töltőre dugom és ezt is bírja.
Amit hiányolok a GPS-nél az a konfigurálhatóság. Konkrétan semmit nem lehet állítani, 1Hz-en 9600 bauddal küldi ha aktiválom és a sortípusok közül se lehet kitiltani a feleslegeseket. A fő AT porton keresztül is lehet nézni a GPS-t, de az nem az igazi, mert aktiválva 1Hz-en automatikusan belehányja ugyanazokat az NMEA sorokat a kommunikációba, és ez gondokat okozhat a modemmel való kommunikációban - nem egyszerű olyan kezelő rutinokat írni, amelyek tolerálják ezt, nyilván nem is lehetetlen azért. Mindenesetre jobban örülnék, ha nem csak ilyen automata behányós módja lenne, hanem olyan is amikor egy adott AT kérdésre 1x válaszol egy legutóbbi valid NMEA információval és annyi, azt jobban lehetne kontrollálni hogy mikor fér bele a kommunikációba az is. Addig amíg ezt nem oldják meg, addig én egy második sorosporton olvasom inkább a GPS-t függetlenül a fő AT porttól...
ESP-hez láttam valami A6 lib-et (ami a modem részéhez használható lenne) de ez is meg a többi is jellemzően mind soft UART-ot használ, ami nekem nagyon nem szimpatikus megoldás, plussz azokon belül a megvalósítás/hibakezelés se feleltek meg az igényeimnek, ezért végül saját lib írására adtam a fejem, ami bármivel kompatibilis lehet amin van több UART - én STM32 maple mini klónnal hajtom...
Szóval mindent összevetve tudom ajánlani az A7-et - lévén hogy a SIM és egyéb modemekhez sincsen out-of-box értelmes lib, így azoknak sincsen különösebb előnye - az A7 pedig tényleg nevetségesen olcsó és egyszerre GPS vevő is...
-
fpeter84
senior tag
válasz
Teasüti
#4362
üzenetére
Szerintem tömör fémtestnél ezt nem nagyon fogod tudni érzékelni... Viszont ha a touch-os fényerőszabályzás a célod, akkor nézz utána az SGL8022 célcsippnek. Nekem pont a napokban hozott egy marékkal a ződmikulás. Ki még nem próbáltam, de youtubeon lehet találni csomó videót amin látszik a viselkedése a különböző program módjaiban...
-
fpeter84
senior tag
Lévén hogy nem atomreaktor vezérlésről van szó, nem hiszem hogy ez olyan nagy probléma lenne
De mechanikai megvalósíthatóság / tartósság szempontjából nekem a pedál által rugón keresztül taposott load cell tűnik a legjobb megoldásnak. Koszolódás, oxidálódás, kopás nagyjából kizárva, talán egy kis hőfüggősége lehet de gondolom úgyis szobában lesz minimális hőingadozás mellett, a potinál ez is nagyobb gond. A rugó és a load cell méretezésével nyilván kicsit kísérletezni kell, de egy ilyen érzékelő ebay/aliról alig pár $, hozzá egy HX711 ami alapból 80Hz, a datasheet határáig kihajtva úgy 144Hz-et tud az már szintén bőven elég feldolgozási sebességet nyújthat...
-
fpeter84
senior tag
pár kövérebb kondival ez nem hiszem hogy akkora probléma lenne - lévén hogy külső AREF nélkül meg magát az 5V analóg tápfeszt használja egy ilyen AVR referenciapontnak...
(van belső Vref is az említett 32U4-ben, de az meg csak fix 1.1V-ot tud). Mellesleg a műverősítős megoldás is pontosan ugyanolyan tápfesz érzékeny, tehát rendesen ki kell simítani...a 32U4 a micro-n egyébként "csak" 10 bites ADC-t tud, ezt is bele kell számolni. Alternatíva lehet pl egy Due (csak az méretesebb és drágább) mert ez 12 bites ADC-vel rendelkezik és ezt megfejeli egy programozható gain (PGA-t kell keresni a SAM3X doksiban) amivel 1/2/4-es szorzót lehet a bemenő fesznek adni, ezáltal 3.3V tápfesz mellett 0-1.65 vagy 0-0.825V-ra lehet csökkenteni az értékes tartományát. Másik alternatíva lehet sok más mellett (ami Arduino IDE kompatibilis) az STM32, amiből ugyan a maple clone minimal board nem elég mert azon nincsen AREF+ és a VDDA is fixen a tápra van húzva, de valamelyik "nagyobb" tesó klón boardon biztosan van AREF láb is. Vagy ugyan OFF, de a Microchip PIC családban dolgoztam már több olyan kontrollerrel is amiben van szélesebb skálán programozható belső Vref és/vagy integrált műverősítő funkció. Mikroe IDE-vel pedig az USB HID eszközként élesztés is könnyű pl (csak ezekhez programozó hardver is kell, ami 8$+)
-
fpeter84
senior tag
válasz
gyapo11
#4336
üzenetére
a műverősítős bűvészkedésnél akkor már jóval egyszerűbb egy mezei feszosztóval belőni az AREF lábat a tápfeszre kötött potiból max állásban kijövő fesz fölé egy hajszállal - illetve az nem derül ki hogy milyen prociról is van szó, van amelyikben van 1/több beépített szoftverből állítható analóg referencia érték is
-
fpeter84
senior tag
Igen, vagy a poti tápfeszével tudsz játszani, vagy az AREF bemenetét húzhatod lefelé a mikrokontrollernek, vagy olyan ADC-t hasznáhatsz aminek annyira nagy a felbontása hogy a megmaradó tartományban is jó marad. A mechanikus áttételt sorolnám legutolsó megoldásnak, mert macerás megoldani, holtjátékot növel, stb...
-
fpeter84
senior tag
A jó öreg win-es paint-nél jobbat erre nem tudok a mai napig - ha tényleg pixelről pixelre akar menni az ember, messze ez a legkényelmesebb szerintem. A legjobb a régi XP-s verzió volt, a 7/10 alatti már kicsit túl "modern" de még az is jó...
A gombos problémára: lehet hogy addig nem inicializálja az érintőkijelző könyvtárat, és valójában ez borítja meg a technikát? Milyen hardverekről beszélünk egyáltalán? Lehet hogy a programozó lábait próbálja meg pont használni a lib...
-
fpeter84
senior tag
Én PIC-el építettem annó olyan lejátszót, ami tetszőleges hosszú wav-ot tudott lejátszani valami 30KHz mintavételezési frekvencia @ ~12-13bit mono minőségben SD kártyáról. Nem a csodák csodája, nyilván nem zenehallgatásra való, de az emberi beszéd tökéletesen érthetően "tisztán" szólt rajta. Ha nem is a 328-assal, de valamelyik ARM-al (Due,STM32) simán megoldható lenne. (A 328 órajele, feldolgozási tempója valszeg csak számottevően gyengébb minőségre lenne elegendő, ami már tényleg torznak hangzik)
szerk: nem kell hozzá DAC csipp, csak 2 PWM csatornával és pár passzív alkatrésszel megoldható. Erősítő kellhet mögé, vagy egy aktív PC-s hangszóró...
-
fpeter84
senior tag
Azért olyan drága az adafruit, sparkfun, stb, mert egyrészt erőforrásokat fektetnek (nyugati tarifával) a terméktámogatásba, másrészt baromira pénzéhesek
Nyugodtan vedd a töredék árú kínai breakout verziókat, ugyanolyan tökéletes lesz. Nekem most hozott a postás pont párat az emlegetett DS3231 csippesből - igen, ennyi az ára, szállítással együtt, csak elemet kell bele rakni
Ha szoftveres kompatibilitás miatt tényleg a DS1307 kell, akkor olyat is találsz bagóért, csak a DS3231 stabilabb, okosabb és nem csak 5V-ról üzemeltethető...
-
fpeter84
senior tag
válasz
Teasüti
#4246
üzenetére
ez nekem egy mezei eljárásnak tűnik...
void valami()
{
lcd.setCursor(0, 1);
lcd.write(byte(2));
lcd.setCursor(2, 1);
}
...
case 30: //LED max brightness
lcd.print(F("Max brightness:"));
valami();
lcd.print(Bmax);
break;
case 31: //LED min brightness
lcd.print(F("Min brightness:"));
valami();
lcd.print(Bmin);
break; -
fpeter84
senior tag
válasz
Teasüti
#4238
üzenetére
Ezt az I2C vagy RTC problémára érted? I2C-nél próbálkoztam a HardWire-el is, ugyanúgy viselkedett... RTC ügyben nem igazán látom értelmét mást vadászni, mert túl egyértelműen a gyári kvarc a bűnös... Félretettem a leműtött kvarcot és majd próbálgatom még ha lesz rá időm, akár teljesen idegen procira kötve is, illetve van még pár ugyanilyen STM32 mini boardom is, azokat is majd megkínálom hajszárítóval hogy hogyan viselkednek
-
fpeter84
senior tag
2 újabb "érdekesség" STM32 ügyben...
Az STM32F103C és az Arduino IDE kapcsolatáról: nyákegyszerűsítés okán a default PB6-7-en lévő default I2C1 helyett a PB8-9-re kötöttem egy LM75-öst - gondoltam ott az I2C1_REMAP regiszter, majd átbököm inicializálás előtt. Ha megteszem, jéggé fagy a Wire.begin()-nél a proci...
Újabb drótgány a nyákon, köthettem keresztbe a funkciókat, még jó hogy nem drágán gyártatott nyák csak itthoni lézernyomtatós-vasalós fajta...A másik talán még durvább a kínai mini STM32 board kapcsán: feltűnt, hogy fél nap ketyegés után 5 perccel le van maradva az óra. Aztán amikor radiátorra tettem az LM75 tesztelésekor, az RTC alapján másodperces ütemet villogó led periódusa felment vagy 1.5-2mp-re...
Nem tudom, hogy csak ez a példány ennyire peches e, vagy az összes ilyen boardra szemét kvarcot (vagy annak látszó izét) tettek e a kínaiak, de ennek brutális a hőfüggősége... Lecseréltem egy fémkapszulás 32.768KHz-es kvarcra, és azóta pontosnak tűnik... -
fpeter84
senior tag
STLink-em van, azzal programozom. Próbáltam soroson is, de meguntam a macerát hogy ide-oda kell tenni a jumpereket és vettem hozzá programozót.
Azthiszem Janos250 #4191 és a Te hsz-ed rávilágít a problémámra: ha az IDE-ben a programozási módot sorosra tesszük, akkor letiltja a JTAG-ot valamint az USB-t és GPIO módba kerülnek a lábai. Ha viszont az STLink módot választjuk, akkor az összes JTAG-hoz köthető lábat elkapcsolja a GPIO módról (azt is amit egyébként nem használ a programozó), valamint itt találtam rá utalást hogy ekkor az USB-t is inicializálja valamennyire akkor is ha én nem teszem meg a programomban, így azok a lábak is átállítódnak. A futó programból regisztereket kapcsolgatva valószínűleg helyre lehetne tenni - elvileg ahogy nézem, a JTAG szabad lábait egyesével is vissza lehetne állítani, így talán működne az STLink és, meg a GPIO-k is. De végül nem húzhattam már az időt, átdrótoztam a PB5-6-7-re a vezérlést, így működik, tudok haladni.
Mindenesetre jó tanulság, hogy nyákgyártás előtt próbapados szakaszban alaposabban kell tesztelni a konkrét lábakat, és nem cserélgetni utólag a funkciókat
Amikor megjött az STLink, akkor ugyan felraktam a Keil-t mert kíváncsi voltam a realtime belső debugra, de valahogy nem kapott el a gépszíj - már túlzottan hozzászoktam ahhoz hogy megoldom a debugot sorosporton... A jövőben lehet adok még neki esélyt, de egyelőre az Arduino IDE hatalmas támogatottsága nagy előny, és haladnom kell a projektekkel, nem tölthetek időt azzal hogy még a környezettel is ismerkednem kelljen...
Néhánnyal lejjebb volt egy sleepmode-al kapcsolatos kérdésem - esetleg abban van tapasztalatod? Miért van az, hogy az összes példaprogram/library kizárja a loop-ot, a setup végén meghívja az alvást, és trigger esetén mindig újraindul a program. Olyat nem is tud, vagy csak nem találtam még, hogy onnan folytatódik a program ahol fel lett függesztve?
Az eddigieket köszönöm, a jövőben talán segít elkerülni az ilyen fél napos szívásokat
-
fpeter84
senior tag
Sziasztok ismét!
Segítsetek rajtam plz, bajban vagyok egy STM32F103C8T6 kínai minimal board-al...
"deszkamodell" formájában jól működött a kapcsolásom - bár akkor még más PB lábakat használtam kimenetnek, és tették is a dolgukat ahogy kell. Aztán terveztem egy saját nyákot alá, ahol célszerű volt az adott lábakat másikakra cserélni, így most a PA11, PA12, PA15-nek kellene vezérelnie egy külső eszközt (ki/bekapcs, reset, int), de meg se mozdulnak, hiába kapcsolom őket OUTPUT-ra és változtatom az értéküket... A végén visszanyúltam a "hello world" LED villogtatásig, hátha valami részegységet incializálik ami lefogja ezeket a lábakat a háttérben, de erről sincsen szó, már ez a kapcsolás sem képes a fenti PA lábakat megmozdítani
#define LED PC13
#define gprs_rst PA11
#define gprs_pwr PA12
#define gprs_int PA15
void setup() {
pinMode(LED, OUTPUT);
pinMode(gprs_rst, OUTPUT);
pinMode(gprs_pwr, OUTPUT);
pinMode(gprs_int, OUTPUT);
}
void loop() {
digitalWrite(LED, HIGH); // turn the LED on (HIGH is the voltage level)
digitalWrite(gprs_rst, HIGH);
digitalWrite(gprs_pwr, HIGH);
digitalWrite(gprs_int, HIGH);
delay(1000); // wait for a second
digitalWrite(LED, LOW); // turn the LED off by making the voltage LOW
digitalWrite(gprs_rst, LOW);
digitalWrite(gprs_pwr, LOW);
digitalWrite(gprs_int, LOW);
delay(1000); // wait for a second
}Próbáltam turkálni a doksiját a procinak, és ami feltűnt, hogy a PA11, PA12-n az USB is, de elvileg a "main function after reset" az a GPIO módjuk lenne. A PA15 pedig a JTAG sor része, és a GPIO csak alternatív funckió. Tovább puhatolóztam, és kiderült hogy a szintén JTAG-hoz társított PB3 és PB4 is döglöttnek mutatja magát, és a legközelebbi 3-as amit szépen kapcsolgat a fenti példaprogram az a PB5, PB6, PB7...
Hiányzik valami lépés amitől GPIO módba váltanak ezek a lábak? A nyák már készen van, nem szívesen kezdenék "léggányolásba" ha szoftverből is helyrebillenthető a dolog...
-
fpeter84
senior tag
Sziasztok! STM32-n használ valaki sleep módot? Ahány projektet/library-t találok, minddel ugyanaz a bajom: valójában úgytűnik hogy egyik sem altatja, hanem inkább kikapcsolja teljesen a procit és visszatéréskor újraindul a program. Nekem arra lenne szükségem hogy meghívva elaludjon, a WKUP pin felhúzásakor pedig onnan folytassa a program a futását ahol fel lett függesztve. Most valamit én értelmezek nagyon félre, vagy hol lehet a probléma? Valaki használja olyan módon ahogy én leírtam?
-
fpeter84
senior tag
A LED-nek erőteljes a fénye vagy csak pislákol? Ha utóbbi akkor rövidzárlatra tippelnék, ha nem akkor valami mással akasztja meg a kontrollert... Nézd át az egészet, hogy valahol nem látsz e megfolyt ónt a lábak között...
Tápot USB-ről kap vagy külső tápról? Utóbbit mindenképpen érdemes kipróbálni, hátha csak nem bírja a portod...
-
fpeter84
senior tag
válasz
gyapo11
#3141
üzenetére
Csak ugye ha egyszer azt mondtad hogy megjött, akkor neki joga van azt mondani hogy küldjed vissza - ezt mondjuk baromságnak tartom az ebay és ali részéről, ha valami nem felel meg a leírásnak akkor azt automatikusan ugyanabba a kategóriába kellene sorolniuk, mint a meg nem érkezettek... Szóval értékfüggően kezelem az ilyen helyzeteket, meg hogy tulképp mennyire is kamuzott az eladó - tudatos lehet a dolog vagy véletlen. Van olyan szitu, amikor egyértelműen tudatosan kamuzik, jobbnak tünteti fel az áruját mint ami, a drágább cucc/konfig helyett az olcsóbb belsejűt küldi, vagy átverős memkártya, pendrive stb... De tény hogy a sokszáz vásárlásom alatt elég ritkán futottam ilyen szituációba, meg kell tanulni olvasni a sorok között, feedbackselector-t használni, olyantól vásárolni akin látszik hogy nem akar negatívot gyűjteni tehát ha szabályosan panaszkodok akkor korrektül fog eljárni, stb...
Az az akku valszeg nem akku, hanem mezei szárazelem volt direkt átverésre gyártva - nekem is volt ilyenem. Meg olyan USB hub is, amin valójában nem volt chip csak valami kamu csepp és a vezetékek simán csak körbejárták a 4 aljzatot, gyakorlatilag csak egy "hosszabbító" volt kifejezetten átverésre gyártva...
-
#3139
fpeter84
senior tag
Daszkalosz19
#3138
fpeter84
senior tag
válasz
Daszkalosz19
#3138
üzenetére
ha kamuzott az eladó és tracking nélkül jött, akkor ez az a szituáció amikor azt mondom hogy nem érkezett meg, refund
egyébként az elcsúszásra: felbontás esetleg rosszul definiálva? Még az is lehet hogy más a felbontása mint aminek hirdették, pár standard értékkel érdemes próbálkozni hogy miként befolyásolja a viselkedését...
-
fpeter84
senior tag
válasz
Janos250
#3108
üzenetére
Aki itthon készletez az maga kockáztatja a vámot, ha ipari mennyiségben tolja akkor talán számlát is ad róla és áfát fizet, plusz az itthoni postaköltség - így már annyira nem nagy csoda az ára. 99%-ban én is kínából rendelem a dolgaimat, csak azért írtam hogy nem zárom ki az ilyeneket mert időnként jöhet jól ha 1-2-3 nap alatt megkapom amire szükségem van...
eBay esetén a Paypal-ban, Ali esetén az AliPay rendszerében kell megbíznod, nekik kell kiadnod a kártyaadataidat, de maga a kereskedő egyik esetben sem lát belőled többet egy email címnél. Annyi, hogy az Ali buyer protection picit gyengébb mint az eBay-é. Utóbbi nagyon automatikusan a vásárló javára dönt ha pl nincsen tracking és elveszik valami, és nem csinálod ezt notóriusan minden második csomaggal. Ali-n picit többet kell focizni, tovább húzhatja az időt az eladó, gyakoribb a tracking - bár az utóbbi időben már ez sem igaz annyira. Ráadásul Ali-n egyre gyakoribb a fake tracking, amilyen esetben fogalmam sincsen hogy hogyan kezelné a problémás helyzetet a staff. Pár év alatt 3-400 vásárlás és sokezer $ elköltése után is abszolút megbízhatónak tartom mindkét rendszert, csak tudni kell kiszűrni a potenciális csalókat: feltűnően sokkal olcsóbb mint az átlag, kezdő user (kínainál a 100 alatti eladás), nem 98-99%-os minősítés, stb...
-
fpeter84
senior tag
-
fpeter84
senior tag
válasz
Teasüti
#3066
üzenetére
Az ilyen új dolgokat (timer, egyéb IRQ) egyébként ne egy meglévő programon belül próbálgasd, hanem nyiss egy új hello world projektet, amivel mondjuk egy ledet villogtatsz, vagy ha van oszcilloszkópod akkor azzal nézheted a lábat - kizárandó az egyéb hibákból, összakadásokból adódó helyzeteket
-
fpeter84
senior tag
válasz
Teasüti
#3064
üzenetére
Van IRQ/INT lába a modulnak? Lehet programozni kell, lehet alapból is így viselkedik, de azzal tud szólni hogy van kész kiolvasható adata. A kis UNO-nak szerintem túlzás az 1KHz+matekozás, vedd vissza alacsonyabbra és timer IRQ helyett menjél rá a pin change IRQ témára!
-
fpeter84
senior tag
válasz
Teasüti
#3057
üzenetére
Egyébként valóban, sokszor egy 40-50$-os tablet lehet a legjobb megoldás a GUI megjelenítésre
A kékfog viselkedése meg majd kiderül a gyakorlatban, keress rá blogokat, tutorialokat - lehet minden írás után le kell húzni a resetet? Akkor az úgy elég macerás, annyi erővel már a kézi resetgomb megnyomás se problémásabb...
-
#3060
fpeter84
senior tag
norbert1998
#3059
fpeter84
senior tag
válasz
norbert1998
#3059
üzenetére
Feltéve hogy egy időben csak 1 motor mozog... A 12V 1.5-2A (18-24W/db) azért rendesen meg tud már rántani egy kicentizett tápot, hát még ha ez 3x... És itt nyilván fontos a precíz kiszámítható mozgás aminek elengedhetetlen feltétele a stabil táp... A PC táp szerintem teljesen jó kiindulási alap hozzá - megfelelő lábait összecsukva be lehet indítani alaplap nélkül - én is ilyet használnék első körben, aztán maximum ha később a kompaktabb kivitel lenne a cél akkor néznék hozzá kínából valamit...
-
fpeter84
senior tag
válasz
Teasüti
#3052
üzenetére
A HMI nem más, mint egy tetszőleges mikrokontrollerrel és szoftverrel ellátott LCD, ami fogadja a parancsokat, SD kártyáról vagy USB mass storage-ről beolvasva a hozzá a dolgokat... Tehát ezt akár Te is meg tudod csinálni egy megfelelő LCD-vel és Due/Mega/STM stb platformmal...
A megfelelőt azért írom, mert egy fontos dologra oda kell figyelni: ilyen kisebb mikrokontrollerrel csakis (ez nem teljesen igaz, de nem kezdő projekt) olyan panelt lehet közvetlenül meghajtani, aminek van saját framebuffere, és nem kell fix időzítéssel másodpercenként x alkalommal ráküldeni a képet, csak tetszőleges sebességgel adhatod neki a parancsokat és adatokat valamilyen buszrendszeren keresztül, ő meg majd frissítgeti maga a panelt a fb-ből.
Ami automatikusan kizárható, az az LVDS bemenetes panelek, valamint a párhuzamos RGB bemenettel rendelkezőek közül azok, amelyeknek Hsync Vsync bemenetei vannak. Sajnos a nagyobb LCD panelek mind ilyenek, ezek kiesnek. Ha ilyet akarsz akkor ne uC-t használj hanem valami fejlettebb platformot mint egy RPi, BPi, stb... Természetesen a VGA és HDMI bemenetes komplett szettek is ide tartoznak...
Ami használható uC-vel is, azok lehetnek sokvezetékes parallel RGB bemenetűek, de a H/Vsync helyett RS (utasítás/adat), RW (olvasás/írás), reset lábai lesznek. Ezeket általában meg lehet hajtani 8, 16, 18 stb adatláb + a fenti vezérlőlábakkal. Ezenfelül lehet SPI/I2C is. A 2-5" (meg pár nagyobb is akad) kategóriában sok panel akár mindhárom meghajtási típust is támogatja - legalábbis a vezérlője, mert van ahol fixre van drótozva valamelyik funkció, erre oda kell még figyelni, de van ahol megadják a lehetőséget pár tüskére rakott láb vagy átrakható SMD ellenállással a választásra...
-
fpeter84
senior tag
válasz
Teasüti
#3049
üzenetére
A SoftSerial-t tényleg jól elfelejtettem
De csak egyszerűbb ha van a kéznél USB soros és nem kell alakítgatni semmit...Vagy egy mega/due/nagyobb stm32 board lehet a megoldás jó sok lábbal, vagy egy SPI/I2C-n is vezérelhető típus... Mi lenne az igény? Ha érintős, akkor gondolom színes LCD, nem monokróm karakteres/pixeles vagy kicsi OLED. De mekkora kb?
-
fpeter84
senior tag
válasz
Janos250
#3044
üzenetére
Van itthon jópár mindenféléből, és többnyire nem volt velük gondom: FT232, PL2303, CP2102, CH340g, valami ASIX/Moschip is van aminek nem rémlik a pontos típusa - kivéve pont az FT232-vel, jobban mondva a kínai klónjával ami ránézésre és regisztereit tekintve is 100% ugynanaz, viszont időnként - talán instabil tápra? - hajlamos elfelejteni az USB ID-jét, full 0000 lesz mindkét azonosítója és nem tud vele mit kezdeni a driver. Javítható, az FTDI-től valami EEPROM programozó eszközzel helyre lehet tenni. Továbbá a PL2303-nak van olyan szépséhibája - feltehetően abból is van kínai klónom is - hogy az új driver kiköpi őket, amivel a win10 élesztené. Le kell tölteni hozzá valami sok sok éves őskövület drivert és azzal atomstabilan teszi a dolgát...
Valamiért nem találtam rá pár gyors kereséssel, ezért írtam a másik alternatívákat... Csak ahogy nézem elég átabotán forrasztják rá a kijelzőket, azzal lehet lesz még egy kis utómunka, dehát ezért óccó, nem dlága 
Újabb drótgány a nyákon, köthettem keresztbe a funkciókat, még jó hogy nem drágán gyártatott nyák csak itthoni lézernyomtatós-vasalós fajta...
Nem tudom, hogy csak ez a példány ennyire peches e, vagy az összes ilyen boardra szemét kvarcot (vagy annak látszó izét) tettek e a kínaiak, de ennek brutális a hőfüggősége... Lecseréltem egy fémkapszulás 32.768KHz-es kvarcra, és azóta pontosnak tűnik...
Új hozzászólás Aktív témák
Hirdetés
ekkold
- Topping D30 Pro (ezüst) eladó
- ! AMD Brutál Gamer Konfig ! 9800X3D / 7900XTX ( RITKASÁG ) 32Gb RAM 32Colos ROG Monitor
- Gamer Billentyűzet Akció ! Steelseries, Razer, Logitech, Corsair - Számlával, Garanciával, Ár alatt!
- Újszerű Lenovo,15,6"FullHd IPS,Ryzen 5(8x3,7Ghz)VEGA 8 VGA,12-20GB RAM,SSD+HDD
- Hálózati rendszermérnök és IT rendszerüzemeltetés
- AKCIÓ! nVidia Quadro P4000 8GB GDDR5 videokártya garanciával hibátlan működéssel
- Alkatrészt cserélnél vagy bővítenél? Nálunk van, ami kell! Enterprise alkatrészek ITT
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- Napi 700 ft tól elvihető RÉSZLETRE BANKMENTES HP 840 G11 Ultra 5
- Telefon felvásárlás!! Apple Watch Series 6/Apple Watch Series 7/Apple Watch Series 8
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest