Fórum témák

» Több friss téma
Fórum » ARM - Miértek hogyanok
 
Témaindító: gtk, idő: Jún 26, 2007
Lapozás: OK   141 / 177
(#) don_peter válasza csatti2 hozzászólására (») Júl 21, 2019 /
 
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.
A hozzászólás módosítva: Júl 21, 2019
(#) csatti2 válasza don_peter hozzászólására (») Júl 21, 2019 /
 
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.
(#) don_peter válasza csatti2 hozzászólására (») Júl 21, 2019 /
 
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.
(#) cross51 válasza csatti2 hozzászólására (») Júl 21, 2019 /
 
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:
  1. 0x08000d18  ldr r3, [r7, #4]
  2. 0x08000d1a  str r3, [r7, #12]
  3. 0x08000d1c  ldr r3, [r7, #12]
  4. 0x08000d1e  ldr r3, [r3, #4]
  5. 0x08000d20  ldrh r3, [r3, #0]
  6. 0x08000d22  uxth r3, r3
  7. 0x08000d24  and.w r3, r3, #128  ; 0x80
  8. 0x08000d28  cmp r3, #0
  9. 0x08000d2a  ite ne
  10. 0x08000d2c  movne r3, #1
  11. 0x08000d2e  moveq r3, #0
  12. 0x08000d30  uxtb r3, r3
  13. 0x08000d32  str r3, [r7, #20]


függvény hívással:
  1. 0x08000d40  ldr r3, [r7, #4]
  2. 0x08000d42  mov r0, r3
  3. 0x08000d44  bl 0x8000926 <Peripheral::UART::TransmitterEmptyInterruptStatus()>
  4. 0x08000d48  mov r3, r0
  5. 0x08000d4a  str r3, [r7, #12]
  6.  
  7. 0x08000926  push {r7}
  8. 0x08000928  sub sp, #12
  9. 0x0800092a  add r7, sp, #0
  10. 0x0800092c  str r0, [r7, #4]
  11.  
  12. 0x0800092e  ldr r3, [r7, #4]
  13. 0x08000930  ldr r3, [r3, #4]
  14. 0x08000932  ldrh r3, [r3, #0]
  15. 0x08000934  uxth r3, r3
  16. 0x08000936  and.w r3, r3, #128  ; 0x80
  17. 0x0800093a  cmp r3, #0
  18. 0x0800093c  ite ne
  19. 0x0800093e  movne r3, #1
  20. 0x08000940  movs r3, #0
  21. 0x08000942  uxtb r3, r3
  22.  
  23. 0x08000944  mov r0, r3
  24. 0x08000946  adds r7, #12
  25. 0x08000948  mov sp, r7
  26. 0x0800094a  ldr.w r7, [sp], #4
  27. 0x0800094e  bx lr


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?
(#) csatti2 válasza cross51 hozzászólására (») Júl 21, 2019 /
 
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.
(#) don_peter válasza csatti2 hozzászólására (») Júl 21, 2019 /
 
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ó?
A hozzászólás módosítva: Júl 21, 2019
(#) csatti2 válasza don_peter hozzászólására (») Júl 21, 2019 /
 
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.
(#) don_peter válasza csatti2 hozzászólására (») Júl 21, 2019 /
 
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.
(#) csatti2 válasza don_peter hozzászólására (») Júl 21, 2019 /
 
Ez nem PWM. Mindegy, az áramkör ismerete nélkül én nem ötletelgetnék tovább.
(#) don_peter válasza csatti2 hozzászólására (») Júl 21, 2019 /
 
Ez a visszafejtett szint illesztője.
A 40v-os részen megy be a jel, D0-n pedig a mikrokontrollerbe megy.
(#) kapu48 hozzászólása Júl 22, 2019 /
 
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!
(#) icserny válasza kapu48 hozzászólására (») Júl 22, 2019 /
 
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).
(#) csatti2 válasza don_peter hozzászólására (») Júl 22, 2019 /
 
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.
(#) rolandgw válasza kapu48 hozzászólására (») Júl 22, 2019 /
 
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.
(#) don_peter válasza csatti2 hozzászólására (») Júl 23, 2019 /
 
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.
(#) csatti2 válasza don_peter hozzászólására (») Júl 23, 2019 / 1
 
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.
(#) don_peter válasza csatti2 hozzászólására (») Júl 24, 2019 /
 
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.
(#) don_peter válasza csatti2 hozzászólására (») Júl 24, 2019 /
 
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.
(#) don_peter hozzászólása Júl 26, 2019 /
 
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?
(#) csatti2 válasza don_peter hozzászólására (») Júl 26, 2019 /
 
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).
(#) don_peter válasza csatti2 hozzászólására (») Júl 29, 2019 /
 
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.
(#) csatti2 válasza don_peter hozzászólására (») Júl 29, 2019 /
 
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.
(#) don_peter válasza csatti2 hozzászólására (») Júl 29, 2019 /
 
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ő.
(#) csatti2 válasza don_peter hozzászólására (») Júl 29, 2019 /
 
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).
(#) don_peter válasza csatti2 hozzászólására (») Júl 29, 2019 /
 
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..
(#) csatti2 válasza don_peter hozzászólására (») Júl 29, 2019 /
 
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.
(#) don_peter válasza csatti2 hozzászólására (») Júl 29, 2019 /
 
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.
(#) don_peter válasza csatti2 hozzászólására (») Júl 30, 2019 /
 
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.
(#) csatti2 válasza don_peter hozzászólására (») Júl 30, 2019 /
 
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.
(#) cross51 válasza don_peter hozzászólására (») Júl 30, 2019 /
 
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.
Következő: »»   141 / 177
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem