Smartare delay i C

[Icecap]

Ingen bra lösning heller, programmet får likaväl vänta vilket var vad som inte skulle ske.

jesper: helt rätt, skillnaden är vad man vill uppnå och vilken "storlek" µC man jobbar med. Att begära att en PIC ska jämföra ett par 32 bit variabler är inte vettigt till sånt men att göra det i ett 32 bit system är helt och alldeles vettigt så som så mycket annat är det en frågan om vad man vill uppnå och med vilken hårdvara, ett generellt svar med den "perfekta metod" kan inte ges helt enkelt.

[dangraf]

Jag funderar lite på jaspers lösningar. Första förslaget kring

twait = tick + TICKS_PER_MS(45); // vänta 45 ms
while (tick < twait) {
gör_nåt_vettigt_ffs();
}

finns det inte risk att det blir fel här? låt säga att man vill vänta 8 tick då blir

Första fallat tick = 0 ger tWait = 8 => while( tick < 0x0008) stannar i satsen tills tickräknaren räknat upp.
Andra fallet tick = 0xFFFE ger tWait = 0x0006 => while (tick < 0x0006) hoppar ur satsen direkt.

Själv brukar jag nästan köra på jespers första förslag men använder en annan typ av uträkning

Kod: Markera allt

U16 tickCounter
void timerInterrupt 
{
  tickCounter++;
}

int main(void)
{
  U16 timestamp = tickCounter;

  while( 1)
  {
     if( (tickCounter-timestamp) > TICKS_PER_MS(45 ) )
     {
           // gör det som ska göras med 45ms fördröjning
           timestamp = tickCounter
     }
  }
}

Det finns ett mer färdigt exempel i tråden
http://elektronikforumet.com/forum/view ... =7&t=44387


applikationerna jag gör brukar vara i form av state-maskiner som ligger i state"idle" och inte gör någonting i vanligafall. Men om man vill göra något sätter man state-maskinen till ett start-state och hoppar runt mellan olika state tills dess att allt är klart. Då får man även en ganska enkel indikation på om applikationen "gör något" eller ifall allt är klart och att man kan gå o lägga sig (sleep).

[edit] tog bort följande rader i mitt inlägg eftersom jag missade en del av texten i tidigare inlägg

Nästa förslag med att kalla på funktioner i interrupt rutinen verkar fungera lite bättre men det är fortfarande en stor risk att man blockerar andra interrupt (såvida man inte kör med prioritet) eftersom funktionsanrop kan ta lång tid som kallas inifrån interrupt rutinen.

[Icecap]

Som sagt tidigare: det finns många fungerande sätt och alla är ju bättre än att stanna av i ett delay, sedan får den exakta lösningsmodellen bero på vilken hårdvara man har och hur programmet flöder i övrigt.

Jag använder också tillståndsmaskiner ibland om det är ändamålsenligt.

Jag gillar din lösning.

[blueint]

LCD_busy -> I/O -> Interrupt on change är en annan metod.

[Icecap]

Som inte fungerar...

På de vanliga HD44780 LCD är busy ett svar i en statusfråga, inte en ledig ledning. Hade det varit så hade interrupt varit skitbra!

Men när jag använder LCD använder jag aldrig "Clear all"-kommandot utom vid initieringen! All utskrift körs direkt, icke preemptivt och jag har trimmat rutinen till att köra OK på alla display (de kan variera lite i hastighet) men så snabbt som möjligt ändå.

När jag ska fylla ett display med ny information placerar jag cursorn på första plats å första raden (dursorplacering går snabbt), skriver ut texten utan att göra annat mellan, placerar cursorn på andra raden och gör samma sak där, klart!

Skriver man ut "samma sak" (t.ex. "Fläkt xxx%") och på en knappsats justerar upp/ner kommer hela texten att flimra med en "Clear all"-kommando och att skriva ut texten först och sedan bara skriva ut "xxx" är fullt möjligt men mer krångligt rent programmeringsmäsigt och så mycket snabbare är det inte.

Jag skriver ut oavsett om det är samma värde/text som ska stå där och det fungerar bra.

Att all säkerhetsreglering osv sköts av ett interrupt är sedan en annan sak, godkänd av Bosch till försäljning i USA är det i alla fall.

[Nerre]

Ja det är väl oftast det smidigaste sättet, i princip kan man ju ha ett minnesområde som "speglar" displayen. Alla funktioner skriver till minnet och sen har man en interruptrutin som uppdaterar displayen från det.

[jesper]

@dangraf:
Jo, när det någongång blir nära overflow på tick, så uppstår det en sån situation.
Med 32-bitars variabel tar det 49 dagar innan det blir aktuellt (med 1ms tickrate).
Det var ju bara ett exempel. Som sagt, inte alla lösningar passar alla.

Din lösning tar hand om overflowsituationen, men kostar kanske lite extra overhead. Dock knappast något problem.

[Korken]

http://elektronikforumet.com/forum/view ... =7&t=44343
Här är ett bra exempel. Bara att blinka en LED, men det är en bra princip.

//Korken

[v-g]

Jag håller med de som säger att det inte finns generellt _EN_ bra metod.

Jag höll på med en sak (som fortfarande väntar på att bli klar ) som var tänkt att drivas på batteri så jag hade en delayrutin som dels satte ner processorhastigheten till ett minimum dels körde SLEEP funkade gjorde det ju. Sen om det egentligen sparade så mycket ström vet jag inte.

Det kändes i det fallet som helt onödigt att processorn står på full macka när man tex hade skrivit ut till display eller väntade på knapptryck i menyn.

Har för mig att det som gav mest var att köra i så låg processorhastighet som möjligt.

Vad gäller problemlösningen tycker jag KISS är en bra regel, behöver man realtid osv ja då kodar man för det, är det en display på ett hemmabygge så är det ju såklart en annan femma.

För egen del kör jag oftast med dumma delayer då dessa är enklast att implementera

Lat är smart