PCB-Neuigkeiten - Finden von Softwarefehlern im PCB Design Prozess

Dieser Artikel wird vorstellen, wie man diese versteckten, aber häufigen Fehler vermeidet und verschiedene Techniken einführt, die Ingenieuren helfen, versteckte Fehler in PCB-Kopiersoftware zu finden. Die meisten Softwareentwicklungsprojekte basieren auf einer Kombination aus Code-Inspektion, Strukturprüfung und Funktionstests, um Softwarefehler zu identifizieren. Obwohl diese traditionellen Techniken sehr wichtig sind und die meisten Softwareprobleme finden können, können sie viele häufige Fehler in heutigen komplexen Systemen nicht erkennen.

Strukturtests oder White-Box-Tests können Logik effektiv finden, Steuerfluss, Berechnungs- und Datenfehler im Code. This test requires a complete overview of the internal workings of the software (hence the term "white box" or "glass box") in order to understand the details of the software structure. Es prüft jeden bedingten Ausdruck, mathematische Operation, Ein- und Ausgang. Aufgrund der zahlreichen zu prüfenden Details, Strukturprüfung prüft jeweils eine Softwareeinheit, in der Regel eine Funktion oder Klasse.
Code Review verwendet auch die gleichen komplexen Techniken wie Implementierungsfehler und potenzielle Probleme, um zu finden. Wie White Box Tests, Überprüfungen werden normalerweise für jede Einheit der Software durchgeführt, weil ein effektiver Überprüfungsprozess zentrale und detaillierte Inspektionen erfordert.
Anders als Review und White Box Tests, Funktionstests oder Black Box Tests gehen davon aus, dass nichts über die Implementierung der Software bekannt ist. Es prüft den vom gesteuerten Eingang angetriebenen Ausgang. Funktionstests bestehen aus Testverfahren, die von Testern oder Entwicklern geschrieben wurden., welche die erwartete Programmausgabe spezifizieren, die einem Satz spezifischer Programmeingänge entspricht. Nach Ablauf des Tests, Der Tester vergleicht die tatsächliche Leistung mit der erwarteten Leistung, um das Problem zu finden. Black Box Tests können unerfüllte Anforderungen effektiv finden, Schnittstellenprobleme, Leistungsprobleme, Fehler in den am häufigsten verwendeten Funktionen des Programms.
Obwohl die Kombination dieser Technologien die meisten Fehler finden kann, die in einem bestimmten Softwareprogramm verborgen sind, sie haben auch Einschränkungen. Codeüberprüfung und Whitebox-Tests zielen jeweils nur auf einen kleinen Teil des Codes ab, den Rest des Systems ignorieren. Black Box Tests behandeln normalerweise das System als Ganzes, Details zur Umsetzung ignorieren. Einige wichtige Probleme können nur entdeckt werden, wenn man sich auf die Details ihrer Interaktion im gesamten System konzentriert; Traditionelle Methoden können diese Probleme nicht zuverlässig identifizieren. Das Softwaresystem muss als Ganzes überprüft werden, um die spezifische Ursache des spezifischen Problems zu finden. Da es in der Regel unmöglich ist, jedes Detail im Programm und seine Interaktion mit allen anderen Teilen des Codes gründlich zu analysieren, Die Analyse sollte sich auf die spezifischen Aspekte des Programms konzentrieren, von denen bekannt ist, dass sie Probleme verursachen.
This article will explore three potential problem areas:
* stack overflow
* Race conditions
* deadlock
Readers can read the second part of this article online, which will explore the following issues:
* Timing issues
* Reentrant conditions
All of the above problems are quite common in systems that use multi-task real-time design technology.
stack overflow
The processor uses the stack to store temporary variables, Parameter an die aufgerufene Funktion übergeben, den Thread "state" speichern, und so weiter. If the system does not use virtual memory (in other words, it cannot transfer memory pages to disk to free up memory space for other uses), Der Stapel wird auf die Größe des Produkts fixiert, wenn er die Fabrik verlässt. Wenn aus irgendeinem Grund der Stack außerhalb des vom Programmierer zugewiesenen Bereichs geht, das Programm wird unsicher. Diese Instabilität kann schwerwiegende Systemausfälle verursachen. Daher, Es ist wichtig sicherzustellen, dass das System im schlimmsten Fall genügend Stapel zuweisen kann.
Der einzige Weg, um sicherzustellen, dass kein Stapelüberlauf auftritt, ist die Analyse des Codes, Ermittlung der maximalen Stapelnutzung des Programms unter verschiedenen möglichen Bedingungen, und dann überprüfen, ob genügend Stack zugewiesen ist. Es ist unwahrscheinlich, dass der Test eine bestimmte Kombination von Soforteingängen auslöst und das Worst-Case-Szenario im System verursacht.
The concept of stack depth analysis is relatively simple:
1. Erstellen Sie einen Aufrufbaum für jeden unabhängigen Thread.
2. Ermitteln der Stack-Nutzung jeder Funktion im Aufrufbaum.
3. Überprüfen Sie jeden Aufrufbaum, um festzustellen, welcher Aufrufpfad von der Wurzel des Baums zum externen "Blatt" den meisten Stack erfordert.
4. Fügen Sie die maximale Stack-Nutzung jedes unabhängigen Thread-Aufrufbaums hinzu.
5. Determine the maximum stack usage of each interrupt service routine (ISR) in each interrupt priority level and calculate the total. Allerdings, wenn der ISR selbst keinen Stack hat und den Stack des unterbrochenen Threads verwendet, Die maximale Anzahl von Stapeln, die von der ISR verwendet werden, sollte dem Stapel jedes Gewindes hinzugefügt werden.
6. Für jede Prioritätsstufe, Fügen Sie die Anzahl der Stacks hinzu, die verwendet werden, um den Prozessorstatus zu speichern, wenn ein Interrupt auftritt.
7. Wenn Sie RTOS verwenden, add the maximum number of stacks required for the internal use of the RTOS itself (different from the system call caused by the application code, which is included in step 2).
Darüber hinaus, Es gibt zwei wichtige Dinge zu beachten. Erstens, Ein Aufrufbaum, der nur aus hochrangigem Sprachquellcode erstellt wurde, ist wahrscheinlich unvollständig. Die meisten Compiler verwenden Laufzeitbibliotheken, um gängige Rechenaufgaben zu optimieren, wie Multiplikation und Division von großen Ganzzahlen, Gleitkommaverfahren, etc. Diese Aufrufe sind nur in der vom Compiler generierten Assemblersprache sichtbar. Die Laufzeitbibliotheksfunktionen selbst können viel Stapelplatz beanspruchen, und sie müssen in die Analyse einbezogen werden. If you are using the C++ language, all the following types of functions (methods) must also be included in the call tree: structurers, Zerstörer, überlastete Betreiber, Strukturen kopieren, und Konvertierungsfunktionen. Alle Funktionszeiger müssen ebenfalls geparst werden, und die von ihnen aufgerufenen Funktionen werden in die Analyse einbezogen.