Svenska ElektronikForumet

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.

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.

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.

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.

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å.

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".

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.

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.

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?

=) 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.

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

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?

Tämligen enkelt att detektera det.

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!

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.