Fórum témák
» Több friss téma |
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
Jogos, de ha a villogó kurzort is szeretné közben akkor nem lessz jó + amiért nem szeretem a felesleges kiírást az a plussz proci idö.
Gondolom sima C ben direkt portírással sokkal gyorsabb, de itt Arduino alatt egy kurzor alaphelyzetbe állítás plussz egy karakter írás az kb. 2960 mikroszekundum.
Ha azt akarod, hogy a 2. karakter villogjon, akkor kapcsold be a kurzort, majd írd újra az 1. karaktert. A kurzor az utoljára írt karakter utáni pozícióban fog villogni (ha jól rémlik).
Az tény hogy visz el processzor időt (bár ezt lehet akár ideiglenesen szüneteltetni is ha a felhasznált időzítő megszakítását letiltom). Viszont csináltam méréseket mennyi processzoridőt visz el, és 20 frame/sec frissítési sebességre állítva 1% körül mozgott mindössze.
Ja és tud a driver villogó karakter(eke)t is megjeleníteni, tehát simán lehet villogó kurzort csinálni vele (vagy villogtatni az éppen állítandó számjegyet). A hozzászólás módosítva: Feb 12, 2020
Igen ezt csinálja. Viszont nekem az elsö karakter a nulladik (elsö) kockában van az meg a nem akar villogni. Most az van, hogy a beirando helyeket megtöltöm 0-val és a villogástol balra esö karaktert irja át a gép. Eredetileg azt terveztem ( igy van a régi ASM gépemen) hogy a sötét displayen villogással jelzem hol a cursor és annak a kockának a tartalmát lehet változtatni. Ez valahogy az Arduino progiban nem megy. De nem baj, most jo ez igy is.
Megnéztem egy kijelző adatlapján, a DDRAM cím állításával lehet a kurzor pozícióját (mellékesen az írás pozícióját is) beállítani. RS = 0, adat = 0x80 + pozíció.
Én is nézegettem az ASM progamot ott is a valami ilyesmit csináltam. Most ezzel nem akarok foglalkozni. Lehet, hogy majd egyszer. Most örülök, hogy azt csinálja amit kb akartam.
Mindkettőtöknek (tbarath és bbb) nagyon köszönöm. Úgy tűnik, kezd világos lenni a dolog.
Helló!
Valaki tudna segíteni milyen környezetben lehet lefordítani ezt a projektet? Nem találom benne utalást sem make fájlban! Bővebben: Link
Szerintem VisualStudio. Az első könyvtár név erre utal.
Na már megcsináltam a szémlálo szenzorokat , sajnos a fiokban levö gyáriak nem fértek oda, igy külön kellett mechanikusan megoldanom a feladatot.
Most már van két optoérzékelöm, amik elött forog a motor tengelye. Fordulatonként egyszer szakitja meg a fényt egymás után az elsö, majd a másodikon. Ebböl kell megirnom a progit, ami fel illetve lefelé számolja a fordulatokat. Van erre egy bevált eljárás? A szenzorokrol ilyen sorban kapom a jeleket az adott irányba. Szenzor S 1: 0 1 1 0 0 Szenzor S 2: 0 0 1 1 0 Azaz ha az elsö szenzor 1-re vált (High) megvan az irány, ha a második is 1 akkor számolja a fordulatot, ami ezután történik már nem érdekes addig amig ujra nem 0 mind a kettö bemenete, s majd valamelyik ujra 1-re ugrik. A szenzorok már számolják a forgást, csak még nem jol. Szoval érzékelem a mozgást, a fordulat ki is mutatja, de visszaugrik az eredeti értékre. Még egy kicsit agyalnom kell, hogyan kezeljem a két jelet, hogy azt tegye amit akarok. Szép estét!
Ez a jelforma Quadrature encoder / decoder / counter, AB signal neveken fut, ezekkel lehet rákeresni.
Ha a számlálás a fontos, akkor is el kell dönteni, hogy szükség van-e az utolsó bitre, vagy elegendő minden második jelváltást számolni? Ha elegendő minden másodikat számlálni, akkor elég az egyik jelre (pl az A-ra) tenni egy pin change interrupt-ot. A számlálás pedig úgy működik, hogy a pillanatnyi A és B jeleket XOR műveletbe hozzuk. Ha 1, akkor felfelé, ha 0, akkor lefelé számlálunk. A számláló lehet 8, 16, 32 bites: ki kell számolgatni, hogy mennyi időnként fog átfordulni. A program logikájának kezelnie kell az átfordulást, ha az előfordulhat egyáltalán. 64 bites számlálóval például ki lehet zárni az átfordulást teljesen .Ha kell az utolsó bit is, akkor kicsit bonyolultabb a számlálás, vagy lehet egy trükköt csinálni: csak az A jelre van interrupt továbbra is, és leolvasásskor megnézzük az AB értéket, és ez alapján -1, 0, +1, +2-vel kell korrigálni a számláló értékét. Végig lehet gondolni, hogy ez jól fog működni feltéve, hogy az interrupt gyorsabban lefut, minthogy két egymás utáni jelváltás tudna történni. Lehet olyat is csinálni, hogy minden változásra ráteszünk interruptot, A-ra és B-re is. Ez egy tipikus megoldás. Ilyenkor ha egymás után írjuk az előző és a jelenlegi mintát, akkor kapunk egy négybites értéket, ami alapján elágazunk, hogy: * Felfelé számlálás * Lefelé számlálás * Nincs számlálás (ha periodikus a mintavételünk, akkor előfordulhat, ha változás interruptunk van, akkor ez hiba mert nem fordulhatna elő) * Hiba dekektálás: egyszerre két változás történt két mintavétel között, tehát gyorsabb a jel, mint amit mérni tudunk Ha valójában nem a számlálás a fontos, hanem a sebesség mérés, akkor lehet olyat is csinálni, hogy input capture funkciót használunk két jelváltás közötti idő mérésére. Ha a jeladó teljesen pontos - tehát minden jel szélessége egyforma - akkor ezzel lehet a legfrissebb, legpontosabb sebesség leolvasást csinálni. Lényeges kérdés, hogy mennyi időnként jöhetnek a jelek leggyorsabban, és hogy kellően gyors lesz-e a feldolgozás ehhez? Ha interruptot használunk, akkor lényeges, hogy a többi feladat interruptjai is késleltethetik a feldolgozást, tehát a legrosszabb esetre kell számolni, hogy akkor se veszítsünk el jelet! Éppen ilyen számlálón dolgozgatok. A feldolgozási idő miatt úgy terveztem, hogy egy külön ATTiny25 processzor számolja a jeleket. Ez 16MHz-vel járatható, esetleg trükkel 20MHz, sőt 24MHz-vel kvarc nélkül is, és pont elég lába van. A főprocesszor pedig SPI-n kérdezgeti, hogy hol áll a számláló. Ezzel a megoldással kimértem, hogy kb 50 CPU cycle alatt tudok egy A jel változást feldolgozni. Ezt a kódot feltettem a github-omra, és a mérés eredményét is leírtam: https://github.com/rizsi/Arduino-IR-decoder/tree/master/lathe_gui/q...ements A mérést úgy csináltam, hogy egy Arduino program adta a mérendő jelet, sokmillió jelet számoltattam vele oda-vissza, és egyet sem hibázhatott. Szkóppal is nézegettem közben, hogy minden oké-e. Itt a mérőprogram kódja: https://github.com/rizsi/Arduino-IR-decoder/blob/master/lathe_gui/t...or.cpp Kétféle megvalósítás van benne: egy bitbanging jelgenerátor, illetve próbálkoztam egy PWM alapúval, ami működött, de az elején és a végén nem volt tökéletes a jelforma még, és inkább félbehagytam és a bitbang változattal mértem. Ezekután teljesen rákattantam a kvadratúra jelek számolásának a problémakörére, és csináltam egy újabb programot, ami interrupt helyett periodikusan lekéri az AB jel értékeket, és úgy számolja őket. Ez az új program fix periódusidővel dolgozik, és 12 órajelenként képes egy jelváltást venni. És eközben még SPI-n ki tudja tolni a pillanatnyi számláló értéket a legnagyobb sebesség mellett is. Ez is ATTiny25-ön működik, és annyi piszkos trükköt kellett hozzá bevetnem, hogy épphogy csak az éjféli kakasáldozat maradt ki. Ezt a kódot még nem mértem élesben, csak szimulátorban, és ezért nem is publikáltam még. De lényegében drop-in replacement-je lesz a fent linkelt programnak, csak a lábkiosztás is változni fog. Elvileg 1-2 órajelet még lehet spórolni ebből is, de annak már nem fogok nekiállni. Így is milliónál többet tud számolni másodpercenként.
Vagy használjon stm32-t (arra is lehet fejleszteni arduino-ban és lassan olcsóbb is egy bluepill vagy maple board az atmegás boardoktól). Az képes tisztán hardverből lekezelni az encoder jeleit, a 16 bites timer regiszterből meg akkor olvasod ki az aktuális értéket amikor akarod.
Szia, kösz a választ. Ez nem encoder ( mégha a kodok annak is néznek ki), csak igy akartam bemutatni, hogy van 2 szenzor, ami elött forog a tárcsa egy nyilással, azaz elöbb az egyik majd a másik szenzor érzékeli majd ugyanilyen sorrendben zárnak vissza. Fordulatonként egyszer fordul elö, és a displayen kell frissiteni a fordulatok mennyiségét - esetleg visszirányban is. ( fel/leszámol. Alapbol lefelé fog számolni és 0 értéknél megállitja a motort.
Talán igy kellett volna irni: S1: ____|~~|_____ S2: ______|~~|___ A ~~ a szint tetejét mutatják azaz mind a 2 szenzorbol csak fordulatonként egy fázisban eltolt impulzus jön. A sebbesség nem kritikus maximum kb 1 ford/sec. Lehet, hogy talán majd a tapasztalat alapján egy kicsivel több, de nem nagyon hiszem, azaz max 10 Hz-nél nem lesz több. Már valamit irtam, és félig meddig müködik is, csak egy kicsit át kell alakitani az egész kod strukturáját, mert összekeveredik az indulási értékek beadásával. Az uj strukturában 3 résznek kell lenni: Indulási jellemzök bevitele ( pl. menetszám), a tekercs meg a drot mérete stb Tekercselés Manuális modus - ilyenkor áll minden motor, de kézzel lehet forgatni a tekercset és azt is számolni kell. ( leágazásokhoz stb) Most még minden együtt van a loopban. A hozzászólás módosítva: Feb 15, 2020
Ja, értem, ez egy tekercselő számláló lesz, fordulatonként jön egy jel. Ilyen sebessegnel nem kell nagyon centizni a CPU idővel az biztos. Viszont mégis interruptot használnék, mert anélkül - csak pollozva - esetleg a teljes jelet átugorjuk anélkül, hogy észrevennénk, hogy történt egyáltalán valami. Itt is alkalmazható a trükk, hogy ha az S1-en magasat olvasunk, akkor van jel, és ha ekkor az S2 alacsony, akkor felfelé, ha magas, akkor lefelé számolunk. Pszeudókód:
És úgy kell felkonfigurálni a pin change interruptot, hogy az S1 bemenet felmenő éljére fusson le az interrupt kezelő. (És a lemenő élre is le fog futni, mert csak úgy lehet konfigurálni, de ott a külső feltétel mindig false lesz.) A számlálót lehet nullázni (atomic blokkban), vagy csak megjegyzed, hogy honnan kezdted a folyamatot és meddig kell menni.
Köszönöm szépen! Én az interruptot a motorok hajtására terveztem használni , de kiprobálom a te megoldásodat is ( de majd csak éjjel vagy jövö héten). A countert ebben az üzemmodban kizárolag a 2 szenzor vezérli, azaz van egy elöre beállitott érték ( pl 1000) és a motor forgásával ezt lenullázza. Ha közben esetleg meg kell állni, akkor csak kézzel lehet a csévét forgatni, de utánna ujbol a motor forgatja, addig amig a számlálo nem nulla.
Sziasztok!
Tudna valaki segíteni, letöltöttem a grbl-master zip könyvtárat, de sehogyan sem sikerül hozzáadni az arduino könyvtárakhoz. Arduinoban zip könyvtárként amikor betöltöm hogy hozzáadjam ezt a hibát produkálja: "a meghatározott mappa zip, nem tartalmaz érvényes könyvtárat" több helyről letöltöttem, de állandóan ez a hibaüzenet fogad.
Helló!
Nem kellene a zip fájlt előbb kitömöríteni?
Próbáltam, de semmi változás. A hibaüzenet továbbra is fent áll.
A letöltött .zip-ből csak a grbl mappát kell az /Arduino/libaries/ másolnod.
Sziasztok.
Hogyan lehetne azt megoldani, hogy a szabványos 1602-es LCD-t ne csak az alaplapi nyákkal párhuzamosan rögzítsem, hanem hogy szöget zárjon be? Tehát ha az alaplap az asztalon fekszik, az LCD mégis kb. a szememre merőlegesen áll? Az ötletem eddig annyi, hogy az LCD-t egy nyákra forrasztom, aminek az aljára vannak elvezetve a forrpontok, ezt pedig rá tudom az alaplapra szögben rögzíteni, de nem tudom, hogyan rögzítsem még pluszban, hogy ne törjön le az LCD egy idő után. Esetleg van más ötletetek? Köszi.
NYÁK-ra négy csavarral rögzíteni a kijelzőt, forrpontokkal. Forrasztási pontok a két szélére, majd két háromszög alakú NYÁK-kal, mint köztes darabbal rögzíteni az alaplaphoz. Így az elektromos kapcsolatok is megvannak. A 90°-os tüskesorokról beforrasztás után le lehet húzni a műanyag tartókat, így azok helye is megspórólható.
A háromszög alakú lemezeknek nem feltétlen kell a szélén lenniük. Maga a kijelző nem egy romlandó alkatrész, elméletileg nem nagyon kell cserélni, én beforrasztanám fixen. Esetleg a vízszintes forrasztási pontokba tüskesor aljzat...
Sziasztok!
Van egy érdekes problémám. Vettem egy Arduino Mega 2560-at és egy Nextion Enhanced NX4832K035-ös kijelzőt és egy tutorial videó segítségével próbáltam életet lehelni beléjük: bemásoltam az eredeti könyvtárat ami a Megához lett konfigurálva, feltöltöttem a progit az Arduinora és a kijelzőre is. Összekötöttem őket (Tx-et az Rx-hez És Rx-et a Tx-hez), de nem akarnak kommunikálni. A Mega és a Nextion is külön-külön, gépre kötve működik: az Arduinotól megkapom a parancsokat és a kijelzőnek is tudok küldeni különböző értékeket. Van itthon egy Leonardo, azzal is próbálkoztam sikertelenül (persze akkor szerkesztettem a config fájlt). Mi lehet a probléma?
Köszi a tippet! Elindulok ezen a vonalon, ez elég stabil megoldást eredményez.
Logikai analizátorral ellenőrizd, hogy milyen parancsokat kap a kijelző. Lehet, hogy hiányzik egy karakter vagy a parancsokat lezáró 0xFF 0xFF 0xFF trió, esetleg a kijelző és az Arduino más-más sebességen akar kommunikálni a másikkal.
Köszi a gyors választ! Megpróbálom ellenőrizni.
Bármivel is próbáltam analizálni nem jött össze. Úgy néz ki, hogy nem indul el a kommunikáció. Egyedül az Arduino IDE monitorjával tudtam megnézni, bár tudom, hogy nem így gondoltad. Amikor ezt megnyitottam küldött egy parancsot a megának( az Rx led villanásából gondolom) és utána indult meg az adat a Tx-en (szintén a Tx led világításából gondolom). Más körülmények között nincs adatátvitel (nem villog/világít se a Tx se az Rx led).
Itt a kód amivel próbálkozok. Ilyen parancsokat kaptam az arduinotól, ha számít valamit: n0.val=129⸮⸮⸮np.val=0⸮⸮⸮t1.txt="Hello!⸮⸮⸮
A kódra passzolok de a
t1.txt="Hello!⸮⸮⸮ részből hiányzik a lezáró idézőjel. t1.txt="Hello!"⸮⸮⸮ |
Bejelentkezés
Hirdetés |
