Shipping buggy code: The most critical skill for a programme

C, C++, Pascal, Assembly, Raspberry, Java, Matlab, Python, BASIC, SQL, PHP, etc.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45168
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av TomasL »

Jo, det blir det, eftersom en felfri programvara skall kunna hantera ett oförutsägbart och okänt fel på hårdvaran på ett förutsägbart sätt.
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av lillahuset »

Nerre: Och där var jag tvungen att hålla med dig.
I övrigt däremot tycker jag du är naiv men det kanske har med din scoutbakgrund att göra. "Alltid redo", heter det väl? :)

TomasL: Ja, om det ingår i specifikationen men inte annars.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45168
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av TomasL »

Tja, det kan ju vara sådana trevliga fel som den första revisionen PIC32 hade.
Under vissa specifika förutsättningar med viss specifik kod så blev data som lästes från programminnet (dvs konstanter, tabeller osv) felaktigt.
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av lillahuset »

Om jag inte minns helt fel hade PIC16 problem med EEPROMet i början. Jag har för mig att "work around" var att inte använda adress 0 i EEPROM. Men jag kanske minns helt fel, det var ju länge sedan. :)
Nerre
Inlägg: 26655
Blev medlem: 19 maj 2008, 07:51:04
Ort: Upplands väsby

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av Nerre »

TomasL skrev:Jo, det blir det, eftersom en felfri programvara skall kunna hantera ett oförutsägbart och okänt fel på hårdvaran på ett förutsägbart sätt.
En felfri programvara kan inte hantera alla fel. Det är t.ex. helt omöjligt för en programvara som styr en telefonväxel att fungera efter en kärnvapenexplosion.

Det finns i princip ingenting som är så 100% fungerande, inte ens en hammare eller skruvmejsel fungerar till 100% om man ska se det så.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45168
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av TomasL »

EN programvara kan aldrig bli helt felfri, den kan möjligen bli felfri i förhållande till kravspecen (som naturligtvis också skall beskriva hur det skall testas).
Utifrån det scenarier kan den bli Bugg/felfri, men aldrig någonsin helt bugg/felfri dvs aldrig helt perfekt, utan enbart "tillräckligt bra".
Mr Andersson
Inlägg: 1394
Blev medlem: 29 januari 2011, 21:06:30
Ort: Lapplandet

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av Mr Andersson »

Nerre skrev:
Mr Andersson skrev: För att bevisa att koden aldrig kommer att göra någonting ospecificerat måste du bevisa att hela kedjan, från användare, till hårdvaran, till kvantfysiken som bestämmer elektronernas beteende, är felfri. Vilket i princip är omöjligt.
Nu blandar du ihop att visa att hela lösningen fungerar som avsett med att enbart koden fungerar som avsett.

Blir det "fel" på hårdvaran är det inte "fel" på koden.
Koden kan ju inte fungera isolerat utan hårdvara som kör den. Är det fel i hårdvaran gör inte koden det som den skulle göra.

Visst, det är väl kanske mer en filosofisk synpunkt än en rent teknisk. Men säg t.ex. att en viss kombination av normalt helt giltiga instruktioner får processorn att låsa sig. Min åsikt är att det är mjukvarans fel om den triggar buggen, trots att problemet startade i hårdvaran. Men jag förstår om alla inte håller med.
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av lillahuset »

Nja, man måste nog separera mjukvara och hårdvara. Det blir lite absurt annars.
Däremot bör man speca att mjukvaran i möjligaste mån ska göra något begåvat vid hårdvarufel. Tex ställa utgångarna i felsäkert läge, larma och sedan gå och lägga sig.
Nerre
Inlägg: 26655
Blev medlem: 19 maj 2008, 07:51:04
Ort: Upplands väsby

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av Nerre »

Alla hårdvarufel går ju inte att hantera på det sättet. Tänk om det blir hårdvarufel som gör att en utgång "fastnar" som hög ("stuck at 1", som det kallas), hur ska mjukvaran ens kunna detektera det?
bearing
Inlägg: 11229
Blev medlem: 2 mars 2006, 01:01:45
Ort: Ängelholm

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av bearing »

=) det var inte ett så bra exempel, för ingångsbufferten ligger nämligen normalt efter utgången, så det är bara att läsa ingången...=)
Detta kan man testa på en PIC eller liknande. Sätt utgången hög, och skriv nåt enkelt program som läser ingången och tänder en lampa ifall den skulle bli låg. "Dutta" med en sladd från jord till aktuell I/O.
Användarvisningsbild
rvl
Inlägg: 5720
Blev medlem: 5 april 2016, 14:58:53
Ort: Helsingfors

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av rvl »

Sen kan man skylla på hårdvaran för mystiska (mjukvarorelaterade) resets vid test och skeppa ytterligare en bug ända till Mars. Men det är förståss rätt coolt att patcha en bug på Mars. https://www.rapitasystems.com/blog/what ... spacecraft
Nerre
Inlägg: 26655
Blev medlem: 19 maj 2008, 07:51:04
Ort: Upplands väsby

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av Nerre »

bearing skrev:=) det var inte ett så bra exempel, för ingångsbufferten ligger nämligen normalt efter utgången, så det är bara att läsa ingången...=)
Det gäller ju bara på en processor där ingångar kan konfigureras som både in- och utgång. T.ex. lär inte adressbussen på en vanlig processor ha sån funktion. Och hur ska t.ex. en mjukvara som körs på huvudprocessorn kunna detektera att en pinne på UART fastar som hög eller låg?
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45168
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av TomasL »

Tämligen enkelt att detektera det.
bearing
Inlägg: 11229
Blev medlem: 2 mars 2006, 01:01:45
Ort: Ängelholm

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av bearing »

Nerre skrev:
bearing skrev:=) det var inte ett så bra exempel, för ingångsbufferten ligger nämligen normalt efter utgången, så det är bara att läsa ingången...=)
Det gäller ju bara på en processor där ingångar kan konfigureras som både in- och utgång. T.ex. lär inte adressbussen på en vanlig processor ha sån funktion. Och hur ska t.ex. en mjukvara som körs på huvudprocessorn kunna detektera att en pinne på UART fastar som hög eller låg?
I det program jag beskrev ska I/O:n sättas till utgång vid uppstart, och vara det genom programmet. Att konfigurerar till ingång innebär att utgångsbufferten avaktiveras, inget mer. Den "aktiverar" inte någon ingång. En I/O port fungerar så att när man läser från port-registret så läser man från ingångsbufferten, oavsett om utgångsbufferten är aktiv eller ej. När man skriver till port-registret skriver man till utgångsbufferten, oavsett om det är aktivt eller ej. Detta innebär att även om porten har aktiv utgång kan man läsa ingångsbufferten. Ifall pinnen är kortsluten till jord, eller ansluten till VDD, syns detta vid läsning, trots att porten är konfigurerad till utgång. Nu lärde du dig något nytt!

Angående UART kan man använda en processor med dubbla UART, och läsa det man just skickat med UART2, för att dubbelkolla att det blev rätt. Så även detta kan lösas!
Senast redigerad av bearing 4 oktober 2017, 18:16:51, redigerad totalt 1 gång.
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av lillahuset »

Var inte för säker på hur I/O-portarna ser ut. Det du beskriver är nog det vanligaste men jag har sett andra lösningar.
Skriv svar