Az eredeti van nekem nem a kínai verzió, de ettől még nagyon hasonlóak, ha nem teljesen egyformák kivéve a teljesítményben gondolom.

Tudom, hogy van más megoldás, pl. a HAL szenzor, de én szeretném úgy megcsinálni ahogy eredetileg is működött. Egy STM32F103-assal oldották meg a kijelző vezérlést és gondoltam, ha ők ebből megtudták csinálni, akkor talán én is.

Legvégső esetben termesztésen az lesz, de jobb lenne még is csak ez az eredeti megoldás.

ui: Nem rögzíti a kereket és nem tölt vissza, szabadon fut.

Lemásoltad a bemenet kezelését az eredeti megoldásról?

Mondjuk szerintem érdemes lenne megnézni valamelyik drónos fórumot, vagy vannak ezek a propelleres órák is. Nekik vannak tapasztalataik ilyen motorokkal kapcsolatban.

Vissza fejtettem, de az eredetit használom.
Bekötöttem a vezetékeket a mikrovezérlő helyére és ott monitoroztam le a logikát.
Sajnos nem értem mi ez a jelsorozat, zaj nem lehet mert túl éles, pedig a FET-ekre gyanakodtam, hogy esetleg azok okozzák.

Nem értek benne teljesen mindent, de Kb a függvényhívást és, hogy a stack-en máshova pakolják az értékeket nem látok mást.

always_inline:


függvény hívással:


Nem igazán értem az első verzió miért okoz problémát még ki próbáltam azt is, hogy __disable_irq(); és az __enable_irq(); között van a flag olvasás, de nem még az se segít ha a callback hívása előtt tiltom majd utána engedélyezem a globális IT-t.

Nem tudom te ebből a disassy-ból látsz valami érdekességet?

Nem látok. Mondjuk nehéz is lenne, mert én nem férek hozzá a regiszter értékekhez és memóriaterületekhez. Lépésről lépésre futtasd a kódot és nézd meg melyik ponton akad ki és miért. De itt már magadra vagy utalva.

Kissé padhelyzetben az előbb szét húztam az akkumulátort vagy is jobban mondva lehúztam az akkumulátort a motorról, hogy megnézzem tudok e impulzust generálni csak a kerék megforgatásával. Sajnos nem tudtam, de összedugva ismét a motort és az aksit, megnéztem analizátorral és lám megszűntek az alap helyzetben bejövő furcsa és felesleges jelek.

Most már csak akkor indikálódnak jelek, ha a gázkart meghúzom.
Csatoltam a mostani adathalmazt.
Ebből kellene ki indulnom, hogy miképpen és milyen jelek ezek. Gondolom valami időalapú jelsorozat lehet, mert ahogyan elnézem átlagban 15.4KHz-es időközzel jönnek az impulzusok, majd vannak másabb nem sima impulzusok, olyanok mint ha adat lenne, lehet ez valami kitöltés lehet? Vagy esetleg kimondottan valamilyen adat?
Feltételezem ha nem változik a gázkar állapota, akkor egyforma jelek jönnek és mikor változik akkor megváltozik a jelalak is.
Rá pillantasz? Hátha most látsz valamit.

ui: feltételezem amúgy, hogy emiatt a sok furcsa jel miatt halhatott meg a kijelző vezérlés.

Kérdés: Elképzelhető hogy ez egy aszinkron soros kommunikáció?

Nem valószínű, hogy kommunikáció, mert akkor lenne valami közös az impulzushosszakban. Ha megfigyeled, akkor látszik, hogy mindenféle hosszú impulzus van és nem tűnik úgy, hogy lenne közös időosztójuk.

Őszintén szólva, ha ez fázis feszültség (leosztva és szint illesztve) akkor ennek nagyon nem így kellene kinéznie.

PWM jelre is gondoltam, másik topikban is erre a következtetésre jutott egy srác, bár elég kusza a jel ami nagyon aggaszt. Sajnos ez a jel jön ki, nem lesz jobb.

Ez nem PWM. Mindegy, az áramkör ismerete nélkül én nem ötletelgetnék tovább.

Ez a visszafejtett szint illesztője.
A 40v-os részen megy be a jel, D0-n pedig a mikrokontrollerbe megy.

Szevasztok!

Az Atolic IDE-nek van egy hasznos funkciója, hogy szürkítéssel kiemeli azokat a részeket, amik éppen nincsenek befordítva a feltételes fordítási funkciók között.

Ez nekem hiányzik a Keil uVision5-böl. Valahol be lehetne ezt kapcsolni benne?
Köszi a segítséget!

Az Editor/Configuration menüben a Colors & Fonts lapon a C/C++ Editor Files kiválasztásánál látok ilyesmit az utolsó (Inactive text) elemnél.

- Az opaqe opció elől ki kell venni a pipát, csak utána engedi megváltoztatni a háttérszínt.
- A színezés csak a sor végéig tart, ez zavaró lehet (gusztus dolga).

Valami ilyesmit sejtettem. Viszont még mindig nem értem, miért nem változik az impulzusok hossza és sűrűsége. A növekvő fordulatszám függvényében meg kellene szaporodnia az impulzusoknak.

Elvileg működik, összetett header állományoknál megbízhatatlan.
Látnia kell a függőségeket, ehhez egy Build kell.
Dynamic Syntaxt Checking/ Enable, alapértelmezett.

Eljutottam odáig a mérésekkel, hogy valamiért ki-be kapcsolgat az eredeti vezérlő, tehát nem csak a mikrokontroller dögölhetett be rajta, hanem más is, valószínűleg maga a DCDC konverter része is meghibásodott. Tulajdonképpen ez okozhatta magát a mikrokontroller meghibásodását is. Szóval tegnap már sikerült elérnem odáig, hogy végre normális jeleket tudjak venni, ha tekerem a kereket kézzel akkor is van impulzus és minél gyorsabban forgatom annál sűrűben jön a jel. Most azon agyalok, hogy tudnám kiváltani a DCDC konvertert, mert most is 84v-ról meg és abból csinál 5v-ot a 3.3v-os stabilizátornak.
Ezek után pedig ki is dobom az eredeti panelt.

Egy másik DC/DC konverterrel. Kb. 2 perc alatt találtam a Texas Instruments-nél olyat, ami alkalmas lenne a feladatra és amiből ingyenes minta is kérhető (céges email címről javasolt a fiókot létrehozni). Pl.: LM5164. Van hozzá webes tervező is, ami kiszámolja milyen és mekkora passzív alkatrészek kellenek még (pár ellenállás, kondi és egy tekercs) a megadott bemeneti feszültség tartomány, kimeneti feszültség és áram értékekhez.

Az alkatrész SO-8 powerpad-del, amit picit trükkösebb beforrasztani, mint a hagyományos SOIC-ket. Én a nyákot 170 fokra fűtött lapra helyezve, felülről az IC-t forró levegővel szoktam berakni (a nagy középső pad helyére előre teszek kis ónt és folyasztószert), majd a lábakat már hagyományosan pákával forrasztom.

Köszi, a beforrasztással nem lenne gond, nagyobb baj, az, hogy ez olyan új chip, hogy máshonnét nem is igen lehet beszerezni csak a gyártójától...
És az online számoló felületet is, úgy látom csak regisztráltaknak van fenntartva..
Megkérdezem itt bent a céget, hogy van e esetleg regjük és akkor lehetne rendelni is tőlük pár mintát. Köszi az infót.

Köszi, regisztráltam és rendeltem mintát, remélem jó lesz.
Az online számoló is jól működik, ott szerintem ki is számolom milyen diszkrét elemek kellenek még körítésnek és megrendelem azokat is. Köszi még egyszer.

Uraim, adott egy jó kérdés.
BMP képet SD kártyáról FSMC-vel hajtva, 4bit-en, hogy lehetne gyorsítani? (több mint 1 MBájt a kép)
Videó a mostani sebességről.: Bővebben: Link
Van esetleg ötletetek?

Felejtsd el a BMP formátumot. Konvertáld át a képeket olyan formátumra, amit direktben a kijelzőre lehet küldeni.
Ha tudsz 2MB-os külső SRAM-ot csatlakoztatni, akkor érdemes oda olvasni az SD kártyáról, majd onnan DMA-val gyorsan átlőni a kijelzőre.
Másik lehetőség, hogy külső flash-t használsz, amin a képeket tárolod, majd DMA-val a CPU-t kikerülve küldöd az adatokat a flash-ből az FSMC buszra.
Ha a képek tűrhetően tömöríthetőek (pl. liblzg), megpróbálhatod a belső flashben tárolni őket és kettős puffereléssel szakaszosan kiírni (egyik buffer írodik a képernyőre, másikba kitömörítesz, majd csere).

24bit-es képet 16bitesre alakítók át, mielőtt kirakja az LCD-re.
Ez a konvertálás 3 biteltolásos és éselés után kész is.
Sejtem hogy pár órajelciklust felemészt, de nem olyan nagyon sok az, hogy jelentősen gyorsulna a kijelzés.
Külső RAM-ot nem akarok használni, bár tényleg talán ez lenne a legjobb és leggyorsabb megoldás a kejlző maximális sebességének kihasználására.

Lehet nem is vacakolok vele, ameddig nem kell a gyors kepváltás.
Azért köszi.

Ahogy gondolod, de simán le lehetne szorítani a képbetöltést kéttized másodperc alá a mostani 3 másodpercről. Sokkal jobban mutatna.
Én egyébként automatizáltam a képkonverziókat így minimális erőfeszítést igényel új képek hozzáadása a programomhoz.

Ha jól emlékszem nem rég írtam is egy ilyen programot WIN-re, hogy a png képet átalakította 16bit-es színre és (RAW) formátumra. Majd a fájlt feltöltve SD kártyára és onnét tölti be az adatot. Ez még az időjárás rendszeremhez írtam anno, PIC32-re.
Gondolom az a program felhasználható lenne ide is.

A legnagyobb bajom most inkább az, hogy kivittem a kijelzőt napra és gyakorlatilag használhatatlan. Még világosban is alig látható, de ha napfény is éri, nulla a beláthatósága.
Alternatívát kell keresek mert ez így biciklibe nem használható.

Nincs valami ötleted?
Olyan megoldás kell, hogy fénynél is azért látható legyen a kijelző.

Ha nem ragaszkodsz a színekhez (bár van abból is többszínű), akkor esetleg egy e-ink kijelző tökéletes lehet. Az remekül látszik napfényben (sőt, akkor a leginkább). Lehet kapni egyébként olyan LCD kijelzőket is, amik napfényben is jól működnek (nem vettem még ilyesmit, így ebben nem tudok segíteni).
Amire figyelj oda, hogy milyen hőmérséklet tartományra tervezték a kijelzőt. A legtöbb kijelző nem szereti a fagypont alatti hőmérsékletet (ha nem tervezed a biciklit ilyenkor használni, akkor nem probléma, hisz az akkuk sem nagyon kedvelik ezt a hőmérsékletet).

Ezzel szemezgetek most: Bővebben: Link
Nincsenek színek, de jól látható lenne.
Frissítési idővel vagyok bajban, lassúak még nagyon..

Hmm, 4 másodperc. A kindle-m ennél sokkal gyorsabb. Nézz meg pár youtube videót, valaki csak talált olyan modellt, ami viszonylag gyors.

Pont youtube-n mazsolázom, de mind elég lassú.
Minél gyorsabb lesz gondolom az ára is úgy fog változni.
Van egy határ szerintem ami felett már nem éri meg vele foglalkoznom.
Keresgélek egyelőre, aztán csak találok valamit.

Keresek és nézegetem, de esélytelen, hogy normális e-ink-et vegyek. Vagy nagyon drága vagy minél nagyobb annál több a frissítési idő.
Marad ez a 4.2", ez a 4mp, talán elviselhető és bízok benne, hogy ha csak egy szegmensét kell frissítenem nem lesz nagyon durva a frissítési idő és a frissítésből eredő árnyékhatás.

Ha nem probléma, hogy ez kisebb, akkor érdemes egy pillantást venni erre is: Waveshare 296x128 2.9inch E-Ink raw display black/white two colors ...efresh. Ez támogatja a részleges frissítést is (0,3 s).
Esetleg használhatsz két kijelzőt (minimális a fogyasztásuk úgyis). A fontosabb gyakran frissített adatok mehetnek magasabbra szem elé (sebesség, aktuális teljesítmény felvétel, stb.) gyorsabb frissítéssel. A ritkábban érdekesek (akkumulátor töltöttség, stb.) pedig lejjebb, ahol a mostani kijelződ volt, egy nagyobb lassabb kijelzővel.

Mennyi RAM-od van?
Nem járható az hogy SD-re kimenteni RAW file-ba (16 bites) színnel, hogy a bit tologatást megspóróold és egy dupla bufferrel az egyik buffer-be olvasol az SD-ről a másikat meg copy-zod ki a kijelzőre?
Vagy az SD olvasási sebességét (SCLK) nem tudod növelni?
Ezzel lehet, hogy tudsz lefaragni az 4mp-ből.