Fórum témák
» Több friss téma |
WinAVR / GCC alapszabályok: 1. Ha ISR-ben használsz globális változót, az legyen "volatile" 2. Soha ne érjen véget a main() függvény 3. UART/USART hibák 99,9% a rossz órajel miatt van 4. Kerüld el a -O0 optimalizációs beállítást minden áron 5. Ha nem jó a _delay időzítése, akkor túllépted a 65ms-et, vagy rossz az optimalizációs beállítás 6. Ha a PORTC-n nem működik valami, kapcsold ki a JTAG-et Bővebben: AVR-libc FAQ
Köszönöm kedves Pethical!
Bár sejtettem, hogy a chip-en belül lesz a megoldás, és a három memória közül az EEPROM lehet az "igazi", valójában még válaszodnál is részletesebb javaslatra számítottam...
Ilyesmire gondoltam, de nem próbáltam ki.
Ha akarod tehetsz bele még egy magic numbert is, hogy tudd, hogy volt-e már valaha mentve bármi is az eepromba, vagy csak szemét van benne.
A kódblokk üres sorokat tesz be amit engem már egy ideje szörnyen bosszant. Azt hiszem, hogy a CRLF-et, CR-ként és LF-ként értelmezi és még helytelenül is, mert az CR-t is új sorként kezeli. Amit ide beírtam az három sor, nem pedig 5, közte két teljesen felesleges üres sorral.
Kérdés, hogy "mennyit" mozog. Adatlapot ha megnézed, az eepromok kb 100000-szer irhatók...
Én inkább pl ha van RTC chip, abban szokott lenni ram (meg elem), vagy FRAM-ot használnék, ami korlátlanul írható
Köszönöm szépen Pethical! Erre gondoltam, Nagyszerű, működik, tényleg sokat segítettél!!! Még egyszer köszönöm!
Szomorúság, amiket Pipi kolléga ír, mert 30-40-szer is elfordulhat 50-60 fokot, vagyis akár 40x600impulzus =24.000 értéket is felvehet NAPONTA!, ami 4 napos élettartamot sejtet... Lelki szemeim előtt olyan diódás-elkós külső áramkőr lebeg, ami kikapcsolás, illetve áramszünet esetén még néhány másodpercig kitart, és pl. a D5 lábon érzékeli, hogy most jött el a mentés pillanata... Nyilván az egész kütyü csak akkor működhet, ha D5 megkapja az 5V-ot, de így elsőre ezt egy If-el meg lehet oldani. Köszönettel derűs estét kíván; Tambi A hozzászólás módosítva: Jan 29, 2023
EERAM az eszköz neve. Van SPI és I2C verzióban is.
SRAM és EEPROM is van egy tokon belül. Folyamatosan írhatod, nem használódik el, mert a RAM területre írsz. Ha elmegy a táp, észreveszi, és egy kondenzátorban tárolt energiával átmásolja az EEPROMba. Mikor megjön a táp, automatikusan átmásolja az EEPROM tartalmát a RAMba.
Folyamatosan forog az enkóder? Vagy ember forgatja. Előbbi esetben kiépíthetsz egy backup tápot a mikroprocesszornak, ami észreveszi, ha elmegy a táp, utóbbi esetben érdemes csak akkor menteni, amikor megmozdult az encoder. Tekerés közben biztos, hogy el kell menteni az értéket, vagy csak akkor, amikor már megállt az encoder? Mit csinál ez az encoder egyáltalán?
Lásd mellékelt. Többször használtam ezt a megoldást, teljesen jól működik csak egy-két dolgot át kell gondolni az alkalmazás előtt.
Bekapcsoláskor a kontrollerhez kapcsolódó egyéb eszközök juttatnak feszültséget a kontroller valamelyik lábára? Pl. egy RS485 - UART konverter IC TX lába előb kerülhet magas sziintre, mint a kontroller kondenzátora feltöltődne. Ezt egy egyszerű soros, 1 kΩ-os ellenállással ki lehet bekkelni. Kikapcsoláskor, amikor a kondenzátorban még van feszültség de a környezet már nyugovóra tért, lophatja valami az áramot? Pl. direkt kapcsolat egy 2x16 karakteres LCD kijelzővel. Amikor beüt az áramszünet, ezeket a lábakat bemnetre kapcsolod és készen is van. Programozás szempontjából nem egy nagy dolog. Bekacsoláskor ellenőrzöd, hogy a feszültségfigyelő lábon van-e feszültség. Ha van, lehet továbblépni. Ha nincs, várakozol, amíg meg nem jelenik a ménkű. Ha a lábon megszűnik a feszültség (célszerű megszakítást használni), indítod az aktuális adatok mentését. 2200 µF-nak bőven elégnek kell lennie, ha arról csak a kontroller jár. Én a mentés után újra szoktam indítani a kontrollert mert mentés előtt minden kimenetet bemenetre kapcsolok, minden megszakítást letiltok, mindent leállítok stb. Még így is bőven van idő a kondenzátorban, újraindítás után még a maradék energia miatt feléled a kontroller, ezért kell bekapcsoláskor figyelni, van-e valós tápfeszültség vagy csak a kondenzátor utolsó rúgásáról van-e szó.
Óh igen, ezzel sajnos nem számoltam.
 No, de korrigáljunk, és oldjuk meg csak szoftveresen.  Ha naponta 25 000 írás van, és egy címet az EEPROMban 50 000 írásra használsz csak, akkor 2 bájt 2 napig tart. Egy Atmega328 IC-vel számolva aminek 1024 bájt EEPROMja van, 2 nap * 1024 bájt / 2 bájt = 1024 nap, azaz majdnem 3 évig ki fog szolgálni az IC. Ehhez az kell, hogy az EEPROMban azt is tárold el, hogy mennyiszer írtad az adott címet. Lehet ez mondjuk pont a 0x0000. cím. A 0x0002-től meg egy egész, hogy épp melyik címnél járunk, melyiket írjuk. És kezdetben a 0x0004-től írjuk az adatokat, ez így az első szabad cím. Tehát: 1. Kell egy változó, int EEPROM_Writes = 0; 2. Kell egy másik, int EEPROM_Address = 0x0004; 3. Indulásnál 3/a. Kiolvasod a 0x0002-es címet az EEPROM_Address változóba, ide fogsz írni (ha 0, vagy 0xFFFF, akkor 0x0004 legyen, ekkor még nem volt használva az EEPROM, ez írd is vissza) 3/b. Kiolvasod a 0x0000 címed az EEPROM_Writes változóba (ha az előbb 0-t, vagy FFFF-et olvastál, akkor legyen ez 0 és ezt is írd vissza a 0x0000 címre) 3/c. A pulses értéket kiolvasod az EEPROM_Address címről, ez a mentett értéked 4. Minden írásnál inkrementálod az EEPROM_Writes változót 5. Ha elér egy határt (mondjuk 1 000-el osztható), akkor beírod a 0. címre (ebből nem kell élő adat, kis hiba belefér) 6. Ha eléri az 50 000-et, akkor 6/a. Inkrementálod az EEPROM_Address-t 2-vel, és beírod a 0002-es címre 6/b. Nullázod az EEPROM_Writes-t és beírod a 0 címre a 0-t 6/c. Az értéket beírod az EEPROM_Address címre, hogy meglegyen, mert itt fogod keresni legközelebb 7. Ha az EEPROM_Address eléri a 0x03F0 értéket, akkor már az utolsó 16 bájtot írod, jelzed, hogy csere szükséges pár napon belül 8. Ha a 0x3FE címnél is elérsz a 6. ponthoz, akkor nem 0x03FF, hanem 0x0004 a kövi cím és sírjon, hogy EEPROM élettartam már nagyon lejárt. (Bevezethetsz egy olyat, hogy innentől, az újrakezdéstől kezdve egy címet mondjuk csak pár alkalommal írsz utána lépsz tovább, így kisebb az esélye, hogy kiégeted egy adott címen. Ehhez mondjuk letárolsz az EEPROM_Writes-ba mondjuk 100 000-et és ebből tudod, hogy mivel nagyobb, mint 100 000, így 101 000-nél már lépni kel és nem nullázni, hanem 100 000-re állítani. Így ezt se kell tárolni. Ehhez a 6-os pontban nem csak azt kell figyelni, hogy 50 000-nél több-e, hanem előtte meg kell nézni, hogy 100 000-nél több-e) Ezzel a módszerrel 1020 bájtunk maradt, mert 4-et felhasználtunk élettartam kímélésre. Az 510 darab 2 bájtos egész szám tárolására elég, így 510 * 50 000 írásod lehet biztonsággal. Ez 25 500 000 írás összesen, ami napi 25 500 írással számolva kereken 1 000 nap. A 0. cím pedig 50 * 510 = 25 500 alkalommal fog íródni, ami bőven belefér, a 0x0002 pedig 510 alkalommal íródik felül. Tehát ha minden nap megy, hétvégén is, akkor 2 év 9 hónap lesz egy IC élettartalma, ráhagyással, mert nem használtuk ki az írási lehetőségeknek csak kb. a felét. Ezen bizonyára lehet egyszerűsíteni is, ha van bárkinek ötlete.
Egyszer én is terveztem hasonló rendszert, de aztán kiderült, hogy akkor is elfordulhat a jeladó, amikor az MCU nincsen áram alatt, és ezért mégsem jó megoldás ez. Tényleg leírhatnád, hogy mire használod ezt a rendszert. Ha el lehet helyezni egy ésszerű 0 pontot és annál újra kalibrálni induláskor, az jobb megoldás.
Az a megoldás, hogy felismered, hogy a táp csökken, és akkor írod be az értéket, az szerintem is működik és remekül megoldja az öregedés problémáját. Külön hardver sem feltétlenül kell hozzá, a tápfeszültséget a belső referenciához mérten lehet monitorozni, és lehet detektálni, hogy csökken. Úgy kell megcsinálni az áramkört, hogy ilyenkor még legyen egy kis szusz a rendszerben a lementéshez, tehát a kapacitást a fogyasztáshoz képest jól kell méretezni. Ha nem jó megoldás a folyamatos tápfeszültség méregetés, akkor egy feszültség osztóval a "bandgap reference"-hez viszonyítva lehet a beépített komparátort használni, ennek előnye, hogy egyetlen egy lábat használ el, és mégis azonnal interruptot is tud adni, amint a tervezett szint alá esik a tápfeszültség. Erre reakcióként le lehet kapcsolni a fogyasztókat és a kondenzátor energiájára építve csinálni egy mentést, ahogy Bakman is írta. Hasonlóan a brown out detektor interruptja is talán használható lehet erre a célra. Ez pont erre való, hogy biztonságos leállást implementáljunk általa. Előnye, hogy semmilyen plusz hardver nem kell, és el se kell használni sem ADC-t sem a komparátort erre a célra, ha kellene másra. Megoldás lehet az is, hogy egy kis akkumulátorral a teljes szenzort szünetmentesíted a mikrokontrollerrel együtt. Ez drágább és kicsit gondolkodósabb is, de megoldja azt a problémát, hogy mi van ha a kikapcsolás alatt is tekergetik a jeladót. A Pethical féle megoldást lehet úgy is csinálni, hogy körbe-körbe írod az EEPROM-ot valami olyan szisztéma szerint, amivel felismerhető, hogy melyik volt az utoljára írt cella. Így nincsen kitüntetett cella, amit adminisztratív célra használsz, hanem mindegyiknek ugyanaz a szerepe. Bejegyzésenként eggyel több bittel mint amit menteni kell, ez megoldható. A hozzászólás módosítva: Jan 29, 2023
Üdv!
AT90S2313-10SI tartalmát kellene másolnom és írnom, abszolút semmi info nincs róla, egy kisszériás távirányítóban van külső 4Mhz-es külső órával. A másikban egy AT90S1200-12si van, ami nem működik sajnos és keresztbecserével biztos az a rossz (induláshoz szükséges gombot nyomva amíg nyomva van van órajel, majd eltűnik, illetve a gomb mátrixon egy FET halott volt gate fele valamiért). Természetesen bármilyen chip jó, amire fel lehet írni, csak mivel lenne érdemes ezt kiolvasni és írni, illetve ha esetleg le van védve, akkor azt honnan lehet tudni és mit lehet kezdeni vele? Bármilyen forrasztás nem probléma, Arduino, rpi, ch341a és usbasp van kéznél, de mást is lehet venni, ha kell. Ahogy nézem usbasp támogatja, de kérdéses nincs-e levédve, hogy deríthető ki és hogy másolható, ha védett? A hozzászólás módosítva: Jan 30, 2023
Rákötöd a programozót, és megpróbálod kiolvasni a programot. Próbáltad? Ha sikerül, akkor nyertél. Ha nem, akkor nem lehet. Lezárást nem egyszerű megkerülni. Vannak olyan hirdetések a neten, hogy párezer dollárért megcsinálják neked.
20 éve nem gyártják ezt a mikrokontrollert, nehéz lesz szerezni. Van egy lábkompatibilis utódja az ATtiny2313. Ha jól tudom, akkor a bináris nem jó, újra kellene fordítani a forrásból a programját.
A chip szerzés a legkisebb probléma.
Nem próbáltam még, áramkörön belül csak a programozó 6 vezetékét kéne bedrótozni, programozót 5V-ra jumperelni és annyi, maradhat minden rajta, 4MHz óra és egyebek is? Gondolom usbasp viszi, mert leírásban szerepelt valahol ez. Illetve win7/10 alá mit ajánlanál GUI-nak, vagy mi az avrdude parancs, amivel kiderülne a védelem állapota? Nagyon nem vagyok AVR-es dolgokban jártas, csak akadt ez a dolog. Igazából ha értenék hozzá, meg is írhatnám nulláról, mert elég kevés funkció van, de ez nekem rémálom lenne kb .Ilyen régi chipnek nincs valami ismert sérülékenysége?
Ezt a konkrét csipet nem ismerem, de aminek néztem az adatlapját, ott úgy működött a kiolvasás védelem, hogy kiolvasáskor csupa FF-et adott. Azt tippelném, hogy a kiolvasás végigfut, csak a kiolvasott tartalom lesz unalmas, ha védett a program.
Nem használom ezt a programozót.
Atmel mikrokontrollerekhez Atmel ICE-t vagy PICkit 4-et használok Atmel Studioval.
Köszönöm szépen mindenkinek a részletes elgondolásokat!
A "kütyü" MD10 néven 0,1 fok pontosságú szögmérőként funkcionál egy szalagos fémfűrészgépben. Csak sajnos téveszt... Mivel 600 mm-es gerendákat is vágunk vele, a néhány tizedfok "csalás" több milliméter behegesztendő hézagot is eredményezhet, vagy pl nem merőlegesen hegesztjük fel az oszlopra a talplemezt, ami sok cm dőlést is okozhat... és jön a levonás, vagy a macerás függőlegesbe állítás és műgyantával történő aláöntés... A "tévesztés"-t részben konstrukciós, részben emberi hiba okozhatja: A forgatandó fej kellően csapágyazott, tömege azonban közel 300 kg. Ezért a kollégák a pontos, 0,1 fokos beállítást kézzel történő enyhe ütögetéssel tudják csak megoldani, mert 300 kg-t nem lehet ilyen pontosan sem megállítani, sem 0,1-0,2 fokkal arrébb fordítani. Az ütögetés, mivel kézzel történik nem árt a gépnek, de vélelmezzük, hogy az ilyen "gyors" impulzusugrásokat az MD10 nem képes kezelni. Ha hinni lehet az "írás"-nak, az MD10 40 kHz-ig működik, ami ugye 25 usec, az alkalmazott Omron encoder 3600 pulzust ad fordulatonként 3000f/perc-ig, ami 18kHz-es, ami 55usec. A leggyorsabb kezű kezelőt feltételezve, mondjuk a beállító kéz sebessége 20(!) m/sec (72 km/h!). A beállítókaron 0,1 fok elfordulás 4,3 mm elmozdulást jelent, ami 4,3/20000 = 220 usec. Ez durván egy nagyságrenddel(!) hosszabb idő, mint a jeladó és számláló működési sebessége, tehát a hiba máshol keresendő, vagy rossz az "okoskodás" -om? Persze szerencsésebb lett volna 40 kHz-es jellel meghajtani a mérőt, sőt akár ac servomotorral is forgathatnánk az encoder-t, biztos kiderülne valami... Ha ezt Mach3-ból megcselekdnénk szerinetetek mennyire lenne pontos pl a 3000 f/perc??? Talán az elektromosan szennyezett környezet játszik közre; bár az árnyékolás tökéletesnek tűnik, néha 8-10 CO2 hegesztő is üzemel 20-30 m-es körzetben, darabonkánt 300-400 A hegesztőárammal... Köszönettel; Tambi
Nincs kizárva, hogy a 3600 impulzus fordulatonként igazábol 3600 impulzus periódust jelent, egy periódusban pedig négy impulzus is van. Két fel- és két lefutó él Gray kód szerint. Így a 18 kHz mindjárt 72 kHz-re módosul (a számításaidat nem ellenőriztem).
En VSCode-ot hasznalok (pontosabban Mac-en csak 'code') PlatformIO-val, tobbek kozott USBasp-vel is. Abban nem vagyok jaratos, hogy a GUI mennyire tamogatja a Build/Upload-tol eltero funciokat (99%-ban csak ezeket hasznalom), de a pio parancssora eleg jo.
Végül megnéztem a programot is, szerintem van benne elvi hiba is. Ugye lefelé élre számolsz, amit interruptban kezel a program. Mi történik, ha rezeg a bemenet úgy, hogy a 2. láb fel-le-fel-le-fel-le lépeget? Miközben a másik láb állandó értéken van. Ez ugye lehetséges akkor ha pont az átmenetnél állt meg a jeladó és mondjuk a dolgozók ütögetik a munkadarabot, de az nem mozdul el csak rezeg még. Ebben az esetben a program egy irányba fog számlálni többször egymás után miközben valódi elmozdulás nem történik. Tehát hibát gyűjt elvileg korlátlan mennyiségben. Még rosszabb, hogy ilyen átmenet körüli rezgések a való életben maguktól is tudnak jönni a jeladókból (egy éles projekten egyszer megjártam már ezt sajnos, de legalább tanultam belőle). A kvadratúra jelnek ha jól emlékszem minden élére reagálni kell ahhoz, hogy pontosan tudjuk számolni, nem elég csak az egyik jel egyik irányára.
Szintén probléma lehet a jelsebesség is. Bár ebben nem vagyok biztos, mert ha többszáz kilós a munkadarab, akkor a tenyér ütögetése nem hiszem, hogy óriási szögsebességet tud eredményezni, ugye az impulzusmegmaradással kell számolni, és ott a tömegek (illetve pontosabban a tehetetlenségi nyomatékok a tengelyhez mérten) arányában osztani kell a sebességet egyből. De az biztos, hogy az Arduino nagyon sokat lassít a mikrovezérlő futásán. Két probléma van az Arduino keretrendszerrel kvadratikus dekóder készítéshez: eleve nagyon lassú ahhoz képest amit a csipből ki lehetne hozni. Mind az interrupt végrehajtás, mind a digitalRead hívás óriási overhead-del jár. Mikor mást lényegében nem csinálunk, akkor ez az overhead valódi probléma. A másik probléma, hogy ha mást is csinál a csip, akkor nem könnyen tudunk valós idejű válaszidőt számolni. Például az UART kommunikáció interruptja is késlelteti a pin change interrupt végrehajtását. Az meg ki tudja meddig tart? Nem tudunk legrosszabb válaszidő becslést adni, márpedig egy valós idejű (real time) rendszernél ez alapvető volna. (Elvileg lehetséges becslést adni, hiszen az Arduino rendszer teljes forráskódja szabad szoftver, és pontosan megismerhetjük, hogy mit hogyan csinál. Csak éppenséggel nem egyszerű feladat.) Nem olyan régen csináltam egy hasonló projektet egy esztergához, annyi különbséggel, hogy ott lineáris jeladó volt. Elvileg is tökéletes megoldást akartam adni, és a fenti problémák miatt úgy döntöttem, hogy egy külön csipet szánok a mérésre, ami csak ezt csinálja, viszont garantált válaszidővel tud működni. Végül olyan megoldást sikerült csinálnom, ami egy ATtiny25-ön fut és 12 órajelenként garantáltan vesz egy mintát és ez alapján pontosan dekódolja a kvadratúra jelet. 32 biten számol, és ezt 1-2 lábon digitálisan át tudja küldeni a mester processzornak, ami a kijelzést végzi. Plusz képes a nullázó jel vételére és megjegyzi, hogy hol tartott a számláló amikor a nullázás történt. Ezt a dekódert oda tudom adni akár felprogramozva is, ha érdekel. Órajel függvényében 1.3-1.6 MHz jelsebességig garantált a működése. Mivel éppen technológiákat akartam kipróbálni amikor ezt a projektet csináltam, ezért csináltam hozzá néhány tech demó jellegű kiegészítést is: * egy MCU szimulátort, amivel teszteket tudtam végrehajtani PC-n és minden átmenet ki van tesztelve ebben a szimulátorban, hogy jól működik * Arduinoval adtam neki teszt bemeneteket és ezzel is teszteltem a valóságban, hogy jól működik * weben elérhető változatot is csináltam a főprogramnak: https://rizsi.com/programs/lathe_gui/emscripten/lathe.html Ez azt tudja, hogy ugyanaz a program fut böngészőben mint a mikrovezérlőben, csak a fizikai világ helyett egy szimuláció fut. A fenti csúszkákat mozgatva a hétszegmenses kijelzőn mutatja a mért értéket. Pont maga a dekóder ebben nem fut, mivel az a fizikai világ része ezen az absztrakciós szinten.
Vagy használhat a célnak jobban megfelelő mikrokontrollert. Az STM32 családot ismerem közelebbről, ott lehetőség van az enkóderek hardveres kezelésére. Még csak megszakításra sincs szükség, a timer periféria mindent intéz.
Ahogy mondod, nem jó az enkóder dekódolási logika és a digitalRead függvény sem a legfürgébb az interruptban. Viszont ha már Arduinót használna, akkor lenne egy jobb megoldása az enkóder figyelésre, EZ a könyvtár szerintem nagyságrendekkel jobb megoldás mint a programban használt digitalRead es interrupt. Persze itt is ha az A B jelet az Arduino D2/D3 -as (interrupt 0/1) lábára köti. A kritikus része ASM ben van megírva, sajnos nagyon mezítlábasan beszélek Assemblerül így nem tudom megállapítani hogy mennyire van korrektül megírva, de számomra ha már Arduinó + enkóder akkor = csak is ez a könyvtár.
Kedves Fórumtársak!
MINDENKINEK ismételten szeretném megköszönni a részletekbe menő és hasznos segítséget! Mivel az csöves TV javítása után nagyjából négy évtized kihagyásom volt az elektronikában, így többhét kell, mire a sok információt egyáltalán képes leszek megérteni. Az általatok írtak egyenlőre arról győztek meg, hogy én magam nemigen tudok jobb rendszert csinálni, sőt még egyenrangút sem, mint jelenleg beépített, ezért szívesen megnézném Asch kolléga projektjét, akár vásárlási céllal is. Köszönettel; Tambi
A jelenlegi számláló
Sziasztok!
Tud nekem valaki segíteni ATTINY24A fuse "visszaszámolásában? Ennyit tudok: Low fuse = E2, High fuse = DD (BOD level 2.7V) / DC (BOD level 4.3V), Extended fuse = FF, Lock fuse = FF ezt kellene valahogy "visszaszámolni", hogy egy darab AVR-t fel tudjak pörkölni működőre Magyarul, hogy a bitről bitre X-elgetős megoldásnál hova kell tenni az X-eket.. 1db AVR van csak itthon, és ha elmatekozom, akkor autókázhatok rosszabb esetben...E2: 11100010, és simán végig X-elem? Vagy van trükk? negált esetleg? Köszönöm!
Szia!
Igen, de nekem visszafele kell  hexából...
Itt be lehet írni a hexát az apply-ra kattintva pipálgatja be a dobozokat: https://eleccelerator.com/fusecalc/fusecalc.php?chip=attiny24a&...BIT=FF
A linkbe már be vannak építve az általad adott értékek.
Szia!
Tökéletes, köszönöm!
Kedves Ash, és Fórumtársak!
Most többen meg fognak kövezni, mert az avr-en kívül is szándékozom alkatrészt használni egy olyan "gyors" enkoderhez, amit pl egy esp32-vel is meg lehetne oldani... A feladat még mindig a fentebb vázolt enkoderes szögmérővel függ össze; nevezetesen az elvárt max néhány 100Hz, esetleg kHz-hez képest rendkívül gyors, 20 MHz-es mérést kívánok megvalósítani azért, hogy az enkoder által küldött jelekből még véletlenül se maradjon számolatlanul egy sem, vagyis az enkoder ne tévesszen. Ezt úgy kívánom elérni, hogy valójában 3 db 74191 bináris fel/le számláló számolja a jeleket, egy NANO pedig összegzi és kijelzi, számol ameddig számol, gyakorlatilag van rá ideje... ARDUINO programozási tudás(???)szintemre jellemző, hogy a mellékelt 16 sort egyheti szívós munkával hoztam össze. Mostanra működése megközelíti a tökéletest, azzal a hibával, hogy eggyel kevesebbet mutat a TM1637 kijelző, mint a soros monitor. Az "1" és "2"-t még rendesen kijelzi, de a többi értéknél; 4-től 1024-ig 1-el kevesebbet, tehát 3-at, 7-et, 15-öt, .....1023-at mutat, és az összeg sem 1023, csak 1022. Hol a hiba? Köszönettel; Tambi U.i.: A "SZÁMLÁLÓ_4013-7473-74190-7447" és a "GYORS ENCODER TM1637"-el csupán szemléltetés, a valósában a "SZÁMLÁLÓ_7473-74191" jeleit fogja számlálni a "GYORS ENCODER TM1637 MIN" A hozzászólás módosítva: Feb 12, 2023
Az stm32-ben van hardveres inkrementális enkóder interfész, ott csak a 16 bites számláló átfordulásokat kell valami szoftveres (ami lehet megszakítás alapú is) úton detektálni.
|
Bejelentkezés
Hirdetés |
