- Milyen billentyűzetet vegyek?
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- SD-kártyát vennél? Ezért ne csak a GB-ot nézd! – Tech Percek #9
- Fejhallgató erősítő és DAC topik
- ASUS notebook topic
- Melyik tápegységet vegyem?
- Milyen SSD-t vegyek?
- Azonnali alaplapos kérdések órája
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- AMD K6-III, és minden ami RETRO - Oldschool tuning
-
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
-
válasz
gya/352
#19398
üzenetére
Hoppá.
Találtam egy ilyet:Slow SPI, Testing VS1053 read/write registers...
19:04:19.827 -> D: This is not a VS1053, but a VS1003 instead!
19:04:19.938 -> D: Fast SPI, Testing VS1053 read/write registers again...
19:04:21.637 -> D: This is not a VS1053, but a VS1003 instead!A setupban át van ez javítva?
#define DEC_VS1053 // Hardware decoder for MP3, AAC, OGG
//#define DEC_VS1003Bár a log szerint így is felismeri, de hátha.
-
gya/352
tag
-
gya/352
tag
Köszönöm a segítséged.
A particiós séma az default volt. A többit nem tudtam mit jelent, így nem kisérleteztem vele.
Nem tudom mennyi féle sémának kellene lenni ott, de nekem három van.
A pastebin-t nem ma fogom megismerni, úgyhogy elnézést, de bemásolom az egész soros monitort.
Szerk:
Eltünt amit bemásoltam, lehet hogy túl sok lett volna és nem engedte a fórummotor. -
#19396
Aryes
nagyúr
Laurencius
#19390
válasz
Laurencius
#19390
üzenetére
Próbáld már ki, hogy az ExampleTftBufferedCameraFrame.cpp fájlban ezt a részt módosítod:
void sendLineToDisplay() {
if (screenLineIndex > 0) {
screenLineStart();
#if GRAYSCALE_PIXELS == 1
for (uint16_t i=0; i<camera.getLineLength(); i++) {
sendPixelByte(graysScaleTableHigh[camera.getPixelByte(i)]);
sendPixelByte(graysScaleTableLow[camera.getPixelByte(i)]);
}
#else
for (uint16_t i=0; i<byteCountForDisplay; i++) {
sendPixelByte(camera.getPixelByte(i));
}
#endif
screenLineEnd();
}
}úgy, hogy a for (uint16_t i=0; sorokban a 0-t átírod például 20-ra! Ez elvileg a képet 20 pixellel balra fogja tolni. Ha ez működik, akkor lehet tovább lépni.
-
Ilyenkor jövök rá, mennyire csak a felszínét piszkálgatom én ennek az egésznek...
Honnan a fenéből tudja, hogy mivel kell összelinkelődni, ha a setup.h-ba nincs include-olva és még csak nem is egy könyvtárban vannak?
Arról nem is beszélve, hogy pl az initializeScreenAndCamera() 6 fájlban fordul elő, de ezek közül egyik sem a library-ben fordul elő, hanem example fájlok:
-
#19391
Aryes
nagyúr
Laurencius
#19390
válasz
Laurencius
#19390
üzenetére
Ez nekem magas, remélem valaki el tudja nekem magyarázni, hogy hogy tud lefordulni ez a gyakorlatilag üres fájl...
-
#19390
Laurencius
újonc
Aryes
#19389
Laurencius
újonc
Aha... igen ez. Nem tudom, hogy mi az a #include. Nem volt semmi gondom a kód feltöltésével, az Arduino tökéletesen működik a kijelzővel meg a kamerával.
Lehet, hogy arra gondolsz, amikor elolvastam a kód feltöltésének az utasítását, ott volt, egy olyan kitétel, hogy ezt, meg ezt kézzel másoljam be egy adott könyvtárba, de ha már benne van, akkor nem szükséges.
Hát, most nem tudom pontosan idézni, de ha szükséges, akkor majd előbányászom, és itt majd idézem a megfelelő sorokat.
Fordítás Arduino IDE-ben:Töltse le az összes fájlt
másolja az "src/lib/LiveOV7670Library" és az "src/lib/Adafruit_GFX_Library" fájlokat az Arduino "libraries" mappájába (ha már rendelkezik "Adafruit_GFX_Library"-vel, akkor nem kell másolnia)
Nyissa meg az „src/LiveOV7670/LiveOV7670.ino” fájlt az Arduino IDE-ben
Válassza az Eszközök -> Tábla -> Arduino Uno/Nano lehetőséget -
#19389
Aryes
nagyúr
Laurencius
#19388
válasz
Laurencius
#19388
üzenetére
Mármint hogy ezt?
A github oldal megvolt eddig is, csak nem értem, hogy ez az *.ino fájl hogy kerül lefordításra, mert hogy nincs benne egyetlen #include sem... -
válasz
gya/352
#19386
üzenetére
Nagy dolog nem lehet, mert alapvetően működik a cucc.
Vannak különböző memóriasémák, abban a menüben ahol a lapot kiválasztod, meg a portot stb. Ki tudod választani, hogy mennyi legyen az app, az OTA, és a SPIFFS. Ha nem szeretnéd OTA frissíteni a firmware-t, azt ki is lehet hagyni. Próbálj végig többféle sémát, hátha ott van a kutya elásva.A kódot megnézve elég beszédes debug ügyben. Tedd már meg, hogy nem csak a hiba jelentkezése utáni debug szöveget, hanem bekapcsolástól az összes kiírást (a hiba jelentkezéséig, illetve az első sikeres lejátszásig) lemented a terminálról mondjuk ide hogy meg tudjuk nézni.
-
-
válasz
gya/352
#19384
üzenetére
A routerre vonatkozó kérdést már másodszor ugrod át elegánsan...
Feltöltéskor milyen memóriamodellt választottál ki? Úgy tűnik az adatok tartós tárolása hibádzik valahol. Viszont a kezelő felület html része is a SPIFFS-ben van tárolva, és az működik, tehát SPIFFS van.
-
gya/352
tag
Igen, ez igaz, én sem találtam nyomát, hogy másnál is így működne.
Telefontöltőről működtetem a cuccot, de elmegy a PC USB portjáról is, kb. 150 mA-t vesz fel. Az ESP32-ről van átdrótozva az 5V a DAC-ra és ott van rajta még 47 uF kondi.
Elég nehezen tudom elképzelni hogy a felsorolt problémák lennének, mert a hiba az elég konzekvens, viszont van néhány adó amivel viszont jól működik. -
válasz
gya/352
#19378
üzenetére
Volt már téma korábban.
Anélkül, hogy beleásnám magam a szoftver részébe: ha azzal gond lenne, annak valószínűleg nyoma lenne a github oldalon az issues fülön, de nincs. Tehát valószínűleg hardveres gond lehet. Elsősorban a táp résszel lehet valami gubanc: milyen tápot kap az egész cucc és külön-külön az összetevők?
Ha az rendben van, akkor az összeköttetés az esp és az mp3 modul közt (rövidzár, laza forrasztás, esetleg külső zavar). És nem tudom, hogy a router, amire az egész kapcsolódik, volt-e már újraindítva, de az is tud problémát okozni. -
gya/352
tag
Üdv Mindenkinek!
Bocs ha nem ide való a téma, de alkalmasabb topikot nem találtam.
Nagyon új vagyok a témában úgyhogy előre elnézést kérek.
Összeraktam próbából egy internetes rádió lejátszót. ESP32 és VS1003. Az edzelf féle projectet. Azért ezt mert ez volt a számomra legjobban másolható, mivel Arduinohoz, programozáshoz nem nagyon értek. Alapjában véve működik a cucc, de vannak vele gondjaim. A legnagyobb baj az, hogy induláskor nem kezdi el lejátszani a beállított állomást, hanem mégegyszer ki kell választani a web-es felületről és úgy kezdi el lejátszani. Úgyan ez igaz szinte bármelyik rádióállomásra, hogy ha kiválasztom a listából akkor sem kezdi el lejátszani, hanem újra ki kell választani és akkor már műxik. Remélem érthetően irom le miről van szó. Ilyenkor az alábbi látszik a terminálon:
[19:54:01]D: Connect to host icast.connectmedia.hu/5001/live.mp3
[19:54:01]D: Song stopped incorrectly!
[19:54:01]D: REG Contents
[19:54:01]D: --- -----
[19:54:01]D: 0 - 808
[19:54:01]D: 1 - 33
[19:54:01]D: 2 - 8
[19:54:01]D: 3 - 6000
[19:54:01]D: 4 - 0
[19:54:01]D: 5 - AC45
[19:54:01]D: 6 - C1
[19:54:01]D: 7 - 1E06
[19:54:01]D: 8 - 0
[19:54:01]D: 9 - 0
[19:54:01]D: A - 0
[19:54:01]D: B - F8F8
[19:54:01]D: C - 0
[19:54:01]D: D - 0
[19:54:01]D: E - 0
[19:54:01]D: F - 0Van valakinek ezzel kapcsolatban tapasztalata?
Ez lenne a legfontosabb kérdés, ezen kívűl van még más gond is, mert nem fogadja a parancsokat MQTT-n keresztül, de annélkül lehet élni.
Köszönök bármilyen tippet. -
#19373
Aryes
nagyúr
Laurencius
#19372
válasz
Laurencius
#19372
üzenetére
Tedd már meg, hogy belinkeled, hogy pontosan mit és honnan töltesz/fordítasz (*.ino fájlt), mert ilyen zavaros github oldalt még nem láttam.
Mit nyersz egyébként a kép mozgatásával? -
#19372
Laurencius
újonc
Laurencius
újonc
Arduinó Mega 2560 val szeretnék vezérelni egy TFT kijelzőt. A problémám az, hogy potméterrel tervezem a kijelzőn megjelenő képet jobbra-balra (20 pixellel) mozgatni A program írása a gond. Tudnátok-e ebben segíteni egy-két ötlettel, tanáccsal?
A kijelző:
1,8 hüvelykes SPI TFT LCD kijelző modul ST7735 128x160
A project:
https://www.youtube.com/watch?v=Dp3RMb0e1eA&ab_channel=Indrek
Mindezt már megépítettem, csak a potméter kódját nem tudom beilleszteni a fő kódba. -
Wolfram
aktív tag
válasz
vargalex
#19366
üzenetére
Igen, esp8266:esp8266:d1_mini, kihalásztam azarduino-cli board listall -ból (a list nem ment).
Viszont most azt látom hogy a fordítási idő elképesztő hosszú ( 4 perc? )
arduino-cli --fqbn esp8266:esp8266:d1_mini compile <projectdir>
Ehhez van valamilyen paraméter? (fordításhoz használt memória stb)
-
válasz
ekkold
#19363
üzenetére
Mert az ARM ismeri a lebegőpontos műveleteket, az AVR meg nem.
Mikor csináltam az oszcilloszkópomat (UNO), ciklusidőre ki volt számolva a program, és a lefordított asm alapján faragtam le további értékes μs-okat meg pontosítottam az időzítéseket.
Akkor láttam, hogy milyen ügyes optimalizációkat csinál a fordító. -
ekkold
Topikgazda
Igen lehet ilyen "trükkökkel" gyorsítani egy programot, de ez processzor függő is.
Pl. a BluePill (STM32F103) a legtöbb utasítást egyetlen órjel alatt végrahajtja, tehát a feltétel kiértékelés, vagy éppen egy változó ellenőrzése ugyanúgy egyetlen órajel idejéig tart (14 nanosec).Csak érdekességképpen az ESP procik lassabban olvassák a flash-t mint az STM (és a programkód a flas-ból fut), emiatt ez utóbbi annak ellenére gyorsabb, hogy alacsonyabb az órajele. Amikor elkezdtem használni a BluePill-t, meg is lepett, hogy mennyire gyors (főleg egy arduino-hoz képest). Ráadásul hardveres szozó/osztó modulja van így az esetek nagy részében az is egyetlen órajel. Ez anyit jelent, hogy a kódban pl. szorzás helyett bitléptetést használva (vagy fordítva) ugyanolyan sebességgel fut a program. De mondjuk Atmega proci esetén (pl. arduino nano) hatalmas sebességkülönbség van a két módszer között. Ez utobbi esetében a szorzás/osztás esetén gyakorlatilag egy ciklusnak kell lefutnia a prociban.
-
válasz
ekkold
#19361
üzenetére
Esetleg még érdekességképpen annyit, hogy ha egy feltételt többször is meg kell vizsgálni (pl.: if(feltétel1 && feltétel2)
...
if(feltétel1 && feltétel3)
...) akkor előzetesen a feltétel1 vizsgálatának az eredményét érdemes egy változóba menteni, mert azt tudja úgy optimalizálni a fordító, hogy a processzor egyik regiszterét használja cache-nek (a lassabb RAM művelet helyett) és így magát a vizsgálatot is csak egyszer végzi el. -
ekkold
Topikgazda
válasz
tibi-d
#19360
üzenetére
Ha a feltételek egymást kizáró relációban vannak, akkor kérdés a gyorsaság
Ebből a szempontból nézve is a második verzió a gyorsabb.
Viszont akkor lehetne if()....else.... ágat létrehozni, hogy a harmadik feltételt ne is vizsgálja ha a második teljesült. Ez még egy hajszálnyit jelenthet sebességben. -
-
#19351
ReFleXx
addikt
razorbenke92
#19347
ReFleXx
addikt
válasz
razorbenke92
#19347
üzenetére
mondjuk inkabb berakok egy 200forintos tp4056os töltőmodult az tuti nem engedi 3V alá meriteni.
-
#19349
ekkold
Topikgazda
razorbenke92
#19347
ekkold
Topikgazda
válasz
razorbenke92
#19347
üzenetére
Amúgy szerepel a 18650-es akksik adatlapján, hogy meddig lehet kisütni, károsodás nélkül?
Pl. fehér lehet üzemeltetek 18650-es celláról ami kb 3V-ig tudja kisütni, utána meredeken csökken a fényerő. Eddig úgy gondoltam, hogy ez így rendben is van - vagy mégsem? -
#19348
Aryes
nagyúr
razorbenke92
#19347
válasz
razorbenke92
#19347
üzenetére
Mindig tanul az ember
-
#19347
razorbenke92
őstag
Aryes
#19343
long readVcc(){
long result; // Itt olvasod ki a belső referenciát AVCC-hez viszonyítva
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
delay(2);
ADCSRA |= _BV(ADSC);
while (bit_is_set(ADCSRA,ADSC));
result = ADCL;
result |= ADCH<<8;
result = 1125300L / result; // 1023*1100mV osztva 1.1 értéke AVCC-re vetítve// ha 1023-at mértél, akkor AVCC 1100 mV// ha 256-ot mértél, akkor AVCC ~4400 mVreturn result; }Itt van fent a kód, sajnos fejből nem vágom ennyire a regisztereket, ezért csak egy régi kódomból tudtam kipuskázni, de lehetséges.
Ahol megismerkedtem ezzel, ott Attiny45-öt táplálok direktben 18650-ről a gyerek egyik csillagprojektorában. Eredetileg elemmel ment és nem tudott magától kikapcsolni. Akksira váltottam, viszont azzal mire észreveszem a merülést a fényerőn, addigra kinyírtam volna a cellát. Szóval van benne egy szimulált "merülés" effekt, ami leveszi a LED-ek fényerejét, amikor a cella már közeledik a 3V-hoz.
-
Harcipocok84
tag
Jelenleg a betáp után (ami egyébként stabil 6V) van egy LF50CV, ami szépen kreál stabil 5V-ot. Azután van egy fóliakondi majd azt követ egy 1000uF-os kondi, és ezután van az Arduino betáp lábjai. Majd nem messze onnan ismét van egy 1000uF-os kondi, de az inkább a bluetooth modul miatt van benne. Biztos vagyok benne hogy nem ez a legelegánsabb megoldás, de ez eddig működött tökéletesen, és ettől az egy EEPROM hibától eltekintve nem volt más gond vele. Tudom hogy a fesztab IC elé is kellene kondi, de alapból stabil tápról kapja már a 6V-ot is.
-
#19343
Aryes
nagyúr
razorbenke92
#19342
válasz
razorbenke92
#19342
üzenetére
Az atmega tartalmaz egy beépített feszültségreferencia adót, ami kvázi egy ultrapici 1.1V stabkocka
...
Ha megméred az internal vref feszültségét, abból vissza tudsz skálázni a tápfeszre.Ezt meg lehet csinálni? Hogy? Úgy tudom a beépített 1.1V feszültséget csak referenciaként lehet használni analóg méréshez, de azt magát nem lehet megmérni. 🤔
-
#19342
razorbenke92
őstag
Aryes
#19341
Jó ötlet a saját implementációjú BOD.
Nem resetel magától, de megvéd a rossz írástól.Ha esetleg a hardver módosítás akadály lenne, akkor szoftverből is megoldható egy kis trükközéssel.
Az atmega tartalmaz egy beépített feszültségreferencia adót, ami kvázi egy ultrapici 1.1V stabkocka.
Az analóg referencia feszültség a legtöbb alap tervezésben egyezik a tápfeszültséggel, tehát az analóg mérés 1023 esetén a pillanatnyi tápfesz, fele esetén fél tápfesz, stb.
Ha megméred az internal vref feszültségét, abból vissza tudsz skálázni a tápfeszre.
Pl. ha 512-nek méred, akkor kb. 2.2V a tápfesz. Ha 256-nak, akkor kb. 4.4V -
#19341
Aryes
nagyúr
Harcipocok84
#19340
válasz
Harcipocok84
#19340
üzenetére
Azért ne ess kétségbe, nem áll meg itt a tudomány.
Meg lehet ezt kvázi bolondbiztosra is csinálni.
Tegyél egy nagy kondenzátort a táp és a gnd közé, a kondenzátor elé nyitó irányban pedig egy schottky diódát.
Az egyik szabad analóg pinre kösd rá a tápfeszültséget a dióda előtti részről egy áramkorlátozó ellenálláson keresztül. Az 5V tápot osztás nélkül rá tudod kötni, az ellenállás azért kell, hogy bekapcsoláskor ne azon keresztül töltődjön a kondi.
Minden EEPROM írás előtt nézd meg, hogy kap-e még (kívülről) megfelelő tápot a cucc. Ha elég nagy kondit teszel oda, a tápfesz elvétele után még akár pár másodpercig is képes üzemelni, így biztonságosan le tudod állítani. Ez a véletlen brownout-okat is ki tudja küszöbölni (bizonyos szintig), de a megoldás igazából az lenne, ha stabil tápot kapna és nem kapcsolgatná ki senki random módon, ha már fontos automatizált folyamatot vezérel.
-
Harcipocok84
tag
válasz
razorbenke92
#19336
üzenetére
Nagyon szépen érthetően leírtad, köszönöm!
Sajnos az van amitől tartottam... Ha be van kapcsolva a brownout akkor bármikor újraindulhat ezek szerint a vezérlő, ami egy automatizált folyamat közben nem a legszerencsésebb. Én ezért is kapcsoltam ki. És így eddig soha nem indult újra, nem szakadt meg a folyamat, ellenben előfordulhat hogy hülyeséget ír az EEPROM-ba.... Egyébként Atmega2560-at használok, 16MHz a kristály, ezek szerint 4,7-et kellene beállítanom. -
válasz
tibi-d
#19338
üzenetére
Nem a timert állítod le, csak letiltod az interruptot. Annyi mellékhatása lehet, hogy egy interrupt kicsivel később fog kiváltódni, mert két flag egyszerre szükséges hozzá: a timer interrupt és az interrupts enabled. A timer lefutásával beállítja az interrupt flag-et, az úgy is marad, amíg a másikat újra nem engedélyezed.
Ha a timert az interrupton belül inicializálod, akkor értelemszerűen onnantól annyival el lesz csúszva. -
tibi-d
tag
Szeretném megérteni a noInterrupt, interrupt páros működését. Van egy feladat, ahol egy timerinterrupt másodpercenként lefuttat egy taskot. Viszont a programnak van olyan része, ami nem szereti, ha megszakítják. Az a kérdésem, hogy ha a noInterrupttal leállítom a megszakítást mondjuk az utolsó megszakítás után 0.6 másodperccel később, és engedélyezem 0.7-kor, akkor az időzítés hogy alakul? Folytatja 0.6-tól, esetleg 0.7-től, vagy kezdi előről az 1s-ot?
-
#19336
razorbenke92
őstag
Harcipocok84
#19335
válasz
Harcipocok84
#19335
üzenetére
A brown-out önmagában azt jelenti, hogy a mikrokontroller olyan üzemi feszültségen kezd működni, ahol már instabillá válHAT. Tehát ezen a tartományon még nem feltétlenül indul újra, de már csinálhat buta dolgokat.
Ezek a buta dolgok magukban foglalnak olyan eseteket is, amikor a feszültség már nem elegendő például egy eeprom lebegő tranzisztorának átkapcsolására.
Kérdésedre válaszolva: EEPROM írás befejezésében nem tud segíteni, inkább abban segít, hogy az írás el se kezdődjön.
Ha az írás előtti pillanatban még nem alacsony a feszültség, akkor azt az egy írási műveletet megszakítatlanul be tudja fejezni. (Megfelelően kondenzátorozott elektronika esetén a brownout feszültség felső határától a blackoutig van annyi energia, hogy egy-egy byte eeprom írást még befejezzen vele).Amikor a brownout detection be van kapcsolva, olyankor a mikrokontroller felismeri mikortól nem kellene pl. EEPROM írásba fogni, és szándékosan reset állapotba teszi magát, így még akkor is újraindul, ha nem kéne, sőt általában beállít egy status bitet is, amiben jelzi magának, hogy az újraindulás oka az alacsony feszültség volt.
Ha nálad nincs bekapcsolva, az pontosan okozhat olyan gondot, hogy a kódfutás megszakítatlan, de az eeprom-ba szemetet írsz, ha nincs meg a kellő tápfeszültséged. Definíció szerint az ilyen állapotokat igyekszik a brownout-detection megakadályozni.
Szerk.:
2.7V lehet kicsi, de akár nagy is. Ez az Atmega328p esetében 10MHz órajelhez a biztonságos feszültség.
Ezt mehet feljebb, 20MHz esetén 4.5V, de lehet akár még alacsonyabb is, ugyanis a chip minimum feszültsége 1.8V a 8MHz-es belső oscillátort használva.
Ha az elterjedt Nano/Uno kártyák valamelyikét használod, akkor azon 16MHz oscillátor lesz, tehát inkább átmennék 4.5V-ra. -
Harcipocok84
tag
válasz
razorbenke92
#19334
üzenetére
Na, ez már valami amin elindulhatok. A Brown-out detection alapból ki is van kapcsolva nálam. Viszont alapból 2,7V-on áll, ami nagyon kicsi, nem?
Mit csinál pontosan ez a brown-out? Valamiért beesik a feszültség és ilyenkor ha éppen EEPOM műveletben van akkor azt befejezi? de hogyan?
Illetve ha tényleg ez történt volna hogy beesett a feszültség a kritikus alá, akkor nem kellett volna hogy újrainduljon az arduino? De nem indult újra, végig tudott menni a folyamaton és használt is utána.... -
#19334
razorbenke92
őstag
Harcipocok84
#19328
válasz
Harcipocok84
#19328
üzenetére
A probléma megértéséhez kicsit bele kell mélyedni az EEPROM-ok lelki világába.
Fizikai rétegen egy eeprom írás igazából úgy zajlik, hogy törlődik az összes byte. Ez az általános elképzeléssel ellentétben nem azt jelenti, hogy nullázódik, hanem azt, hogy minden érték 1 lesz. Majd ebből az állapotból szelektíven állít mindent nullára.
Ugyebár te egy viszonylag kicsi tartományon operálsz, tehát a bytejaid (arduino int 2 byte) valahogy így festenek:
0b1000000010010110 (előjelbit, +150 15 maradék biten)
Amikor a dínó írni próbál, átáll erre:
0b1111111111111111
majd elkezd nullázni. Ha azonban nem ér végig brownout miatt például, akkor kapsz a memóriába egy bármilyen számot, ami 32,767 és az általad menteni kívánt szám között szerepel valahol.Ha kritikus információt akarsz menteni, akkor ahogy a többiek írták, mentsd el többször, és vezess ellenőrző összeget a mentésekről, hogy tudd, ki a hibás.
-
#19333
#68216320
törölt tag
Harcipocok84
#19330
#68216320
törölt tag
válasz
Harcipocok84
#19330
üzenetére
Lehet, hogy butaság, de mi van olyankor, ha dupla rekordot használsz az íráshoz?
1.a. első rekordba beírod a tartalmat
1.b. visszaolvasod az első rekord tartalmát
1.c. ha klappol, akkor csinálsz egy crc-t, ezt beírod a második rekordba2.a. második rekordba beírod a tartalmat
2.b. visszaolvasod a második rekord tartalmát
2.c. ha klappol, akkor csinálsz egy crc-t, ezt beírod az első rekordbaÍgy hiba esetén (crc error) van egy valid adatod.
-
#19332
cog777
senior tag
Harcipocok84
#19330
cog777
senior tag
válasz
Harcipocok84
#19330
üzenetére
Ha fontos az adat amit elmentesz, lehet hogy mentenek melle egy CRC/checksum whatever extra meta adatot es azzal ellenoriznem a beolvasott adatot. Ha hibas, akkor egy alapertek hasznalnek. (esetleg naploznam ezeket az esemenyeket egy sd kartyara, de ez mar nagyon extra)
-
#19331
ekkold
Topikgazda
Harcipocok84
#19330
ekkold
Topikgazda
válasz
Harcipocok84
#19330
üzenetére
Az EEPROM kb. 10^6 irást bír ki (egymillió). Az olvasás nem számít, akárhányszor olvasható. Megsérülni akkor tud a tartalma, ha írás közben fogy el a táp.
Ha reprodukálható a hiba, akkor azért a szoftverhiba is esélyes. Az EEPROM-ba mentéshez szoktam definiálni egy struktúrát a mentendő adatok számára, ezt használva gyakorlatilag nem lehet elrontani a címzést sem.
-
Harcipocok84
tag
Sajnos pont az a bajom, hogy nem tudom reprodukálni és zavar, hogy nem tudom miért történt. Programozási hiba talán kizárva. Az EEPROM címek nem fedik egymást, és egyik változó sem akar a másik EEPROM mezőjébe írni. A menthető értékek ahogy írtam maximalizálva vannak, tehát még 150 felé sem mehetett volan az érték, mert ha értékadás utána 150 feletti az érték akkor 150-re visszaírja és csak ezután történik az EEPROM-ba írás.
Az hogy a szóban fordó EEPROM cím "elhasználódott" kizárt, mert max. 100-200db írás történhetett rá eddig. Bár én ha jól tudom az olvasás is bele számít az elhasználódásba, nem tudom hogy igaz-e...Működött szépen az eszköz, menet közben átírtam az adott értéket 100-ról 120-ra, elmentettem az EEPROM-ba, majd az eszköz működött szépen tovább. Hozzáteszem mentés utána újra beolvassa az értékeke és ebből dolgozik tovább, tehát a mentéskor még jó érték volt benne, és visszaolvasáskor is jó volt.
Majd jött egy áramtalanítás,elindult az eszköz, setup részben beolvastam újra mindent, és ott már a rossz érték volt. Visszaírtam az értéket 120-ra, újra elmentettem, majd újabb áramtalanítás után megtartotta a jó értéket, és azóta is jól működik áramtalanítás után is.Egyszer hülyüt meg.... És ez nagyon zavaró...
Esetleg egy öteletem van: a felhasználó szerint, volt egy olyan pillanat, amikor bekapcsolta, majd szinte azonnal ki is kapcsolta.
- Elképzelhető olyan, hogy pont olvasta azt az adott EEPROM címet amikor hirtelen kapott egy áramtalanítást, így az "megsérült"? Olvasás tönkre tudja tenni a cím tartalmát ha idő előtt befejeződik?
- Olvastam valamit a Brown-out-ról, hogy talán pont az ilyen dolgok ellen véd? Hogy ha éppen EEPROM művelet zajlik, és megszűnik a táp akkor előtte befejez minden EEPROM műveletet? DE NEM AKARLAK EZZEL megvezetni, lehet semmi köze hozzá... -
#19329
Aryes
nagyúr
Harcipocok84
#19328
válasz
Harcipocok84
#19328
üzenetére
Szia! Ha ez egyedi eset volt, akkor bármi lehet. Az EEPROM írás viszonylag hosszú művelet, az is lehet, hogy éppen akkor áramtalanítottad, mikor írt volna, és még egy korábbi értéket kaptál vissza.
Az is lehet, hogy az egyik cella egyik bitje elérte a maximális írási mennyiséget és csendben elromlott. Talán 10ezer írást bír egy ilyen EEPROM cella, te tudod, hányszor írtál bele. Próbáld a hibát reprodukálni, ha tudod melyik cella volt. -
#19328
Harcipocok84
tag
Harcipocok84
tag
Sziasztok!
Használom Arduino Mega-val az EEPROM library-t.
Jellemzően INT Értékeket mentek el különböző memóia területekre, minden 5. memória címre írok ki egy-egy változó értékét, tehát nincs átfedés.Tökéletesen működik is, szépen írja-olvassa az értékeket ki-be kapcsolás utána az eszköz. Az értékeket mentés előtt lekorlátozom, amint a maximális érték felé megy akkor újra értéket adok neki ami a maximális értékkel egyenlő. Ez is működik, nem tudom magasabbra állítani az értéket.
Viszont történt egyszer, hogy beállítottam egy értéket 50-re, majd újraindítás utána 27000 körüli értéket dobott vissza, pontosan már nem tudom mennyi volt.
Ez miért lehetett szerintetek? mikor ment el fals adatot? mihez kapcsolható ez az érték (gondolok itt arra, hogy valamilyen típus maximális értéke, stb...)
Természetesen ügyelek rá, hogy ne loopban legyen az EEPROM írás/olvasás, csak értékadáskor nyúl az eepromhoz... -
válasz
#68216320
#19323
üzenetére
Kell egy darab nyáklap, amire alkoholos tűfilccel rárajzolod az érintkezőket méretarányosan, és valaki kimaratja neked. Szerintem csak akad itt a topikban is valaki helybeli, aki sörért/csokiért segít.
Utána valószínűleg le kell csiszolni a másik oldalát, hogy ne legyen vastagabb, mint egy microSD kártya. -
válasz
Wolfram
#19320
üzenetére
Esetleg ezzel tegyél egy próbát, nem teszteltem, csak hogy fordul-e.
#include <HTTPClient.h>
class customHTTPClient : public HTTPClient
{
public:
using HTTPClient::GET;
String GET(const String &url)
{
String result;
if(begin(url))
{
if(GET() > 0)
{
result = getString();
}
end();
}
return result;
}
};
void setup()
{
customHTTPClient http;
String result = http.GET("http://www.test.com");
} -
Janos250
őstag
válasz
Wolfram
#19320
üzenetére
Nincs ez elbonyolítva.
Hirtelenjében ezt hoztam össze.
Ha erre gondoltál használd, ha nem, majd valakinek valamire hátha jó lesz.#define __cplusplus 201103L#include <WiFi.h>#include <WiFiClient.h>#include <string>#include <iostream>#include <fstream> // ofstream#include <stdio.h>using namespace std;#define remoteServerPort 80//const char* ssid = "*********";//const char* password = "*********";uint8_t ServerIPlocal[] {192,168,0,30} ;uint8_t gatewayIPlocal[] {192,168,0,1} ;uint8_t subnetIPlocal[] {255,255,255,0} ;WiFiServer remoteServer (remoteServerPort );WiFiClient remoteServerClient ;void setup() {delay(1000);Serial.begin(115200) ;delay(1000);WiFi.begin(ssid, password );delay(2000);WiFi.config(ServerIPlocal, gatewayIPlocal, subnetIPlocal) ;WiFi.setAutoReconnect(true);delay(2000);printf("\nConnecting to %s \n",ssid);uint8_t i = 0;while (WiFi.status() != WL_CONNECTED && i++ < 20){printf(".");delay(500);}if(i == 21){printf("\nCould not connect to \n",ssid);while(1) delay(500);} ;string strMyURL = "http://"+to_string(WiFi.localIP()[0])+"."+to_string(WiFi.localIP()[1])+"."+to_string(WiFi.localIP()[2])+"."+to_string(WiFi.localIP()[3])+":"+to_string(remoteServerPort);printf("My URL: %s \n",strMyURL.c_str() );uint8_t ip[]{192,168,0,33};String valasz = httpGet((IPAddress)ip) ;Serial.println(); Serial.println(); Serial.println(); Serial.println();Serial.println("ez a valasz:");Serial.println(valasz);} // end setupvoid loop() {} ; // end loopString httpGet(IPAddress ip){const char GET_HTTP[] PROGMEM = R"=====(GET / HTTP/1.1)=====";uint16_t idozites ;String reply ;WiFiClient remoteServerClient ;if (!remoteServerClient.connect(ip,80)){return "no connect";Serial.println ("connect hiba");} ;// Serial.println ("connected");remoteServerClient.println(GET_HTTP);idozites = 0 ;reply = "" ;while (remoteServerClient.available() ||(idozites++ < 500)) // rxBuffer->available(){if (remoteServerClient.available()){char c=remoteServerClient.read();idozites = 0 ;reply += c ;// printf("%c",c);}else{delay(1);}; // if (remoteServerClient.available())} ; // end while (remoteServerClient.available())// printf("\n");remoteServerClient.stop(); // _rxBuffer = NULL; _connected = false;// Serial.println();Serial.println();Serial.println();Serial.println();// Serial.println("Ez a string");// Serial.println(reply);return reply ;};
-
#68216320
törölt tag
Sziasztok.
Van ötletetek arra, hogy milyen megoldással lehetne egy microSD kártya foglalatból vezetéken kihozni az ereket?
Lehet ugyan kapni szalagkábellel extender-t, de nekem arra volna szükségem, hogy a kártya slotba belemenjen egy dummy kártya, ami a másik oldalán pin-ekben végződik.
Létezik ilyesmi? -
-
-
Megnéztem, nagyon jó kis kezdő szett annak, aki nem szeretne forrasztással bíbelődni, csak plug-and-play.
Sajnos semmilyen részletet nem ír az alkatrészekről, de a motor a videó alapján talán a nagyobbik (1:120) áttételű lehet. Én mégis azt mondom, hogy pont neked való lenne. -
Na, összeszedtem pár javasolt alkatrészt kifejezetten smart car témában:
UNO/Mega kompatibilis cuccok:
TB6612 Mosfet Stepper Motor PCA9685 Standard IIC I2C PWM Servo Driver Shield V2 For Arduino Robot PWM Mega R3 Replace L293D
[link]
Én ilyet használok a mega boarddal, de akkor még nem volt ennyire drága
Előnye, hogy van rajta egy kisebb proto pcb, ahová fel lehet forrasztani kisebb dolgokat, kijelzőt, LED-eket.2Pcs 1:120 electric TT Motor Durable Dual Shaft DC 3V ~ 9V DC Geared Motor for Robot Toys Smart Car Replace DIY Kit
[link]
Ahogy írtam, egy vonalkövető robothoz jobb a lassú motor, mert hiába lehet PWM-mel szabályozni, de bizonyos kitöltés alatt nem mozdul meg, csak zúg.Optokapu az encoderhez (a kerék sebességét lehet vele mérni):
[link]Reflektív opto, ütközés/közelségérzékeléshez:
[link]Vonalkövetéshez nem kifejezetten alkalmas, oda színes LED + fototranzisztor kell, ilyet készen most nem találtam, az enyémen sincs amúgy, de lenne rá igény
I2c RGB szenzort találtam, de a vonalkövetéshez legjobb 3-5 szenzort egymás mellé tenni, a vonal vastagságától függő távolságban. Ezt egyszerűbb és olcsóbb otthon legyártani.Bluetooth modul:
[link]
A HC06 csak vevő, telefonnal lehet párosítani, a HC05 az master-ként is tud működni, saját távirányítót lehet belőle építeni.D1 mini/ESP kompatibilis cuccok:
360 fokos szervó
[link]A hangsúly a 360fok / folyamatosan körbe forgó (continuous) tulajdonságon van, ezek át vannak alakítva, hogy ne csak oda-vissza tudjon forogni, hanem folyamatosan is. Nem kell hozzá driver, a fentihez még kereket is adnak.
D1 mini motor shield
[link]
Ha mégis DC motort szeretnél használni (janos250 linkelt egy kis méretű motort, ami jó hozzá).Ha majd még eszembe jut valami, megírom.
-
zsolti_20
senior tag
Sziasztok! Szeretnék építeni egy szolenoid kapcsoló szerkezetet amihez az áramforrást 18650-ről szeretném megoldani.
Régebben már építettem egy viszonylag jó kapcsolást egyszerűbb dolgokhoz, de a szolenoidhoz kicsit több áramerősség szükséges, amit a jelenlegi 5v DC-DC converter nem igazán bír kezelni.
Van itthon egy elég jó power bankom, ami képes 2.1A-t leadni 5V, mellett ez elég volt a 2 szolenoid kapcsolóhoz, de nem szeretnék egy komplett power bankot befogni erre. Tudnátok légyszíves ajánlani olyan DC-DC convertert ami a 3.7V-os 18650-ből tud stabil 5V-ot csinálni a lehető legnagyobb áramleadás mellett?
Jelenleg ezt használom:
[link]
De ez egész biztosan nem tudja a leírtakat, mivel 3-at párhuzamba kötve sem bírt el egy szolenoid kapcsolóval, nekem pedig kettőt kellene kapcsolnom.
Köszönöm!
Akkor láttam, hogy milyen ügyes optimalizációkat csinál a fordító.
Előnye, hogy van rajta egy kisebb proto pcb, ahová fel lehet forrasztani kisebb dolgokat, kijelzőt, LED-eket.
Új hozzászólás Aktív témák
Hirdetés
- Samsung Galaxy A55 - új év, régi stratégia
- WLAN, WiFi, vezeték nélküli hálózat
- Formula-1
- Milyen billentyűzetet vegyek?
- War Thunder - MMO Combat Game
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- SD-kártyát vennél? Ezért ne csak a GB-ot nézd! – Tech Percek #9
- Medence topik
- Allegro vélemények - tapasztalatok
- Fejhallgató erősítő és DAC topik
- További aktív témák...
- BESZÁMÍTÁS! MSI SUPRIM X RTX 4080 16GB videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! 6TB Seagate SkyHawk SATA HDD meghajtó garanciával hibátlan működéssel
- BESZÁMÍTÁS! 4TB Samsung 870 EVO SATA SSD meghajtó garanciával hibátlan működéssel
- BESZÁMÍTÁS! Intel Core i7 8700K 6 mag 12 szál processzor garanciával hibátlan működéssel
- BESZÁMÍTÁS! Intel Core i7 4790 4 mag 8 szál processzor garanciával hibátlan működéssel
- MSI CreatorPro Z16P - i7-12700H, RTX A5500, értintőkijelző
- Beszámítás! Sony PlayStation 5 825GB SSD digital konzol garanciával, hibátlan működéssel
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max/
- LG 45GS95QE - 45" Ívelt OLED / 2K WQHD / 240Hz 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- ÚJ Apple Macbook Air 15,3 M4 10C CPU/10C GPU/16GB/256GB - Ezüst -(2025) - 3 év gari - MAGYAR
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged