- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Magga: PLEX: multimédia az egész lakásban
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Gurulunk, WAZE?!
- Kempingezés és sátrazás
- Viber: ingyen telefonálás a mobilodon
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
-
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
-
DigitXT
félisten
válasz
lanszelot
#19855
üzenetére
A többszálúság az a kivétel.
Azt arra mondtam, hogy olyankor "kicsit"
bonyolultabb tervezni a programot. Amúgy, ha szigorúan nézzük, nem
soronként fut a program, hiszen a fordító előre lefordítja gépi kódba.
A leírt szöveg absztrakció...
Szkipt nyelvek tudnak soronként futtatni
programokat. (Ott simán lehet, hogy teljesen szar sor marad a kódban,
mégis hibátlanul fut, amíg oda nem ugrik... És akkor elszáll hibával...
)Ilyen szempontból az Arduino által futtatott C sokkal jobb, mivel már a
fordítás közben kiderülnek a szintaktikai hibák + típusosak a változók...
(Mondjuk egy AWK ezzel szemben sokkal rugalmasabb, könnyebb vele
pl. szövegeket feldolgozni, ad hoc jelleggel, rövid programokat írni. Ám
ha elírsz valamit simán megeszi: csak futás közben jön ki, hogy bugos.)Az Arduino Uno/Mega mint egymagos architektúra, egyszerre egyetlen
dolgot csinál, de azt relatíve gyorsan, így tudod kihasználni, hogy kvázi
egyidejűleg látszólag több dolgot csináljon, hogy "pörgeted" a loop-ot.Na most a delay az ezt hazavágja! Szóval nagyobb projekteknél, amikor
több bemenetet kell figyelni, vagy pl. szoftveres soros portot használsz,
nem fér bele, hogy álldogáljunk másodperceket, mert elveszik az adat...
És ilyenkor jön az, hogy megszakítás: az észreveszi... Illetve a hardveres
UART (ami szintén megszakításokkal működik), nagy sebességnél jobb!
Viszont felesleges megszakításokra építeni a programot, ha bőven elég
az is, hogy pörög a loop... A millis() figyelése jobb. Lásd órádra pillantás.Szerk: oké, a SoftwareSerial is megkerüli a delayt megszakításokkal, de
vannak limitációi. Én most pl. Nextion kijelzővel kommunikálok 115200
baud sebességgel (RX1), anno ez mintha nem akart volna összejönni...
Szerk: emellett egy másik porton olvasom a kijelzendő adatokat, stb. -
DigitXT
félisten
válasz
lanszelot
#19848
üzenetére
Most, hogy bemásoltad a kódot, lehet érdemben beszélgetni róla.
Szóval Arduinonál úgy működik, hogy először lefut a setup, aztán meg
átmegy a loop-ba, s az végtelenül ismétlődik. Esetedben ugye a setup
egyrészt inicializálja a kijelzőt, másrészt (meglepetés!) elindítja a soros
portot is, 9600 baud beállítással. Ez azért jó, mert a Serial Monitoron a
program futását tudod monitorozni és tudod debuggolni, ha vmi "gázos".A delay használata egyszerű programoknál rendben van, vagy ha vmire
kifejezetten várni kell, hogy megtörténjen. Ellenben, egy olyan program,
ami folyamatosan (kellene hogy!) nézzen egy bemenetet megakad tőle:
tehát az a delay(1000) az elején feleslegesen vár egy másodpercet. És
amit utána kiértékelsz, az NEM az aktuális mért érték! Hanem még az
egy másodperccel korábbi: nyilván "tanulós" programban ez is elmegy,
amennyiben az ember tisztában van vele. De ha nem, kigyomlálandó...
Erre jött a jótanács a millis() használatról, hiszen az egy mindenkoron
növekvő számláló, a bekapcsolástól kezdve, ezredmásodpercben.
(Tehát, anélkül tudsz mondjuk ~1 másodpercenként csinálni "akármit",
hogy az MCU kifejezetten addig az 1 másodpercig ne csinálna mást...)A koncepcionális különbség pedig annyi, hogy nem megállsz és vársz,
hogy elteljen egy adott időszak (közben nem csinálsz semmit), hanem
szépen csinálod a dolgod, csak időről időre az órádra pillantasz, és ha
azt látod, hogy eltelt már az adott (várakozási) idő, akkor csinálod meg
az időzített/ütemezett feladatot. (Így több dolgot is kényelmesen tudsz
más-más időközönként végrehajtani.) Első körben szerintem ennyi...pont ezért nem szúrtam be, mert lehetetlen ide berakni
Nekem nem úgy néz ki, mintha lehetetlen lenne, ha egyszer sikerült... -
DigitXT
félisten
válasz
lanszelot
#19842
üzenetére
Az a program amit bemásoltam az annyi.
Nem, nem annyi, mert csak egy részét másoltad be, a többiről meg vagy írtál,
vagy nem. Így nem lehet érdemben segíteni, hogy félinformációkat közölsz.
Nincs vizsgálat.
Mert a sensorValue < 90 az szerinted mi, ha nem egy feltétel vizsgálata?mit tanulnék, ha megírt programokat töltögetnék fel a leírás szerint?
Nagyon sokat: megnézed mit csinál, lépésről-lépésre megpróbálod megérteni.Nincs program. Csak kezdő vagyok. A legelején tartok.
Attól még amit megírtál, és feltöltöttél egy program. Arduino esetén van neki
egy setup része, meg egy loop. Te a loop-ot sem osztottad meg velünk...
Mondok egy vicceset. Annak idején egy programozási versenyen sajnos már
nem maradt időm az egyik feladatra egyáltalán, de mivel volt példa, hogy mit
kérdezhetnek a programtól tesztként, annyit írtam, hogy azt választ írja ki.Még csak if sem volt benne, egyszerűen ilyen jellegű megoldás volt: print(42)
Ha és amennyiben a teszt kérdésre jó volt a válasz, érhetett egy pontocskát.Azt mindenkire rábízom, hogy mi volt a kérdés...
-
DigitXT
félisten
válasz
lanszelot
#19836
üzenetére
Nagy vonalakban úgy, ahogy írod, egymagos processzoron: pont erre céloztam,
hogy azért a megszakítás ennek keresztbe tud verni rendesen, illetve többszálú
programnál egyéb problémák is felmerülnek a párhuzamosítással kapcsolatban.
(Márpedig egy ESP32 pl. kétmagos, szóval nem teljesen elrugaszkodott dolog.)Az a baj, hogy feltételezed, hogy adott programrészbe került és ott volt a baj a
delay funkcióval, pedig ez a legkevésbé valószínű.
Sokkal valószínűbb, hogy
a kód nem is ott tartott. Ilyenkor hasznos beszúrni egy pár Serial.print(akármi)
hívást a kritikus részekre, és nézni a Serial Monitor-on, hogy mit írtál el...Nagyon könnyű elgépelni valamit, s ha megeszi a fordító, akkor sz.rul fog futni:
az egyik ilyen legtriviálisabb (kezdő*) hiba valami értékének a téves vizsgálata,
nevezetesen ha véletlenül nem az "==" operátort használod, hanem az "="-t...
Simán lefordul, simán fut, csak nem azt csinálja, amit gondoltál, hanem amivel
hasonlítanád, azt adja értéknek, majd értékeli, hogy 0 vagy 1* az eredmény.*: de nem csak kezdők követhetik el, hiszen lehet elgépelés is, emiatt néhány
fejlesztői környezet direkt nézi az ilyet, warningot dob rá, hogy ezt akartad-e...*: pontosabban "nem nulla", nehogy valaki belekössön... Egy gyors példa erre:
if (sensorValue = 90) { valami } else { egyéb } Ennél nem csak az a baj, hogy
az "egyéb" soha nem fog lefutni, hanem az is, hogy a sensorValue utána végig
90 lesz, egészen amíg újra be nem olvastad... (És ez egyetlen pici elgépelés.) -
DigitXT
félisten
válasz
lanszelot
#19834
üzenetére
Nincs ezzel baj, senki nem úgy kezdte, hogy mindent tud, bár bizonyára
könnyebb úgy az élet, hogy az ember legalább nagy vonalakban ismeri a
koncepciót. Viszont úgy segíteni, hogy nem írod meg, pontosan miben...De örülünk, hogy megoldódott. Ha lenne bármi kérdés, biztos tudunk vmi
segítséggel szolgálni, csak ilyenkor látni kellene, miben kell segíteni...Ui: ha már mindent megértettél, akkor rátérhetünk a megszakításokra.
![;]](//cdn.rios.hu/dl/s/v1.gif)
(Vagy nekem még nagy kedvenceim a mutatók, és a type casting, LOL.)Sőt, egy időben a bitshifting is valami fekete mágiának tűnt. Pont csak a
minap vetettem bele magam, és tök könnyű vele dolgozni... Ez van.
Ez a belevetés erős túlzás, de maga a koncepció ott is tök egyszerű, és
ha érted a szintaxist, akkor teljesen triviális a megfogalmazás...
De ha egyik sincs meg, akkor tényleg csak néz az ember, hogy EZ MI?! -
DigitXT
félisten
válasz
lanszelot
#19829
üzenetére
A 200 ms delay nagyon rövid, ha normálisan működne, akkor se villogás, inkább vibrálás lenne az, amit látsz. Amúgy azért nem szerencsés a delay, mert addig nem csinál semmi az MCU, tehát pl. nem mintavételezi az analóg bemeneteket, így ugyanennyivel később fogod észrevenni, ha változott. (Nyilván 0.2 mp nem a világ, de ha felrakod mondjuk 0.5-re, akkor már látható, és felesleges késleltetés a program érdemi működésében, egy minimalista animáció/keret villogtatás miatt.
)Valami alap dologban szerintem el vagyok tájolódva.
Másold be a teljes kódot, kérlek! -
DigitXT
félisten
Egyébként teljesen felesleges az egész képernyőt törölni, csak villogni fog.
De amúgy igaz, hogy így részleteiben beszélgetni egy baromi egyszerű, kicsi
kódsorról, nem fog megoldást hozni, ha a teljes program máshol van elszúrva.
(És itt nem bántásból írom, hogy elszúrva. Én is elkövettem "koncepcionális"
hibát, még a minap is, pedig már programozgattam Arduinora is, és mégis...)Kérjük a teljes kódot, és megköpködjük...
Helyesen: segítünk debuggolni! -
DigitXT
félisten
válasz
lanszelot
#19815
üzenetére
Nem lehet, hogy valami LCD frissítési turpisság van mögötte? Vmi felülír valamit? Milyen kijelző? Szerintem a display.print(gas)-t sem kellene állandóan kitolni neki, csak ha változott az érték. Meglehet, hogy maga a felirat tünteti el a fehér keretet: ha így van, megpróbálkoznék kicsit nagyobbra venni, hogy kilátsszon mögüle.
-
DigitXT
félisten
válasz
gabikaa39
#12753
üzenetére
Ez azért lehet, mert a nagy Á betű két bájton jelenik meg (c3 81) a szerkesztőben. Ha ezeket akaratodon kívül külön-külön íratod ki, akkor jelenhet meg kirksz-kraksz.
Rákerestem erre a glcdfont.c-re, és megpróbáltam megfejteni neked a dolgot.
(Sosem foglalkoztam a témával, azt se tudom, eszik-e, vagy isszák az Adafruitot.)A PROGMEM tartalmát úgy kell értelmezni, hogy minden egyes karakter grafikus "képét" adja meg: 5 bájt van minden karakterre (5x7-es mátrix esetén bőven* elég).
Nem tudom, ki volt az a marha, aki 12 bájtonként tördelte be a kódot, aminek ugye pont semmi köze nincs az egyes karakterekhez, de legalább az umlaut a-t (ä) már külön bejelölte, így jól látszik, hogy melyik 5 bájt tartozik össze, le is lehet rajzolni:
0x22=0100010
0x54=1010100
0x54=1010100
0x78=1111000
0x42=1000010
Vegyük észre, hogy a fenti táblában hanyatt van esve a betű = fordítsuk el balra.A megoldás, hogy kitalálod, hogyan nézzen ki az a bizonyos Á betű, aztán ezt "jól lekódolod" és beilleszted a progmem megfelelő pozíciójába... Nem intuitív, tudom... (Egy bájt egy "pixeloszlopot" ír le, ebből van végül 5 db minden egyes karakterre...)
Talán a legegyszerűbb az umlaut A-t meghekkelni: levenni a pöttyöt a bal oldaláról, és onnantól olyan, mint egy Á. Vagy legalábbis arra emlékeztet: 7D helyett 7C-t...
Persze azt tudni kell, hogy pontosan melyik karakterrel kell ilyet kiírni. A kis ä a 132-es pozícióban van "általában", és valóban: ebben a kódban is ott van definiálva. Nézd el nekem, hogy a nagyot nem tudtam fejből, az a 142-es? Talált: ÄÉs ha már itt tartunk, fejtsük meg azt a függőleges vonalat is.
Az a c3, azaz 195 0x00 0x00 0x00 0xFF 0x10, most hogy már látjuk a mátrixot, ez egyértelműen egy függőleges vonal, és egy pötty tőle jobbra: ilyesmi.├ (Tipikus UTF-8-as "karakter".) Az utána következő u-szerű karakter meg elvileg egy ü akar lenni, legalábbis ezt hámoztam ki a kódból. És ez teljesen normális is, próbálj beírni egy ALT+129-et!
*: 1 bitet mindig elpazarol, ha úgy tetszik, hiszen csak 7 bitet használ ki a 8-ból.
-
DigitXT
félisten
válasz
KFORboy
#12707
üzenetére
Jó a gondolatmenet egy Gipsz Jakab által létrehozott kamu webshopra...
De azért a hestore.hu-t ilyenhez hasonlítani? Némi tájékozatlanságra vall.Az elmúlt 5 évben 21x rendeltem tőlük, legtöbbször személyes átvétellel,
ritkán postázva: talán az egyetlen "probléma" az volt, hogy a karácsonyfa
égősor nem SMD LED-del szerelt, de akkor is felhívtak, hogy így is kell-e?Rendkívül precíz, korrekt csomagolás, valós raktárkészlet, gyors szállítás:
nagyjából ez jellemzi. Sajnálom, hogy máshol átvertek: ez nem ilyen hely!Ui: igen, az Uno-t is innen vettem, összesen ~150K-t hagytam náluk.
Nyilván Kínából olcsóbb adott cucc, de néha hónapokat várhatsz. Itt nem.Ilyenem van itthon pár darab, mert SMD forrasztáshoz én béna vagyok.
-
DigitXT
félisten
válasz
ratkaics
#12389
üzenetére
Alacsony nyomás esetén "test"-re záró "olajgomba".
Felejtős, teljesen értelmetlen műszer: amikor jelez, a motornak már reszeltek.
Rendes jeladó kell, vagy ellenállás alapú, vagy saját elektronikával rendelkező:
utóbbi kényelmesebb, mert csak 5V kell neki és 0-5V közötti kimenő jele van,
pontos, megbízható... Az ellenállás alapú érzékeny a csatlakozásra (nagyon),
és fizikailag sokkal nagyobb, emiatt nekem sokszor volt vele gondom.NTC ellenállás, vagy valami hasonló megoldható a vízkörben.
Igen, jellemzően 10K NTC "szabvány" utólagos műszereknél. De amit gyárilag
beleraknak (jellemzően a termosztátnál van gyári jeladó, jó esetben 1/8"NPT!),
bármi lehet. (A menetet érdemes előre ellenőrizni, mert ez az 1/8"NPT is csak
az utólagos műszerek de facto szabványa: össze lehet keverni az M10-zel.)
Legbiztonságosabb: vízcső elvág, bele egy adapter és abba a megfelelő jeladó.mágneses elven működő impulzus jeladó, mint a bringákon
Megoldható, de nem valami pontos: mekkora motor, mekkora a kerék/tempód?
GPS nem rossz, de késik, és kiviteltől függően nem túl pontos értékeket ad.
Nekem gyárilag 6 jel esik egy fordulatra és 13"-os a kerekem: ez viszonylag jó.Feszültségmérés: Ez talán megoldható.
Na igen, ez teljesen triviális... Lenne: annyiban bonyolítottam meg az életemet,
hogy az a cucc, ami összegyűjti az adataimat hajlamos volt újraindulni, amikor
leesett a tápfesz 8-9V-ra indítózásnál. Szóval beraktam egy pufferkondenzátort,
és egy diódát elé, aminek mellékhatása, hogy a tápfeszt nem méri pontosan.
(De a diódán eső feszültséggel szoftverből korrigálok, úgy "közel használható".)Ez nem tudom még pontosan, hogyan működhet...
Úgy, hogy a gyertyapipán nagyfesz ugrál, ami a köré tekert vezetékben, mint az
"antennán" jelet generál, amit lehet számlálni. A fordulatszám meg abból adódik.
Ahogy előttem írták, nem mindegy, hogy 2T, vagy 4T, bár ez "attól függ", ugyanis
simán van, hogy a 4T motor is belegyújt tök feleslegesen egyet a kipufogásba is,
mert úgy egyszerűbb volt a gyártónak, így pont ugyanannyi jeled van, mint 2T-nél.A kapott impulzusok értékelésében viszont árnyalnám cidalain kommentjét.
Szokás pl. egy teljes másodpercig számolni az impulzusokat, abból számolható
az aktuális fordulatszám közelítőleg, és viszonylag stabilan. Hátránya, hogy nem
teljesen valós időben követi az eseményeket, lemarad a gyors változásokról és a
pontossága +/- 60 rpm. (Csak a 60 többszöröseit fogod tudni ilyen módon mérni.)
Nekem sokkal jobban tetszik az a megoldás, hogy a két gyújtás közötti időt kell
mérni, és abból következtetni az aktuális fordulatszámra. A lehető leggyorsabban
így lehet reagálni, biztos nagyon szép analóg görbe jönne ki belőle: hátrány, hogy
a kijelzett érték ugrál, de nagyon. Ha meg elkezdesz átlagolni, hogy simítsd, már
ott is vagy, ahol a part szakad. Mondjuk el tudom képzelni, hogy a logfájlba megy
pontos érték, kijelzésre meg jó a közelítő, akár analóg műszeren (léptetőmotorral).
Amúgy is az analóg fordulatszámmérőnek van egy szépsége, intuitív, megszokott.
(Az, hogy manapság jellemzően léptetőmotor hajtja, tehát alapvetően tök digitális
a működése + véges a felbontása, senkit nem érdekel. Csak szaladjon a mutató.) -
DigitXT
félisten
válasz
ratkaics
#12383
üzenetére
Nekem van egy rakat műszerem, de nem Arduinoval dolgozom fel az adatokat.
(Még...) Első körben azt kell tisztázni, hogy honnan lesz az input, utána jöhet,
hogy mit fogsz kijelezni, meg logolni. Eddig csak a sebességmérésre ugrottak
a srácok, de írtál ott cifrábbakat (bár alap dolgokat): fordulatszám, olajnyomás.
Előbbihez talán lehet "ellopni" jelet a gyújtótrafótól. Utóbbit viszont nem úszod
meg egy beépített jeladó nélkül, aminek nem feltétlen van hely a motorblokkon.Megannyi kérdés! Sebességet lehet kerékről is mérni. De a váltóról is szokták.
Talán a feszmérés még a legtriviálisabb. (Bár nekem van ~3 feszmérőm, LOL.) -
DigitXT
félisten
válasz
Atamano
#12314
üzenetére
Ugyanúgy rossz.
Temp2 értékét adod vissza, de annak soha nem adsz értéket.
Lehet, hogy csak elírás, és az akart lenni, hogy:
Temperature1 = (sensors.getTempCByIndex(SENSOR_INDEX));
if(Temperature1 == -127)
{// do nothing
}
else{
Temperature2 = Temperature1;
}
Serial.print(Temperature2);Amúgy nem vagyok biztos benne, hogy nem menne syntax error-ra egy töküres
blokk. De most nincs előttem a fordító. Viszont, ha már így írod, akkor én oda a
a "do nothing" helyére csak beletennék egy darab újra olvasást, tuti, ami fix...Persze ez mondom, túlbonyolítás, az egész ellenőrzés valójában egyetlen sor...
if (Temperature1 != -127) Temperature2 = Temperature1;
Addig semmi szükség az else ágra, amíg hibakezelést nem akarsz csinálni...Szerk: ahh, közben törölted, akkor mindegy, a lényeg akkor átment.
-
DigitXT
félisten
válasz
Atamano
#12312
üzenetére
Ne az éles változóba rakd a beolvasott értéket, hanem egy átmenetibe...
Megnézed, hogy mennyi az annyi, ha -127, és ez a hibajelzés, akkor ez
nem kerül be az aktuális hőmérsékletet tároló változóba, így nem jelenik
meg a felhasználónak. Ott marad az előzőleg mért érték, ami amúgy kb.
pontos is lesz, feltéve, hogy viszonylag lassan változik a hőmérséklet.Nem olyan izgalmas a dolog, hogy példa kódot kelljen írnom rá...
Szerk: na jó, most nézem, hogy amit te írtál, az valójában totál rossz.
Mivel ugye a temp2-nek soha nem adsz értéket, ám azt írod ki a végén...Átírom azt:
Temperature1 = sensors.getTempCByIndex(SENSOR_INDEX);
if (Temperature1 != -127) Temperature2 = Temperature1;
else
Temperature2 = Temperature2; //erre semmi szükség, csak magyarázza
Serial.print(Temperature2);A fenti példában azzal lehet baj, ha rögtön hibás olvasással kezdtél, így a
Temperature2-ben nincs valid érték és azt akarod (valahogy) megjeleníteni.
Erre kéne inicializáció, mondjuk írjon ki 0 fokot, amíg nem tudja, mennyi... -
DigitXT
félisten
válasz
Atamano
#12308
üzenetére
Valami ilyesmire. De valójában egyszerűbb megoldásra: nem is feltétlen olvasnám
rögtön újra, hanem az egyértelműen hibás értéket eldobnám és kész. Nem tudom,
milyen gyakran frissíted, de maradna a kiírt érték a következő frissítésig. Ennyi.Amit a kolléga ír, hogy 5x próbáld újra, az se rossz ötlet, de nem feltétlen előnyös,
főleg, ha esetleg a programnak várnia kell a konverzióra, és közben csinálna mást.Szerk: ki lehet íratni hibajelzést, de ha a felhasználó nem tud vele mit kezdeni, hát
kevésbé fáj, ha kimarad a hibás olvasás és a következő körben látja a friss értéket. -
DigitXT
félisten
válasz
Atamano
#12305
üzenetére
Amennyire tudom, zavarérzékeny a kommunikációja...
Megfelelő feszültségtüskével totál le lehet fagyasztani!Természetesen ameddig csak hibát dob, de újra tudod
olvastatni, akkor azt kell csinálni. Ha átmeneti a zavar,
nincs ezzel semmi gond, a hibás értéket meg eldobod:
a felhasználó meg se látja, hogy egy frissítés kimaradt. -
DigitXT
félisten
válasz
tibi-d
#12242
üzenetére
Izébigyó: a videókártya driver az nagyon nem Open Source, nagyon rossz példa...
A hardverért ugyan fizettél, drivert meg kapsz hozzá - már ameddig kapsz -, hiába
van benne valami hiba, azt csak a gyártó tudja kijavítani, te otthon magadnak nem.Extrém példa: egy régi szkennernek a gyártó nem készítette el a Win7-es driverét,
így dobhatod ki a kukába, vagy használhatod tovább XP-vel. Ha Open Source lenne
nyilván nem kérdés, hogy tudod-e portolni magadnak Win7-re, vagy sem, esetleg a
"közösség" már megtette helyetted. -
DigitXT
félisten
válasz
zsolti_20
#12230
üzenetére
Szerintem neked nem a szoftvered (?) eladásán kellene még gondolkodnod, hanem hogy az alapfogalmakkal tisztában legyél, s vmi jól működő kódot írj, saját kútfőből. Ha ez mind megvan, akkor térhetünk vissza arra, hogy más ember munkájáért, amit neked ingyen elérhetővé tett adott feltételekkel jogszerű-e ill. etikus-e pénzt kérned?
Persze, ha kapsz licenszt a továbbértekesítésre, az más kérdés! Akkor azon kellene elgondolkodni, hogy mennyi hozzáadott értéket jelentenek a te kiegészítő soraid?
(Miért venne tőled bárki meg egy Arduino-t, amin a te kódod van "fixen"? Ha maga is építget + tanulgat, inkább hasznos számára az általad feltalált ismeret, ha van ilyen, amit esetleg ő maga is tovább fejleszt, neadjisten kijavít, ha bugos... azért ezek nem ipari megoldások, főleg azzal a mentalitással, hogy nem tudom miért, de most jó.)Szerk: na, telóról írtam (legalább sokáig tartott), szétesett az egész, bocsi.
annyira kinotte magat a project hogy akar eladasra is mehetne
Szerk2: milyen projekt amúgy, mert amit itt láttunk belőle, az eléggé ilyen otthoni gyakorolgatás volt (amivel nincs semmi baj, pont arra van a platform), és baromira nem egy kész termék. Ha viszont van ilyened, és az ahogy előttem írták nagy részben más munkájára épít, akkor bizony nem úszod meg a licenszelést. Azért az nagyon kevés, hogy a binárisból majd nem fejtik vissza, és akkor megúszod. Illetve működhet, csak se nem etikus, se nem jogszerű. Persze amíg nem jönnek rá, bármit eladhatsz "sajátként".
-
DigitXT
félisten
válasz
zsolti_20
#12181
üzenetére
Szerintem ez még jó gomb mellett is tud anomáliákat csinálni, mert nincs
prellmentesítve, és egy kattintást lehet, hogy 20-30 kattintásnak érzékel...Szerk: mondjuk ha semmi kritikus nem függ tőle, akkor önmagában azt a
kis villogást, amit ennek hatására a LED-ed csinál, nem fogod észrevenni. -
DigitXT
félisten
válasz
zsolti_20
#12167
üzenetére
Attól függ! Simán megoldható gerjesztőáramkör nélkül, csak nem konstans
jelet írsz ki az adott lábra, hanem egy négyszögjelet, ennek előnye, hogy a
sípolás frekvenciáját saját magad választod ki. Még zenélni is tudsz vele.
(Vagy mondjuk a rendőr-szirénát utánozni, 670 és 1500 Hz közt csúsztatva:
kerestem róla a videót, uis skicceltem össze egy ilyet tavasszal... De csak
a programkód van meg: úgy látszik mégsem vettem fel a nagy művet, LOL.)Tehát, ha esetleg mégis ilyet próbálnál ki, a tone függvény a barátod...
-
-
DigitXT
félisten
válasz
Bogyo72
#12149
üzenetére
A nem háttérszínű törlés is jó ötlet, mert akkor látod, miből marad ott: csak
azt tudom elképzelni, hogy véletlenül nem pont az előző értéket írod ki...
Olyat nem tudok elképzelni, hogy adott parancs eredménye véletlenszerű...Szerk: én nem szórakoznék a gettextbounds-szal, ha tudom, hogy mekkora
a lehető legszélesebb szöveg, akkora téglalapot rajzolnék alá mindig. -
DigitXT
félisten
válasz
Bogyo72
#12147
üzenetére
Ne csak az utolsó karaktert próbáld kiírni háttérszínnel, hanem konkrétan
kompletten az előző karakterláncot. Akkor annak kutya kötelessége pont
ugyanoda kerülni, ezzel letörölni az előző kiírást, majd mehet az új.A gettextbounds-os történet + a háttérszínnel való törlés is jó lenne szvsz,
max. azon bukhat, ha az új szöveg szélességét kérdezed, az nem segít...Szerk: debuggolásban hasznos, ha valami rikító színnel aláfestesz, így ha
nem pont azt törlöd, mint amit kell, konkrétan látni fogod, hogy miért nem,
ha meg feleslegesen nagyot törölsz, akkor azt is látni fogod, mekkorát.
Szerk2: én azt csinálnám, hogy egy adott infónak előre meghatároznám a
lehetséges legnagyobb szélességét, és mindig akkora területet törölnék... -
-
DigitXT
félisten
válasz
zsolti_20
#12011
üzenetére
Ezt inkább a telefon topikjában. Az utángyárott akksi lehet szar, eBayen árulnak
mindent... Mindent IS. Ami nagyon olcsó, általában szar is. Nem nagyon szokta
érdekelni a kínait, hogy amit ráír az konkrétan hazugság, még 18650-ben sem.Utóbbi azért volt itt releváns téma, mert azt lehet tápnak használni. Samsung S5
akkut nem. (Pont ma vettem egy 18650 töltőt tesztelésre... Telefon akkuhoz nem
tudom, mi lenne a jó: pl. az se rossz, hogy ha fele annyi időt bír ki, akkor kamu a
kapacitása, de esetleg az akku tömege is árulkodó, de csak akkor tudod lemérni,
ha már nálad van, szóval ha kiderül, hogy kamu szar, így jártál. Esetleg refund.) -
DigitXT
félisten
válasz
zsolti_20
#11923
üzenetére
Neeem... A "kinek" lesz a helyi változód, konkrétan a függvény paramétere.
Ha csak egy pipe-ot tud egyszerre nyitni, mi lenne ha lezárnád küldés után?Szerk: a szerkre, na igen, nem definiáltam a móricka példában i-t, my bad...
A fordító sipákolna! Vannak amúgy nyelvek, ahol nem, és így is lefutna, LOL.Az az int változó amúgy nem a címnek kell, hanem a címek tömbjét címezni...
Mert ugye azért van a címeidnek tömbje, mert nem törvényszerű, hogy 1,2,3,4,5
az összes cím, lehetne öt tetszőleges számkombináció, viszont a ciklus csak a
tömb elemein lépdel végig, nem érdekli, hogy mi lesz az öt elem... Sőt valójában
az sem, hogy mire fogod használni a 0-4 közötti paraméterekkel hívott függvényt. -
DigitXT
félisten
válasz
zsolti_20
#11921
üzenetére
Baromi egyszerű, csak az alapfogalmakat kell ismerni. Kezdve azzal, hogy a
void az nem egy hasra ütött elnevezés, hanem a visszatérési érték típus... ún.
visszatérési érték nélküli függvények ezek (leánykori nevükön szubrutinok).
Mint függvények viszont paraméterezhetők, tehát írhatsz ilyen függvényt, hogyvoid kuldes(int kinek){
radio.begin();
radio.openWritingPipe(addresses[kinek]);
radio.setPALevel(RF24_PA_MIN);
radio.stopListening();
const char text[] = "Hello World";
radio.write(&text, sizeof(text));
delay(1000);
}Ezt pedig utána úgy hívod meg, mint bármilyen más függvényt, pl. kuldes(1).
És ez kényelmesen ciklusba szervezhető, ha úgy gondolod, hogy egy gomb
mindent vigyen:
"if gomb 1 megnyom"
for (i=0;i<5;i++) kuldes(i);Szerk: ne feledd, hogy tömböknél az első elem címe nem 1, hanem 0.
-
DigitXT
félisten
Szerintem itt arra gondolt a költő, hogy ezt a kódrészletet bedobja egy nagyobb
kódba, amikor az itt a loopban szereplő dolgokat, egy kuldjedwaze nevű "voidba"
teszi, viszont valami furmányos okból nem ír bele for ciklust a tömbön való végig
lépkedéshez, hanem inkább kuldjedwaze2 néven újabb voidot szeretne írni, hogy
oda másik tömbhivatkozást használjon. Ez kétségkívül nagyon érdekes módja a
tömbök használatának... A 30 bájt spórolás külön tetszett, ínséges időket élünk. -
DigitXT
félisten
válasz
zsolti_20
#11915
üzenetére
Nem akarok windischgrätz lenni, de tudod, hogy a const az mitől const?
Mert ha igen, akkor hogy gondoltad, hogy majd azt növelgeted?Megint olyan tippeket kérsz tőlünk, hogy nem látjuk, hogy mit csinálsz,
de ebből mondjuk meg, hogyan kell jól/jobban csinálni. Legalább valami
normális kódrészletet szúrj be, amiből látszik a probléma. Ezek megint
nem Arduino specifikus dolgok, hanem a tömbökkel vannak gondjaid. -
DigitXT
félisten
Egy Uno készlettel kezdtem. Végig vacakoltam a hétszegmenses/LCD kört,
aztán megváltás volt a 320x240-es színes kijelző, sokkal több infó elfér...
(Nyilván az Unora is lehet rendes LCD-t kötni, de nekem az már túl barkács,
nem lehet megúszni, hogy az ember fixre építse vmi műszer dobozba, stb.)Ha nem modulokat veszel, az M5stack se LEGO, ugyanúgy drótokkal megy.
Csak az alapokat nem kell dobozolni, és még egy pici akku is jár hozzá...
Legutóbbi projekt, roller gyors-diagnosztika. Abszolút el lehet játszani vele:
Tavaly a mérlegem vezérlését írtam meg rá, ez is DIY, 5 kg load cell, HX711:
-
DigitXT
félisten
válasz
zsolti_20
#11896
üzenetére
A fele nekem kínai, de pl. az LCD-s baszakodás helyett nekem sokkal jobban
tetszik pl. az M5Stack beépített kijelzője. (Igaz, csak 3 beépített gombja van.)
Viszont pont azért stackable, mert vannak hozzá modulok, egymásra építhető.Szerk: van benne beépített SD kártya olvasó is. Meg hangszóró: gagyi de szól,
azaz kb. kettő perc alatt írsz példaprogramból mp3 lejátszót, nyilván nem nagy
zenei élmény céljából, de pl. visszapofázni a felhasználónak. Ez is gagyi, de
legalább van.Néha olyan érzés fog el, hogy az új kólaautomatákon is ilyen van. -
DigitXT
félisten
válasz
Gergosz2
#11888
üzenetére
Írjunk be ilyeneket hasra, hogy ne foglalj 1Kbyte-ot egy String-nek, ha csak
két szót fogsz benne tárolni? Vagy mire gondolt a költő? Eleve az Arduino-
féle String implementáció egy nagy szar, és nem igazán ajánlott használni.Simán el tudom képzelni, hogy sok ilyen van benne, s azért fekszik meg.
De lehet nagyobb vasat alá tenni a projektnek, csak nehogy azt is kinője. -
-
DigitXT
félisten
Van webshop meg telefonos elérhetőség is. Azért mondtam, mert elég nagy
választékuk van polcról is. Bocsánat, hogy nem kerestem ki neked a konkrét
alkatrész elérhetőségét. Amúgy mondanám, hogy hestore.hu, de oda "hiába"
mész, rendelős. Viszont ha raktáron van, 1 nap és mehetsz érte. Vagy posta. -
#11735
DigitXT
félisten
tonermagus
#11734
DigitXT
félisten
válasz
tonermagus
#11734
üzenetére
Mi is volt a kérdés?
-
#11733
DigitXT
félisten
tonermagus
#11732
DigitXT
félisten
válasz
tonermagus
#11732
üzenetére
De a 7-8 kg-os etetőcsónakot meg ugye nem 9V-os elemről akartad táplálni?
-
#11719
DigitXT
félisten
tonermagus
#11717
DigitXT
félisten
válasz
tonermagus
#11717
üzenetére
Ahogy az előttem szóló írja egy ilyen 9V-os elem képtelen nagy áramokat leadni,
amikor megpróbálkozol annyira terhelni, drasztikus feszültségesést láthatsz...
Természetesen a kapacitása is a béka segge alatt van: ha szedtél már szét ilyet,
láthattad, hogy 6 db icipici cellából áll, ilyen felhasználásra teljesen alkalmatlan...Fognod kéne valami Li-Ion cellát (pl. a klasszikus 18650), és azzal meghajtanod:
azok kapacitása sokszorosa egy 9V-os elemnek (3-4x) névleges feszültség 3.6V
azaz kettő ilyen sorba kötve, 7.2V névleges feszen bőven kiszolgálná a motor. -
DigitXT
félisten
válasz
zsolti_20
#11692
üzenetére
Valószínűleg arról van szó, hogy csak mutatót definiáltál. Nem foglalva neki
megfelelő mennyiségű memóriát, írsz bele, a vakvilágba. Esetleg egymásra
írnak. A C ugye egy típusos nyelv... így nem lehet a kódoddal kapcsolatban
beszélgetni, hogy bemásolod egy részletét + állítasz valamit, hogy mit ír ki,
ám azt nem mondod meg, hogy melyik változóra, mikor, és mi az a változó.Szívesen segítenék, de ez alapján szerintem nem lehet. A konyvtar pl. egy
char[9]? És beleraktad, mondjuk hogy "konyvtar" az inicializálásakor? -
DigitXT
félisten
válasz
zsolti_20
#11686
üzenetére
OMG: nyilván...
De az nem is volt benne az eredeti kódrészletedben...
Bepakoltál 8 db byte-ot egy közelebbről meg nem határozott tömbbe és kalap.
Mivel a print a lezáró nulláig megy, s az nem volt benne, ettől már "fagyhatott":
amiért akkor működik, amikor megadtad neki az inicializáláskor a fájlnevet, az
az, hogy az implicit belerakja a lezáró nullát. Tudom, hogy elsőre nem annyira
triviális a karaktertömb / mutató kérdés, de ez alapvetően C, és nem Arduino...Szerk: sajna a pastebint nem tudom megnézni a céges gépen, ebédszünetben
telefonról néztem, aztán ennyi maradt meg belőle a fejemben. -
DigitXT
félisten
válasz
zsolti_20
#11679
üzenetére
Nézd, programozni nem lehet csak ennyire elmesélős szinten. Nem tudjuk,
pontosan mit csináltál azzal a sprintf-fel, mibe akartál vele írni mit... Azt se,
hogy debug esetén mit látsz: az alap C programozást célszerű megismerni.
Kifagy az egész? Már mi? Az arduino? Végtelen ciklusba kerül a kód? Nincs
lefoglalva előre a memória? Nem nullára végződik a karakter sorozat? -
DigitXT
félisten
válasz
zsolti_20
#11672
üzenetére
Az csak elírás, hogy egyszer kis string, másszor meg nagy String? Csak mert
nem ugyanazt jelentik. A String az egy objektum, annak van "+" művelete. Míg
a string az nem objektum: talán így le sem fordul a kód, ha kisbetűvel írtad...A "filename" amúgy micsoda? Azt hol definiáltad, és hogyan kap értéket?
Na igen a 8.3 is befigyel, de így nehéz debugolni, hogy csak a fél kód van meg. -
DigitXT
félisten
válasz
zsolti_20
#11668
üzenetére
Ilyenkor célszerű felütni valami referencia dokumentációt, pl. mondjuk ezt: [link]
bool SdFat::exists ( const char * name )
Test for the existence of a file.
Parameters:
[in] name Name of the file to be tested for.Returns:
true if the file exists else false.Vastagítás tőlem: ennek nem lesz jó a String objektum, ha amúgy azt használsz:
szerencsére erre is van megoldás, konkrétan átkonvertálja karaktertömbbé. -
DigitXT
félisten
válasz
zsolti_20
#11661
üzenetére
Mint írtam, az a vessző a paramétereket választja el, tehát ahogy a hibaüzenet írja:
az a hívás nem érvényes, hogy átadnál neki egy const char [5] és egy char [13]-at.
Ott egyetlen paramétert vár, tehát előtte össze kellene fűzni, pl. valami ilyesmiképp SD.exists(concat("asd/",filename))Csak most nincs előttem, hogy ez a concat megvan* natív C-ben, vagy az Arduino
féle Strings objektum kreálmánya, amit amúgy nagyon fikáznak ebben a cikkben...*: ha nincs, akkor persze meg lehet írni, de ez nem Arduino-specifikus dolog.
-
DigitXT
félisten
Tud konvertálni, persze, csak honnan a viharból* tudja, hogy mi a TZ?
Én úgy értettem a kérdést, hogy GPS alapon kell, a te kódod ugye NTP...*: hacsak meg nem mondod neki "parasztosan", hogy márpedig ez.
Szerk: ha jól látom, te is beírtad kézzel, hogy CET... Szerintem a kérdés
arra vonatkozott, hogy ezt honnan lehet megtudni GPS alapján: amúgy
találtam vmi NMEA stringet, ami erre vonatkozik, de nem próbáltam. -
DigitXT
félisten
válasz
gazso75
#11341
üzenetére
Ez teljesen jó megoldás, mint mondtam, ez programozható...
Csak akkor valójában semmi köze a GPS pozícióhoz, hanem
felteszed, hogy mindig Magyarországon használod a cuccot.
Amit a kolléga linkelt szintén jó lehet, csak fel kell másznia a
cuccodnak a netre, hogy lekérdezze az időt, időzónával... -
DigitXT
félisten
válasz
gazso75
#11339
üzenetére
GPS pozíció szerint kellene a helyi idő? Az érdekes lesz... Nem elég ugye az
időzóna határokat pontosan ismerni, de még ott van a téli-nyári időszámítás is.
(Amíg van.) Kis hazánkban ugye +1 óra télen és +2 nyáron: ez programozható.Gyorsan rákeresve egy ausztrál Arduino projektet találtam, ahol ugye országon
beül is van van három különböző időzóna. Mindenesetre érdekes a kérdés...
Szerk: belenézve az ausztrál kódba az szart se ér. FIX 10 órával tolja el. Azt
hittem legalább figyelembe vesz valamilyen koordinátát az országon belül, LOL.Ha univerzális megoldás kell, a tzdata lesz a kulcs, gondolom netről letölthető.
-
-
DigitXT
félisten
Én most egy NEO-M8N alapú cuccal szöttyögök. (M5Stack) Példaprogram fut:
beltérben picit nehezen talál jelet, de kellő türelemmel megvárható az is. (Csak
rohadt nagy szórással mér ilyenkor, szóval 1-3 km/h körül ülök egy helyben.)Szerk: kint azért jóval pontosabb volt. Bár kevesebb hódot látott, mint a telefon.
-
DigitXT
félisten
válasz
gazso75
#11198
üzenetére
Az a baj a kódban, hogy az "előző értéknek" mindig eltárolod az aktuálisat.
Akkor is, ha az egy hibás adatot tartalmazó mérés. Két ilyen egymás után,
és már be is került a logba a hibás adat... Igaz, nem kétszer, csak egyszer.
(Folyománya, hogy a hibás adat "elfogadása" után a jót is egyszer eldobja.)A másik, amit weiss is ír, hogy ha újra beolvasod, akkor már nem telejesen
biztos, hogy ugyanazt kapod vissza, mint a korábbi olvasásnál... Változóba
tenném, így csak egyszer olvasnám be, azon nézném a feltétel teljesülését.A harmadik, amire még gondoltam, hogy az hibás adathoz vezethet-e, ha túl
sűrűn próbálod olvasni az aktuális értéket, bár ha ez az adott modul tudja az
5 Hz-es frissítést is, akkor elvileg 4 Hz-en kérdezgetve nem lehet baj. De azt
nem tudom, hogy hogyan működik a háttérben a könyvtár, ami kezeli...A negyedik ehhez lazán kapcsolódón: ha van 2 méteres szórása, akkor nem
túl sok értelmét látom másodpercenként négyszer rákérdezni, hol a játékos.
Szerintem sok-sokesetenkénthibás koordinátából nehezebb távot számolni.Ha viszont ennyire behatárolt a felhasználás, akkor a hibás adat értelmezése
is túlságosan megengedő (csillió km/h): elég az ha mondjuk 50 métert ugrott
odébb egyetlen másodperc alatt, futva azt se követhette el => mérési hiba. -
#11088
DigitXT
félisten
---gabika---
#11087
DigitXT
félisten
válasz
---gabika---
#11087
üzenetére
Mert rosszul van zárójelezve. Csak nyomvatartásra megy be,
viszont folyton kapcsolgatja az állapotot, amíg nyomva van... -
DigitXT
félisten
Én azt se tudom, hogy eszik-e vagy isszák ezt a polyfuse-t, ám azt azért kicsit cikornyának érzem, hogy tutorial (!) alapján épített cucc legyilkolja a PC USB-jét. Ha és amennyiben ilyen könnyen előfordulhat (nem csak occó kínai klónnal)...
Szerk: rákerestem, nagyjából értem, és úgy néz ki pár találatból, hogy a Nano-n nincs, ellentétben mondjuk az UNO-val. Tiszta szerencse, hogy nekem UNO van.
Simán stepper motorozgattam vele itt az USB-ről. Még laptopról is. Igaz, hogy nem nagy áramú valamire kell gondolni, hanem épp ellenkezőleg, műszeregység lépetőmotorja volt/lesz a meghajtott cucc, kifejezetten kis áramfelvételű (elvileg). Szerk2: szervót (még) nem próbáltam, de akkor külső táp nélkül inkább nem. -
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.
-
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
DigitXT
#10835
üzenetére
Na kivittem a kütyüt a fészerbe. Rá az éles órára: valóban 90 körül akadt meg a
mutató. Utána persze én sem tudtam visszavinni nullába, mert én is beleírtam a
programomba, hogy ha (elvileg) már végállásban van, ne próbálkozzon tovább.
Pedig egy kis erőltetéssel át lehetett volna billenteni, de nyilván ez nem opció...Szétszed, összerak, és a lényeg: TESZTEL! Nem hogy elindulok, aztán kiderül.
-
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.) -
DigitXT
félisten
válasz
t72killer
#10829
üzenetére
Anno unokatesómnak volt egy játékautója, ami 6 db "C" elemmel ment, sokáig.
Persze az drága volt, de jött az ötlet, hogy 9V. Mi baj lehetne? Ment vagy 1 percet.Másik ökörségem (ezt már felnőtt fejjel követtem el): 9.6V akkupakkos játékautóra rákötöttem egy 12V motorakksit. Ment is mind a meszes. (Persze relatív, mert azt a rohadt nehéz akksit alig bírta el, kicsit olyan volt, mint egy önjáró lövegtorony.
)Aztán leégett az egyik motorvezérlő... Pedig már épp hagytam abba a tesztelését. A következő ötletem inkább egy bazinagy nitrós játékautó "zöldrendszámosítása".
De hogy ne csak OFF-oljak jelenleg egy UNO-val tekergetem a motorom km óráját teszt üzemmódban: nagyon jól jött volna, amikor kiakadt, hogy visszatekerem vele. Mielőtt vki félreértené: léptetőmotoros "analóg" sebességmérőről van szó. Nem táv! (A köznyelvben az "óratekerést" másra értik.
Kb. 90 km/h-val álltam vele... LOL.) -
DigitXT
félisten
Bár nem ismerem a fejlesztőkörnyezetet, de általában meg kell adni a path-t,
ha csak ilyen kacsacsőrök közé rakod a headert, azt az alap helyen keresi.Minimum idézőjelbe kéne tenni (HA a forrásfájl mellett van), vagy konkrétan a
könyvtárat is megadni. De mint mondtam, ez csak az "általános tapasztalat". -
Azt arra mondtam, hogy olyankor "kicsit"
Szkipt nyelvek tudnak soronként futtatni
)
Sokkal valószínűbb, hogy![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
ekkold- Csere-Beszámítás! Gigabyte Aorus Elite RX 9070 XT 16GB Videokártya! Bemutató darab!
- GIGABYTE RTX 3060TI 8GB VISION OC
- Csere-Beszámítás! Sapphire Pulse RX 9070 XT 16GB Videokártya! Bemutató darab!
- Topping D30 Pro (ezüst) eladó
- ! AMD Brutál Gamer Konfig ! 9800X3D / 7900XTX ( RITKASÁG ) 32Gb RAM 32Colos ROG Monitor
- Fém, összecsukható és kihúzható fotó állvány eladó
- 129 - Lenovo Legion Pro 7 (16ARX8H) - AMD Ryzen 9 7945HX, RTX 4080
- Telefon felváráslás!! Xiaomi Redmi Note 11, Xiaomi Redmi Note 11 Pro, Xiaomi 11 Lite
- LG 45GR65DC-B - 45" Ívelt 1500R / 5120x1440 / 200Hz 1ms / Adaptive Sync / AMD FreeSync / HDR 600
- ÁRGARANCIA!Épített KomPhone i5 13400F 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged