Fórum témák
» Több friss téma |
Na, eredmények:
Megcsináltam a kalibrációt kíváncsi voltam mennyit ad vissza 67-et adott ami nem kevés. Ez után már szépen adta az 1,24V-ra az 1541-et ami a 3,291V ra csak -1LSB. Mindez az eredeti 1,5 ciklusos mintavéttel.
Lényeg akkor hogy kalibráció nélkül lehet játszani de előfordulhat olyan proci amiben nagy az eltérés.
A kódodat látva az uint16_t nekem eléggé neccesen hangyzik ARM alatt. 32 bites processzorról van szó, a legoptimálisabb, leggyorsabb és legkisebb kódot az uint32_t adja (kivéve STM8).
Az uint16_t-vel többlet munkája lehet a mikroprocesszornak, mert mindent 32 biten végez, amit 16 bitre kellene átalakítania. 32 bites procin alapból 32 bites értékekkel érdemes játszani. Az uint16_t-t kizárólag akkor használom, ha memóriában 16 bites adatokat akarok tárolni, hogy ne foglaljon sok helyet. A map függvény nem ez a kategória, a 16 bit szerintem lassú és csak a probléma van vele.
Ez igaz lenne, ha az ARM-nál hülyék dolgoznának. Mivel természetesen nem azok, ezért gondoltak arra hogy ez ne jelentsen gondot. Éppen ezért (pár kivételtől eltekintve) pont ugyanakkora kódot generál ha 16 bites változóval dolgozol, mintha 32 bitessel dolgoznál (a memória használat viszont kevesebb [de nem mindig
 , csak ha több változót is inkább 16 bitesként használsz]).Ha nem hiszel nekem, akkor nézd meg mi is a különbség pl. egy 16 bites szám 1-el növelésekor, illetve egy 32 bitesnél. 32 bit:
16bit:
A trükk az, hogy adat regiszterbe másolásra, illetve visszaírásra több utasítás is létezik (az adat típusától függően, pl. itt a h a végén azt jelenti, hogy halfword-öt töltsön be és a maradék biteket nulláza). A többi utasítást már a regisztereken végzi a processzor 32biten. A hozzászólás módosítva: Jún 22, 2017
Azert ezt nem mondanam, mert altalaban veve teljesen igaza van. Az teny, hogy az ARM-en nem okoz szamottevo lassulast a 16 bites valtozok hasznalata, de altalanossagban igaz az, hogy az adott processzor szamara legtermeszetesebb valtozok hasznalata jobb, rovidebb kodot eredmenyez. A te esetedben stack-en allokalt valtozokrol van szo, tehat semmi memoriat nem sporolsz vele.
A külső HW 16 bites adatokat szolgáltatót.
Ehhez igazítottam az adatszélességet. Éppen nem volt semmi spórolási szándékom. Az ARM pedig mindkettővel egyformán megbirkózik. És az eredeti előjeles lebegőpontos számítást, alakítottam át unsigned egészre. (Közben becsúszott egy kis hiba.) De végül mégis jóval gyorsabb lett a számítás. A hozzászólás módosítva: Jún 23, 2017
TFT LCD-ről van szó.
Csak pozitív egész számon ábrázolt pontmátrix van rajta. Semmi szükségem nem volt az eredeti lebegőpontos számításra. Így is megszenvedtem vele. Mert a Touch nem lineáris adatokat mért. Ráadásul a 2 tengelyen különböző eltérésekkel kellet korigálni.
csabeszq elmondott egy altalanos igazsagot, amire te azt valaszoltad, hogy butasag. En pusztan erre reagaltam, nem az adott megoldasra.
Elnézést kérek CSABESZQ-tól!
 Csak hirtelen meggondolatlan reagálás volt. Amit már nem tudok törölni!
Persze megoldhattam volna úgy is, hogy:
Beolvasom a 16 bites adatot, aztán konvertálom 32 bitesre. Nehogy már szegény ARM Kiakadjon! Ki íráskor pedig konvertálom a 32 bites adatot, 16 bitesre, hogy az LCD-nek megfelelő legyen! Na, erre értetten, hogy butaság lenne!  Idézet: Akarmit is csinalsz, ez pontosan igy fog tortenni. Ugyanis a C nyelv minden char, short tipust int-re konvertal automatikusan, azaz jelen esetben 32 bitre. Ezt magatol megcsinalja, ha akarod, ha nem. A szamitasokat int vagy unsigned int vegzi, legfeljebb a vegeredmenyt vagja le kisebbre. Ha van egy 8 bites valtozod (legyen mondjuk 'a'), aminek az erteke 255, es azt irod, hogy a + 1, akkor az 256 lesz, es nem 0. Mert a valtozo nem lehet 256, de a vele vegzett muvelet eredmenye mar igen.„Beolvasom a 16 bites adatot, aztán konvertálom 32 bitesre.” Idézet: Ettol a hozzaallastol van sokszor az, hogy a mai hardvereken egyes prorgramok lassabban futnak, mint 30 eve egy C64-en... Kis tulzassal. Ugyan mar, birja a proci! Az egy alapveto programozoi szemlelet kellene legyen, hogy amit meg lehet rovidebbre, gyorsabbra csinalni, foleg, hogy ez nem all semmibol, azt ugy is kell megcsinalni. „Nehogy már szegény ARM Kiakadjon!”
Szerintem tévedsz!
Itt a bizonyíték. Részlet az ASM debugerból, a Kérdéses 16 bites adatokról:
Látni, hogy mindenüt fél szót töltbe: LDRSH r0,[r6,#0x00] LDRSH r0,[r6,#0x02] És az eltolási cím értéket is 2 byte-vel növelte. Tehát szépen megfér 2 fél szó 4 Byten LDRSH, LDRSHT Rt, [Rn, #offset] Load register with signed halfword — Terjesztitek nagy hévvel ami nem is igaz!
És mikor visszateszi az eredményt ugyan oda ahonnan kivette:
STRH, STRHT Rt, [Rn, #offset] Store register halfword Szintén csak fél szó! A hozzászólás módosítva: Jún 23, 2017
Nem tevedek. Amikor azt mondom, hogy a fordito a char es short-ot int-re konvertalja, akkor az azt jelenti, amit te is latsz a disassembly listaban. Veszi a memoriabol a 16 bites-es short-ot es betolti egy 32 bites regiszter also 16 bitjebe es a regiszter felso 16 bitjet pedig kinullazza (unsigned), vagy elojelesen kiterjeszti (signed). Es ettol kezdve a muveleteket mar 32 biten vegzi. Ha megnezed a kodot, akkor LDRSH-val betolti a 16 bitet, de a kovetkezo utasitas, a SUB mar 32 bites. Tehat int-re konvertalja a 16 bites valtozot, es int-kent kezeli a muveletek soran. A elojel kiterjesztes az ARM eseteben nem kerul semmibe, de van olyan processzor, ahol igen, es ezert mondtuk, hogy altalaban jobb egybol 32 bites ertekekkel dolgozni.
Gondoltam, hogy ilyen nyakatekert kifogással fogsz elő szuszakolni!
Csak azért, hogy azt hihesd, hogy neked van igazad. Kit érdekel, hogy a proci belül mit csinál! Az neki nem kerül külön utasításba, se órajelbe. A lényeg, hogy kifele, a 2*int16_t Elfért 1*32biten. Nem kellet neki 64bit, memória. És ha jól szervezem a memória foglalást! Nekem 100* 2Byte az nem foga elfoglalni 100*4 Bytet, mint neked! Maradok az előző véleményemnél, (Butaság amit terjesztetek!) És sehol nem látni rá példát, hogy csak kizárólag intet használnának. Az alacsonyabb adatszélesség használata meg büntetendő, viselkedés lenne. A hozzászólás módosítva: Jún 23, 2017
Nem erted, amirol mi beszelunk, nem folytatom.
Hogyne érteném!
Mereven ragaszkodsz, amit tanultál az iskolába! És nem mersz rugalmasan az alkalmazkodni az HW-hez.
Kapu! Nem igazán érdemes ezen szerintem vitázni. Egy 32-bites ALU-val rendelkező proci, ha tetszik ha nem, 32 biten fog számolásokat végezni.
Ha 8-16-stb bites számokat használsz, az előbb utóbb, sok esetben plusz assembly utasítással lebontásra kerül. 32 biten sokszor rövidebb kódot is eredményez 32 bites változókat használni char helyett, mégha pazarlónak is tűnik. Lavírozni kell a FLASH pazarlás (asm szétbontás) és a SRAM pazarlás között. Ha pack-olod az olyan struktúrákat ahol char-okat meg shortokat használsz, akkor már komoly RAM takarékosságot lehet elérni, tehát kód függő ennek alkalmazása. Killbill jól mondja és teljesen igaza is van (az a fránya tapasztalat... ), és mindegy milyen architektúrán dolgozol, a sima változóid előbb vagy utóbb kikötnek az architektúra alapegységénél. Ezen kár vitázni.Használhatsz AVR alatt is longot, de abból byte egységet fog létrehozni, és azzal dolgozik, nem kevés asm "lebontó" kódot generálva ezzel. De használhatsz 32-bites ARM, vagy 64-bites PowerPC mag alatt is byte-ot, akkor meg felbővíti 32-bitessé / 64 bitessé, maximum utána levágja Neked az értelmezésnél. Idézet: „a legoptimálisabb, leggyorsabb és legkisebb kódot az uint32_t adja” Szerintem: kódméret: Mivel az ARM utasításkészlete támogatja a 16 bites adatstruktúrát a kód mérete nem változik. forrás Végrehajtási idő: Leggyorsabb, ha az adat 4 byte-ra igazított és 32 bites: forrás. Illetve vannak kivételek a pl. M3-nál a DSP utasítások, mert itt a 16 bites gyorsabb. Ugyancsak gyorsabb a 16 bites osztás és a gyökvonás. Amíg a mikrokontrollerek viszonylag kis méretű RAM-mal rendelkeznek addig én érdemesnek tartom átgondolni a futási idő / rendelkezésre álló memóriaterület arányát. Másik, pedig az, hogy ha a periféria 8 bites kommunikációt igényel, akkor pl. a DMA miatt nem szerencsés azt 32 bitesként kezelni. A hozzászólás módosítva: Jún 24, 2017
Van a Profik tábora.
Akiknek nem kifizetődő HW közeli kódot írni, mert az nem hordozható egyszerűen. Ezért azt is meg kelleni írnia. Ami már neki nem éri meg. Ezért inkább állítja, hogy az fáj a processzornak, ami közben csak neki fáj! És van az amatőrök tábora. Akiknek csak az adott, STMxx Architecturával van lehetősége dolgozni. Mert ez még megfizethető a számára. És kielégíti az igényeit, nincs is szándékában mást alkalmazni. Mivel az ujjbab beruházással járna …. Van valamilyen Discoveri… lapunk, amin még memória bővítés sincs kiépítve. Most e körülmények között semmit nem nyom a latban az érveitek. Mivel én spórolni akarok a Ram-al, Mert kel a Grafikához, viszont nem akarok memória bővítésre sem költeni. A többit meg ha1drp meg írta előttem. Még hozzá tenném, hogy utána nézhetsz, a linkel ASM táblázatban, minden bit szélességű művelet egyforma számú órajel alatt hajtódik végre. Nem értem miről (minek) is győzködtök?
Üdv.
Keil uVision5 ben programozom, hogyan lehet beállítani hogy pl amikor elkezdem pötyögni hogy HAL_.... akármi akkor kidobja a lehetséges függvényeket vagy válzókat amiket gyorsan ki is választhatok azok közül amiket az include fájlok tartalmaznak vagy deklaráltam. Láttam videón van akinek előjön a felugró ablak de nálam ilyen nincs. Gondolom valahol be kell kapcsolni.
Hali!
Atollic TrueStudio-ban nálatok az AltGr + C billentyűkombinációra beszúrja a "&" jelet, vagy előjön ez az idegesítő ablak? Illetve az AltGr+B "{" se működik... Erre van valami megoldás?
Atollic-ot nem ismerem, de a normálisabb IDE-kben át lehet állítani a gyors-gombokat. Keresd meg, mihez kötötték ezeket és töröld ki őket.
Tyű megtaláltam, sikerült, köszi! (Bár gondoltam rá korábban, de azt hittem ebben nincs ilyen.)
Szóval most megint ARM-el foglalkozok (kezdő szinten), de még mindig nem döntöttem el, hogy milyen IDE-t válasszak. Főleg kijelzőket szeretnék kezelni vele, amihez kell a nagy erőforrás, illetve majd SD, webes dolgok.. stb. Csak az a baj, hogy nem túl magától értetődő, hogyan kell használni a perifériákat.
Hát kijelző kezelés és kijelző kezelés között is sok különbség van.
Mikrokontrollereknél maradva TFT esetén pl. lehet: - Pici mikrokontroller. SPI interfész. Még látszik a kijelző frissítés, de épp csak. Bonyolult GUI-ra nem igazi. - Közepes kategória. pl.: STM32F1 144 lábú. Külső SRAM és 16 bites (párhuzamos) kijelző kezelés FSMC-n keresztül. Kettős bufferelés (SRAM-ba rajzolsz, mikor kész DMA-val kilövöd a kijelzőre). Ezzel már korrekt GUI-k készíthetőek. A frissítés sem látszik. - Komolyabb megoldás: pl. STM32F4 külső SDRAM (lásd Discovery kit). Itt már animációk is beleférnek. Láthatod, hogy mindig igény szerinti a nagy/kicsi erőforrás. Persze egy ha egy házautomatizáláshoz akarsz kezelőpanelt tervezni akkor kell a legnagyobb (bár ott már egy mikroprocesszor alapú cucc jobb választás lehet, pl. raspberry pi).
Animáció is kell, és úgy néz ki, hogy a MIPI DSI 4 lane megoldással lesz. Csak sajnos nekem STM32F407 board van, az meg még nem tud ilyet, de pl. a 469 már igen.
Bár a DMA-s megoldás is tetszik. Igazából még semmi sincs eldöntve, csak próbálom a körvonalakat megtalálni. Csak hát ezekben a témákban el kell mélyülni, és nem tudom melyik IDE-vel tudok jobban haladni. A hozzászólás módosítva: Jún 25, 2017
Az IDE maga tulajdonképp csak egy felhizlalt szövegszerkesztő. Tény viszont, hogy bizonyos csomagokhoz járnak előre elkészített függvénykönyvtárak, illetve saját ARM fordítók is. Ezek viszont már szép összegekbe szoktak kerülni és csak akkor éri meg megvenni ezeket, ha az ember megkeresi velük az árukat. Ha csak hobbicélú az érdeklődés, akkor inkább az ingyenes IDE-k között érdemes szétnézni, illetve meg kell nézni milyen ingyenes (vagy nem-kereskedelmi célra ingyenes) könyvtárak léteznek, amik megfelelnek a feladatra.
|
Bejelentkezés
Hirdetés |
