Entwicklungsprozess für ein eingebettetes Projekt mit erheblichen Änderungen an der Hardware

Question

Ich habe eine gute Idee, über Agile Entwicklungsprozess aber ich habe keine Ieda, wie ein eingebettetes Projekt mit erheblichen Änderungen an der Hardware abzubilden, dass.

Ich werde im Folgenden beschreiben, was wir derzeit tun (Ad-hoc-Weise keinen definierte Prozess noch) nicht. Die Änderungen werden in drei Kategorien unterteilt und verschiedene Prozesse sind für jeden von ihnen verwendet:

1. Änderung der Hardware

   Beispiel: verwenden Sie einen anderen Video-Codec IP

   a) Studie die neue IP

   b) RTL / FPGA-Simulation

   Implementieren

   c) die Legacy-Schnittstelle - unterwegs b)

   d) Warten Sie, bis Hardware (Tape out) ist bereit,

   f) Prüfung auf der realen Hardware

2. Hardware Verbesserung

   Beispiel: Verbesserung der Bildanzeigequalität durch den zugrunde liegenden Algorithmus zu verbessern

   a) RTL / FPGA-Simulation

   b) Warten Sie, bis Hardware und Test auf der Hardware

3. Geringfügige Änderung

   Beispiel: Nur Änderung Hardwareregister Mapping

   a) Warten, bis Hardware und Test auf der Hardware

Die Sorge ist es scheint, wir haben nicht zu viel Kontrolle und Vertrauen zu Software-Reife für die Hardware-Änderungen. Dieses Vertrauen ist entscheidend für den Projekterfolg, da der Bring-up Zeitplan immer sehr eng ist und der Kunde eine nahtlose Änderung gewünscht, wenn auf eine neue Version der Hardware zu aktualisieren.

Wie haben Sie diese Art von Hardware-Änderung? Haben Sie das von einem Hardware Abstraction Layer (HAL) lösen? Haben Sie einen automatischen Test für die HAL-Schicht? HAL arbeitet für ein matural Produkt, aber es könnte nicht funktioniert gut für ein Verbraucherprodukt, dass Veränderungen schnell. Wie haben Sie testen, wenn die Hardware-Plattform nicht einmal fertig ist? Haben Sie gut dokumentierte Prozesse für diese Art von Veränderung?

Answer 1

eine Hardware Abstraction Layer (HAL) Hinzufügen ist ein Muss, wenn Sie die zugrunde liegende Hardware zu ändern während der Lebensdauer des Produktes zu erwarten. Wenn es richtig gemacht, können Sie Unit-Tests für beiden Seiten der HAL erstellen.

Zum Beispiel ist die HAL einfach eine API von der Benutzeroberfläche der aktuellen Anzeige-Hardware. Sie können eine gefälschte Hardware-Treiber schreiben, der nicht ein physisches Gerät nicht fahren, sondern reagiert auf unterschiedliche Weise, um zu überprüfen, dass Ihre oberen API Schichten behandeln alle möglichen Antwortcodes aus dem HAL. Vielleicht schafft es eine Bitmap-Speicher (statt mit dem Auto externe I / O), dass Sie zu einem erwarteten Bitmap zu vergleichen, um zu sehen, ob es richtig zu machen ist.

Ebenso können Sie einen Komponententest schreiben, die gute Abdeckung des HAL aus den oberen Schichten liefert, so können Sie sicherstellen, dass die neue Hardware-Treiber richtig reagiert. Mit Hilfe der Anzeigebeispiel, Sie durch alle möglichen Bildschirmarten, Schnittstellenelemente, Scroll-Methoden usw. Leider für diesen Test, den Sie physisch benötigen, um die Anzeige zu sehen, aber Sie können möglicherweise Side-by-Side laufen mit alter Hardware zu sehen Verbesserungen in der Geschwindigkeit oder Abweichungen im Verhalten.

Zurück zu Ihrem Beispiel, though. Wie anders ist die Umstellung auf einen anderen Video-Codec? Sie sind nur noch Bytes um an Ihrer oberen Schicht schieben. Wenn Sie einen bekannten Codec sind Implementierung, wäre es hilfreich, Quelldateien zu haben, dass wirken als Unit-Test (eine vollständige Palette von möglichen Datenformate abdeckt), um sicherzustellen, dass Ihre Codec decodiert und zeigt sie richtig (ohne Absturz!). Dekodieren in eine Bitmap im Speicher einen guten Unit-Test sorgt für -. Sie können nur einen Speicher zu einem rohen dekomprimierte Rahmen vergleichen tun

Ich hoffe, das hilft. Wenn nicht, fordern Sie weitere Fragen.