Svenska ElektronikForumet

Konstig ämnesnamn, har en liten fundering och det skulle vara intressant att höra vad ni andra tycker.

EN väldigt vanlig sak är att använda en while-loop när man skall kolla en flagga för att se om en resurs är ledig.
Till exempel, om man skall skicka en byte via uarten, så är det ju inte helt ovanligt att man använder (PICs flagga för att kontroller om bufferten är tom)

Problemet som jag ser det är att om nått går snett, så kommer programmet att fastna i denna loop och inte komma ur den om inte watchdogen återstartar processorn.

Är detta sätt att skriva egentligen förenligt med god kodstandard.
Vore det inte lämpligare att expandera loopen och införliva en räknare också, så man hoppar efter en viss tid.

Vad tror ni om detta.

"Vore det inte lämpligare att expandera loopen och införliva en räknare också, så man hoppar efter en viss tid."

Jo, om fallet är sådant att flaggan kanske inte kommer så har jag alltid någon form av timeout räknare inblandad.
(och som alla vet så ska den försiktige programmeraren alltid förvänta sig det oförväntade.)

Det är väl inget fel med att använda while looper som sådan. Men det kanske är fel på tänket när man gör en sån om men inte har en plan B.
Om det är ett problem att programmet hänger sig i loopen (vilket det ju oftast är), så måste man självklart ha en timeout med i loopen, t.ex:
eller

Det beror på vad hela projektet ska göra, hur kritisk det är.

Jag använder extremt sällan detta sätt alls, helt enkelt av den anledning du anger: om det aldrig blir klart låser allt sig.

Men en motfråga:
Om man lägger till en time-out och den utlösas - vad ska då göras?

Tänk ett projekt som mäter en sak och skickar data om detta via en seriell länk, exakt som du ger som exempel. Något är fel så att serieporten inte sänder och den blir alltså aldrig klar till nästa och nästa osv. Man lägger till en time-out så man kan knäcka detta onda tillstånd - men vad ska göras då?
* Sluta sända helt? Vilken nytta har man då av enheten?
* Återstarta UART'en? Men vad om initieringen är skit och det är orsaken till att det inte vill sig?
* Har det kanske hänt en grey-out? Är detta då rätt lösning? Eller ville det vara bättre med ett grey-out skydd?

Det går såklart inte att ge ett enda generellt svar på dessa frågor, de rätta svar beror ju på det specifika projekt men det är ju säkert att man ska tänka mer på varför det (UART) plötsligt inte fungerar och vad som kan orsaka detta. I slutändan är det helt beroende på slarvig progranmmering och/eller dåligt design och det kan ingen time-out i världen lösa...

Jag försöker oftast skriva så att programmet aldrig står och väntar på någonting, har flaggan inte kommit så går vi vidare i programmet och fixar med annat så länge. Lite av multitasking, nästan åt round robin hållet, ingen process får ensamt hänga hela programmet någon längre stund.

Det kanske är lite annat på jobbet, men om jag programmerar hemma har jag inget emot en konstruktion utan timeout. Flera anledningar:
* Man behöver lämpliga värden till alla timeouter. Att bara "sätta en sekunder" slutar alltid med att man måste förlänga ibland.
* Man måste hantera felet rätt. Jespers variant är väl den jag har använt, men då blir det oftast omstart på hela skiten för det är svårt att återvända till programflödet. Om man vågar får man väl börja använda throw().
* All felhantering gör koden komplexare och mer oöverskådlig, och ökar därmed sannolikheten för andra fel.
* Det är oftast lättare att diagnostisera grundproblemet om programmet fastnar på ett ställe som man kan hitta än att det börjar göra recovery-försök.

Sen får man ju naturligtvis sätta in såna timeouter där det visar sig behövas, men det är ju en helt annan femma.

Jag brukar alltid lägga till en timeout på sådana loopar, om det inte är en intern flagga som man med säkerhet vet kommer att ändras inom kort (såvida inte processorn slutar snurra).

Jag ersätter while med for(...) ... och inne i denna for-sats kollar jag flaggan och gör en break om den är satt.

Om for-loopen tar slut innan flaggan satts kommer loop-variabeln skvallra då den stannar på maxvärdet. Då returnerar jag en felkod eller sätter en felflagga.

Jag håller med om att det där att hantera fel kan bli komplext, men det minsta man kan göra är ju att göra användaren uppmärksam på att något inte står rätt till. Man måste givetvis även göra eventuella inkommande data ogiltiga om det t.ex handlar om en inläsning. Annars kan det gå riktigt fel... Hur viktigt det är att alltid få rätt data beror ju helt på vad man ska göra.

En sak är ju hur man gör själv, dock har jag noterat att en hel del bibliotekskod är skriven på detta sätt, framförallt HW-bibliotek, vilket uppenbarligen kan skapa problem.

Allt beror ju på vad man ska göra.
Man får fundera på "lång tid" är självklart i förhållande till vad du ska göra före, efter och samtidigt.

Jag brukar undvika I/O-funktioner i bibliotek av delvis sådana anledningar (men mest för att de ofta är dåligt skrivna, i alla fall Atmel's) ... Däremot läser och skriver jag till interna EEPROM med bibliotekets funktioner - där finns ju en "vänta"-loop på att EEPROMet ska bli klart. Men där anser jag att man får lita på att processorn fungerar - det kommer aldrig att hända att EEPROMet aldrig blir klart.

Om applikationen är sådan att den absolut inte skall göra något annat än att vänta på att villkoret för loopen while (!TRMT) skal bli falsk så är det ok att göra denna typ av konstruktion.

Under de 30 år som jag sysslat med maskinnära programutveckling är det dock ytterst sällan jag stött på en sådan situation.