- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Bluetooth hangszórók
- Azonnali fotós kérdések órája
- Raspberry Pi
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Szünetmentes tápegységek (UPS)
- Nem indul és mi a baja a gépemnek topik
- AMD Navi Radeon™ RX 9xxx sorozat
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
-
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
-
Janos250
őstag
válasz
Teasüti
#11831
üzenetére
Igen, egy méteren belüli pontosságot tud. Én ezt úgy írtam - ahogy szokás - hogy deciméteres pontosságot tud, tehát a hiba egyszámjegyű deciméterben kifejezve.
A koordináta rendszerre meg pontosan az igaz, amit leírtál.
Nem lényeges, hogy ténylegesen mi a valódi koordináta, mert úgyis attól relatív lesz, tehát egy tetszőleges pontot tekinthetsz origónak.
Majd ha lesz időm, egy picit részletesebben is leírom. -
#11807
tonermagus
aktív tag
Teasüti
#11806
tonermagus
aktív tag
-
Gergosz2
veterán
válasz
Teasüti
#11747
üzenetére
igen, a 127Unak van köze hozzá.
Milyen képet mutat a logic analizer más kitöltésnél? Mondjuk 25%-on?
A csatorana 25% duty-val menne,és mivel B a negáltja így az 75%-on.A célom az volna, hogy minél kevésbé rángassa meg a tápot, mert az meg nem tudja szabályozni a kimenetét és alkalmanként némi vibrálást követően le is kapcsol. Próbáltam default-nál (~500 Hz) gyorsabban is hajtani, de ez nem oldotta meg a gondot, ellenben csúnyán elkezdett forrósodni a pwm meghajtó.
Egy kapcsolási rajz nem ártana.
-
Gergosz2
veterán
válasz
Teasüti
#11739
üzenetére
Szia!
Nem írtad milyen frekin szeretnéd járatni, de ha minden igaz ezt keresed:
50%-os kitöltési tényezőnél egymásnak az inverze legyen a két csatorna.
void PWM_setup(void)
{
TCCR0A = B10110001;
TCCR0B = B00000001;
OCR0A = 127U;
OCR0B = 127U;
}
void GPIO_setup(void)
{
pinMode(5,OUTPUT);
pinMode(6,OUTPUT);
}
void setup() {
// put your setup code here, to run once:
GPIO_setup();
PWM_setup();
}
void loop() {
// put your main code here, to run repeatedly:
}8 bites timerre húztam ezt fel, de van egy 16 bites is ha nagyobb felbontás kell. Nem pont 50%- ez, de almost, de az is pöccre re belőhető. Gyorsan ezt dobtam össze.
-
-
válasz
Teasüti
#11069
üzenetére
Sejtettem.
De megnéztem mégegyszer a kódot, és megvan a hiba.
pinMode(button, INPUT_PULLUP);
}
void loop ( )
{
bool buttonState = digitalRead(button);
if (buttonState == HIGH)
{Stateállapota, mivel adigitalRead(button);mindig magas értéket ad, de a gomb azINPUT_PULLUPmiatt eleve magasan van.
if (buttonState == LOW)esetén a kód működni fog, persze ha a gomb jól van bekötve.
-
DigitXT
félisten
válasz
Teasüti
#10957
üzenetére
Ez lehet nem a beolvasok egy négyszögjelet kategória.
Az biztos... De annál jobb kihívás!
a felfutó és lecsengő éleket is figyelem
Akkor neked vmi utófeldolgozott jeled van, mert a VR szenzor jele elég ocsmány.
Ha úgy tetszik, ez sem a beolvasok egy négyszögjelet kategória. (Erre a Maxim
MAX9924-et terveztem bevetni pár éve. De jól felsültem az SMD forrasztással.
)A vicc az, hogy amit most használok jelátalakító, az a dízelek injektorvezérlését
nézegető kütyü, amit teljesen más jelre alkalmaztam. A jelalak nagyon hasonló:
-
DigitXT
félisten
válasz
Teasüti
#10955
üzenetére
Okés, megértettem, csak gondoltam megosztom a gondolataimat, azaz ha
már mindent IS figyelsz a motoron, fontos(abb) paramétereket is nézhetnél,
mint mondjuk a kuplung figyelése. Nem is értem, hogy az mire jó, de sebaj.Én is raktam be csipogót indexre, meg korrekt visszajelzést a műszerfalba,
így nem felejtem kint. Ehhez kondi kellett és relé.Mikrokontroller pont nem.Szerk: ne csak offoljak... Az alábbi ábrán nem tetszik a fordulatszámjel: jól
láthatóan lépcsős (hiszen másodpercenként összegzi csak), és késik is a
valósághoz képest (ami valóságot pl. jól modellezi az olajnyomásmérő jele).
Továbbá 2000 rpm alatt nullát mér (ez a jelátalakító hibája, ami 5V alatt nem
triggerel). Na most. A terv az, hogy LM2917-tel analóg feszültségjelet állítok
elő, azt bevezetem (egy szabad ADC-n) a logba, és voilá!. Kérdés, sikerül-e.
És ha igen, akkor miért nem. Elég gyors lesz-e, pontos lesz-e, meg ilyenek. -
DigitXT
félisten
válasz
Teasüti
#10952
üzenetére
a piros lámpa a műszeregységen bőven elég a feladatra
Hát ez egy igen nagy tévedés, sajnos. Ha az világít fordulaton,
akkor a motornak már reszeltek. Bővebben: link Amúgy, azok
után amiket felsoroltál, az olajnyomásmérő ujjgyakorlat lenne:
egyszerű feszmérés. (Van belőle digitális, jeladós cumó, de
a hagyományos ellenállásos is teljesen jól használható.
)
Most mondjam azt, hogy nekem van mindkettő? Igen, van...
Gyári olajnyomásgomba meg kuka, mert az annyit ér.Fogyasztásméréshez az injektor vezérlését tudod monitorozni.
Szerintem baromi hasznos cucc, feltéve, hogy elég pontos.
(Nekem sajnos karbis a motor, így én áramlásmérővel sz*pok.)TPMS-ből én tavaly szereltem szelepsapkást: tökéletes. Na jó,
kis hibája, hogy álló helyzetben nem frissül, így másnap reggel
a tegnap esti nyomást / hőmérsékletet látom. Mozgásra frissül.
Viszont azóta nem kellett fújni a gumit: külön nézegetni sem.
-
Janos250
őstag
válasz
Teasüti
#10952
üzenetére
"Olajnyomás"
https://www.ebay.com/itm/0-3m-Wire-Pressure-Transducer-or-Sender-Sensor-for-Oil-Fuel-Diesel-Gas-Air-Water/172992432465?hash=item2847270951:m:m6lmraNbOpqMwaLfpGJ7qPg
Ehhez is kell ADC. Nekem bevált, de kalibrálni célszerű.Én autó benzinpumpa menet közbeni hibakereséshez használtam pár ével ezelőtt. Mobiltelefonon mutatta az aktuális benzinnyomást.
A fogyasztás mérésre én is kíváncsi lennék. A gyári megoldások - tudtommal - az injektor jeléből számítják, mert az áramlásmérők olyan pontatlanok, hogy a visszafolyás miatt használhatatlan a jelük.
-
válasz
Teasüti
#10903
üzenetére
Én állapotgéppel csinálnám, akkor semmit nem kell bonyolítani a beolvasáson, csak olvasod szépen sorba a tokeneket. Ha Gxx érkezik, az állapotgép átbillen paraméter állásba, így a következő beolvasások mind az előző parancs paraméterei közé kerülnek, és ha újra Gxx érkezik, akkor az állapotgép visszabillen parancs állásba, ekkor hajtod csak végre az előző parancsot az összes paraméterével együtt.
-
válasz
Teasüti
#10901
üzenetére
Ha jól értem, te nem akarsz kompatibilis lenni semmivel, hanem építesz egy saját protokollt egy meglévő alapján. Vagyis amíg kerested rá a megoldást a kódban, akár meg is írhattad volna.
A leírás alapján nagyon egyszerűnek tűnik a megoldás, csinálni kell egy tömböt, amiben leírod, hogy a G01 után lesz még két paraméter, és akár betűtől függetlenül a következő kettőt beolvassa, legyen X0 Y0 vagy akár újra G0 G0 (vagy használd csak erre az X Y betűket és akkor még hibaellenőrzésre is használhatod). -
DigitXT
félisten
válasz
Teasüti
#10862
üzenetére
Nem, ez a Stepper könyvtár használata. (Az analóg km óra bemenete közvetlen
a léptetőmotort hajtja: a sebességjeladó négyszögjele a digitális órára megy, az
vezérli ki az analógot... De azt nem etethetem kamu jelekkel, mert nem akarom
eltekerni mért a távot. Jelige: mégegyszer nem! Lásd SpeedoHealer tesztelése.)aryes: egyelőre nem is kell értelmezned, majd ha kérdésem is lesz, akkor.
Szerk: de nem akarok bunkó lenni, ha esetleg annak tűnne. Röviden: volt egy
mechanikai hiba az órámban, ami miatt a mutató elakadt, így a léptetőmotor az
adott helyzetből csak felfelé tudta mozdítani, lefelészinteegyáltalán nem. Mivel
ezt a hibát elvileg elhárítottam, nem ártott az is letesztelni, hogy most már jó-e?
S nem úgy, mint legutóbb, hogy elindulok vele, és csak menet közben láthatom,
hogy felakad, vagy sem... Sajnos a gyári vezérlő nem játssza végig azt a ciklust
minden gyújtásráadáskor, amit animált GIF-ként beraktam: ezért kellett az UNO. -
DigitXT
félisten
válasz
Teasüti
#10833
üzenetére
Kérlek szépen ez egy Malaguti gyári óra, viszont a mutatóját lecseréltem, mert
egy kicsit fel lett spécizve: világítós, hogy sötétben is lássam, és tök jól néz ki.A gond az, hogy legutóbb olyan indexvisszajelzőt tuningoltam bele, ami persze
szintén tök jól néz ki (erős a fénye, stb.), csak kicsit megtolta a számlapot, így
felakadt a mutató, a vezérlő meg elvesztette a fonalat: ezt úgy-ahogy javítottam.Egy darabig működött is, de megint belefutottam egy hasonló helyzetbe, pont a
műszaki vizsgám napján... Nagyon ciki lett volna, ha 90 km/h-val állok, de időm
sem volt sok, így csak lekaptam a burkolatot, kézzel visszatekertem nullába, s
lehúztam a 4 kábelét, hogy maradjon ott. Vizsgasoron jobb a 0 km/h, mint a 90.
A digitális óra működött! Szóval mérte a távot, meg mutatta a sebességet is.
Azóta viszont egy ugyanilyen (bontott) órát mókolok, és azt kell, hogy mondjam,
hogy NEM hülyeség, amit a KOSO és egyéb utólagos műszergyártók csinálnak:
nem feltételeznek, hogy "biztos nullában áll" a mutató, végigcsinálnak egy teljes
ciklust, és akkor tudják. Egyben demonstrálják, hogy a műszer működik, szóval
ha ezután menet közben nem mutatja, amit kéne neki (sebesség, fordulatszám,
vízhőmérséklet, olajnyomás, benzinszint, vagy bármi, amire épp a műszer való),
akkor tudhatod, hogy a bejövő jellel lesz gond. Malaguti ezt nem csinálja. Sajna!Ne is mondd a SpeedoHealert! Egyszer teszteltem vele, kivezérelte ez a tesztjel
vmi 300 km/h-ra az órát... utána persze nem tért vissza nullába, és hiába veszed
le a gyújtást, azt hiszi, hogy nullában áll. Ha teljesen lehúzod róla a tápot, akkor
mozgatja egy picit visszafelé, de csak ~10 km/h-nyit... A hajam megőszült, mire
nullába visszatért... ráadásul sikerült olyan ütemesen újraindítgatni, hogy közben
kinullázta az össz. futott km-t. Nem vettem észre, napit szoktam figyelni: csak a
kúton tankoláskor, amikor fel akartam írni, hogy 42XXX van benne? És volt kb. 31.Igen, végül a megoldás az lett, mint amit írsz. SpeedoHealer, és kb. egy éjszaka
tolta bele a km-eket, hogy meglegyen mind: az analóg órát persze lekötöttem.
Ha akkor van egy UNO a kezemben, akkor a "120-szal állás" esetén rádugom és
zutty a nullába, nincs baj. Persze ezt akkor még nem tudtam, de mindig tanulok.Amúgy nem pont erre szántam, de ezzel is "tanulom", és jó, hogy ezt is tudja.
Azt mondjuk még nem teszteltem, hogy ez amúgy 5V-os léptetőmotor, vagy sem
(azaz mi jön ki a Malaguti egységből), mindenesetre működik simán 5V-ról. Csak
le ne égessem az UNO-t is, mert külső tápegységet nem dugtam rá az L293D-re.Szerk: egyébként tetszik az ötlet, hogy egy Arduinoval meghajtva pontos / gyors
"analóg" órát is lehetne a gépre varázsolni. Kicsit fura, hogy késve vezérli a gyári.
(Lehet, hogy azért, mert hajazni akar a valódi analóg óra "tehetetlenségére", nem
tudom, de az biztos, hogy a digitális órán hamarabb jelez, sőt olvasható értéket.) -
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
-
válasz
Teasüti
#10677
üzenetére
Azért off, mert már túl sok vagyok ebben a topikban, nem akarom ingerelni a többieket.
Hát a koncepció az, hogy egyforma teljesítménnyel adom le a jelet, de elhangolom a vivő frekvenciát 38kHz-ről, hogy a vevő nehezebben érzékelje.![;]](//cdn.rios.hu/dl/s/v1.gif)
Azt hittem, hogy ez egyszerű dolog: addig növelem a frekvenciát, amíg már nem tudja fogni a vevő a jelet, de tévedtem: gyakorlatilag minden frekvencián képes fogni a jelet, 2kHz-től 100kHz-ig. Viszont vannak frekvenciák, amikre kevésbé érzékeny, ezeket vagyok kénytelen használni.(#10678) tvamos: nem igaz, hogy nem számít, biztosan jobb lenne az egész, ha cm pontossággal tudnék mérni, de egyrészt nem akartam lehetetlen célt kitűzni, másrészt pedig az említett Lego robot is így lett kitalálva, és így is jól használható. Már akkor boldog lennék, ha azt a pontosságot sikerülne elérnem.
-
válasz
Teasüti
#10672
üzenetére
Abszolút hatótávolságot.
Most annyit tudok mérni, hogy az adó 0-50cm-en belül van, 50-100cm közt, vagy 100cm-en túl. Én pont ennyit akartam eredetileg. És amiért ez szerintem érdekes, az az a tény, hogy az ir vevőn és két ir leden kívül csak egy előtét ellenállást használok, minden más szoftveresen van megoldva. -
válasz
Teasüti
#10668
üzenetére
"Én ezt megoldanám frekvencia modulációval"
Mit? Vagy 6 különböző funkciót írtam le az előbb csak 1 tankhoz. És még vannak ötleteim. Például a beacon jel jelenthetné, hogy sikeres volt a találat, vagy akár a tank egészségi állapotát. És valahogy össze is kell hangolni a kommunikációt, ha nem akarom, hogy az összes tank egyszerre beszéljen."különböző jelerősségekhez is lehetne saját frekvenciát rendelni. Mondjuk az első tank 30-33 Khz között sugároz, a második 34-37 közt "
És honnan vegyek ennyi különböző ir vevőt? Arról nem is beszélve, hogy a 38kHz-es tsop vevő 25 és 45kHz között simán vesz minden frekvencián. -
válasz
Teasüti
#10666
üzenetére
Pedig eddig azt hittem, figyeltél.
A beacon jelben benne kell lenni a tank azonosítójának, vagyis, hogy ki sugározza éppen a jelet. Ebből tudja a másik, hogy kit lát (terv szerint kettőnél több tank is részt vehetne egy harcban, bár elsőre örülök, ha kettőt meg tudok építeni...
), illetve, hogy nem a saját maga által küldött jelet látja mondjuk egy falról visszatükröződve.
A másik, hogy mivel analóg jelet nem tudok kivenni az ir vevőből, kell egy trükk, hogy távolságot tudjak mérni.
Több különböző "fényerővel" fogom kiküldeni a beacon jelet. Mondjuk 5mA lesz az 1-es fényerő, 10mA a 2-es, stb. A különböző fényerők más-más távolságról fognak látszódni. De honnan tudom, hogy ha látok egy beacon jelet, az egy közeli tank gyenge jele, vagy egy távoli tank erős jele? Hát onnan, hogy maga a jel tartalmazni fogja, hogy ki küldte és milyen erősséggel.
Tehát mondjuk így fog kinézni az 1-es tank 5-ös erősségű beacon jele: 0x15. A lövés meg legyen mondjuk 0x1F. Akár még azt is bele lehet írni, hogy a tank eleje vagy a hátsó része sugároz, így az egyik tank egy jelből meg tudná állapítani, hogy a másik tank menekül előle, vagy éppen célba vette.
-
válasz
Teasüti
#10664
üzenetére
A GCR kódolás. Az volt a baj, hogy ha túl sok 0 vagy 1 jött egymás után a soros adatfolyamban, megzavarta a vevőt, elmászott a gain (begerjedt?
), az adatlapon lehet olvasni, hogy bizonyos jelhosszúság (0) után kötelező szünetet (1) beiktatni.
Először az 5 bites, Commodore-féle változatot próbáltam, de az csak az egymást követő 0 bitek számát maximálta 2-ben, az 1 biteket nem, így akár 8db 1-es bit is jöhetett egymás után, és nem akart úgy működni, ahogy vártam. Ezért kitaláltam egy 6 bites kódolást, ahol se kettőnél több 0, se kettőnél több 1 nem jöhet egymás után, és ezt már szereti a vevő. Plusz két ellenőrző bitet használok az átviteli hibák detektálásához. Így a normál soros kommunikáció 11 bitje (1 start + 8 adat + 1 paritás + 1 stop) helyett ugyan 16 bitet küldök (1 start + 2x6 adat + 2 ellenőrző + 1 stop) egy byte átviteléhez, de azt akár 4000baud sebességgel (~230byte/s), és majdnem minden átviteli hibát ki tudok szűrni. 
A hibás adatot felismeri a rendszer és eldobja.
Így most nem az történik, hogy bizonyos távolságból elkezd a hasznos adat közé mindenféle szemét keveredni, hanem van egy
határozott távolság, ahol egyszerűen megszűnik a kommunikáció. És ez volt a cél. -
válasz
Teasüti
#10651
üzenetére
Te tényleg értesz.
"Az adó-vevő hókuszpókusz"
Ez sajnos kudarcba fulladt, mert nem bírok belőle analóg jelet kifacsarni. De maga a soros kommunikáció már egészen jól működik. Viszont távolságtól függetlenül néha egészen közelről is hibák jelentkeznek, amit képtelen vagyok visszafejteni, ehhez már vagy egy oszcilloszkóp kéne, amit linkeltél, vagy egy digitális jelanalizátor, amit Janos250 kolléga ajanlott régebben, de egyik sincs itthon sajnos. Gyanítom már nem a kommunikációban van a hiba, inkább valami esp specifikus dolog lehet, ami néha megzavarja a pontosan időzített küldést."38 Khz-es négyszögjel esetén - vagy ami átjön a bandpass filteren - húzza GND-re."
Analóg jel esetén ez úgy működne, hogy a jel mindig valahol 3.3V és 0V közt lenne, az adó távolságától és az adás teljesítményétől függően. A kettő közt félúton van egy választóvonal, ami alatt 0-nak, fölötte pedig 1-nek veszi a feszültségszintet, tehát bizonyos távolságból az adás egyszerűen csak el fog tűnni. Persze tudom, hogy van egy sáv, ahol határozatlan lesz a, mondjuk 1.8-2.5V közt, itt valószínűleg véletlenszerű adatokat fogok kapni. -
válasz
Teasüti
#10613
üzenetére
Én kérek elnézést, nem akartam senkit megsérteni, és természetesen csak azokhoz szólt az előbbi, akik tudnának segíteni, csak valamilyen okból mégsem tették. Tele van a fórum mérnökökkel és műszerészekkel, reménykedtem, hogy valaki csak megszólítva érzi magát.
Érdekes ez a DBU, köszi a tippet, utána fogok olvasni, ez tényleg hasonló, mint amit én akarok, de nem pont olyan. -
Teasüti
nagyúr
válasz
Teasüti
#10505
üzenetére
Na ez mekkora véletlen!
Most döbbentem rá, h 5V-on küldi a megszakítást az mpu6050 giro modul, esp32 meg annyira nem rajong ezért. Viszont belekukkantva az ellenállás utáni feszültségbe, kiderült éppen tökéletes magasságba fut fel a tüske és a program is csont nélkül működik az IO0 lábon és bootloop sincs.
Ennek mekkora esélye volt már??Ez ebben az egy esetben jobb megoldás, mint újratervezni a nyák-ot.
-
brickm
őstag
válasz
Teasüti
#10606
üzenetére
Nem előny, hanem direktíva, és a gyártásban EU-n bleül gyakorlatilag kötelező.
[link]
Az ólom és egyéb ide tartozó nehézfém és vegyianyag mentes termékeknek(az utolsó smd ellenállásig) kell legyen ROHS adatlapja, ami elérhető online formában, ahol rendeled.
a fejlécet nézd. -
tvamos
nagyúr
válasz
Teasüti
#10595
üzenetére
Az alkatreszeim olommentesek. Ujonnan nem is veszek masmilyet, mert barmi, ami leesik ingyen, az ugyis olommentes. Sokszor a munkahelyen forrasztom be a paneljaim, (profi cucc van, sztereo mikroszkop, meg mindenek,) ott meg evidencia az olommentes. Raadasul az osszes cuccom lecsereltem kb. 8 eve. (Koltozkodeskor szinte mindenbol uj lett...)
-
gyapo11
őstag
válasz
Teasüti
#10520
üzenetére
Vannak kis szaturációs feszültségű tranzisztorok. Vagy fet, de annak is kell a feszültség. Vagy leültetni a tranzisztort test alá negatív feszóltségre esetleg egy védődiódával, vagy egy rail-to-rail műveleti erősítő, aminek a kimenete pozitív táptól testig tud működni.
-
válasz
Teasüti
#10530
üzenetére
Nem azt a linket.
Amit a kijelzővel kapcsolatban írtam.
Egy hobbiprojekthez elfogadható kendácsolás az i2c busz alacsonyabb feszültségre húzása, természetesen ha a megbízható működés alapfeltétel, vagy sorozatgyártásba kerül a készülék, akkor persze érdemes rendes szintillesztést beletenni. -
tvamos
nagyúr
válasz
Teasüti
#10504
üzenetére
Pl. Egy MOSFET jo erre, mert a gate egy kondenzatorkent kepzelheto el, nem kell a veszerlesehez aram, a kimenete meg egy ellenallas.
De van erre IC-s megoldas is, pl. a kedves regi CD4016, vagy ha pici kell,akkor pl. a 74LVC1G3157. Van rengeteg fele.(#10505) Teasüti
Siman. Meg haromszogbe, egy SMD ellenallas helyere kettot sorba, meg egymas tetejere parhuzamosan is, tobbet is. Ha minden nap ezt csinalod... -
válasz
Teasüti
#10489
üzenetére
Miért, az usb vezérlő chip is csak egy mikrovezérlő.
Én ilyen dolgokat, ha nem otthon vagyok, a telefonommal szoktam megoldani, OTG kábel + kártyaolvasóval. Mondjuk én csak a telefonomban lévő SD-ről mentek pendrive-ra, de az elv hasonló.
Az említett raspi zero-nak van mass storage módja, amivel ha gépre kötöd, pendrive-ként viselkedik, ha meg hdd-t kötsz rá, meg lehet oldani egy automatizált script-tel, hogy át mentse rá a tartalmát, mindezt akár egy powerbank-ről. De ez itt eléggé off téma. -
tvamos
nagyúr
válasz
Teasüti
#10380
üzenetére
"Csúnyán benéztem egy tervet: ESP32-n IO0-ra tettem egy MPU6050-es interrupt lábát, ami mint kiderült áram alá helyezve alapból pulldown módba kapcsol és ez download módba teszi a vezérlőt."
Ezert erdemes breadboarddon kiprobalni. (Persze, akkor meg orokre ugy marad...) -
brickm
őstag
válasz
Teasüti
#10317
üzenetére
Úgy értettem, hogy leírtam mire keressen rá és még ott tartunk, hogy a sorosport egy csatlakozó fajta...
De lehet én nagyoltam el a választ, vagy az is lehet, hogy nem ennyire egyértelmű ez a dolog (még neki). Ezért szerkesztettem át inkább.
( Épp gyakorló fázisában vagyok a másokhoz való türelmes hozzállásban, bocs ) -
#10305
balintarduin
újonc
Teasüti
#10304
balintarduin
újonc
válasz
Teasüti
#10304
üzenetére
Itt van menümnek a kódja. Azt csinálja, hogy a kijelzőn a fel le gomb hatására 1-et hozzáad és így le megy a ">" jel a kijelzőn.
#include <Wire.h>
#include <LiquidCrystal.h>
LiquidCrystal lcd(A0, A1, A2, A3, A4, A5);
int upButton = 48;
int downButton = 44;
int selectButton = 28;
int menu = 1;
void setup() {
pinMode(upButton, INPUT_PULLUP);
pinMode(downButton, INPUT_PULLUP);
pinMode(selectButton, INPUT_PULLUP);
Menu1();
}
void loop() {
//első menü fügvényei
if (!digitalRead(downButton)){
menu++;
Menu1();
delay(100);
while (!digitalRead(downButton));
}
if (!digitalRead(upButton)){
menu--;
Menu1();
delay(100);
while(!digitalRead(upButton));
}
if (!digitalRead(selectButton)){
Menu2();
Menu1();
delay(100);
while (!digitalRead(selectButton));
}
// második menü függvényei
if (!digitalRead(downButton)){
menu++;
Menu2();
delay(100);
while (!digitalRead(downButton));
}
if (!digitalRead(upButton)){
menu--;
Menu2();
delay(100);
while(!digitalRead(upButton));
}
if (!digitalRead(selectButton)){
Menu3();
Menu2();
delay(100);
while (!digitalRead(selectButton));
}
}
void Menu1() {
switch (menu) {
case 0:
menu = 1;
break;
case 1:
lcd.clear();
lcd.setCursor(0, 0);
lcd.print(">MenuItem1");
lcd.setCursor(0, 1);
lcd.print(" MenuItem2");
break;
case 2:
lcd.clear();
lcd.setCursor(0, 0);
lcd.print(" MenuItem1");
lcd.setCursor(0, 1);
lcd.print(">MenuItem2");
break;
case 3:
lcd.clear();
lcd.print(">MenuItem3");
lcd.setCursor(0, 1);
lcd.print(" MenuItem4");
break;
case 4:
lcd.clear();
lcd.print(" MenuItem3");
lcd.setCursor(0, 1);
lcd.print(">MenuItem4");
break;
case 5:
menu = 4;
break;
}
}
void Menu2() {
switch (menu) {
case 0:
menu = 1;
break;
case 1:
lcd.clear();
lcd.setCursor(0, 0);
lcd.print(">Staticmenu1");
lcd.setCursor(0, 1);
lcd.print(" Staticmenu2");
break;
case 2:
lcd.clear();
lcd.setCursor(0, 0);
lcd.print(" Staticmenu1");
lcd.setCursor(0, 1);
lcd.print(">Staticmenu2");
break;
case 3:
lcd.clear();
lcd.print(">Staticmenu3");
lcd.setCursor(0, 1);
lcd.print(" Staticmenu4");
break;
case 4:
lcd.clear();
lcd.print(" Staticmenu3");
lcd.setCursor(0, 1);
lcd.print(">Staticmenu4");
break;
case 5:
menu = 4;
break;
}
}
void Menu3() {
switch (menu) {
case 0:
menu = 1;
break;
case 1:
lcd.clear();
lcd.setCursor(0, 0);
lcd.print(">Thirdmenu1");
lcd.setCursor(0, 1);
lcd.print(" Thirdmenu2");
break;
case 2:
lcd.clear();
lcd.setCursor(0, 0);
lcd.print(" Thirdmenu1");
lcd.setCursor(0, 1);
lcd.print(">Thirdmenu2");
break;
case 3:
lcd.clear();
lcd.print(">Thirdmenu3");
lcd.setCursor(0, 1);
lcd.print(" Thirdmenu4");
break;
case 4:
lcd.clear();
lcd.print(" Thirdmenu3");
lcd.setCursor(0, 1);
lcd.print(">Thirdmenu4");
break;
case 5:
menu = 4;
break;
}
}
} -
Teasüti
nagyúr
válasz
Teasüti
#10301
üzenetére
Na de mi a helyzet azokkal a változókkal, amiket nem adat közvetítésre használok, hanem konfigurációra?
Adatnál ugye mindig lesz egy input és egy output amik mozgásban tartják a FIFO-t. Viszont konfigurációs változóknál nincs mozgás, ott vmi beállítja a változót és a többi folyamat meg csak referenciaként használja.
Erre nem alkalmas se az xQueue, se az xSemaphore. -
Tankblock
aktív tag
válasz
Teasüti
#10297
üzenetére
Hello
Erre próbáltalak rávezetni...
A taskokat futattod, és a szükséges információkra vársz bennük.
xQueue meg küldöd az adatokat akár még interuptból is.A folyamatos object létrehozás és törléstől én óvakodnék real time rendszerben.
- Sok idő lehet amíg azobjetumok törlődnek és újból létrehozódka
- Ha valamit nem szabadítasz fel a memóriából, vagy az alatta lévő könyvtás hibás akkor memory leak jelenséged lesz.Tanácsom, hogy írd le mit szeretnél, --> requirement
tervezz hozzá tervezési minta alapján valami szép architectúrát
implement
teszt :-)Enjoy it!
-
tvamos
nagyúr
válasz
Teasüti
#10290
üzenetére
Nem tudom, hogy a "esp32 kernel panic" dologrol van-e meg szo, de nekem volt problemam azzal, hogy task-ok kozott volatile globalokkal akartam adatokat atadni.
A megoldasthoz ezt a doksit hasznaltam: [link]
Az adatokat ennek a pvParameters mautatonak a segitsegevel adtam at.
Bocs, ha mar nem errol van szo! -
Tankblock
aktív tag
válasz
Teasüti
#10290
üzenetére
Szia
Vagy én néztem be (csak notepadba)
de csak a PCNT_CHANNEL_0 használod, tehát ugyanazt a csatornát próbálod meg 2x configolni.
static void initSpeedCounter(void)
{
pcnt_config_t pcnt_config = {
SPEED_SIGNAL_CAPTURE,
-1,
PCNT_MODE_KEEP,
PCNT_MODE_KEEP,
PCNT_COUNT_INC,
PCNT_COUNT_INC,
SPEED_COUNT_UNIT,
PCNT_CHANNEL_0
};és itt is ugyanaz a channel 0...
static void initTachoCounter(void)
{
pcnt_config_t pcnt_config = {
SPEED_SIGNAL_CAPTURE,
-1,
PCNT_MODE_KEEP,
PCNT_MODE_KEEP,
PCNT_COUNT_INC,
PCNT_COUNT_INC,
TACHO_COUNT_UNIT,
PCNT_CHANNEL_0
}; -
Tankblock
aktív tag
válasz
Teasüti
#10285
üzenetére
Hello,
Én inkább a memória/erőforrás kezelés rovására írnám.
Direct használod mindig a PCNT0 csatornát? Az IDF es példaprogramban interuptba számolja az eventeket és xQueue küldi a fő programba.
Szerintem ott akad szét, hogy ugyanazt az erőforrást címzed meg 2 külön taskből és már a setupnál kifagy ahogy írtad.
Amikor megy gondolom valaiért az egyik szál kicsit megcsúszik a FreeRTOS miatt és nem egyszerre próbál funtni 2 init.
Szálkezeléshez jó tervezés kell, mert könnyen lehet Deadlockba futni.
-
_q
addikt
válasz
Teasüti
#10285
üzenetére
Nem értek annyira hozzá, de a taskok nálam is furán működtek. Már korábban lehet írtam, de most hogy szóba került leírom megint hát ha van összefüggés vagy ötlet.
Task nélkül tökéletesen fut a program: ESPNow, I2C, Wifi(Webserver + NTP), SPI. Ezeket használom. Taskokkal megoldva már kevésbé. I2C-n olvasva nem mindig kérte jól le az adatokat az ESP. Próbáltam prioritásokat állítani, próbáltam 0 és 1 mag között ide-oda pakolászni a taskokat. Néha jól olvasta az I2C adatokat, néha nem, néha meg többször egymás után rossz adatok jöttek. Néha reset segített, néha az se. Emellett volt még a wifi-nél NTP-vel is gond, bár ott nem emlékszek, hogy kimondottan a task okozta-e, de azóta hogy nem task-al oldom meg nincs egyikkel se baj.
Tehát ahogy kezdtem nem értek hozzá, tapasztalatot írtam le, de gyanúm az lenne, hogy az ESP nem teljes értékű 2 magos eszköz mint egy számítógép processzor. 0. magon mennek a perifériák, 1. magon meg nem véletlen van a loop is. Tehát lehet próbálkozni taskokkal, de valójában 1 magos az eszköz, 0. mag a sok periféria elem miatt van, hogy ne akadjon össze. Szerintem.
Szívesen fogadok bármiféle észrevételt.
-
Tankblock
aktív tag
-
Tankblock
aktív tag
válasz
Teasüti
#10277
üzenetére
Hello,
Miért az összes file végződése .ino?
Azt nem értem, hogy miért van a fps_cap paramétered a Setup függvényben kiszámolva, de a task már rég fut mire odaérne a számolásban???
A taskok közötti változók kezelésére volatile kellene ha nem lehet máshogy muszáj. Ha meg csak 1x kell
futnia inkább tedd a Task elejére mielőtt a végtelen ciklus futna.....ez inkább C kód mint C++...
Amit tanácsolok, dekomponáld a projectet kisebb részegységekre majd egyesével integráld vissza.
NE használj változókat különböző taskokban főleg ha az csak egy konstans --> arra van a #defineMinimalizáld a változóidat és funkcionlításokat rendezzd classokba...
Task elején class init majd végtelen ciklusba számolja amit kell. Taskok közötti communikációra FreeRTOS is van ajánlása xQueue vagy xEventGroup ha szignálozni kellene,A debug üzeneteket is mentsd le, mert sokat segítenek abban, hogy merre kellene nézelődni. Pluszban most egy MQTT C++ dolgozom és memory leak után nyomozok.
Itt pl a
ESP_LOGI(TAG, "[APP] Free memory: %d bytes", esp_get_free_heap_size());használom a szabad memória fellelhetőségének. -
Janos250
őstag
válasz
Teasüti
#10264
üzenetére
Azt nem mondtam, hogy egyszerű, mert nem erre találták ki, hanem eredetileg az infra távirányítók jelének adására/vételére. Egyébként, ha valaki megcsinálja hozzá a könyvtárakat (mint pl. példádban a ledcSetup, stb.), akkor ebben is pár sor. Persze nem valószínű, hogy valaki megcsinálja, mert valószínűleg nem így akar PWM-et gyártani. Egyébként, ha valaki használja azokat a struktúrákat, amiket korábban Te is használtál a led szalag meghajtására (illetve használja az általad használt könyvtár), akkor némileg szintén egyszerűbb, de akkor meg nem tudja az emberfia, hogy mit csinál. Én szeretem tudni, hogy mit csinálok, ezért szeretem a Tech. Ref-eket.
Pár éve, mikor valahova PWM kellett, akkor azt STM32-vel csináltam, azok is jó procik. Ott is Tech. Ref. alapján. -
-
Tankblock
aktív tag
válasz
Teasüti
#10265
üzenetére
Hello
A második képeden a bementi változó referencia ként van átadva.
Ha tárolni szeretnéd, akkor egy rámutató pointerrel lehet megtenni, ha jól emlékszem. Mivel C++ ezért a PRivate részbe tenném bele és itt csak anyit tennék, hogyclass SillyClassNameRules {
protected :
Stream * s;
int x;
int y;
public:
SillyClassNameRules(Stream &p, int X, int Y) : s(p), x(X), y(Y)
{
// If I not made a huge mistake
//do init here pl.call any additional fnc()
}
} -
Janos250
őstag
válasz
Teasüti
#10212
üzenetére
Olvastam én, csak eddig nem volt időm rá, de most összeütöttem.RMT-vel hogy csinálnál mondjuk 100 Hz 50% PWM jelet?
Így:
Bár most látom, hogy Te 100 Hz-et kérdeztél, én meg 10 kHz-re emlékeztem. Sebaj, átírhatja, akit érdekel.Ha nem kell carrier, akkor ki kell kommentelni
// 10 kHz RMT
const uint8_t GPIOnum = 15;
const uint8_t RMTchNum = 0;
const uint8_t DutyCycle = 50 ; // %
const uint32_t freq = 10000 ;
const uint32_t clockAPBbus = 80000000 ; // RMT use APB bus clock
const uint16_t highCiklNum = (uint16_t) ( clockAPBbus / freq / 100 * DutyCycle ) ;
const uint16_t lowCiklNum = (uint16_t) ( clockAPBbus / freq / 100 * (100 - DutyCycle) ) ;
const uint32_t RMTdata = ( ( (lowCiklNum) <<16) + (1<<15) + highCiklNum) ;
void setup() {
Serial.begin(115200);
delay(1000);
Serial.println("start setup");
pinMode(GPIOnum, OUTPUT);
*((volatile uint32_t *) (0x3FF44530 + GPIOnum * 4 )) = 0x57 + RMTchNum ;
*((volatile uint32_t *) (0x3FF000C0)) |= 1 << 9 ;
*((volatile uint32_t *) (0x3FF000C4)) &= (~(1 << 9)) ;
*((volatile uint32_t *) (0x3FF560F0)) |= 1 ;
*((volatile uint32_t *) (0x3FF560F0)) |= 2 ;
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) = 1 ;
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) |= (1 << 24) ;
*((volatile uint32_t *) (0x3FF560B0 + RMTchNum*8)) = ( (0x80 << 16) + 0x80) ; // carrier freq
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) |= (1 << 28) ; // carrier enable
*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) = (1 << 17) ;
*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) |= (1 << 3) ;
for (uint16_t i = 0 ; i<(64) ; i++ ){
*((volatile uint32_t *) (0x3FF56800 + RMTchNum *64 * 4 + i*4)) = RMTdata ;
};
*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) |= 1 ;
Serial.println("end setup");
delay(500) ;
} // end setup
void loop() {
delay(1000) ;
} ; // end loop
/*
Comments:
*((volatile uint32_t *) (0x3FF44530 + GPIOnum * 4 )) = 0x57 + RMTchNum ; // GPIOnum output = RMT CH RMTchNum
// p 58 (Tech. Ref, 4.12 Register Summary)
// 0x3FF44530 = Peripheral output selection for GPIO_0 (GPIO_FUNC0_OUT_SEL_CFG_REG)
// (0x3FF44530 + GPIOnum * 4 ) = Peripheral output selection for GPIOnum
// 87 (0x57) = rmt_sig_out0 (p. 53 , 4.9 Peripheral Signal List)
// GPIO_FUNC2_OUT_SEL_CFG_REG
*((volatile uint32_t *) (0x3FF000C0)) |= 1 << 9 ; // BIT9, Remote Controller (p. 93)
// DPORT registers/DPORT_PERIP_CLK_EN_REG =1 : enables the peripheral clock (p 92.)
// PERIP_CLK_EN_REG (p. 95 , 5.4 DPort Register Summary)
// BIT9, Remote Controller
// DPORT_RMT_CLK_EN = bit 9 = 0x200
*((volatile uint32_t *) (0x3FF000C4)) &= (~(1 << 9)) ; // PERIP_RST_EN_REG reset for peripherals (p 95)
// BIT9 = DPORT_RMT_RST (RMT reset)
// DPORT registers/PERIP_RST_EN_REG = reset for peripherals
// DPORT_PERIP_RST_EN_REG = (DR_REG_DPORT_BASE + 0x0C4) = 0x3FF000C4
*((volatile uint32_t *) (0x3FF560F0)) |= 1 ; // bit 0 RMT_APB_CONF_REG 1 = Set this bit to disable apb fifo access
// RMT_APB_CONF_REG / bit 0 RMT_MEM_ACCESS_EN Set this bit to disable apb fifo access
// This bit must be 1 in order to access the RMT memory (p. 402.)
*((volatile uint32_t *) (0x3FF560F0)) |= 2 ;
// RMT_APB_CONF_REG / bit 1 RMT_MEM_TX_WRAP_EN This bit enables wraparound mode: when the transmitter of a channel
// has reached the end of its memory block, it will resume sending at the start of its memory region
// RMT_CHxCONF0_REG 15. Remote Control Peripheral/ 15.3 Register Summary (p 396, 397.):
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) = 1 ; // frequency divider's factor , bit7-0 (p. 396)
// freq = 80 Mhz / 1
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) |= (1 << 24) ; // memory blocks allocated to channel , bit27-24
*((volatile uint32_t *) (0x3FF560B0 + RMTchNum*8)) = ( (0x80 << 16) + 0x80) ; // carrier freq
*((volatile uint32_t *) (0x3FF56020 + RMTchNum*8)) |= (1 << 28) ; // carrier enable
*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) = (1 << 17) ; // CLK = 80 Mhz
// bit 17: RMT_CHxCONF1_REG / RMT_REF_ALWAYS_ON_CHn
*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) |= (1 << 3) ;
// bit 3 : RMT_CHxCONF1_REG / RMT_MEM_RD_RST_CHn Set this bit to reset the read-RAM address
// for channel n by accessing the transmitter
for (uint16_t i = 0 ; i<(64) ; i++ ){
*((volatile uint32_t *) (0x3FF56800 + RMTchNum *64 * 4 + i*4)) = RMTdata ;
};
*((volatile uint32_t *) (0x3FF56024 + RMTchNum*8)) |= 1 ;
// bit 0 : RMT_CHxCONF1_REG / RMT_TX_START_CHn . Set this bit to start sending data on channel n
*/ -
ecaddsell
aktív tag
válasz
Teasüti
#10238
üzenetére
Vsz. nem tévedek túl nagyot, ha a Robin Scheibler FFT tesztjének összes float igényét N*log2(N) + 2*N-el közelítem ami 4k FFT esetén kb. 57k float művelet 7ms alatt, azaz per float kb 120ns. Ebből a tényleges float mindenféle overhead nélkül jóval kevesebb (lehet fele se). Persze ez még mindig jópár órajel ciklus nem úgy mint a float DSPknél ahol 1 float 1 órajel, szóval aki nagyságrendi ugrást akar az megy DSP-re.
Röviden: abban a tesztben amit linkeltél vagy valamit nagyon elrontottak, vagy valami olyat néz ami az itt felvetett és tárgyalt FFT szempontjából teljesen irreleváns, szóval kár volt ide hozni.
-
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Azt hittem, hogy ez egyszerű dolog: addig növelem a frekvenciát, amíg már nem tudja fogni a vevő a jelet, de tévedtem: gyakorlatilag minden frekvencián képes fogni a jelet, 2kHz-től 100kHz-ig. 
Új hozzászólás Aktív témák
Hirdetés
ekkold- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Eredeti játékok OFF topik
- exHWSW - Értünk mindenhez IS
- CMF Phone 2 Pro - a százezer forintos kérdés
- Le Mans Ultimate
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- Autós topik
- Nyaralás topik
- EAFC 25
- További aktív témák...
- Apple iPhone 13Pro 128GB Kártyafüggetlen 1Év Garanciával
- Garmin Fenix 8 Amoled 51mm Sapphire Carbon Gray DLC - Használt, karcmentes
- Nitro ANV15-51 15.6" FHD IPS i5-13420H RTX 4050 16GB 512GB NVMe magyar vbill ujjlolv gar
- Apple iPhone SE 2020 64GB Kártyafüggetlen 1Év Garanciával
- iPad Pro 11 gen 2 + magic keyboard magyar makulátlan új állapot
- Telefon felvásárlás!! Apple iPhone SE (2016), Apple iPhone SE2 (2020), Apple iPhone SE3 (2022)
- Üzleti Fujitsu Lifebook u7510 15,6" FHD IPS 2021/08. havi gyártás
- Samsung Galaxy Xcover 5 64GB, Kártyafüggetlen, 1 Év Garanciával
- Creative Sound BlasterX G5 (70SB170000000) (Sound Blaster) (DAC)
- Azonnali készpénzes INTEL CPU NVIDIA VGA számítógép felvásárlás személyesen / postával korrekt áron
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged