- D1Rect: Nagy "hülyétkapokazapróktól" topik
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- Elektromos rásegítésű kerékpárok
- Argos: Szeretem az ecetfát
- zebra_hun: Hűthető e kulturáltan a Raptor Lake léghűtővel a kánikulában?
- Gurulunk, WAZE?!
- eBay-es kütyük kis pénzért
- Parci: Milyen mosógépet vegyek?
-
LOGOUT
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
-
ekkold
Topikgazda
Annak idején amikor ACS712-20 áramszenzorral dolgoztam, akkor volt a legjobban használható, ha sima osztóval állítottam be a féltápot. Nulla áramnál elvileg féltápra áll be, és az áram irányától függően megy ez alá, vagy fölé. Van némi offszethibája, amit szoftveresen próbáltam kompenzálni több-kevesebb sikerrel. Sajnos ez az összes HALL elemmel működő áram szenzorra igaz, és ez korlátozza a felhasználhatóságukat.
Később MCP3221 A/D-vel dolgoztam fel az ACS kimenetét, ez filléres árú, 12bites A/D és egész gyors, azaz sok mintát lehet vele venni rövid idő alatt. Szoftveresen is könnyű a kezelése. Ugyanarról a tápról ment mint az ACS, így volt a legkisebb az offszethiba.
Viszont ezzel lehet a legegyszerűbben leválasztott módon mérni, és ez DC-re is alkalmas. Ezen kívül ha csak AC-re használjuk, akkor a kimenete leválasztható kondival (és máris nincs offszethiba), és lehet AC-ben erősíteni, meg opamp-al preciziós egyenirányítót építeni. Illetve mindez megoldható szoftveresen is, ha van idő elég sok mintát venni és feldolgozni. Viszont csak AC-re, az áramváltók is teljesen jók, sőt talán jobbak is.
Preciz söntöt használva, megfelelő opamp-al erősítve lehet a legpontosabban lehet mérni, de ott viszont nincs leválasztás. Ha ez nem lenne gond, akkor ez lenne a legjobb választás árammérésre.
-
A legpontosabb mérést úgy lehetne elérni, ha
- lm385-2.5 referenciafeszültség-forrást használnál az opamppal, de erősítés nélkül!
- az Arduino ADC-nél pedig a belső 1.1V-os referenciafeszültséget használnád a méréshez referenciaként a default tápfeszültség-referencia helyett.Így az analóg mérés a 0-1.1V közti feszültségekre adna 0-1023 közti értékeket, a mérés pedig tápfeszültségtől és hőmérséklettől függetlenül is pontos lehetne.
-
biker
nagyúr
Csak a szimulátor AC esetén elég érdekes kimenetet produkált, de rájöttem, csak reggel volt, és neki a 3.5V AC az +-3.5V én meg 1.5-3.5V és 2.5V középértékkel kell operáljak
Akkor jó lehet elvileg.
De elvileg, mert 1.5V esetén meg negatív a kimenet az erősítőn. 2.5V a nullapont, ha 5A acs712-re AC-t kapcsolsz 5A akkor a kimenet 1.5V - 3.5V közt oszcillál. Az arduino meg negatívban nem mér, ezért fordítani is kellene, és a negatív is csak pozitiv abs(value)Rohadtul azt hittem, az árammérés lesz a legkönnyebb ebben a projektben...
-
jobban meggondolva egy lm385-2.5 referenciafeszültség-forrás segítségével tápfeszültségtől függetlenül is pontos méréseket lehetne végezni vele.
Még jobban meggondolva
ez nem is igaz. Ha a tápfeszültség nem pontos, akkor a mérés sem lesz pontos, mert az ADC a tápfeszültséget használja referenciaként. Ez esetben a feszültségosztóval pontosabb mérést lehetne végezni. -
stopperos
senior tag
+1 a rail-to-rail-nek. A sima op-amp 0V közelébe sem nagyon tud menni, ahhoz negatív tápfeszültség kell neki.
Én TLV27x -eket használok, attól függően hány darab műveleti erősítő kell egy csomagban (x=1, x=2, x=4).biker: Egy különbség képző műveleti erősítős kapcsolásra van szükséged, továbbá egy 5x erősítésre. Illetve valahonnan kell szerezned pontosan 2,5V-ot. Itt a kapcsolás egy szimulátorban.
Szerk: A 2,5V -ot feszültségosztással tudod 5V-ból előállítani, ehhez stabil 5V-re van szükséged: LP2950CZ-5.0 -
biker
nagyúr
az a helyzet, hogy ahogy nézem, az acs712 legtöbb baján akkor sem tudok segíteni, mint pl mágneses tér érzékenység és társai. Plusz ha meghekkelem egy erősítővel, akkor a nullázást és társait is bonyolítom.
a másik gondom, hogy 1db 3f 100/5A áramváltó annyiba kerül mint 1db 5V kimenetes áramváltó
Kicsit drágább lesz a projekt. Az 5A kimenetesből meg megintcsak problémás lenne 5V-ot kreálni. -
biker
nagyúr
-
biker
nagyúr
Amíg nem volt interrupt a forgóenkóderen addig ha pl 1000ciklusig számolt és átlagolt, akkor addig ugye semmi más nem megy, ami zavaró. Most kipróbálom milyen, hátha így nem gond.
"És ha jót akarsz, gondoskodj a pergésmentesítésről is, mert lassú tekerésnél az is előfordulhat."
Elvileg a delay(1) az megoldja a pergésmentesítést nem?Ami jobban zavar, utálom a próbapaneleket, lehelletnyire se 100% a kontakt ugrál össze vissza az acs712-n a kimenet 2.500 volt helyett +-20mV is lehet, és ez azt jelenti, hogy lévén 5A-es és 100/5 áramváltó megy rá, hogy képes 1-1.5A-t ugrálni. Be kell forrasszak mindent rendesen
Analóg lábon 512 helyett 512-518 közt ugrál, és egy impulzusnyi emelkedés 0,5A ekkora szorzónál. nem gond annyira, mert 1A osztással jelzem ki és számolk vele, mert a léptetést a másik oldalon ugyanilyen mértékben fogadja a másik eszköz, de feleslegesen ne ugráljon. -
biker
nagyúr
Köszi, bizonytalan voltam, mert minden leírásban egy enkóder két lába volt két interruptra kötve, de akkor működhet a ROT1-A = interrupt1(pin2) és ROT2-A = interrupt2(pin3) ?
És a B lábakat meg bármely más definiált pinre köthetem? és írhatom át a kódot megszakításra máris? -
gyapo11
őstag
Hát miben szeretnéd, ha nem C-ben?
Pl.: Hé ardu! Új program. Ha belépek a nappaliba kapcsold föl a villanyt, ha kimegyek, akkor várj 10 másodpercet és kapcsold le ha nem lépett be addig senki.
Régebben törpöltem rajta, hogy lehetne megoldani, hogy abszolút képzetlen emberek is tudjanak programot írni. Nekem a futásidejű értelmező ugrott be, de jó lehet a pc-n fordítás is. A lényeg, hogy a program emberközeli módon legyen írható, egy elektromos ember összeállítja a hw-t, legyen egy hozzárendelő táblázat, ami a hw elemeknek nevet ad (csengő, lámpa-nappali, lámpa-konyha stb.), ezekhez a megfelelő portok legyenek hozzárendelve, és ezután a user írhatja a programot, mikor mi kapcsoljon be vagy ki és milyen feltételek együttállása esetén. Ebből aztán vagy a pc-n futó fordító állít elő futtatható kódot, vagy az arduinon futó értelmező hajtja végre az utasításokat.
Az elektronikát is lehetne valami modulos módszerrel egyszerűsíteni, házilag összerakhatóvá tenni, csak a hozzárendelések lennének az átlagembernek bonyolultak. -
MC Pite
veterán
Különbözőek vagyunk, mindenre van alternatíva
Tizenx éve élveztem mikor a routerben mindent úgy telepítgettem, konfigolgattam össze, (meg több dogot szerettem SCL-be vagy STL-be írni, mert úgy 'szebb') de már ha van egy kis időm, kislányommal vagy egyéb elmaradt dolgokkal foglalkozok, nem akarom a fordítási hibákat x órán át debugolni, ha vannak jól működő modulok amiket már csak fel kell paraméterezni. (És gyárilag már jó AC66U-t használok nas/routernek is, alig van raja add-on.)
Relatív alap igényeim vannak jelenleg (kivételesen ) úgyhogy reményeim szerint ennyit hátrányok nélkül összerakhatok magasabb szinten. -
MC Pite
veterán
Kifejtő: nem tudom minek hívják,extpansion/extension board?, amibe pl csavarozhatom a kimeneteket. Ezekből láttam (vezérlőstül) olyat, amibe már benne az elektronika a 0-10V be/kimenetekhez, stb.
A HVAC kiad 10V-ot, és a bementén várja vissza 0-10V között, ennyin tekeri a ventillátorokat.
Ha a pwmmkimenetre ez rámehet, akkor elég a pwm kimenet. Ha nem, akkor 0-10V kimenet kell a mikrovezérlőre/höz.Nem ismerem a fejlesztők környezetet ezekhez (ezért kérek segítéget), de legetőleg ne C-ben kelljen minde apróságot megírni. Amiket itt láttam példákat, az so-so, ha lenne magasabb szintű, az előnyös lenne.
-
MC Pite
veterán
Köszi, nem tűnik rossznak.
Maga a kifejtők között érdemes olyat keresgélni, amihez már vannak 0-10V áramkörök is, vagy a PWM-re rá lehet küldeni a külső 10V-ot? (Keresgélés közben 'insdustrial' verziókat is láttam, pl a norvi szimpatikus elsőre.)
Beleolvasgatva a topikba elképzelhető hogy ellenállásokkal is kell majd felhúzó ellenállás, stb? (Kisalaktrészekkel mindig bajban vagyok, nem akarok 100db-okat rendelni; meg elég alap villamos ismeretekkel rendelkezem, leírásokat követem, de ha valami nem kerek, akkor jön a pingvinezés.)Viszont: Érdekelne esetleg olyan irány is (ha van), amire van magasabb szintű fejlesztőkörnyezet esetleg. Van ezekre is esetleg ilyen, vagy akkor málnás vonalon kellene nézelődni?
-
Istv@n
aktív tag
Az időket html form-mal, de ott alapból minden mezőnek van értéke. (0, ha nincs beállítva idő) A feldolgozást pedig úgy csinálom, hogy amikor "mentem" az adatokat egy submit gombbal, az elküldött link megfelelő helyiértékeit számmá alakítom és beírom egy tömbbe. (ezek a be / kikapcsolás időpontjai, óra illetve perc). Azért gond a checkbox, mert ha valamelyik nincs kijelölve, akkor az nem küld adatot, és a helyiértékes kiértékelés borul....
-
Tomika86
senior tag
-
Tomika86
senior tag
Igen, tettem.
Most elöször használok esp32-t, de van pár furcsaság számomra.
- Amikor feltöltöm a programot akkor írja hogy connecting, van hogy meg kell nyomni a boot gombot, de legtöbbször nem kellett, ment magától.
- Amit lejebb írtam a hibát se mindig csinálta, volt hogy ugyanazt feltöltöttem és nem rebootolt.
- Nextion kijelzőn vannak mutatós műszerek, ezeknek van bekapcsoláskor egy felfut-lefut programrész a setupban. Ezt meg is csinálja, ahányszor nyomok resetet. De tovább nem megy. Ha a setupba írok egySerial.println("akarmi");
Ezt se írja ki soros monitorra.
Serial.begin(115200);
Serial2.begin(115200);
Megvannak
- megpróbáltam programrészeket kikommentezni, akkor se jó
- sima egyszerű sketch megy rajta. I2c scanner kiírja az ads7828 0x48 címét.
- ha lesz időm kipróbálom csak az i2c adc részt rátölteniBacktrace olyan sorokra mutat ami miatt szerintem nem kellene megállnia. pl. : serial2.begin(115200); és olvasas[tomb] = rpm; erre írja a cpu megállást.
Arduinon ment a program teljesen, egyedül az i2c az új.Esp32nél cpu sebességet kell megadni setupban?
En lábat nem kötöttem sehova, ez nem lehet gond?
Köszönöm a segítséget!
-
And
veterán
Itt annyi történik, hogy a felső dióda vezetni kezd, hogy mekkora áramot, azt a bemenettel soros ellenállás illetve a túlfeszültség mértéke határozza meg. Eleve pár mA-es lehetséges max. árammal szoktak ilyenkor tervezni. A táp (ami eredendően ugye feszültséggenerátor) jó esetben annyival találkozik, hogy a túlfeszültségű forrásból származó minimális árammal csökken az eredeti kimenő árama. Természetesen a soros ellenállásnak és a diódáknak hátrányai is vannak (előbbi enyhén meghamisíthatja mérést, offszetet okozhat), de az ilyen nem precíziós méréseknél általában elhanyagolható.
-
FeniX-
senior tag
Igen, általánosságban gondoltam rá. Csak, mert egyébként az autókban lévő áramkörök zöme (legalábbis régen) be volt öntve gyantába, pont emiatt.
De mondjuk egy sima, mezei közönséges UNO lapka, vagy a kínai klónjai.
Ezt is szerettem volna megkérdezni, hogy mi a leg-hülyebiztosabb csatlakozás? Valaki írta itt korábban, hogy a forrasztás nem túl jó opció.u.i.: ez utóbbi sokszor a próbapadon is megszivat. (a rossz csatlakozás)
-
#15908
tonermagus
aktív tag
Aryes
#15907
tonermagus
aktív tag
Fordítva sajnos komolytalan
Ez vezeték lóg ki belőle ami így előre kerülne...
Az átszámolás már megvan Végső elkeseredésemben átfordítom szoftveresen, de ez így megint nem elegáns..
Amúgy a gondolatmenet jó? sosem programoztam még i2c eszközt, tegnap olvastam először róla hogy léteznek ezek a programozó regiszterek és bitek -
Undoroid
őstag
Köszönöm az eddigi segítségedet!
" a DHT11 csak egész fokokat ad vissza, tizedet nem "
Igen! Az előbb megnéztem az adatlapját és tényleg...viszont most előkaptam egy DHT22-es szenzort, ami egy fokkal jobb lenne erre a célra! Annak használatával mennyit/mit kellene módosítani a fenti kódsorban?
Azért ezt a megoldást kérdezem, mert ha vadászok hozzá egy teljesen másik kódsort, akkor nem biztos, hogy érteni fogom a 'feladat' megoldásának lényegét. Így próbálok tanulni! -
Undoroid
őstag
Szia Aryes!
Végre volt egy kis időm és nekiugrottam ennek a projektnek! Sikerült végre életre kelteni a DHT11, Arduino Nano V3, 2x16-os LCD trióból építhető hőmérséklet- és páratartalom indikáló szerkezetet! A kódja eredetileg UNO-hoz készült, de Nano-val is működik:
#include <LiquidCrystal.h>LiquidCrystal lcd(4, 5, 0, 1, 2, 3);byte degree_symbol[8] ={0b00111,0b00101,0b00111,0b00000,0b00000,0b00000,0b00000,0b00000};int gate=11;volatile unsigned long duration=0;unsigned char i[5];unsigned int j[40];unsigned char value=0;unsigned answer=0;int z=0;int b=1;void setup(){lcd.begin(16, 2);lcd.print("Temp = ");lcd.setCursor(0,1);lcd.print("Humidity = ");lcd.createChar(1, degree_symbol);lcd.setCursor(9,0);lcd.write(1);lcd.print("C");lcd.setCursor(13,1);lcd.print("%");}void loop(){delay(500);while(1){delay(500);pinMode(gate,OUTPUT);digitalWrite(gate,LOW);delay(20);digitalWrite(gate,HIGH);pinMode(gate,INPUT_PULLUP);//by default it will become high due to internal pull up// delayMicroseconds(40);duration=pulseIn(gate, LOW);if(duration <= 84 && duration >= 72){while(1){duration=pulseIn(gate, HIGH);if(duration <= 26 && duration >= 20){value=0;}else if(duration <= 74 && duration >= 65){value=1;}else if(z==40){break;}i[z/8]|=value<<(7- (z%8));j[z]=value;z++;}}answer=i[0]+i[1]+i[2]+i[3];if(answer==i[4] && answer!=0){lcd.setCursor(7,0);lcd.print(i[2]);lcd.setCursor(11,1);lcd.print(i[0]);}z=0;i[0]=i[1]=i[2]=i[3]=i[4]=0;}}
A felmerült hiba megoldása pedig (immár) egyszerű: user error! Ha jobban odafigyeltem volna, akkor hamarabb észreveszem, hogy az Uno- és a Nano annyiban (is) különbözik egymástól, hogy az RX/TX csatlakozásaik fordítva helyezkednek el a PCB-n! Nálam ezt még tetézte az is, hogy erősen használt volt a hozzám került Breadboard és van rajta egy-két pin, ami bizony kontakthibás!Annyi kérdésem lenne még ezzel kapcsolatban, hogy a kijelzett értékeket nem-e lehetne kibővíteni -a programsor módosításával- úgy, hogy a mért értékek egy tizedesértékig lennének kijelezve? Ami biztos, hogy a " C " és a " % " jeleket kettővel el kell mozdítani a jelenlegi helyéről, amit a
set cursorparanccsal lehet megoldani... -
biker
nagyúr
-
Janos250
őstag
"The ULP (Ultra Low Power) coprocessor is a simple FSM (Finite State Machine) which is designed to perform measurements using the ADC, temperature sensor, and external I2C sensors, while the main processors are in deep sleep mode. The ULP coprocessor can access the RTC_SLOW_MEM memory region, and registers in RTC_CNTL, RTC_IO, and SARADC peripherals. The ULP coprocessor uses fixed-width 32-bit instructions, 32-bit memory addressing, and has 4 general-purpose 16-bit registers."
-
Undoroid
őstag
Nem egészen! A programozás lefutása közben a D13-as lábon az addig folyamatos világítás megszakad a pozitív irányra és kb. fél másodpercig bevillan a negatív irányú LED, majd vissza a pozitív ág. Az alaplapon viszont a betáp-LED folyamatosan világít.
Viszont, ha a D13-as pint teszem be a programba, akkor az szépen elkezd felváltva villogni, DE pont ez van akkor is, ha a 21-est teszem aktívvá! Lehet, hogy ez csak valami bug? (mivel elvileg nincs is ennyi kimenete a Nano-nak)
Ami még érdekes volt, hogy az RX(D0) lábat nem tudtam itt aktiválni semmivel*, a LED-ek azt mutatták, mintha a kimeneti láb be se lenne kötve (halványan világított mindkettő)! A TX1(D1) az 1-es szám használatával szépen villogtatta a LED-eket!
Innentől kezdve minden tökéletesen működött egészen az A6-ig! (20 lenne a programsorban a száma) Az A7-es szintén passzív (21 lenne a száma, de arra a 13-as kezd el dolgozni) ...és próbából* beírtam a 22-es számot, arra viszont az alaplapi RX- és a TX egyszerre kezd villogni és a kimeneteik is pont így viselkednek...
Viszont, hogy most alaposabban megnéztem a Nano- és az Uno lábkiosztásait rájöttem, hogy lehetséges
az, hogy összecseréltem a két lapon az RX- és a TX helyzetét (Uno esetén jó volt, de a Nano-nál pont fordítva lehetett)! Ennek ellenőrzésére már csak Péntek délután lesz időm leghamarabb... -
Undoroid
őstag
Első körben csak a 8-as PIN-el próbálkoztam és az szépen -felváltva- villogtatta a két LED-et (természetesen 220Ω-os ellenálláson keresztül) és próbából végiglépkedtem az összes kimeneten! Itt találtam egy anomáliát: a D13-as pinnél (Breadboard használatával dobtam össze a tesztkörnyezetet) a pozitív ágba kötött LED folyamatosan világított
Lehet, hogy valami nem stimmel azzal a kimenettel? pinout ...bár, ezt a hőfok-páratartalom kapcsolás -ha jól emlékszem- pont használja is... A többi kimenet tesztelése folyamatban...és közben nézem a D13-as pin változásait betáp- és Gnd között is!
-
Undoroid
őstag
Üdvözöllek!
Nem, ez nem az! Ezt Én csomagoltam ki a gyári csomagolásából...mivel sokat kísérleteztem már vele, így ki fogom próbálni az ötletedet!
Az egyik gyári programját fogom erre használni:int ledPin=8; //definition digital 8 pins as pin to control the LEDvoid setup(){pinMode(ledPin,OUTPUT); //Set the digital 8 port mode, OUTPUT: Output mode}void loop(){digitalWrite(ledPin,HIGH); //HIGH is set to about 5V PIN8delay(1000); //Set the delay time, 1000 = 1SdigitalWrite(ledPin,LOW); //LOW is set to about 5V PIN8delay(1000); //Set the delay time, 1000 = 1S}Itt alapból a 8-as lábat fogja használni. Ez a kis program alkalmas lesz a többi pin egyszerű tesztjéhez is? ( " a LED a Vcc-digital pin között legyen, és úgy is, hogy a digital pin-GND között. " )
-
-
ekkold
Topikgazda
-
Nincs ASP-m, de mindegy is. A Digiusb Ruby script amúgy tudna vele USB-n kommunikálni (mármint üzeneteket küldözgetni), de az most mindegy.
"Vagy szaladj be a sarki hobbielektronika üzletbe" - ebay-re, mert az itteni egyetlen boltban (munkaidőben van nyitva) szerintem csak rendelésre van, minimum 2000Ft/db
Üres Tiny majd lesz, mert amúgy van, amihez jó lenne. -
Nem érdekes, hogy mi lesz (majd a Logout-on elolvassátok). 2 szervó, meg pár apróság. De USB-t nem használok, azt csak azért kérdeztem, mert könnyebb debug üzeneteket írogatni, ha van valami serial monitor. Szóval rejtély, hogy a 2db szervó miért nem megy softpulse-al.
Amúgy van example 2 szervóra, most próbálom életre lehelni.
-
agent_k
őstag
Arra gondoltam persze...
átnéztem többször, de richtig, hogy elírtam a fő komponens nevét... amateur "csupasz ESP8266"
és erre is simán rátölthetem a kódot és működik ahogy a wemos, küldi az adatot és örülhetek? Energiafogyasztásban van tapasztalatod vagy googli a barátom? -
Az volt a bajom, hogy nem volt egyértelmű, hogy az 5V alatt mit értenek. Ezen is megvan az a lehetőség, hogy ne USB-ről kapja a tápot, és van még egy láb, amit nem tudtam hova tenni.
A VIN egyértelműen egy bemenet, amin a 78L05-re megy a táp, logikus lett volna, hogy az USB is ide jöjjön. És nem, az USB az "5V" nevezetű kimeneten van, ami akármi is lehetett volna, pl. logikusan a 78L05 kimenete. És elég nehéz volt olyan rajzot találni, amin értelmesen megvolt, hogy nem így van : az 5V az USB-ről jön."A szervó lib-nek azért működni kéne rajta, ami attiny85-re készült, csak az időzítések miatt legfeljebb egy kicsit nem lesz pontos."
Le se fordul vele, mert olyan időzítőket használ, ami nincs a Tiny-ban
Ez működött
Meg talán a Servo8bit lett volna jó. -
Ahogy nézem, valahogy semmivel nem kompatibilis, mert tegnap mintha láttam volna némileg eltérő Tiny85 környezetet, ami 8 és 1MHz, de sokkal közelebb van az Arduino-hoz
Csak hirtelen nem jut eszembe, hol.@stopperos : Na ez az, hogy ezt a Digispark Digistump akármit ez lekezelné?
Helyből 16,5MHz, valamelyik TimeLib-re vagy szervós library-re közölte is az IDE, hogy ilyen órajellel nem fog menni, stb.
Meg mire rájöttem/kitúrtam, hogy a táp hogyan van összerakva... -
Ja, azt tudtam, hogy nem hivatalosan támogatott, de azért igen WTF
Meg gondoltam legalábbis kb. akkor fog hátast dobni, ha 13-as pint akarok beállítani, mert olyan nincs neki -> de ez teljes agyhalál (Pláne ez a teljesen barom módon kitalált Digispark cucc.)
Végülis lett szervó, de az már biztos, hogy az Arduino-s kódot írhatom újra hozzá (Eredetileg arra készült, aztán néztem, hogy elég oda egy Tiny, azon helyből megoldott az USB is, miért ne.)
Kösziasegítséget -
USB, elvileg ugye úgy menne, hogy Digistump 16,5MHz (gondolom a Digistamp-et hallotta félre valaki), feltöltés gomb, modul rádug, és működik. Simán csak
"A vázlat 700 bájt (11%)-ot használ a program tárhelyből. A maximum 6012 bájt.A globális változók 9 bájtot használnak a dinamikus memóriából.Running Digispark Uploader...Plug in device now... (will timeout in 60 seconds)micronucleus: library/micronucleus_lib.c:66: micronucleus_connect: Assertion `res >= 4' failed.Aborted (core dumped)"
Mondjuk rootként még nem néztem... Mintha nem tudna kapcsolódni. -
Undoroid
őstag
Sajnos valami nem stimmel a rendelkezésemre álló Nano-val! Továbbra is csak az "egysoros-telikarakteres" kijelzést produkálja. Életjel van, mert a kontroláló LED-ek ütemesen villognak a Nano-n. Ugyanazzal az összeállítással* (csak a mikrovezérlő más) Unoval szépen muzsikál minden, ugyanazzal a programmal. Más programmal hibátlanul működik ez a Nano...
* 16x2-es LCD, breadboard, DHT11 szenzor, 10Kohm poti, bekötővezetékek, betáp: PC USB-portja
-
#15759
Drótszamár
őstag
Aryes
#15757
Drótszamár
őstag
Ez egy kombi szenzor modul, SHT-30 és QMP6988 szenzorok ülnek az i2c buszon.
Az SHT-30 rendben működik 3,3V-on és 5V-on is mindkét eszközzel. A gyártó 5V-ot írt a szenzor modulhoz, maga a QMP6988 1.71V és 3.6V között működik a gyári doksi szerint.Viszont adtál egy ötletet. Hétvégén összenézem a nyers légnyomás adatokat mindkét eszközön.
Ha azok egyeznek, akkor a kiolvasás jó.
A nyers adatokkal és a kalibrációs adatokkal még varázsol egy csomó mindent a library. Szorozgat, osztogat, meg shiftel össze-vissza. Nekem még mindig az a gyanús, hogy valahol kicsúszik az érték a longból.Itt rakja össze a végleges értéket:
Egyelőre fingom sincs, mit és miért csinálQMP6988_S32_t QMP6988::getPressure02e(qmp6988_ik_data_t *ik, QMP6988_S32_t dp, QMP6988_S16_t tx){QMP6988_S32_t ret;QMP6988_S64_t wk1, wk2, wk3;// wk1 = 48Q16 // bit sizewk1 = ((QMP6988_S64_t)ik->bt1 * (QMP6988_S64_t)tx); // 28Q15+16-1=43 (43Q15)wk2 = ((QMP6988_S64_t)ik->bp1 * (QMP6988_S64_t)dp) >> 5; // 31Q20+24-1=54 (49Q15)wk1 += wk2; // 43,49->50Q15wk2 = ((QMP6988_S64_t)ik->bt2 * (QMP6988_S64_t)tx) >> 1; // 34Q38+16-1=49 (48Q37)wk2 = (wk2 * (QMP6988_S64_t)tx) >> 8; // 48Q37+16-1=63 (55Q29)wk3 = wk2; // 55Q29wk2 = ((QMP6988_S64_t)ik->b11 * (QMP6988_S64_t)tx) >> 4; // 28Q34+16-1=43 (39Q30)wk2 = (wk2 * (QMP6988_S64_t)dp) >> 1; // 39Q30+24-1=62 (61Q29)wk3 += wk2; // 55,61->62Q29wk2 = ((QMP6988_S64_t)ik->bp2 * (QMP6988_S64_t)dp) >> 13; // 29Q43+24-1=52 (39Q30)wk2 = (wk2 * (QMP6988_S64_t)dp) >> 1; // 39Q30+24-1=62 (61Q29)wk3 += wk2; // 62,61->63Q29wk1 += wk3 >> 14; // Q29 >> 14 -> Q15wk2 = ((QMP6988_S64_t)ik->b12 * (QMP6988_S64_t)tx); // 29Q53+16-1=45 (45Q53)wk2 = (wk2 * (QMP6988_S64_t)tx) >> 22; // 45Q53+16-1=61 (39Q31)wk2 = (wk2 * (QMP6988_S64_t)dp) >> 1; // 39Q31+24-1=62 (61Q30)wk3 = wk2; // 61Q30wk2 = ((QMP6988_S64_t)ik->b21 * (QMP6988_S64_t)tx) >> 6; // 29Q60+16-1=45 (39Q54)wk2 = (wk2 * (QMP6988_S64_t)dp) >> 23; // 39Q54+24-1=62 (39Q31)wk2 = (wk2 * (QMP6988_S64_t)dp) >> 1; // 39Q31+24-1=62 (61Q20)wk3 += wk2; // 61,61->62Q30wk2 = ((QMP6988_S64_t)ik->bp3 * (QMP6988_S64_t)dp) >> 12; // 28Q65+24-1=51 (39Q53)wk2 = (wk2 * (QMP6988_S64_t)dp) >> 23; // 39Q53+24-1=62 (39Q30)wk2 = (wk2 * (QMP6988_S64_t)dp); // 39Q30+24-1=62 (62Q30)wk3 += wk2; // 62,62->63Q30wk1 += wk3 >> 15; // Q30 >> 15 = Q15wk1 /= 32767L;wk1 >>= 11; // Q15 >> 7 = Q4wk1 += ik->b00; // Q4 + 20Q4//wk1 >>= 4; // 28Q4 -> 24Q0ret = (QMP6988_S32_t)wk1;return ret;} -
Undoroid
őstag
Remek!
" a NANO ugyanazt a μC-t tartalmazza, minden UNO példaprogram változtatás nélkül fut " Pont ezzel próbálkoztam az UNO után! A méretre vágott próbapanelon szépen el tudtam volna tenni a mikrovezérlőt a kijelző mögé, de sajnos valami nem stimmelt (dugaszolós panelon) . A kijelzőn csak egy sor "telekarakteres" kijelzést tudtam megjeleníteni. Nyilván itt Én rontottam el valamit.
Újra fogom próbálniszerk: Kalapács... Neeem, de láttam pár olyan megoldást a világhálón, ami kb. ezen szerszám használatával egyenértékű volt! Pusztítás és azután csodálkozás, hogy nem megy a masina!
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Undoroid
őstag
Üdvözöllek!
" ...komponenseket némileg "hülyeállóvá" kell tenni, vagyis, hogy ne lehessen fordítva összedugni... " Ez pontosan így is van! Nem szimmetrikusan helyezkednek el a csatlakozások, ezért fordítva nem lehet összerakni! ...bár megfelelő méretű kalapács segítségével mindent meg lehet szakérteni!
Tehát az UNO két oldalán vannak elhelyezve a csatlakozások. Két-két csatlakozó aljzat van felszerelve. Az első pár között a szabványos 2.54mm távolság van és ezért ez akár lehetett volna egy, folyamatos...viszont a másik csatlakozó (szintén két nem egyforma darabból áll) viszont az egymással határos pontjai nem 2.54mm-re vannak egymástól, hanem legalább 0.5mm-el messzebb! Így a szabványos raszterre -előre kifúrt- próbapanel pontjai sohasem fognak egyszerre stimmelni! Holnap délelőtt -ha kell- akkor lefotózom a problémát! Úgy látni fogod a gondot!
Ha van kéznél egy UNO és egy tolómérő, akkor mérj meg minden csatlakozási pontot, egyforma távolságra lesznek egymástól az egymás mellett lévő pinek...KIVÉVE a 7. és a 8. pin! Itt van elválasztva egymástól a két csatlakozó aljzat, és ha akarod sem tudod úgy összerakni, ahogyan azt kellene! ...esetleg kalapáccsal...
-
Tomika86
senior tag
-
Tomika86
senior tag
GPIO12 és 0: FET kapcsol 12V-os Relét
GPIO14 és 15: Egyik 10kohm-al földre van húzva és nyomógomb van a 3,3 és bemenet között.
Másikon az LM1815 IC kimenete van sorosan 1kohm-al.
SD kártya többi lába olyan GPIO lábon van ami nem ad semmit boot esetén
GPIO 2: 470ohm előtéttel földre van kötve a LEDJó lenne ha még 5db GPIO lenne a panelon
-
gyapo11
őstag
Esetleg a fw-rel azonos nagyságú tesztprogramot futtatni, ami végiglépked és ír mindent serialra? Hátha flash hiba, ramhiba, eepromhiba, szóval valami időnkénti hw hiba. Ha igen, akkor akár egy másik arduino, beletöltve a fw, és már jó is. Ha az egyéb részekben van hiba, akkor persze ez nem segít.
-
doberman
senior tag
Nagyon köszönöm a gyors választ! (weiss-nek is).
ez már 3.0.3 verzió.. elméletileg a gyerekbetegségeken már túl van. akkor marad a szerelési hiba - kalandra fel, elő a forrasztó állomást, végig nézem mikroszkóppal... ja egyébként akkuról megy -mikor épp olyan kedve van. (egyébként többen panaszkodnak egy fb fórumon, de még többen megelégedve használják - megoldást meg nem nagyon írtak)
még1x köszi! -
Undoroid
őstag
Köszönöm a válaszokat!
Egy "kis" változás lesz az egészben, mert képbe került egy 4x20-as kijelzőmodul, i²c -csatolással. Így viszont simán megférne a kijelzőn egyszerre is a 4db mért érték!
A riasztási kimenetek pedig felejtősek! Így talán egyszerűbben megoldható lenne a projekt... -
ekkold
Topikgazda
Nem tudom mennyire extra, vagy értékes az a program, de lehet, hogy a hardver ismeretében viszonylag könnyen megírható egy másik program az adott funkciókra. A programozó lábak levágása a prociról némi hekkeléssel még kezelhető: pl. kis köszörülés a tokon, ahol a láb befelé folytatódik, és vékony szál odaforrasztása... Némelyik kollégámnak ez sima rutinfeladat lenne
A lényeg: a védelemnek csak olyan szintűnek kell lennie, ami a program értékének megfelelő. Tehát elegendő ha a védelem megkerülése több munka, mint másik programot írni, és akkor nem fog senki sem foglalkozni a feltörésével - egyszerűen azért, mert nem éri meg.
Amit Géza írt lentebb, általában az is elegendő, és teljesen jó megoldás. -
-
Tomika86
senior tag
-
Tomika86
senior tag
Erre gondolok hogy az Unoból ered a 0ra ugrás.
De a bonyolultabb program nem mozog, csak 0ra ugrik letekerésnél. A letekerést úgy érsd hogy 6000es fordulatról hirtelen 4000re,akkor leesik 0ra egy pillanatra.A másik viszont ugrál kettő érték között.
Adcre tettem aluláteresztő szűrőt, de gondolom nem elég.
-
Tomika86
senior tag
Kipróbáltam több értékkel a tömb elemeit, most már csak annyi van, ha hirtelen tekerem le a potmétert akkor leesik egy pillanatra a mutató, akár 0-ra is.
De szerintem ez az uno baja, amivel a négyszögjelet állítom be, a frekvenciát pedig analóg úton változtatom.
Ez viszont ugrál két pont között, pl 1500-1800 két értéken. [link] -
Tomika86
senior tag
// Fordulatszám méréshez
const int hallPin = 2; // pin 2 = int 0
volatile unsigned long cntTime = 0;
volatile unsigned long cnt = 0;
volatile unsigned long rpm = 0;
unsigned long readings[numReadings];
unsigned long readIndex;
unsigned long total;
unsigned long average;
const byte numReadings = 2;
unsigned long measureTime = 0, curTime, startTime = 0;
int dispCnt = 0, measureCnt = 0;
const int resetTime = 2000;
const int minRotNum = 1; // 1 - calc after every rotation
void loop()
{
curTime = millis();
if ( curTime - cntTime > resetTime) // reset when less than 30RPM (dt>2s)
{
cnt = measureCnt = 0;
rpm = 0;
}
if (cnt == 1) startTime = cntTime;
if (cnt - measureCnt >= minRotNum) {
rpm = 60000L * (cnt - measureCnt) / (cntTime - measureTime);
measureCnt = cnt;
measureTime = cntTime;
}
// Smoothing RPM:
total = total - readings[readIndex];
readings[readIndex] = rpm;
total = total + readings[readIndex];
readIndex = readIndex + 1;
if (readIndex >= numReadings)
{
readIndex = 0;
}
average = total / numReadings;
}
void doCount()
{
cnt++;
cntTime = millis();
} -
Tomika86
senior tag
Ehhez [link]pedig ezt a részét használtam fel:
// Smoothing RPM:
total = total - readings[readIndex]; // Advance to the next position in the array.
readings[readIndex] = RPM; // Takes the value that we are going to smooth.
total = total + readings[readIndex]; // Add the reading to the total.
readIndex = readIndex + 1; // Advance to the next position in the array.
if (readIndex >= numReadings) // If we're at the end of the array:
{
readIndex = 0; // Reset array index.
}
average = total / numReadings; // The average value it's the smoothed result.RPM a bemeneti nyers fordulat. average a kimeneti megjelenített, de ugrál a mutató
Egyébként pontos, Frekvencia * 60 jelenik meg mindkettő esetében -
Tomika86
senior tag
Ez a bonyolultabb mérés, ez a hirtelen változásokra van hogy lemegy 0-ra is, meg összevissza ugrál ilyenkor:
const byte PulsesPerRevolution = 2;
const unsigned long ZeroTimeout = 100000; // For high response time, a good value would be 100000.
// For reading very low RPM, a good value would be 300000.
// Calibration for smoothing RPM:
const byte numReadings = 2; // Number of samples for smoothing. The higher, the more smoothing, but it's going to
// react slower to changes. 1 = no smoothing. Default: 2.
/////////////
// Variables:
/////////////
volatile unsigned long LastTimeWeMeasured; // Stores the last time we measured a pulse so we can calculate the period.
volatile unsigned long PeriodBetweenPulses = ZeroTimeout+1000; // Stores the period between pulses in microseconds.
// It has a big number so it doesn't start with 0 which would be interpreted as a high frequency.
volatile unsigned long PeriodAverage = ZeroTimeout+1000; // Stores the period between pulses in microseconds in total, if we are taking multiple pulses.
// It has a big number so it doesn't start with 0 which would be interpreted as a high frequency.
unsigned long FrequencyRaw; // Calculated frequency, based on the period. This has a lot of extra decimals without the decimal point.
unsigned long FrequencyReal; // Frequency without decimals.
unsigned long RPM; // Raw RPM without any processing.
unsigned int PulseCounter = 1; // Counts the amount of pulse readings we took so we can average multiple pulses before calculating the period.
unsigned long PeriodSum; // Stores the summation of all the periods to do the average.
unsigned long LastTimeCycleMeasure = LastTimeWeMeasured;
unsigned long CurrentMicros = micros();
unsigned int AmountOfReadings = 1;
unsigned int ZeroDebouncingExtra; // Stores the extra value added to the ZeroTimeout to debounce it.
// The ZeroTimeout needs debouncing so when the value is close to the threshold it
// doesn't jump from 0 to the value. This extra value changes the threshold a little
// when we show a 0.
// Variables for smoothing tachometer:
unsigned long readings[numReadings]; // The input.
unsigned long readIndex; // The index of the current reading.
unsigned long total; // The running total.
unsigned long average; // The RPM value after applying the smoothing.
void setup() // Start of setup:
{
Serial.begin(9600); // Begin serial communication.
attachInterrupt(digitalPinToInterrupt(2), Pulse_Event, RISING); // Enable interruption pin 2 when going from LOW to HIGH.
delay(1000); // We sometimes take several readings of the period to average. Since we don't have any readings
// stored we need a high enough value in micros() so if divided is not going to give negative values.
// The delay allows the micros() to be high enough for the first few cycles.
} // End of setup.
void loop() // Start of loop:
{
LastTimeCycleMeasure = LastTimeWeMeasured; // Store the LastTimeWeMeasured in a variable.
CurrentMicros = micros();
if(CurrentMicros < LastTimeCycleMeasure)
{
LastTimeCycleMeasure = CurrentMicros;
}
// Calculate the frequency:
FrequencyRaw = 10000000000 / PeriodAverage; // Calculate the frequency using the period between pulses.
// Detect if pulses stopped or frequency is too low, so we can show 0 Frequency:
if(PeriodBetweenPulses > ZeroTimeout - ZeroDebouncingExtra || CurrentMicros - LastTimeCycleMeasure > ZeroTimeout - ZeroDebouncingExtra)
{ // If the pulses are too far apart that we reached the timeout for zero:
FrequencyRaw = 0; // Set frequency as 0.
ZeroDebouncingExtra = 2000; // Change the threshold a little so it doesn't bounce.
}
else
{
ZeroDebouncingExtra = 0; // Reset the threshold to the normal value so it doesn't bounce.
}
FrequencyReal = FrequencyRaw / 10000; // Get frequency without decimals. This is not used to calculate RPM but we remove the decimals just in case you want to print it.
// Calculate the RPM:
RPM = FrequencyRaw / PulsesPerRevolution * 60; // Frequency divided by amount of pulses per revolution multiply by 60 seconds to get minutes.
RPM = RPM / 10000; // Remove the decimals.
// Smoothing RPM:
total = total - readings[readIndex]; // Advance to the next position in the array.
readings[readIndex] = RPM; // Takes the value that we are going to smooth.
total = total + readings[readIndex]; // Add the reading to the total.
readIndex = readIndex + 1; // Advance to the next position in the array.
if (readIndex >= numReadings) // If we're at the end of the array:
{
readIndex = 0; // Reset array index.
}
average = total / numReadings; // The average value it's the smoothed result.
Serial.print("\nRPM: ");
Serial.print(RPM);
Serial.print("\tTachometer: ");
Serial.println(average);
}
void Pulse_Event() // The interrupt runs this to calculate the period between pulses:
{
PeriodBetweenPulses = micros() - LastTimeWeMeasured; // Current "micros" minus the old "micros" when the last pulse happens.
// This will result with the period (microseconds) between both pulses.
// The way is made, the overflow of the "micros" is not going to cause any issue.
LastTimeWeMeasured = micros(); // Stores the current micros so the next time we have a pulse we would have something to compare with.
if(PulseCounter >= AmountOfReadings) // If counter for amount of readings reach the set limit:
{
PeriodAverage = PeriodSum / AmountOfReadings; // Calculate the final period dividing the sum of all readings by the
// amount of readings to get the average.
PulseCounter = 1; // Reset the counter to start over. The reset value is 1 because its the minimum setting allowed (1 reading).
PeriodSum = PeriodBetweenPulses;
// Remap period to the amount of readings:
int RemapedAmountOfReadings = map(PeriodBetweenPulses, 40000, 5000, 1, 10); // Remap the period range to the reading range.
// 1st value is what are we going to remap. In this case is the PeriodBetweenPulses.
// 2nd value is the period value when we are going to have only 1 reading. The higher it is, the lower RPM has to be to reach 1 reading.
// 3rd value is the period value when we are going to have 10 readings. The higher it is, the lower RPM has to be to reach 10 readings.
// 4th and 5th values are the amount of readings range.
RemapedAmountOfReadings = constrain(RemapedAmountOfReadings, 1, 10); // Constrain the value so it doesn't go below or above the limits.
AmountOfReadings = RemapedAmountOfReadings; // Set amount of readings as the remaped value.
}
else
{
PulseCounter++; // Increase the counter for amount of readings by 1.
PeriodSum = PeriodSum + PeriodBetweenPulses; // Add the periods so later we can average.
}
}
Akkor jó lehet elvileg.
ez nem is igaz. Ha a tápfeszültség nem pontos, akkor a mérés sem lesz pontos, mert az ADC a tápfeszültséget használja referenciaként. Ez esetben a feszültségosztóval pontosabb mérést lehetne végezni.
Lehet, hogy valami nem stimmel azzal a kimenettel? 
Lehet, hogy a lábkiosztás nem stimmel?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
ekkold- Szeged és környéke adok-veszek-beszélgetek
- PlayStation 5
- Kazy Computers - Fehérvár - Megbízható?
- Villanyszerelés
- Házi hangfal építés
- Egyéni arckép OFF
- Stellar Blade
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- CPU léghűtés kibeszélő
- Teljes verziós játékok letöltése ingyen
- További aktív témák...
- LENOVO ThinkBook 13s - 13.3" FullHD IPS - i5-10210U - 8GB - 256GB SSD - Win11 - MAGYAR
- Alkatrészt cserélnél vagy bővítenél? Nálunk van, ami kell! Enterprise alkatrészek ITT
- Lenovo LEGION Pro 5 / Pro 7, Lenovo Yoga Pro gépek (RTX 4060 / 4070 / 4080 / 4090)
- Új! Targus - USB-C Dual HDMI 4K HUB - 2 HDMI-vel. Saját töltő nélkül 2 monitorral (120Hz)
- 130+131+132+133 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4080
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged