Kviz pri patku, podpasovka v C ?

Jiří Nesvačil nesvacil na posys.eu
Sobota Listopad 5 16:07:44 CET 2016


Uvedl jsem to na spatnem prikladu pro Vas. Ovsem pokud casujete vice udalosti, tak pouhe bitove and-& nestaci. V mem prikladu u scanu klavesnice to nevadi, ale jiz jen bliknuti ledkou do rytmu jine ledky Vam udela pulsy jinak dlouhe. Nevyhnete se 
odecitani. Nebo odecitani promenne do nuly, ale tam zase riskujte pripadne vynechani pulsu.

Odecteni dvou promennych Vam a-b tj. kolik nabehano od posledka je asi nejrozumnejsi cesta. Jen musite osetrit preteceni uint, aby z toho kompiler neudelal signed.

Za me i takova jednoducha vec zjisteni rozdilu casu nemusi byt az tak jednoducha, pokud se ma udelat dobre.

Jirka

Dne 5. 11. 2016 v 15:19 Pavel Hudecek napsal(a):
> Osobně používám proměnné různých velikostí a hodně často i 8b. Např. vždy, když tam má být  jen 0 nebo 1 (V CodeVisionu bych použil jednobitový typ bit, ale ten normální C nemá). Někdy je to vyloženě super, např. 8b index pole s 256 položkami 
> dokonale garantuje, že nedojde k zápisu mimo.
>
> Ale udělat to, co je na začátku této diskuse, tedy přiřadit hodnotu, která zjevně může překračovat 255 do 8b proměnné, považuji za prasárnu typu "ale vždyť ono to funguje".
>
> Poznámka: V mých projektech zde probíraná situace běžně nemůže nastat, dal bych to do čekací funkce, do místa, které proběhne ve volném čase, přibližně jednou za ms a tam by pak nejspíš bylo:
> if ((ms & 3)==0) {
> nebo
> if (!(ms & 3)) {
>
> PH
>
> -----Původní zpráva----- From: Jan Waclawek
>> Neuniká, zrovna tahle promìnná mù¾e být klidnì lokální v main(). Spí¹ mì
>> zará¾í proè je 8-bitová. To, ¾e u¹etøí (mo¾ná) 3 byty mu docela
>> zkomplikuje ¾ivot. Asi je to zvyk z 8-bitových èipù.
>
> Skomplikuje zivot??? Zartujete, pan kolega.
>
> Je to velmi dobry zvyk, neplytvat RAM. RAM je cca 6x cennejsia ako FLASH a
> na tomto sa s 32-bitmi nic nezmenilo(*). Je samozrejme treba zvazit
> vykonavaci cas, ale testy tohoto typu (na uplynutie nejakej doby) byvaju v
> UI, kde na tom obvykle az tak nezalezi.
>
> Takze aby sme len tak naprazdno nekecali, v prilohe konkretna implementacia
> a preklad, je to sice akoze pre Cortex-M0+, ale v tomto konkretnom pripade
> tam pre M0 (a asi ani M3/M4/M7) rozdiel nie je. Ako vidite, je tam jedina
> instrukcia naviac, neznamienkove rozsirenie (ktore plni funkciu maskovania
> bytu a zaroven konverzia pre nasledujuce porovnanie). Zhodou okolnosti to
> usetrene miesto v 32-bitovej verzii gcc vyplytvalo na zarovnanie pred
> polom konstant... ;-)
>
> Takze 8-bitova verzia znamena 2 byte FLASH naviac oproti uspore 3 byte RAM,
> co je aj bez toho faktoru uspora. To rozsirenie je v pomerne dlhom
> linearnom kuse kodu takze v drvivej vacsine pripadov bude vdaka prefetchu
> aj pri pomalej FLASH vykonane v 1 cykle, to je asi 12% dlhsie vykonavanie
> (ak berieme do uvahy ze vacsinou dopadne porovnanie false).
>
> wek
>
> (*) Ano je mozne ze pride pamatova revolucia, ale aj napriek prvym
> lastovickam u TI a Fujitsu pre vacsinu sveta este neprisla; a aj kebyze sa
> to v tychto dnoch zlomi, takych zo 10 rokov to este nebude v praxi akutne.
>
> --------
>
> #include <stdint.h>
>
> volatile uint32_t tick;
> volatile uint32_t action;
>
>
> 080000c0 <Ticker8>:
>
> void Ticker8(void) __attribute__((noinline));
> void Ticker8(void) {
>  static uint8_t t8;
>
>  if (((tick - t8) & 0xFF) >= 4) {
> 80000c0: 4906      ldr r1, [pc, #24] ; (80000dc <Ticker8+0x1c>)
> 80000c2: 4a07      ldr r2, [pc, #28] ; (80000e0 <Ticker8+0x20>)
> 80000c4: 680b      ldr r3, [r1, #0]
> 80000c6: 7810      ldrb r0, [r2, #0]
> 80000c8: 1a1b      subs r3, r3, r0
> 80000ca: b2db      uxtb r3, r3
> 80000cc: 2b03      cmp r3, #3
> 80000ce: d904      bls.n 80000da <Ticker8+0x1a>
>    t8 = (uint8_t)tick;
> 80000d0: 680b      ldr r3, [r1, #0]
> 80000d2: 7013      strb r3, [r2, #0]
>    action = 1;
> 80000d4: 2201      movs r2, #1
> 80000d6: 4b03      ldr r3, [pc, #12] ; (80000e4 <Ticker8+0x24>)
> 80000d8: 601a      str r2, [r3, #0]
>  }
> }
> 80000da: 4770      bx lr
> 80000dc: 20000008 .word 0x20000008
> 80000e0: 20000004 .word 0x20000004
> 80000e4: 2000000c .word 0x2000000c
>
> 080000e8 <Ticker32>:
>
> void Ticker32(void) __attribute__((noinline));
> void Ticker32(void) {
>  static uint32_t t32;
>
>  if ((tick - t32) >= 4) {
> 80000e8: 4906      ldr r1, [pc, #24] ; (8000104 <Ticker32+0x1c>)
> 80000ea: 4a07      ldr r2, [pc, #28] ; (8000108 <Ticker32+0x20>)
> 80000ec: 680b      ldr r3, [r1, #0]
> 80000ee: 6810      ldr r0, [r2, #0]
> 80000f0: 1a1b      subs r3, r3, r0
> 80000f2: 2b03      cmp r3, #3
> 80000f4: d904      bls.n 8000100 <Ticker32+0x18>
>    t32 = tick;
> 80000f6: 680b      ldr r3, [r1, #0]
> 80000f8: 6013      str r3, [r2, #0]
>    action = 1;
> 80000fa: 2201      movs r2, #1
> 80000fc: 4b03      ldr r3, [pc, #12] ; (800010c <Ticker32+0x24>)
> 80000fe: 601a      str r2, [r3, #0]
>  }
> }
> 8000100: 4770      bx lr
> 8000102: 46c0      nop ; (mov r8, r8)
> 8000104: 20000008 .word 0x20000008
> 8000108: 20000000 .word 0x20000000
> 800010c: 2000000c .word 0x2000000c
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list



Další informace o konferenci Hw-list