-
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
Sziasztok!
Egy 128x32-es SSD1306 OLED kijelzőt szeretnék meghajtani - és nem pl az Adafruit vagy U8glib-el, mert ezek rettentően sok programterületet igényelnek, én meg szeretném egy 4KB-os 8 lábú mikrokontrollerrel megoldani a feladatot... Rátaláltam a tinyOLED lib-re amivel reálisnak tűnik az elképzelés, viszont valami érthetetlen számomra: a fontok programterületre beírása és visszaolvasása! szeretnék definiálni egy custom celsiusfok szimbólumot - nyilván a kis "c" betűből próbálnék kiindulni, de akár a 6x8, akár a 8x16 fontkészletet nézem, értelmezhetetlen számomra hogy miért úgy épülnek fel ahogy:
0x00, 0x38, 0x44, 0x44, 0x44, 0x20, // c 6x8
0x00 ........
0x38 ..111...
0x44 .1...1..
0x44 .1...1..
0x44 .1...1..
0x20 ..1.....
0x00, 0x00, 0x00, 0x80, 0x80, 0x80, 0x00, 0x00, 0x00, 0x0E, 0x11, 0x20, 0x20, 0x20, 0x11, 0x00, // c 8x16
0x00 ........
0x00 ........
0x00 ........
0x80 1.......
0x80 1.......
0x80 1.......
0x00 ........
0x00 ........
0x00 ........
0x0E ....111.
0x11 ...1...1
0x20 ..1.....
0x20 ..1.....
0x20 ..1.....
0x11 ...1...1
0x00 ........
A 6x8-nál már magát a formát se tudom teljesen értelmezni - ebből hogy lesz egy szépen megjelenő egészséges kis "c"? de a 8x16-os is hasonlóan zavaros - belelátom a szép "c" formát, kivéve hogy a karima alsó íve nem a helyén van hanem függőlegesen elfordítva felette... de miért? most a 8x16 lenne a cél, ha az működik már elégedett lennék teljesen... nézegetem a kiirató programkód részletet - tinyOLED.cpp 230-dik sorától és nem látom hogy ott a byte-ok sorban kiküldésében lenne valami elforgatási trükk: az SSD1306 felépítése miatt két 8 pixeles oszlop formájában kell kiszórni a 16 pixeles oszlopokat - ezt látom is, mindkettőnél egy for ciklus elszámol 0-tól 7-ig, és a ci * 16 + i valamint ci * 16 + i + 8 lefelé eltolt területet kiiratja
megnéztem a nagy "C" párját is, az még annyira sem értelmezhető számomra hogy hogyan épül fel...
0xC0,0x30,0x08,0x08,0x08,0x08,0x38,0x00,0x07,0x18,0x20,0x20,0x20,0x10,0x08,0x00, // C 8x160xC0 11......
0x30 ..11....
0x08 ....1...
0x08 ....1...
0x08 ....1...
0x08 ....1...
0x38 ..111...
0x00 ........
0x07 .....111
0x18 ...11...
0x20 ..1.....
0x20 ..1.....
0x20 ..1.....
0x10 ...1....
0x08 ....1...
0x00 ........
Valaki fel tudna homályosítani hogy ezek a dolgok hogyan is működnek?
-
fpeter84
senior tag
válasz
Tomika86
#20365
üzenetére
melyik generáció, ott már ki van vezetve valamelyik canbus az obd csatira? mert A6 C5-nél még nincsen... a diagnosztika csak K és L-en éri el, a 3-4 canbus hálózat csak belső használatra van a különböző vezérlők között. no ebbe másztam bele a műszerfal mögött, mert az a gateway, ott összefut minden - csináltam Y leágaztató kábeleket így mindenhez hozzáférek. találtam egy német nyelvű pdf-et az EDC15P vezérlőről, abból próbálok google translate-el minél többet megérteni, illetve azon túl is sokmindent lehet találni guglizva. elég sok információ megtalálható rajta...
-
fpeter84
senior tag
válasz
Janos250
#20354
üzenetére
éppen turkálom egy A6 C5 canbus hálózatait (elsősorban a powertrain vonalat), térképezgetem fel hogy milyen adatokat tudok onnan kinyerni, és azon agyaltam hogy hogyan lehetne a legjobban megjeleníteni őket, ha valami kis LCD-nél többet akarok? saját program windows-os tableten/laptopon? vb6 és delphi7 amivel utoljára játszottam...
vagy androidos program a fejegységen? ahhoz se konyítok, eddig a MIT app inventor volt a legmagasabb szint, de abban agyhalál lenne ennyi mindent össze puzzle-özni... ekkor jutott eszembe, hogy mi lenne ha egy ELM327-et emulálva a droidos Torque jelenítené meg a dolgokat? elkezdtem guglizni hogy hogyan is néz ki a protokoll, mi lenne a minimum amivel át tudnám verni az app-ot, erre belefutottam ebbe a szuper kis projektbe... Nano+HC06 BT adapterrel működött is pöcc-röff, de mivel a canbus-ról összeszedett adatokból szeretném etetni, a legkézenfekvőbb az lenne ha a natív BT-s és CAN-es ESP32-vel menne, esetleg a 2 CAN miatt a DUE+HC06... de sajnos sosem álltak össze a fejemben igazán tökéletesen ezek az objektum-orientált dolgok, csak totózok kísérletezek aztán van amikor sikerül ráérezni, de most sehogy sem akar menni... -
fpeter84
senior tag
Sziasztok!
Tudna valaki segíteni abban, hogy ezt a motorvezérlő+ELM327 emulátor lib-et hogyan tudnám átültetni hardveres sorosportra? Eredeti formájában Nano-val softserial-al működik, de szeretném vagy egy Due-n használni aminek van 2 CAN-je is, vagy esetleg ESP32-n a belső kékfoggal és CAN-el...
Amivel eddig próbálkoztam: OBDSerialComm.h -ban a 65-dik sorban lévő softserial sort lecseréltem erre: HardwareSerial *serial; valamint az OBDSerialComm.cpp -ben az 5-8 sorokat felcseréltem erre:
setBaudRate(9600);
// serial = new HardwareSerial();
serial->begin(9600);
serial->setTimeout(SERIAL_READ_TIMEOUT);
Valamint az #include után beszúrtam még egy HardwareSerial & serial = Serial1; -t... De arra nem tudok rájönni, hogy a serial=new... sorral mit kellene kezdeni - HardwareSerial()-al nem eszi meg. így fagy a vas, még egy Hello World kiiratásáig se jut el rögtön a setup elején...
Próbálkoztam egy olyan verzióval is, hogy a .h-ból teljesen kikommenteltem a 65-ös sort (nem próbáltam átírni) és helyette ez lett a .cpp-ben: [link] a módosított sorok végére // ### jelölést tettem hogy meg lehessen találni... Ezzel a módosítással lefordul a példa .ino, de nem reagál a kékfog adapterről érkező kérésekre. Természetesen a kapcsolás működik, serial passthrough kóddal látom ahogy a Torque próbál kérdezgetni az ELM-től az AT parancsokkal...
Ha valaki nagyon unatkozik, bele tudna nézni hogy hogyan lehetne feléleszteni?
-
-
fpeter84
senior tag
talált egy centire pontosan ugyanolyan Mega-t is a cimborám, neki feltölti arra is a kódot az alma... próbáltam vmware-ben futó ubuntu alól, az is pontosan ugyanúgy elakad 88%-nál mindig, pedig még az avrdude.conf-ot is megpróbáltuk átmásolni az ő alma gépéről, az ő általa fordított hex-et feltölteni az én gépemen futó ubuntuval megírni... [link] lehet mégiscsak az én vasamnak lesz valami kehe, csak akkor a 10x akkora programot miért tölti fel és futtatja jól?
-
fpeter84
senior tag
-
fpeter84
senior tag
Sziasztok!
Rejtélyes hibába ütköztem egy Mega2560-al (kínai CH340)... Ezt a DRAM IC tesztert szeretném összerakni, le is fordul de amikor megpróbálom feltölteni akkor a nyúlfaroknyi kód feltöltésekor mindig pontosan ugyanott elakad majd némi várakozás után timeout hibába fut: [link]
Először azt hittem hogy álltában megkotlott a vas, de akár egy Blink, akár egy több mint 10x akkora jóval összetettem UTFT_Demo_480x320 program is lefordul, hibátlanul feltöltődik és fut is: [link]
Természetesen úgy is próbáltam hogy csak a vas önmagában mindenféle rácsatlakoztatott dolog nélkül, de ugyanúgy sikertelen a feltöltés. Megkértem egy barátomat tesztelésre - neki egy RobotDyn MEGA nyákja van, arra pöccre felmegy és fut vakon a program, küldi sorosra a dolgokat - sajnos nagyon messze van, az nem járható út hogy nála letesztelem a DRAM IC-ket
Akárhogy nézem a kódot, nem tudok rájönni hogy mi lehet az benne ami megakaszthatja egyik vason, másikon meg nem - csak csupa olyan lábakat piszkál aminek elvileg nincsen rendszer funkciója... Van rá bármi ötletetek hogy mi lehet itt?
-
fpeter84
senior tag
Sziasztok ismét!
Írtam egy saját lib-et kwp1281 protokol olvasáshoz, ami egymaga tökéletesen működik. A szépséghibája, hogy úgy tudtam megoldani a nem blokkoló és timeout-ot is figyelő adatgyűjtést a sorosportról, hogy egy globális rxbufferbe gyűjtögeti az információkat. Emiatt viszont ha egy második instance-ot is szeretnék inicializálni belőle, akkor az ugye ugyanabba az rxbufferbe dolgozna és szétgányolnák egymás adatait...
Csináltam egy egyszerű tesztlibet, amiben látszik hogy mi a problémám... Ezt hogyan illik feloldani, hogyan kellene úgy gyűjtenem egymástól függetlenül az adatokat hogy ne írjanak egymásra?
test_lib.ino
#include <test_lib.h>test_lib instance0;test_lib instance1;void setup() {Serial.begin(115200);instance0.test_print();instance1.test_print();instance0.test_input(1,2,3,4,5,6,7,8);instance1.test_input(8,7,6,5,4,3,2,1);instance0.test_print();instance1.test_print();}void loop() {}test_lib.h
#include <Arduino.h>class test_lib{public:void test_input(uint8_t d0, uint8_t d1, uint8_t d2, uint8_t d3, uint8_t d4, uint8_t d5, uint8_t d6, uint8_t d7);void test_print();};test_lib.cpp
#include "test_lib.h"uint8_t testbuff[8];void test_lib::test_input(uint8_t d0, uint8_t d1, uint8_t d2, uint8_t d3, uint8_t d4, uint8_t d5, uint8_t d6, uint8_t d7) {testbuff[0] = d0;testbuff[1] = d1;testbuff[2] = d2;testbuff[3] = d3;testbuff[4] = d4;testbuff[5] = d5;testbuff[6] = d6;testbuff[7] = d7;}void test_lib::test_print() {Serial.print(testbuff[0]); Serial.print(" ");Serial.print(testbuff[1]); Serial.print(" ");Serial.print(testbuff[2]); Serial.print(" ");Serial.print(testbuff[3]); Serial.print(" ");Serial.print(testbuff[4]); Serial.print(" ");Serial.print(testbuff[5]); Serial.print(" ");Serial.print(testbuff[6]); Serial.print(" ");Serial.println(testbuff[7]);}A program eredménye ugye az, hogy 2x kiírja a 8 7 6 5 4 3 2 1 sort ahelyett, hogy 1 2 3 4 5 6 7 8 és 8 7 6 5 4 3 2 1 lenne a végeredmény...
-
fpeter84
senior tag
[itt] tudsz mazsolázni a microchip kínálatából - I2C-re vannak 2 és 4 bemenetes I2C AD-k is, pl az MCP3424 vagy MCP3428... lehet picit feleslegesen túl okosak a célra, de ha a költségvetés elbírja a bruttó ~2e-es árát akkor még arduino támogatást is hozott hozzájuk a gugli, találsz lib-et példaprogikkal - itthon a chipcad-nél vannak is raktáron...
ja meg elhangzottak a multiplexerek is, ha nem kell nagy sebességgel olvasni az analógokat, akkor az is lehet jó megoldás hogy pár analógnak jelölt lábat digitként használsz, és azzal kapcsolgatsz egy multiplexert az 1db analóg lábra és úgy olvasod a sok sok bemenetet egyesével -
fpeter84
senior tag
válasz
Tomika86
#17684
üzenetére
2002 1.9PD AWX, pont Bosch EDC15P+ van benne, úgyhogy érdekelne hogy mi is ez! Ezt azt találtam a neten, de kifejezetten a kommunikációját taglaló leírást még nem... A KWP1281 működik, de találtam rá utalást hogy elvileg KWP2000-et is tudna a vezérlő K-Line-on, illetve van CAN-je is de arról még annyit se találok...
-
fpeter84
senior tag
válasz
Janos250
#17682
üzenetére
Nekem is kellett picit kémkedni SaleaeLogic-al a kw1281 forgalmat, mert bár a motorvezérlő szépen reagált a 0x01 5baud megszólításra, de pl a műszerfal nem reagált a 0x17 címére - aminek elvileg ott kellene lennie a VCDS és minden egyéb fellelhető információ szerint... Aztán átnyálazva a kommunikációt kiderült hogy a motorvezérlő tényleg a 0x01-en reagál, de a műszerfalat valamiért a 0x17+0x80==0x97-en kell megszólítani az 5baud inicializáláskor. Nem értem hogy erről miért nem találok sehol semmit - minden működőnek riportolt példaprogi a 0x17-es címen kommunikál a műszerfallal - de valamiért az A6 C5-ömön így működik 2 különböző cikkszámú VDO és egy Jaeger/Magneti órával is...
De ez a része most működik szuperül stabilan a hw UART-on több órás közlekedés közben sem tapasztaltam egyetlen újracsatlakozást sem, míg softserial-al bajosabb volt, le leszakadt folyton...
-
fpeter84
senior tag
Egyébként most ezzel játszogatok: [link]
VW/Audi kw1281 (K-Line) protokollon lekérdezek ezt azt a motorvezérlőből, majd az Infotaintment canbus-on ráküldöm a műszerfalra az információkat, mintha a gyári rádió az RDS csatorna nevet, frekvenciát szeretné ráküldeni a központi LCD felső két sorára (2x8 karakter). Elméletben az egész kijelző felett grafikusan is át lehetne venni a hatalmat, de a fellelhető infó morzsákból összecsipegetett inicializálásra nem akar reagálni a műszerfalam - lehet más VW családos nagy kijelzős műszerfallal működik, az A6 C5-el éppen nem... Végülis ez csak egy átmeneti állapot a kísérletezésben, a végleges majd valami olyasmi lenne mint pl a "3d color mfd" néven fellelhető projekt, csak saját ötletekre alapozva, olyan információkkal ami engem érdekel, plussz a google maps navigációs utasításait is szeretném majd rávarázsolni...
Valaki innen játszott már a kw1281 protokollal? Találtam rá több Arduino projektet is, de mind softserial alapú volt és nem túl stabil, ezért meguntam és újrairtam az egészet hardveres sorosport alapúra, és így már atomstabil, nem szakadozgat soha. Szeretnék belebújni az autó Powertrain canbus-ába is - ilyesmivel esetleg játszott már valaki? Próbálom összeszedni az infókat hogy mit hogyan lehet megtalálni az adatfolyamban, meg esetleg van e can-en saját lekérdezésre is lehetőség, vagy csak azzal lehet főzni amit maguktól forgalmaznak egymás között a vezérlők - ez mondjuk picit necces téma, belenyúlni a motorvezérlő-abs-műszerfal kommunikációba - amíg csak read-only hallgatózik, addig nagy baj nem lehet ha nem zárja rövidre az ember
-
fpeter84
senior tag
köszi srácok, igen közben rájöttem hogy bizonyos eseteket miért kerekít felfelé - direkt azért is tettem bele ilyen határon billegő értéket ami már kiprovokálta... az a helyzet hogy egy ennél bonyolultabb képlettel indítottam és eddig egyszerűsítgettem mert először még 1 tizedesben gondolkodtam - de rájöttem hogy még ez is felesleges bonyolítás, ha 2 tizedest akarok akkor round(tmp/10)/100 pont azt adja vissza amit szeretnék, ha 1-et akkor round(tmp/100)/10
a printf-ben a string azért van, mert valójában itt csak debug célból irattam ki hogy lássam hogy utána a végleges helyén hogyan viselkedne - egy vw/audi műszerfal FIS kijelzőjére küldöm az infotaintment canbus-on, ami az adott protokollon 2x8 byte-ot vár ami a string-hez van legközelebb - legalábbis a nyomtatott nagy betűk és számok tekintetében, a kisbetűk és sokminden írásjel tekintetében marhára nem követi az ASCII kiosztást, elég furán lett kitalálva - ha azokat is használnám akkor azt még rendesen át kell gondolni hogy hogyan tudnám map-elni a bemenő string alapján... -
fpeter84
senior tag
Sziasztok!
Arduino-ban van e elegánsabb megoldás a következő mértékegységváltás-kerekítés feladatra?float tmp = 2284.9;
Serial.println(String(tmp));
tmp = round(round(tmp)/10)/100;
Serial.println(String(tmp,2));
mbar-t szeretnék átváltani bar-ra és 2 tizedes jeggyel megjeleníteni egy kijelzőn... Egyrészt nem tökéletes a fenti, mert a példában szereplő 2284.9 mbar a kerekítés szabályai szerint 2.28 bar lenne, a kód meg 2.29-re hozza ki - ennyi hiba tulképp még beleférne nekem és ESP32-n fut úgyhogy pazarolni is van miből, de hátha tudtok rá jobb megoldást ajánlani... -
fpeter84
senior tag
Sziasztok! Tasmota kód piszkálásában van valakinek gyakorlata? Beleszúrtam egy kis saját kódot, de jó lenne ha nem csak a sorosra írná ki a saját debug információimat, hanem a belső webfelületen lévő konzolban is látnám - de erre nem tudok rájönni hogy abba hogyan tudnám "beleküldeni" a saját sorokat... Valaki játszott már vele ilyet?
-
fpeter84
senior tag
Köszi! Én is még küzdök vele, hátha... A végcélom az lenne, hogy egyben tudjak emulálni egy PCF8574-et és egy LM75-öt egy Tasmota számára - egyéb buszrendszerről olvasva a hőmérsékletet a Tasmota számára azt emulálnám, valamint pár kapcsoló utasítást is továbbítani kell a buszrendszer felé... Ha nagyon nincsen rá megoldás, akkor elég lenne egy LM75 is - elvileg ez már lényegében véve meg is van - de elegánsabb lenne ha a digit láb utasításokat sem külön lábakkal kellene átvinni az ESP8266 és 328p között hanem az is mehetne az I2C-n akkor már...
szerk: egyelőre nem is teljesen tiszta, hogy miért is kapok onReceive eseményeket az LM75 olvasásakor is, de akkor is meghívódik, ott van a TWDR-ben a 0 érték és ezt nem tudom elkülöníteni attól amikor éppen a 8574-re is 0-t írok... -
fpeter84
senior tag
Sziasztok!
I2C slave-el foglalkozott már valaki nano/uno/mega-n? Mégpedig azzal fűszerezve, hogy több címet, több eszközt is emuláljon egyszerre... Azt tudom hogy alapjában véve csak 1 slave címet lehet megadni a regiszternek, de guglizva találtam olyanokat hogy az address mask-al varázsolva több eszköznek látszik. Tényleg működik is valamennyire, a lekérdezésekre tudok is válaszolni, de a beérkező utasítások/adatoknál eddig nem sikerült sehogy elválasztanom, hogy mégis melyik címre kapta a byte-ot...
Ezeket megtaláltam: [link] ezt végigpróbálgattam, így sikerült a Wire.onRequest -re válaszolnom is, de a Wire.onReceive -nél sehogy sem tudom eldönteni hogy melyik szenzort akarta elérni a master... [link] - ez meg sajons asm, nem nagyon látom át, nem tudom bele lehetne e nyúlni valahogy...
Valaki mélyedt már el ilyesmiben? -
#14050
fpeter84
senior tag
its_grandpa
#14043
fpeter84
senior tag
válasz
its_grandpa
#14043
üzenetére
azthiszem közben ráleltem, az executecommand eljárás lesz a megoldás amivel a soros/web konzolban is működő parancsokat lehet programkódból is meghívni, pl
ExecuteCommand("POWER OFF", SRC_BACKLOG);
parancsra lekapcsol a relé szabályosan... -
fpeter84
senior tag
Sziasztok! Nekem is éppen a Tasmota-hoz kötődő kérdésem lenne, de programozás oldalról megközelítve...
Arduino ide-vel lefordítottam, ráhúztam egy wemos D1 R2-re és fut is szépen egy sonoff-féleséget utánozva: relé a GPIO14-en, fizikai gomb a GPIO2-n. Ha a loop végére beteszem a saját szemetemet, azzal tudom detektálni hogy éppen a webes vagy fizikai gombbal melyik állapotba lett állítva a relé kimenet:
if ((digitalRead(14)==1) and (myRelayStatus==0)) {
Serial.println("rele bekapcs");
myRelayStatus=1;
}
if ((digitalRead(14)==0) and (myRelayStatus==1)) {
Serial.println("rele kikapcs");
myRelayStatus=0;
}
Viszont arra nem tudok rájönni, hogy hogyan lehetne ugyaninnen saját eseményekre reagálva kezdeményezni egy relé ki vagy bekapcsolást? Van erre valami meghívható eljárása? Nem igazán látom még át, túl sokat tud ez a Tasmota kód... Egy fizikai láb átbökést nyilván bármikor csinálhatnék, de arról a Tasmota nem értesül persze... -
fpeter84
senior tag
Sziasztok! STM32-vel van valakinek tapasztalata a read out protection-al kapcsolatban? Adott egy STM32 klón Gigadevice GD32F103R8T6 csipp, amire sikerült is rácsatlakoznom egy STLink V2-vel - az azonosítóját kiolvassa az openocd és win-es ST-link utility is, de az előbbi csak úgy eldobja a flash dump kísérletet, az utóbbi az konkrétan meg is mondja hogy le kellene róla venni a read out protection-t először. Na most ez ott van a menüben, de ha megpróbálom levenni akkor mi történik? Elveszik a flash tartalma és lesz egy üres eszközöm amit újra írhatok, olvashatok? Természetesen az lenne a célom hogy lementsem ami benne van, nem lenne jó ha fejreállna... Ezt felejtsem el?
-
-
fpeter84
senior tag
válasz
Tankblock
#12410
üzenetére
Természetesen ott van a 0x44 címen - de közben rájöttem hogy hol van a gond - ott hogy bár nincsen rendesen ledokumentálva, de úgy tűnik hogy az összes beállítás regisztere write-only, mindössze egyetlen byte-ot lehet belőle lekérdezni:
Azért kapok mindig 2-t, mert a softmute nem aktív (SM==0) és softstep nem busy (BZ==1) vagyis b10==2... ha a softmute-ot aktiválom a 0x04-es címen, akkor onnantól 3-at kapok vissza, ha kikapcsolom akkor ismét 2-t
Ez nagyban megnehezíti a dolgomat... Adott 2 autós androidos fejegység. 2 különböző platform de az audio proci IC ugyanaz a TDA7729-es. Az egyik kifejezetten jól szól, szeretem a hangját, a másik bár hardverben sokkal bikább, de a hangjával elégedetlen vagyok... Szerettem volna összehasonlítani a regiszterek beállításait első körben, hátha ott rontja el a hangot az erősebb vas - de így ez a verzió bukta...
Saleae Logic-al kissé macerás visszafejtegetni a nagy tömegű kommunikációt, úgyhogy most összerakok egy ilyen i2c_sniffer-t, és írok hozzá egy programot ami valahogyan könnyen összehasonlítható módon megjeleníti a különbségeket a két eszköz buszain küldött beállítások között. B terv, hogy veszek valami DSP-t (mint az ADAu1701), és megpróbálom azzal ráncfelvarrni a hangot...
-
-
fpeter84
senior tag
Sziasztok!
I2C kommunikációval kapcsolatban volna szükségem segítségre... Egy TDA7729 (==TDA7719) audio processzorral szeretnék beszélgetni, lekérdezni a regisztereit. Utasítani tudom gond nélkül, de a lekérdezésekre mindenáron csak annyi a válasza, hogy 2..
Wire.begin();Wire.beginTransmission(0x44);Wire.write(0x0C);Wire.endTransmission(false);Wire.requestFrom(0x44,1);Serial.println(Wire.read(),HEX);Volt, hogy próbából tettem 10ms delay-t a lépések közé hátha nem tud olyan gyorsan válaszolni, de semmi változás. Bármelyik regisztert próbálom 0x00-0x12 (0..18) között, a válasz a read-nél mindig az hogy 2...
Néztem logikai analizátorral is, és tényleg mintha csak ennyi történne a buszon:
Hol lehet a probléma? Ha valaki kicsit járatosabb az I2C kommunikációban, plz lessen bele a fenti datasheet-be - mit csinálok rosszul a kommunikáció során?
-
fpeter84
senior tag
válasz
Atamano
#10894
üzenetére
Igazából szerintem határeset lehet, de az az abszolút biztos ha külső ~1-4.7K felhúzó van
A láb és 5V közé tedd az ellenállást, valamint a láb és föld közé a záró kapcsolót - így alaphelyzetben felhúzva 1-et olvashatsz a lábon, a gomb megnyomásakor meg 0-ra vált. A pinmode-ot pedig akkor sima INPUT-nak add meg pullup nélkül
-
-
fpeter84
senior tag
válasz
Atamano
#10887
üzenetére
Működne, de van egyszerűbb módja is:
pinMode(2, INPUT_PULLUP);
Így semmi más nem kell, mint a kapcsoló másik felét földre kötni! Egyszerűbb, és kapcsolástechnikai szempontból is szerencsésebb, ha a bemenő lábat nem közvetlenül kötöd a tápra, hanem felhúzod egy ellenállással és a kapcsolóval azt húzod földre. Az integrált pullup használatával ez történik külső ellenállás nélkül... Annyi a különbség, hogy ilyenkor 1-et olvasol alap, és 0-t gombnyomott állapotban...
-
fpeter84
senior tag
válasz
zsolti_20
#10857
üzenetére
Nekem nagyon úgy tűnik hogy túlterheltség jeleket mutat - még az nrf modul instabilitását is emlegetted előbbre, nem?
A TP4056-al több sorbakötött cellát nem lehet tölteni. Alapjában véve 1, esetleg több párhuzamos (? ezt tudja valaki) cella töltésére van kitalálva... Fontos hogy ebből a töltő modulból is két féle van - az egyik csak a töltő IC, a másikon pár alkatrész plusszal a mélykisülés védelem is rajta van - utóbbi akkor kell, ha az akku cellán ez nincsen rajta - pl notiból bontva lehet ilyenekkel találkozni, de biztos meg lehet őket találni más forrásból is... Pár hozzászólással lentebb emlegettük a témát pont, ott volt linkelve is egy cikk hogy miről lehet megismerni ha a cella védett vagy sem...
Akku vásárlással nem tudom hogy másnak van e pozitív tapasztalata kínából - én néhányat vettem eddig, és erősen felemásak a benyomások... Kaptam jót is, de inkább több rosszat - de ha nem kell tengernyi mennyiségben, akkor egy olyan projektnél ahol fontos a rendelkezésre állás, ott jobban jársz ha itthon keresel egy normális forgalmazót és márkás akkut veszel hozzá...
-
fpeter84
senior tag
válasz
tvamos
#10856
üzenetére
A töltésben nem vagyok biztos hogy ne tudná kezelni a helyzetet, de max egy kikapcsoló gombot lehet tenni a kimenő oldalra, amivel töltés idejére teljesen le lehet választani a töltő+akku oldalt a fogyasztókról. A puffer üzem szerintem csak programozáskor állna fenn - az nem kritikusan hosszú idő, annyit bőven ki kell bírnia. Akár még az akkufeszt is lehet mérni az ADC Vref-et a belső 1.1V referenciára kapcsolva, megfelelően méretezett feszosztóval, tehát még szólni is tud ha tölteni kellene lassan...
-
fpeter84
senior tag
válasz
zsolti_20
#10854
üzenetére
a ráírt kapacitás nettó hazugság, örülhetsz ha 2-3000-et találsz benne, de mivel tudatosan hazudnak ezért nagy valószínűséggel egy 1000mAh alatti, hamar tönkremenő ipari szemétre írták rá a nagy számot. Onnan lehet tudni hogy hazudnak, hogy ha a Samsung, LG, Panasonic stb nagyon messze jár az ilyen kapacitás sűrűségtől pedig ők vagyonokat ölnek a fejlesztésbe, akkor nyilván nem egy kínai dzsunka gyártó fogja őket a semmiből túlszárnyalni
a li-ion merülési határa ~2.7V körüli, feltöltve 4.25-4.3V és a töltőfesz is 4.3
sorba kötni természetesen lehet őket, akkor lesz 5.4-7.6V-od, amit elvileg ráköthetnél a nano vin-jére, de az OLED-re már semmiképpen akkor sem ha van rajta LDO (az ilyen pici feszstaboknak 6-6.5V a felső határa), és a per pillanat túlterhelt ch340-ből lopott 3.3V kérdését sem oldja meg!
eddig azt emlegetted, hogy USB-re lehessen dugni és tölteni - ha a töltés elhagyható, jó úgy is hogy le kell csatlakoztatni a készülékről akkor semmi gond, egyszerűen kösd az 1, vagy 2 párhuzamosan kötött cellát a lenti ábrám alapján TP4056 modul nélkül - ha a schottky-t leszeded a nano-ról akkor programozni is lehet - bár fura hogy ahol elfér 1 vagy 2 ilyen 18650 cella, ott miért nem fér el az az aprócska modul is akkor már hogy kényelmesen tölteni is lehessen szétbontás nélkül USB-ről?
-
fpeter84
senior tag
Elméletben nincsen szükség szintillesztésre, mert az nrf lábai a doksija szerint 5V-toleránsak amíg nem viszed le 2.7V alá a tápfeszt, és ha max 3.6-ról fut az egész szett akkor irreleváns a kérdés... Az OLED panelen elvileg illene a bemenő jel oldalon egy ellenállásosztónak lennie, a vissza jelszint meg elég egy arduinonak... gond max akkor lehet, ha az I2C-t még az arduino maga húzza fel 5V-ra...
-
fpeter84
senior tag
válasz
zsolti_20
#10847
üzenetére
Azért esik ennyire rondát a 3.3V ág, mert abszolút túl van terhelődve! A ch340-ben lévő belső LDO nem igazán arra lett tervezve hogy külső áramkört is hajtson magán kívül, nagyon jelképes a terhelhetősége! És írtad hogy instabilnak tűnik az nrf - lehet az a ~2.5V se mindig annyi, hanem multiméterrel nem mérhető tüskékben a fele...
A 3xAA cella valóban max 3.6V-ot ad teljesen töltött állapotban? Mert ez a 3.6V az nrf-nek az abszolút maximuma amit illik ráadni! Ha tényleg nem több akkor közvetlenül rákötheted az összes eszközt erre a 3.6-ra, csak a nano-ról kell levenni a schottky-t hogy amikor USB-re dugod akkor ne üsse ki őket, valamint a nano órajelét kell levenni 8MHz-re
-
fpeter84
senior tag
válasz
zsolti_20
#10839
üzenetére
a buzzer max egy nagyon hajszállal halkabban szól kisebb feszről, a led meg az előtét ellenállásával beállítható ugyanolyanra, ha kevéssé válna
kizárásos alapon csak a Q1 lehet LDO, ha az... feliratot nem látsz rajta? rámérve, ha mondjuk 3.5V-ot adsz a modulnak, akkor egyik lábán meg kéne találnod ugyanazt a 3.5-et, másikon már csak ~3.3-at, aztán ha tolod feljebb a bemenő feszt akkor a 3.3-nak fixen maradnia kellene
-
fpeter84
senior tag
válasz
zsolti_20
#10836
üzenetére
Itt találtam kapcsrajzot - persze kérdéses hogy minden klón centire pontosan ugyanilyen e... Az SD101CWS feliratos schottky dióda helyére lehetne becsatlakoztatni az akkut kezelő modult... Magának a schottky-nak az a szerepe, hogyha egyszerre dugod USB-re valamint adsz tápot a VIN-re vagy az 5V buszra, akkor az ne akarjon az USB 5V felé "visszamenni", nehogy kárt okozzon az USB portban... Ide lehetne beilleszteni egy TP4056-os modult li-ion cellával - ő majd ugyanúgy elválasztja a két oldalt, tehát a diódát le lehet forrasztani...
A föld közös, az USB port felől érkező 5V megy a Vcc/5V 4-es lábra, a belső 5V buszt pedig az 5-ös BAT/akku pozitívjára kell csatlakoztatni. Viszont így ugye a nano 5V rendszere valójában li-ion cella feszültségét kapja: töltés közben, töltött állapotban 4.25-4.3V, csontig merülve pedig 2.7V, de az atmega328 8MHz-re állítva simán kezeli a teljes tartományt, csak arra kell figyelni hogy a BODLEVEL fuse bitek nehogy 4.3V-os állásban legyenek, mert akkor még USB-re dugva is folyamatosan a poweroff határán táncolna...
Viszont itt van egy fontos megjegyzés:
"The CH340 chip includes the 3.3 V LDO voltage regulator, which can supply up to 25 mA. There is no refence in the original CH340 datasheet or elswhere on the internet, so I measured the supplied 3V3 voltage directly. With no load, the 3V3 pin voltage was 3.28 V. With load up to 25 mA the voltage dropped to 3.18-3.22 V (on different boards); however at 30 mA load the voltage dropped to 3.10 V and further to 2.85 V at 40 mA."
Ha rámérsz a 3.3V ágra a mostani kapcsolásodban aktív állapotban, ahol az oled és az nrf modul is ezt terheli, valószínűleg azt találod hogy jó ha egyáltalán a 3.1V megvan! Az oled modulod pontosan melyik? Hogy néz ki a háta? Be kellene azonosítani, hogy van e rajta LDO... Ha van, akkor nyugodtan mehet közvetlenül a belső "5V" ágra, vagyis a li-ion+/BAT-ra ő is a nano mellé. Az nrf modul pedig maradhat a nano, vagyis a ch340 3.3V ágán, azt már el kell bírnia, csak legyen mellette némi kondenzátor hogy az impulzusszerű RF adás ne rángassa meg túlságosan...
Így egyetlen komponens maradna out-of-spec, a ch340 VCC 5V lába - ha USB-re dugod akkor 4.25-4.3V kerül rá a TP4056/akku felől, ami ugyan kevesebb mint a doksi szerinti min 4.5V, de szerintem kényelmesen fog róla működni a gyakorlatban, és ha jól értem akkor ez nem is feladatkritikus eleme a rendszernek, csak programozáskor van rá szükség - ha véletlenül 1000 programozásból 1-2x mégis hibát okoz, akkor csak újra neki kell futni a programozásnak mert a bootloader nem sérülhet akkor sem...
Így a gyakorlatban töltheted, programozhatod USB-ről bármikor... Az nrf bőven bemehet 2V alá is, tehát nem probléma ha a ch340-től kapott 3.3V valójában kevesebb mert már csak 2.7-et kap az akku felől és még abból jön le az LDO ejtése. Valószínűleg az oled lesz az első aki feladja az akku merülésével, mert bár a logic oldal 2V alá is mehet (SH1106 és SSD1306 vezérlők), a charge pump regulatornak viszont kell a 3-3.3V papírforma szerint - a gyakorlatban persze ezzel is lehet azt tapasztalod majd hogy jó annak a 2.7 is még bőven...
-
fpeter84
senior tag
válasz
zsolti_20
#10820
üzenetére
A ch340-es klón és az eredeti között annyi a különbség, hogy az eredetin az FT232RL csippből lopják a 3.3V ágat és a doksi szerint external logic meghajtására is jó 50mA erejéig, a kínain pedig a CH340 csippből lopják, amire most sehol nem találtam meg leírva, de rémlik hogy annó valahol láttam hogy 35mA, amiből le kell vonni a saját 12-30mA áramát is még, tehát lényegében véve elég minimális keret marad bármi másnak - persze a gyakorlatban lehet bír általában több terhelést is a belső LDO, de erősen specifikáción kívül mozogva... Az OLED megeszik (ada-s forrás szerint) ~20mA-t, az nrf tizen+ mA-t, ráadásul nálad az erősítős van, az nem tudom még mennyit dob rá. Tehát akárhogyan is, már rég túl vagy a hivatalos specifikáción. Viszont az OLED hátát érdemes lenne megnézni, mert simán lehet hogy ott van rajta is egy LDO és akkor azt le lehetne venni a nano 3.3-as ágáról!
Az atmega328 doksijának 318-dik oldalán van hogy hivatalosan mekkora tápfesszel mit is bír... 20MHz-en min 4.5V kell neki, 10MHz-en már 2.7V-ig is le lehet menni. A nano alapból 16MHz-en ketyeg - saccperkb 4-4.2V kellhet neki minumum ehhez. Persze a gyakorlatban lehet azt találod hogy még 3.3-on is elketyeg, de nem tudhatod biztosra hogy nem fagy e meg néha mégis... Ha biztosra akarsz menni, akkor tényleg érdemes lehet lemenni alacsonyabb órajelre! 8MHz támogatást pl a MiniCore visz az arduino IDE-be. A fuse biteket át kell hozzá írni, és vagy az internal RC 8MHz-re váltani, vagy a kvarcot lecserélve ext 8MHz-re...
Az AA ceruza NiMH cellák feltöltött induló feszülsége nem haladja meg az 1.2V-ot? És biztonságos merítésnél meddig esik le? Ezt tudja valaki?
Ha 3 ilyen AA ceruza akkut használsz, akkor el lehet dobni minden LDO-t! 3.6V éppen mindenkinek jó a felső határon táncolva! Egyenesen bekötheted a nano 5V lábára az elemeket, és ugyanez mehet az nrf és oled-nek is... A szépséghiba, hogy ilyenkor tilos USB-re dugni, mert kiütné a perifériákat - azokat programozáskor le kell választani...
-
fpeter84
senior tag
-
fpeter84
senior tag
A 9V elemmel az a probléma, hogy a nano-n lévő LDO típusú feszstab rengeteget elpazarolna az elemben rendelkezésre álló töltésből, mire 9-ből 5-öt csinál!
8MHz nem lenne elég a nano-nak a feldolgozáshoz? Mert akkor kis átalakításokkal üzembiztosan lehetne üzemeltetni egy li-ion celláról közvetlenül még merülés közeli 3V alatti állapotban is! Kínai CH340 csippes klón a nano, vagy eredeti? Az órajelét vagy kvarc+bootloader cserével, vagy bootloader csere mellett az internal RC 8MHz-re átállítva lehet könnyen elérni... Ha bement 10MHz alá, akkor a doksija szerint akár 2.7V-ig is leeshet a tápfesz, tehát egy csontig merült védett li-ion celláról is elüzemelne még éppen - messze ez a konfiguráció adná az adott térfogatra vetített legjobb üzemidőt, mert semmit nem pazarol hardver szinten!
Még az OLED lehet a kérdéses: ha a nano megy is szépen a 2.7-4.3V között kolbászoló li-ion celláról, a kijelzőnek az már sok lenne, tehát fontos hogy olyan típus legyen amin van kis LDO - ha a tápfeszre azt írják hogy 3.3-6V, akkor van, illetve kis méricskéléssel lehet kideríteni hogy olyan e... Kérdéses hogy az OLED meddig mehet le a tápfeszével - valószínűleg ő lesz a szűk keresztmetszed az akku merülése során, de ezt a gyakorlatban lehet kitesztelni - lehet 3V alatt kikapcsol, de lehet hogy még 2.5V-ról is vígan elüzemel...
-
fpeter84
senior tag
válasz
zsolti_20
#10793
üzenetére
A klasszikus arduino-k nem annyira alkalmasak az elemről/akkuról működtetésre, valamint ha vezetéknélküli kommunikációt is szeretnél, akkor lehetnek már arra is jobb megoldások! Akár az ESP8266 wifi-vel, akár az ESP32 wifi+bluetooth-al - mindkettőből létezik pár $-ért olyan kivitel amire közvetlenül is köthetsz li-ion akkut, tölteni is tudja, üzemelhet is róla... Milyen távolságra szeretnél milyen mennyiségű adatot küldeni, illetve elemről/akkuról mit kéne csinálnia, mi lenne üzemidőben az elvárás?
-
fpeter84
senior tag
válasz
szuszinho
#10791
üzenetére
lévén hogy az ali/ebay tele van a típussal, így jócskán van rá esély hogy hamisítják is a rizsföldiek - sajnos a népszerű termékekre adódó nagy igényt gyakran meglovagolják a zavarosban halászók is... ha látod rajta ezt a huplit, akkor valószínűleg védett - bár az igazán pofátlan hamisítványon akár ez is lehet kamu:
igazán biztos csak akkor lehetsz benne, ha megbontod a zsugort és alálesve látod a kis elektronikát... de ha teszel rá egy védett TP4056 kapcsolást plusszba, azzal bajt nem csinálsz biztosan
-
fpeter84
senior tag
-
fpeter84
senior tag
Sziasztok!
A "hagyományos" arduino-k, vagyis az atmega328 (és kistesói) lock fuse bit-jei nem teljesen egyértelműek számomra... Arra van lehetőség, hogy ISP-vel vagy szoftverből ne lehessen visszaolvasni a tartalmát, de a bootloader képes legyen frissíteni a firmware-t?
@szuszinho: túlmerítési védelem vagy van egy liion/lipo akkun vagy nincsen... Ha 18650-es cella, akkor ha valami márkásabb megbízható forrásból akkor a datasheet-ben benne lesz hogy protected e vagy sem, vagy a méretéből lehet totózni - a védettek egy hajszállal hosszabbak szoktak lenni, illtetve a zsugorfólián lehet egy kis hupli a negatív sarka előt a vékony ráépítés miatt. Ha egyéb csomagolás, akkor szintén a kivezetések környezetéből lehet tippelni, de biztosra akkor mehetsz ha megbontod kicsit - ha közvetlenül a fémházból jön ki a vezeték akkor nem védett, ha bármi sorba van kötve a negatívra akkor védett lehet... Ha pótolni kell a védelmet, akkor pl ez, vagy a legjobb választás egy ilyen kapcsolás, és akkor egyben töltőt is kaptál hozzá... Akkutól is igényektől függően esetleg az RPROG ellenállást érdemes lehet lecserélni rajta, mert általában 1A-re lövik be a kínaiak, ami nem feltétlenül szolgálja az akku tartósságát... A BOD-ot 8MHz vagy alatta én 2.7V-ra állítanám, mert kb itt úgyis letilt az akku védelme...
-
fpeter84
senior tag
válasz
Teasüti
#10737
üzenetére
Fizikai UART oldalon pont hogy nem lenne szükségem több portra, a találatok mind erről szólnak hogy vagy mega/due sok porttal, vagy softserial, de én nem erre gondolok
Virtuális oldalon kellene több sorosport - a modemekhez hasonlóan több soros eszközként jelentkezzen be USB csatlakoztatáskor, és az arduino szoftver oldalon is több portot lehessen írni/olvasni. Ennek a PC oldalon volna jelentősége, hogy ne csak egy szoftver tudjon egy időben csatlakozni az arduinohoz, hanem több program is tudja külön külön utasítani, olvasni a visszajövő infókat mind a saját virtuális sorosportján
-
fpeter84
senior tag
Sziasztok! Találkozott itt már valaki olyan projekttel, hogy egy natív USB-s Arduino (Leonardo, Due, STM32 stb) ne csak egy sorosportot adjon USB-re csatlakoztatva? Azthiszem multiplexing néven kellene megtalálni - pl modemeknél szokott 3-4, akár 5 COM* / ttyACM* / ttyUSB* eszköz bejelentkezni külön a data, debug, control, gps stb felületeknek, de a gyakorlatban persze ez mind egy hardverből kimixelve. Ha jól gondolom ehhez semmi extra hw támogatás nem kell, csak kérdés hogy szoftverből implementált már valaki ilyet? Próbáltam keresgélni, de a fenti szavakra eddig csak olyanokat találtam ahol a különböző UART portokról jövő infókat multiplexelik egybe...
-
fpeter84
senior tag
válasz
LógaGéza
#9962
üzenetére
Csak óvatosan azzal a tápfesszel, mert nálam már nem egy kínai UNO/NANO/MEGA köszönt el 12V bemenő mellett! A rajtuk lévő 1117 LDO-ból legalább 1-2 tucatnyi féle létezik, és van amelyiknél mindössze 12V a megengedett legnagyobb bemenő tápfesz, de olyan is aminél 20V. Mindenesetre nekem már nem egy elpukkant (ugye a 12V-nak írt fali táp se feltétlenül kerek 12V), ezért azóta 8-10V fölé sosem viszem a tápját és így még egy sem adta meg magát... Ha autós felhasználásra kell vagy nem megoldható / nem praktikus az alacsonyabb tápfesz, akkor ilyen filléres step-down-t teszek elé inkább - a rajta lévő MP2307 tartósan mehet 20V fölött is és nem fog elmelegedni...
-
fpeter84
senior tag
válasz
Johnny_vT
#9942
üzenetére
arduino projects, top 10 arduino project és hasonló kifejezésekre keresgélve rengeteg ötlettel találkozhatsz, valamint unalmas óráimban van hogy olyan oldalak arduino kiegészítő listáit nézegetem mint a banggood, dx, gearbest - utána persze nem feltétlenül ott veszem meg ha valami felkelti az érdeklődésemet, de ötlet gyűjtésre jó...
-
fpeter84
senior tag
válasz
XP NINJA
#9914
üzenetére
LCD ügyben első körben én is a mobilra/tabletre alapozást ajánlom több oknál fogva:
- az ilyen arduino shield, meg arduinoval meghajtható LCD-k gyakran elég silány képet adnak... szürkén világító fekete, gyenge betekintési szög, sápadt színek... Most éppen sikerült vennem egy olyan 3.2 colosat aminek kifejezetten jó a képe, de zsákbamacska. Persze a kínai eladók hirdetésében még a 320x240 is UltraHD mega-giga minőség, de csak akkor tudod meg hogy mit vettél amikor bekapcsolod...
- az ilyen natív framebuffer nélküli mikrokontrollerrel LCD meghajtás elég lassú - még a leggyorsabb eljárások is - így elég nehézkes / lehetetlen gyorsan változó tartalmat, látványosabb grafikát kialakítani... Attól függően hogy mi az elképzelésed, érdemes lehet akár egy Pi Zero-n is elgondolkodni - azzal nem probléma a grafika...
Én egy fedkomp/pár adat megjelenítését végző kütyün dolgozgatok mostanában - elsősorban a VAG családos motorvezérlőből nyerem az adatokat KW1281 protokollon keresztül, de úgy tűnik kénytelen leszek pár adatot közvezlenül mérni én is, mert a lekérdezés sebessége nagyon korlátozott és van ahol kritikus a sebesség...
-
fpeter84
senior tag
válasz
gyapo11
#9879
üzenetére
A lábkiosztását írják, úgyhogy ez már antenna+gps egyben. Csak tápfesz (3.3-5V?) kell neki, a TX-en pedig valamilyen baud-al (egyik feedback 9600-at emleget) passzívan jönnek belőle az NMEA mondatok. Kommunikálni vele, átprogramozni nem lehet mert RX lába nincsen és a chipset is ismeretlen, bár nincsenek róla rossz véleménnyel...
-
#9849
fpeter84
senior tag
Speeedfire
#9848
fpeter84
senior tag
válasz
Speeedfire
#9848
üzenetére
Milyen autóval játszanál? Én kipróbáltam többek között ezt és más hasonló kódokat - bár úgy tűnt hogy mindnek kb ugyanazok a gyökerei - de egy 2002-es A6-on totál használhatatlan, megbízhatatlan volt: álló motornál még úgy ahogy csatlakozott de járó motornál szemét szemét hátán. A csatlakozó hardver biztosan jó - ez már kiderült egyéb tesztekkel - úgy tűnik hogy zéró hibakezelés van a fenti kódban, plussz lehet az enyém vezérlője is éppen érzékenyebb / zajosabb... Mindenesetre beleástam magam és végül csináltam egy saját lib-et hozzá ami nem soft serial-al megy hanem rendes hardveres sorosporttal. Működik MEGA, DUE és ESP32 platformon is - utóbbival használom végül...
A csatlakozó hardverről: első körben én is szétgányoltam egy VAGCOM 409 kompatibilis kábelt, de hamar rájöttem hogy egyszerűbben is lehet ezt: MCP2021, L9637D vagy bármilyen hasonló LIN driver megfelel a célra... Per pill az utóbbival megy és hibátlannak tűnik a kommunikáció több óra után is...
Ha mégis kész kábelt vágnál szét, akkor erősen a szerencsén múlik hogy jó e: láttam olyat is már amiben egy fekete paca volt csak a csipp a nyákon mint a kvarcórákban, számológépekben, és arra nem nagyon lehet rácsatlakozni... Ha rendes smd alkatrészekből áll akkor cirka bármelyik lehet jó akár tranzisztorokból, akár komparátorból, akár rendes LIN meghajtóból van összerakva, amennyiben be lehet azonosítani az alkatrészeket benne...
Ha érdekel akkor szivesen megosztom azt amire eddig jutottam...
(az lemaradt, hogy a measurement blocks lekérdezésre mentem rá mint a linkelt projekten is - hibakód olvasással nem szórakoztam mert arra van külön VCDS kábelem is) -
fpeter84
senior tag
válasz
Tankblock
#9842
üzenetére
A 6+2 az az eredeti SD szabvány 4 párhuzamos I/O lábbal plussz kontrol, a mikrokontrollerekkel viszont általában SPI módot szoktunk használni ami a 4+2 a MISO meg MOSI-val (vagy SDI, SDO stb)...
Kicsit gány, de én még úgy is csatlakoztattam MicroSD-t egyszer jobb híján hogy egy SD>MicroSD foglalat lábaira forrasztottam rá a vezetékeket. Végülis működik ha nem melegíti túl az ember a lábait... A hosszabbtávú 3.3V prototípusoláshoz meg érdemes venni egy marék ilyet. Az 5V kontrollerekhez viszont szigorúan csak ilyen jelszintillesztőset szabad használni!
De érdemes lehet az SPIFFS-t is kipróbálni, mert a több mega belső flash-be rengeteg log elfér és akkor nincsen függelék az eszközön! A fájlrendszer feltöltésére van plugin, letöltésre még sajnos nem találtam így az embernek a programba be kell építenie egy dump opciót is, vagy egy külön programmal intézni ezt. Szerencsére az SPIFFS tartalmát nem érinti, ha más arduino programot töltesz fel ideiglenesen a fájlkezelés idejére...
szerk: ESP32 esetén pullup sem kell, ahol kell ott elintézi a proci belső pullup funkciójával a library!
-
fpeter84
senior tag
válasz
Janos250
#9828
üzenetére
Annyira nem csúcs ajánlat, ebayen meg alin ennél olcsóbb a picit nagyobb tudású LOLIN32...
@(#9829) csubuka: ESP-WROOM-32 modullal elvileg ugyanannak kell lennie, különbségek ott akadnak inkább hogy pl a LOLIN-en Li-Ion töltő is van, illetve léteznek olyan ESP32-k amelyek mellé több/kevesebb flash-t társítanak, de a WROOM-os elvileg mind 4MB-os
-
fpeter84
senior tag
válasz
fpeter84
#9812
üzenetére
okkk, rá is jöttem hogy hol néztem be a dolgot... A reset az RTC-t is nullázza, tehát reset után normális ha nincsen idő tárolva... Viszont a deep sleep-ből visszatérve van: összeollóztam a SimpleTime és ExternalWakeUp példákat, így egy külső triggerre ébredve már egyből rendelkezésre áll az idő - bár még valami bogár van, valószínűleg a timezone beállítást akkor is elveszti mert -2 órával éled, de a másodperc/perc egyértelműen mutatja hogy nagyvonalakban rendben van, működik az RTC hardver deep sleep módban...
szerk: ez is megvan... az esp32-hal-time.c-ből át kellett ollózni a setTimeZone-t a tesztprogramba és meghívni ahogy a configTime is teszi: setTimeZone(-gmtOffset_sec, daylightOffset_sec);
Failed to obtain time
Connecting to xxx .. CONNECTED
Tuesday, October 16 2018 00:16:35
Going to sleep now
ets Jun 8 2016 00:22:57
rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:808
load:0x40078000,len:6084
load:0x40080000,len:6696
entry 0x400802e4
Tuesday, October 16 2018 00:16:42
Connecting to xxx .. CONNECTED
Tuesday, October 16 2018 00:16:43
Going to sleep nowugyan arra még nem jöttem rá hogy miért minusz a gmtOffset_sec miközben mi a GMT+1 időzónában vagyunk, de kicsire nem adunk, nagy meg nem számít
-
fpeter84
senior tag
Nekem az az érzésem, hogy a SimpleTime-ban használt getLocalTime valami szoftveres RTC lehet, mert ha berakom plusszba a printLocalTime() -ot rögtön a serial init / wifi csatlakozás közé, akkor szerintem úgy kéne működnie hogy első körben normális a Failed to obtain time, de ha egyszer megtörtént a szinkronizálás, akkor egy reset után ki kéne tudnia írni az időt, de ugyanúgy Failed to obtain time marad...
Azért még kísérletezek vele, hátha rájövök a nyitjára... -
fpeter84
senior tag
Mert Te találtál bármi leírást, példakódot, library-t a témához? Én csak annyit hogy még az IDF-be sincsen rendesen implementálva az egész, nemhogy arduino alá...
Az egyetlen amit találtam az a lenti linken lévő deep sleep, de nekem nem ez a része kellene az RTC-nek, hanem azt szeretném tudni hogy két indítás között mennyi idő telt el... -
fpeter84
senior tag
Jól látom, hogy az ESP32-n még mindig nem sikerült a fejlesztőknek rendesen éleszteni az RTC részt? Időzített felébresztésre ugyan találtam valami szösszenetet, de nekem az idő múlását kellene nyomon követnem - azt kellene tudnom, hogy mennyi idő telt el az előző bekapcsolás óta... Marad a külső RTC hardver, vagy valaki talált már ezzel kapcsolatban valami használható próbálkozást?
-
fpeter84
senior tag
-
fpeter84
senior tag
Valaki tudja értelmezni, hogy a gyakorlatban mit is csinál ez a részlet a LOLIN32 kapcsrajzán?
Más értelmét nem látnám, minthogy alapból az USB VBUS-ra köti a belső 5V hálózatot, de ha az utóbbira az 5V lábról kerül a tápfesz, akkor szétválasztja a két oldalt hogy az USB 5V-ja ne találkozzon szembe a külső forrás 5V-al... De nem igazán értem hogy a gyakorlatban hogyan is működhet...
-
#9763
fpeter84
senior tag
DrojDtroll
#9762
fpeter84
senior tag
válasz
DrojDtroll
#9762
üzenetére
azt kell lereagálni ha túllép egy küszöbértéket, vagy folyamatosan akarod mérni és loggolni?
-
fpeter84
senior tag
vagy a nodemcu, vagy az arduino lábkiosztása ,vagy egyik sem azonos az esp eredeti gpio láb számozásával...
itt látszik is, hogy a Dn és GPIOn számozás elmászott valamilyen ostoba oknál fogva...
valamiért annó az uno mega korában kitalálták hogy nekik nem jó az hogy PORTA.1 meg PORTC.5, hanem D1, D2, Dn elnevezés kell, és valamiért ezen is hasonlóan átcímkézték a lábakat... Az ESP32 alapú LOLIN32-n már szerencsére nem...
(#9757) csubukaa 9600 a lua firmware baudja, de a bootloader amit az ide-ben kell állítani az eltérő, a videó szerint 115200
-
fpeter84
senior tag
A nodemcu feliratból kiindulva feltehetően AT parancsokra reagáló LUA-s firmware van most rajta. Ha eredeti formájában szeretnéd használni akkor a nodemcu AT command stb kifejezésekre keresve indulj el, ha pedig arduino IDE-ből szeretnéd programozni akkor ezt találtam rá így hirtelen: [link]
-
fpeter84
senior tag
válasz
csubuka
#9743
üzenetére
Sorry, ezt jól benéztem, összekevertem adatfalo viráglocsolós projektjével! Ott lenne elég egy ilyen eszköz a feladatütemezőjével minimális kiegészítéssel! Neked csak akkor, ha még lehet találni neten valami olyan szolgáltatást amivel "ingyen" lehet küldeni SMS-eket...
-
fpeter84
senior tag
válasz
csubuka
#9739
üzenetére
Az említett modulok mind tudják a hanghívást, sms fogadást és küldést, a többi csak extra ezen felül a jövőre nézve!
Nekem egy MR3220 V1 a routerem (egyelőre, bár egy Xiaomi MIR3G már be van tárazva hogy leváltsa), és nálam is extroot-al pendrive adja a tárhelybővítést. A szépséghiba, hogy a mai openwrt már túl kövér, a 4MB-ba épp csak cipőskanállal fér bele és már nincsen hely az USB támogatás utólagos telepítéséhez, de szerencsére ImageBuilder-el előre belerakva még éppen elvan minden ami kell az extroot-hoz...
De ha van net a router alatt és csak ezt a vezérlést végzi, akkor erre sincsen szükség! Minimál rendszerrel bebootol, GPIO lába van elég (IO kártya se kell), egyszerűen crontab-ba beütemezhető hogy kapcsolgassa a GPIO lábait és kész!
-
-
fpeter84
senior tag
Annak lehet jelentősége, hogy a TFT LCD vezérlő csippeken a read / write külön lábakra került? A command / data ugye egyetlen láb két állása, de az írás olvasás valamiért kettő külön lábra... Lehet annak jelentősége hogy mindkettő lábnak idle-nek kell lennie néha, vagy egy tranzisztorral esetleg egyetlen GPIO lábra is rá lehetne kötni őket?
-
-
fpeter84
senior tag
válasz
csubuka
#9724
üzenetére
Szimpla SMS küldésre teljesen alkalmas egy régi telefon - de itt tényleg a régiekről, a nem színes kijelzős őscuccokról beszélünk. Ezeknek az alaplapján / alsó csatlakozóján általában TTL/LVTTL sorosportot lehet elérni, és AT parancsokkal utasítani. A szépséghibájuk hogy SMS küldés / hívás indításon kívül nem igazán lehet továbblépni velük! Egyébként a komplett ipari / riasztó kiegészítő modulokkal is ez a baj: van pár ki/bemeneti lába, pár eseményt le tud kezelni, SMS-t küld és esetleg fogad, de okosabb funkciókra a jövőben képtelen, nem fejleszthető...
Az olyan modulok mint a SIM900, M590E, AiThinker A6/A7 stb modulok általában ennél sokkal többet tudnak: natív parancsok FTP, TCP, UDP, HTTP stb kezelésre, tehát sokkal összetettebb feladatok is könnyedén levezényelhetők vele. Sőt, pl a SIM5320E olyan okos, hogy ő maga ki tudja váltani a mikrokontrollert mert LUA nyelven írt programot lehet rá tölteni és automatikusan futtatni, ami eléri az összes funkcióját és perifériáját! Sajnos picit drága és a tokozása se túl praktikus, sajnálom hogy valami egyszerűbb kisebb olcsóbb verzióban nem készítették el ugyanezt...
Az OpenWrt kérdéshez leírhatnád hogy mid van - gyártó, típus, alverzió - hátha nem olyan nehéz feladat az... Az OpenWrt-s közösség is hasonló építő jellegű szerintem mint ez, szóval hátha. Ráadásul ha USB-s akkor mehet rá akár mobilmodem is, ha nem mindig jön a WAN felől net...
Annyira elhanyagolható áram folyhat a riasztó és a szirénája között, hogy szerintem azt aligha tudod megbízhatóan érzékelni az ACS712-vel! Ráadásul deaktiválni se tudod sehogy távolról az akkus szirénát hiszen annak pont az a lényege hogy szabotázs / vezetékszakadás esetén is megszólaljon! De a vezérlő szálra rá lehet párhuzamosan csatlakozni...
1-3-5e-ért komplett modulokat lehet kapni - olcsóbban még igényel némi kiegészítést, drágábban csak rádugod a tápot vagy rádugod a shieldet az arduino-ra, rácsatlakozol sorosporttal és kérdezgethetsz is tőle egyből AT parancsokkal. Fontos, hogy sok típus nem igazán tolerálja a klasszikus UNO/NANO/MEGA stb 5V I/O feszültségét, ézért vagy felezett órajelű 3.3V-os típust kell keresni ezekből, vagy egyből olyannal indulni ami megfelel az elvárásoknak: Due, STM32, ESP család, stb stb. A shieldek általában lekezelik a jelszintillesztés kérdését...
-
fpeter84
senior tag
válasz
csubuka
#9714
üzenetére
Neked nem hiszem hogy szükséged volna ilyesmire, max valami arduino "kompatibilis" GSM/GRPS modul elég, nem atomreaktort akarsz kapcsolgatni róla
Egyébként kell a mobilnet egyáltalán? Wifin nem lehet csatlakozni az otthoni hálózatra? Mert akkor egy ESP8266/ESP32 is elég lehet, vagy ha valami OpenWrt-képes routered van akár azzal is levezényelhető a feladat! Sőt, akár egy ESP8266 alapú SonOff kapcsolós hálózati aljzattal, okostelefonos app-al magad is vezényelheted távolról a dolgot... Persze abból kimarad akkor az alkotás öröme, de kevesebb a szívás is
(#9715) Teasüti
Ezek millis-el mért szintidők egyes feladatsorok végrehajtása során, tehát minél kisebb annál gyorsabb volt és ezredmásodpercben értendők. Az overall összehasonlítás emiatt nem igazán helytálló, inkább a részeredményeket érdemes összevetni az alapján, hogy a projektedben leginkább milyen feladatok várhatóak!
-
fpeter84
senior tag
Említettem már, hogy imádom a vadászatot a bugtengerben?
Ugye a Due-n a serial.begin nem volt képes visszavenni a hatalmat egy pinMode/digitalWrite művelet után. A változatosság kedvéért az ESP32-n pedig egy serial.begin/serial.end után a pinMode nem képes rendesen bekonfigurálni a GPIO lábakat...
Az illetékes regiszterek amiket kézzel kell beállítani:
GPIO_FUNCx_IN_SEL_CFG_REG
GPIO_FUNCx_OUT_SEL_CFG_REGAz ESP32-n LCD meghajtással pedig végül eddig jutottam:
Kíváncsi volnék, hogy a szimpla vonalhúzás miért ennyivel gyorsabb náluk? Lehet az ott használt ILI9341-nek valami hardveres gyorsítása / trükkje van rá? Bár akkor valószínűleg a screen fill is sokkal gyorsabb lenne, szóval inkább sejtek valamiféle mérési bugot mögötte... Mindenesetre a többi területen észrevehetően gyorsabb parallel módban...
-
fpeter84
senior tag
Igaz, a terhelhetőségét elfelejtettem... Ha kínai UNO / MEGA / Leonardo aminek a táp részén egy az itt látható U5-höz hasonló SOT23-5 tokozású LDO adja a 3.3V ágat akkor 200-250mA a terhelhetősége, ha Due akkor közel 1A minusz amit a proci levesz belőle, ha NANO akkor viszont mivel ott többnyire a CH340 csippből lopják a 3.3V-ot, ezért annak a terhelhetősége max 20-30mA... Szóval szerencsésebb külső forrásról próbálgatni többnyire...
-
fpeter84
senior tag
válasz
csubuka
#9687
üzenetére
Pontosan nem ismerem ezeket a rendszereket, de úgy tudom hogy az ilyen szirénáknak saját akkumulátora van szabotázs esetére - ezért feltételezem hogy a felhúzott láb az alap állapota, valószínűleg 12V és ez megy le földre amikor sípolnia kell - így ha elvágják a vezetékét akkor is megszólal... Mindenesetre ha egy multiméterrel rámérsz és beizzítasz egy riasztást akkor látni fogod hogy mi történik rajta és hány V mellett. 12-t nem köthetsz közvetlenül az arduino-ba, de egy optocsatolón/feszosztón keresztül megoldható.
Esetleg ha a készülékházon / kezelőfelületén van egy visszajelző led ami riasztáskor felgyullad akkor arra is rá lehetne csatlakozni a sziréna helyett! Ha van ilyen, akkor valószínűleg a LED egyik lába a belső 3.3/5V tápon van és a vezérlő a másik lábát földre húzva kapcsolgatja. Ezt akár közvetlenül is be lehet drótozni egy arduino-ba!
Az sms küldés gyerekjáték kategória csak célszerű olyan modemet választani amihez akadnak kezelő library-k - ott alap az sms példaprogram amiből kiindulhatsz...
-
fpeter84
senior tag
Tartok tőle látványos előrelépést már csak úgy lehetne elérni, hogyha volna 16 egy sorba eső láb és 16 bites módban hajtaná meg a kijelzőt, de ahhoz le kéne rugdosni a GPIO 6-11-ről a belső flasht és a fuse bitek átvarázslásával áttenni valahová totál máshová, hogy felszabaduljon a 4-21-ig sorban minden láb, plussz még legalább 3 láb a vezérlésre... De akkor már inkább natív LCD meghajtó porttal és frame bufferrel rendelkező platformot kéne keresni...
(#9686) MrChris
Ha érzed hogy akkor is erősen küzd a megtekerés ellen a tengely amikor éppen nem léptet csak él a rendszer akkor igen, áram alatt van... Egyébként nekem az ilyen nem igazán működött jól - ki kihagyott lépéseket. Most honnan kapja a tápfeszt? Az arduino 5V lábára dugtad? Akkor próbáld meg a 3.3-al...
-
fpeter84
senior tag
Nem elégedetlenkedés, hanem nem szeretem a félmunkát
Fogtam az mcufriend_kbv-t, és elkezdtem kiirtani belőle azt amitől lassú: az univerzálisságot, hogy bármelyik lábra lehetett definiálni bármit. Itt az eredmény:
Ez már egyértelműen látványosan beelőzi a HVSPI-t jópár láb árán... Persze lehet hogy ott is lehetne még mit optimalizálni, kérdés hogy ott a CS mellőzése pl mit eredményez - ha nincsen mellette más az SPI buszon... Mondjuk ott jóval több órajelenként van 1-1 CS váltás, lehet elhanyagolható lenne a különbség...
És működik a hw vertical / horizontal scroll és a due/mega/stm-hez képest a sw scroll is elég gyors! Lévén hogy eldobtam az univerzálisságot ("platformfüggetlenség"), megpróbálom kigyomlálni még belőle ami felesleges, hátha találok közben még pár %-ot valahol
-
fpeter84
senior tag
Opcionálissá tettem a ChipSelect használatát - hiszen ez csak akkor kell ha több kijelző lenne buszba kötve - ez több mint 15%-ot gyorsított rajta és kicsivel beelőzte a HSPI módot!
Az enyémen RM68410 csipp van. Valakinek esetleg van valamilyen más 8bit parallel LCD-je amivel ki tudná próbálni? Illetve esetleg valakit érdekel a dolog, próbálna még agyalni rajta hogy valahol lehet e nyerni pár %-ot?
-
fpeter84
senior tag
Első eredményeim 320x240 felbontásban (ez csak a kijelzőm fele), lehet még tudok rajta itt ott faragni, gyorsítani...
Közben rájöttem, hogy az mcufriend_kbv-ben is van ESP32 támogatás, de elég primitív lassú megvalósítással, a szétszórt lábakat egyesével írja. Én a 12-19-es lábakat sorban vettem D0-D7-nek és csak 12-t kell balra bitshift-elni az adat byte-on és már lehet is írni a set/clear-t...
@ecaddsell: ezek megvoltak, az első hsz-ben is már ott volt, de azért végigpróbáltam a 3 féle lehetőséget amit eddig működőképesnek találtam:
*((volatile uint32_t *) (GPIO_OUT_W1TC_REG)) = x
ESP_REG(GPIO_OUT_W1TC_REG) = x
GPIO.out_wltc = xÉrdekes módon a 3dik észrevehetően, legalább 20%-al gyorsabb mint a másik 2 regiszter elérés, de továbbra is az az érzésem hogy ez messze nem közvetlen elérés hanem csak virtuális, valami köztes rétegen keresztül levezényelve...
szerk: kipróbáltam az mcufriend_kbv ESP32 8bit támogatását is, és tényleg irtó lassú az enyémhez képest: 4 421 642 overall
-
fpeter84
senior tag
Köszönöm a tippeket az ESP32 regisztereivel kapcsolatban - úgytűnik valóban az RTOS keverhet be... Egyetlen butuska tesztprojektet leszámítva - ahol a csipp se stimmelt, az enyémen RM68410 van - nem találtam rendes lib-et a parallel 8bit ESP32-re, ezért nekiestem hogy átfaragjak egy idegen projektet...
Fogtam ezt az STM32_TFT_8bit lib-et ami az Adafruit GFX csomaggal működik együtt, és első körben minden hardverközeli műveletet átírtam pinMode, digitalWrite és digitalRead alapú lassú, de mindennel kompatibilis univerzális megoldásokra és miután meggyőződtem róla hogy ez így nagy lassulással de még mindig működik az STM32-vel, a lábak átcímkézésével lefordítottam az ESP32-re is és működött első pöccre a Lolin32-n is! Nem vagyok hozzászokva, hogy ilyen gördülékenyen menjenek a dolgok, lesz még itt valahol szívás tuti
Az eredmények a graphictest_kbv.ino-t futtatva:
MEGA2560 az MCUFRIEND_kbv lib-el: 37.24 sec
DUE az MCUFRIEND_kbv lib-el: 8.36 sec
STM32F103C az STM32_TFT_8bit lib-el direkt PORTA hívásokkal: 19 sec
STM32F103C a fentiből hekkelt dummy lib-el: 93.6 sec
ESP32 a fentiből hekkelt dummy lib-el: 17.4 secNyilván a 240 vs 72MHz ad némi előnyt az ESP32-nek az STM-el szemben, de a 3.33x órajel mellett 5.38x tempót hoz már így is, bár a DUE-től még messze jár... Ráadásul az STM lib-el se eredeti, se széthekkelt módban nem akar menni a hardveres scroll a demóban, a szoftveres scroll meg halálosan lassú - ennek az okára még jó lenne majd rájönni, feltehetően valahol bizonyos regiszter visszaolvasásoknál lesz a bug...
A következő lépés az lesz, hogy a dummy hívásokat megpróbálom a lehető leggyorsabb direkt ESP32 regiszter hívásokra lecserélni - remélem úgy simán beelőzi majd a DUE-t is...
-
fpeter84
senior tag
Miközben keresem az ideális alap hardvert a projektemhez, most az ESP32-höz érkeztem (azt keresem hogy egy adott LCD-t mivel tudnék a létező leggyorsabban meghajtani)...
AVR-en, STM32-n, ATSAM-en működött simán, hogy egy regiszter aliasra hivatlkozva átírtam az adott regiszter értékét, például:
REG_PIOD_PDR = (REG_PIOD_PSR & 0x00000030);Az ESP32-n viszont mintha ez körülményesebb lenne. A közvetlen elérésre ezt a hibát dobta:
C:\Arduino\ESP32\projects\GPIO_test\GPIO_test.ino: In function 'void set_databits_input()':
GPIO_test:7: error: lvalue required as left operand of assignment
GPIO_ENABLE_W1TC_REG = 0x000FF000;
^
exit status 1
lvalue required as left operand of assignmentA hw könytárban lévő kódokat túrva 2 azonosan működő megoldást találtam eddig:
ESP_REG(GPIO_ENABLE_W1TC_REG) = 0x000FF000;
vagy
GPIO.enable_w1tc = 0x000FF000;Ami viszont nem igazán normális, hogy nem történik meg azonnal a regiszter állítása! Ha abban a pillanatban visszaolvasom a GPIO_ENABLE_REG értékét akkor még az előzőt találom benne, ha berakok 1ms várakozást akkor már azt aminek lennie kell! Mi a fene okozhatja ezt a jelenséget? Így nem igazán lehet kimaxolni a GPIO írás olvasás sebességét közvetlen eléréssel...
-
fpeter84
senior tag
válasz
Janos250
#9620
üzenetére
Igazából az lenne az igazi megoldás ha javítanák a fejlesztők a dolgot, és akkor másnak nem kéne hibavadásznia a jövőben
Megpróbálok utánanézni a bugreportnak hogy hogyan is működik... Mindenesetre ha valaki nagyon unatkozik és van due-ja és digit szkópja vagy saleae logic-ja, akkor megnézné hogy nála is reprodukálódik e a hiba?Serial3.begin(9600);
Serial3.write(0x32);
Serial3.end();
pinMode(14, OUTPUT);
digitalWrite(14,LOW);
delay(100);
digitalWrite(14,HIGH);
delay(100);
Serial3.begin(9600);
//REG_PIOD_PDR = (REG_PIOD_PSR & 0x00000030);
Serial3.write(0x33);A reg piszkálás nélkül nálam nincsen második byte küldés...
-
fpeter84
senior tag
válasz
fpeter84
#9613
üzenetére
Addig vadásztam a regiszterek előtte-utána állapotát hogy sikerült megfejtenem a hiba okát, és biztos vagyok benne hogy ez valamiféle bug lehet... A PIO Status Register-ből (PIO_PSR) kiderült hogy az RX láb újra inicializáláskor átvált PIO letiltott / peripheral active módba, de a TX láb valamiért PIO módban ragad... A PIO Controller PIO Disable Register (PIO_PDR) manuális átbökésével peripheral active módba ismét tudja használni az USART a TX lábát is!
-
fpeter84
senior tag
Sziasztok! Úgy tűnik hogy egy bugba futottam, de nem találok rá gyógyírt guglizva... Szóval adott egy soros protokol amit egy 5 baud-ra lassított címhívással kell nyitni, majd 9600 baud-ra váltva kommunikálni. Az 5 baud-ot úgytűnik se a mega, se a due mikrokontrollerének hw uart-ja nem szereti, ezért szoftverből valósítanám meg delay-ekkel megtüzdelve, de amíg a mega-n működik az hogy serialX.end majd pinmode out, digitalwrite fel/le, a végén pedig seriaX.begin-el újraindítom a kommunikációt, addig a due-n ha először megpiszkálom a lábat digitalwrite-al, utána hiába nyitom meg újra begin-el a sorost, egyszerűen süket marad, nem jön ki egy bit sem a TX lábon, de az RX láb vesz akkor is! Ez nekem egyértelműen buggyanús jelenség, de nem találok rá még csak hivatkozást sem, nemhogy megoldást. Bár mega-n működik a dolog, de én a due-t szeretném ehhez a projekthez használni a jelentősen nagyobb sebessége és több ram/flash-e miatt... Van rá ötletetek hogy mit lehetne vele kezdeni?
-
fpeter84
senior tag
válasz
Teasüti
#7455
üzenetére
és @vargalex
Azért utána matekozva, normál esetben nem tűnik akkora problémának... 3.3V-os környezetben ha pl egy 10K normál és 10K NTC alkot feszosztót, akkor amikor alsó szélső értéken van az NTC akkor is csak 0.33mA folyik, vagyis úgy 1.1mW fűti. Problémává max akkor válhat, ha autós 12-14V-os környezetben egy 1K+1K NTC dolgozik, mert az már egészen számottevő 0.2W-ot fűtene el, de ha felvesszük az értékét annak is 20-100K-ra akkor az is elhanyagolható tartományba esik... Tehát tervezői "hibát" kell véteni ahhoz hogy problémát okozzon a dolog...
@vargalex
A doksija szerint a standby current max 1uA, viszont utána sehol nem találom részletezését hogy hogyan kell standby-ba tenni... Vagy csak annyi hogyha nem kérdezel tőle akkor alszik és gyakorlatilag nulla készenléti árammal várakozik?
-
fpeter84
senior tag
Azthiszem felesleges is tovább rugózni a kérdésen hogy ki hisz a ceónak és ki a mérnöknek - mindenesetre már csak a praktikussági oldalát is nézve szerencsésebb a 3.3-as szenzorokat és shieldeket keresni mert akkor csak 1 tápfeszt kell biztosítani alá és feltehetően a fogyasztás is kisebb lesz. Nem beszélve arról hogy sokszor illik az érzékelőket (pl THT, NTC, PTC) nem is a közös tápfeszre kötni mert "elmelegednek" hanem az egyik IO lábról adni neki a kakaót ideiglenesen a mérés idejére...
-
fpeter84
senior tag
ez valahol hasonló, mint amikor a marketingosztály azt adja parancsba az autóknál hogy márpedig 30-50e km-es olajcsereperiódus kell, a mérnökök meg fogják a fejüket hogyha rajtuk múlna akkor még a 15e-et is inkább csökkentenék... én inkább a mérnököknek hiszek - lehet pesszimisták, és lehet tényleg bírja a többet is valameddig - de mint ahogy az általad linkelt oldalon is említik:
The ESP32 does actually have an internal snapback circuit that protects it from overvoltage; in theory you should be able to feed it a fair amount of volts more. However it stresses the pad silicon (due to increased electron tunneling, iirc) and the long term effects aren't known so it's not in the datasheet.
-
fpeter84
senior tag
akkor a gyári mérnökök biztosan rosszul tudják hogy mit írtak a doksiba, a ceo-nak meg megtanították a kommunikációs szakmunkásképzőben hogy mehet rá az 5V, tehát mehet...
ettől függetlenül lehet az az általános tapasztalat hogy bírja, nem pusztul bele, de attól még nem egészséges és jobb elkerülni egy megfelelő jelszintű érzékelő választásával, vagy feszosztó/jelszintillesztő közbeiktatásával...
-
fpeter84
senior tag
Fizikailag lehet bírja egy darabig, esetleg nem jön ki belőle az éltető füst azonnal, de a specifikációik szerint nem, tehát nem terveznék vele:
ESP8266 - 23. oldal 5.1. Electrical Characteristics - a tápfesz és a VIH is max 3.6V lehet
Az ESP32 picit összetetteb rendszer, itt a lábak a mux-tól függően kaphatják a VIO-t a maggal közös VDD3P3_CPU ágról valamint a VDD_SDIO 1.8-3.3V ágáról is, a táp pedig a 42dik oldal 5.1 Absolute Maximum Ratings szerint max 3.6V lehet
-
fpeter84
senior tag
válasz
ngabor2
#7416
üzenetére
Van ilyenem, de erősen korlátozott hogy mire jó - leginkább nem sokra... 115200 baudos sorost, 100KHz-es I2C-t már nem nagyon bír lekövetni. Láttam olyat amit nem tranzisztorokból/fetekből raktak össze hanem valami cél chip volt a modulon - az talán jobban bírja a tempót!
-
fpeter84
senior tag
Elméletben a PIR-eken lévő BIS0001 (vagy klón) 3-5V tápról is mehet, az ilyen általános kínai modulokon pedig ott szokott lenni egy SOT23-3 tokos, feltehetően LDO csipp, a kimenetre pedig a pdf-ek 3V-ot írnak. Meg kell nézni, ki kell mérni hogy az valóban egy 3.3V-os LDO e? Ha igen, akkor egyszerűen le kell kapni, át kell hidalni, és máris kész a 3.3V-os modul...
-
-
fpeter84
senior tag
válasz
Victoryus
#7287
üzenetére
A kérdéses lib-ekben érdemes nézelődni, mert lehet át lehet konfigurálni hogy 2x2 default helyett 1x4-es felállásban kezelje. A .c és .h fájlokban nézelődj hogy az inicializálásnak vannak e opcionális paraméterei, esetleg lehet e többféleképpen meghívni az init parancsát, vagy fixre égetve is lehet konstans formában. Meg persze az is előfordulhat, hogy nem készítették fel rá...
-
fpeter84
senior tag
válasz
gyapo11
#7284
üzenetére
Szerintem folyamatosan megy a stream függetlenül a tartalmától és a pc oldali szoftver dönti el a 0/1-ekről hogy mit kezd vele - a rajta lévő CY7C68013-ben lévő 8051 mag szerintem nem elégséges szoftveres elemzésre, épp csak az alap I/O funkciók ellátására alkalmas...
Ha aida-val nézed az eszközök > usb eszközök rovatot akkor ott látod majd hogy hogy épül fel, mi miből származik. Dugj sorban a portokra egy felismerhető nevű eszközt, és akkor látod hogy melyik port melyikkel osztozik az erőforrásokon... Egyébként olyat is tapasztaltam már egy notin, hogy a natív portokon xarakodott a saleae, de egy adott hub chippre épülő hubal meg szépen ment - szóval lehet valami kommunikációs időzítési problémák jönnek elő ilyenkor, amin ronthat de akár segíthet is egy köztes pont...
-
fpeter84
senior tag
válasz
gyapo11
#7280
üzenetére
A sebesség csökkentési hiba az általában USB porthoz köthető! Kerüld az USB hub használatát, és ha van elég portod akkor lehetőleg olyanra tedd ahol a root hub-on nincsen senki más csak ő (aida, egyéb programokkal lehet feltérképezni a root hub-okat). Továbbá kerüld az USB 3.0, alternatív USB chipset-hez köthető portokat, lehetőség szerint mindig a natív alaplapi chipsethez tartozó USB 2.0 portokat keresd...
A másik hibaforrás a kínai klónokon lévő EEPROM: ez nem a sebesség, hanem a program indításkori detektálási bizonytalanságot tud okozni. Az eredetire a lehető legalacsonyabb elérési idejű típusokat teszik, és ezt szándékosan ki is használja a szoftver inicializálási rutinja a klónok kiszűrésére. Egyszerűen le kell cserélni az EEPROM-ot pl egy Microchip félére - ez nekem problémamentes volt mindig. Az EEPROM tartalmát pedig vagy külső íróval kell átmásolni, vagy a Cypress USB Console nevű programmal is beleírható, ha nem read only-ra van húzva a RW lába a nyákon...
vagy androidos program a fejegységen? ahhoz se konyítok, eddig a MIT app inventor volt a legmagasabb szint, de abban agyhalál lenne ennyi mindent össze puzzle-özni... ekkor jutott eszembe, hogy mi lenne ha egy ELM327-et emulálva a droidos Torque jelenítené meg a dolgokat? elkezdtem guglizni hogy hogyan is néz ki a protokoll, mi lenne a minimum amivel át tudnám verni az app-ot, erre belefutottam ebbe a szuper kis projektbe... Nano+HC06 BT adapterrel működött is pöcc-röff, de mivel a canbus-ról összeszedett adatokból szeretném etetni, a legkézenfekvőbb az lenne ha a natív BT-s és CAN-es ESP32-vel menne, esetleg a 2 CAN miatt a DUE+HC06... de sajnos sosem álltak össze a fejemben igazán tökéletesen ezek az objektum-orientált dolgok, csak totózok kísérletezek aztán van amikor sikerül ráérezni, de most sehogy sem akar menni...
Új hozzászólás Aktív témák
Hirdetés
ekkold
- BESZÁMÍTÁS! Apple MacBook Pro 14 M4 16GB RAM 512GB SSD garanciával hibátlan működéssel
- BESZÁMÍTÁS! Microsoft XBOX One S 1TB játékkonzol extra kontrollerrel garanciával hibátlan működéssel
- Új! HP 230 Vezetéknélküli USB-s Billentyűzet
- Bomba ár! Fujitsu LifeBook U7310 - i5-10GEN I 16GB I 256SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
- ÖRÖK GARANCIÁVAL - OLCSÓ, LEGÁLIS SZOFTVEREK 0-24 KÉZBESÍTÉSSEL - Windows - Office - LicencAruhaz.hu
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest