Kviz pri patku, podpasovka v C ?

Jiří Nesvačil nesvacil na posys.eu
Sobota Listopad 5 17:52:28 CET 2016


Ano mate pravdu v preruseni se to dela takto u malych CPU. U vetsich CPU ovsem rozdeluji ulohy na preruseni a hlavni smycka. U vetsich CPU delam maly OS a distribuuji cas.

I takove blikani v hlavni smycce (OS) chcete, aby bylo pravidelne. K odecitani v hlavni smycce nemusi dojit pravidelne za 1ms, ale presto chcete, aby vysledny efekt byl skoro 100%

Pokud udelate:

if( (aktulani_cas-start_cas) > neco)
{
...

Tak jeden vypadek  tj. nezavolani, protoze OS byl zatizen se skoro nepozna, sesynchronizuje se v dalsim kole. Ve Vasem pripade se s odecitanim jedne rozhodi, pri casovem vytizeni, to je znat.

Jirka


Dne 5. 11. 2016 v 16:47 Pavel Hudecek napsal(a):
> Tak samozřejmě blikání s LEDkou je něco jiného a dělá se jinak, obzvláště pokud to má být s více najednou, aniž by se jen banálně střídaly.
>
> Ale zas to jde přehledně a hlavně bez přiřazení nekompatibilních proměnných, např.:
>
> if (++ledCnt>250) ledCnt=0;
> switch (ledCnt) {
>    case 0: LED1=1; break;
>    case 80: LED1=0; break;
>    case 120: LED2=1; break;
>    case 200: LED2=0; break;
> }
>
> To celé samozřejmě buď v ms přerušení, nebo zas v čekací funkci, v sekci začínající
> if (msSync==1) { msSync=0; // -----------------
>
> PH
>
> -----Původní zpráva----- From: Jiří Nesvačil
> 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
>
> _______________________________________________
> 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