Verwendung von Beaglebone Black als Prototyp eines kommerziellen Produkts

Ich entwerfe ein System und kann mit Sicherheit sagen, dass ich ein wenig überfordert bin. Die Anforderungen des Projekts sind wie folgt;

7" WVGA Touchscreen ansteuern und Grafiken erzeugen

4-20 mA Eingang

3 x 4-20 mA-Ausgänge

2 analoge Eingänge

4 digitale Ausgänge

2 digitale Eingänge

Spi-Bus (5 x CS)

I2C

PWM für LED-Controller

Eeprom zur Datenspeicherung

Ich habe den größten Teil des Systems unter dem Eindruck entworfen, dass wir BBB als Hauptprozessor für das System verwenden würden, aber der BBB wurde wegen seiner Eignung für die Verwendung in einem kommerziellen Projekt in Frage gestellt.

Ich dachte daran, die BBB für die 1. Iteration des Board-Designs zu verwenden. Sobald wir ein funktionierendes System eingerichtet haben, können wir das Board mit dem Cortex-A8 und allen anderen Komponenten, die von der BBB benötigt werden, neu gestalten. Da die BBB alles Open Source ist, sollte dies möglich sein, oder?

Gibt es dafür eine bessere/einfachere Lösung mit einem Mikroprozessor oder ähnlichem? Die Produktlebensdauer wurde als eines der Probleme bei der Verwendung von BBB bezeichnet, da das Produkt eine Lebensdauer von 15-20 Jahren haben muss.

Ich sollte auch hinzufügen, dass ich den größten Teil der Programmierung für das System übernehmen werde und nur geringe Erfahrung mit C++ habe. Jede Hilfe/Beratung wäre willkommen!

Wenn Sie Lebensdauer sagen, meinen Sie damit, dass die BBB 15 bis 20 Jahre verfügbar sein muss oder 15 bis 20 Jahre nach dem Bau überleben muss?
Diese BBB oder mehr, um genauer zu sein, schätze ich den Cortex-A8.
Braucht man wirklich einen Cortex A8? Wie viel Verarbeitung findet hier statt?
Das ist, was ich frage: Nicht zu viel muss nur eine Schnittstelle haben, um die Werte auf dem Bildschirm anzuzeigen, und dann nur die Signalverarbeitung.

Antworten (1)

Ich denke, Sie sollten Ihre Fähigkeiten nutzen, um einen funktionierenden Prototyp bereitzustellen, und ein Gerät auswählen, das bereits alle Elemente bereitstellt, bei denen Ihre Fähigkeiten nicht auf ihrem Höhepunkt sind. Stellen Sie sicher, dass das Gerät und die unterstützenden Elemente alle erforderlichen Komponenten/Module enthalten, die Sie benötigen, damit Sie sich auf die Entwicklung Ihres Ziels/Ihrer Lösung konzentrieren können.

Sobald Sie es erreicht haben und mit den Ergebnissen zufrieden sind und alle notwendigen Nutzungskommentare berücksichtigt haben und sich mit den Endergebnissen vollkommen wohl fühlen, ist es an der Zeit, eine Rückschau zu machen und genau festzulegen, was Sie im Endprodukt benötigen. Berücksichtigen Sie, was Sie über Strom- und Spannungsanforderungen, Batterielebensdauer, Sicherheit usw. gelernt haben.

Die Chancen stehen gut, was auch immer es ist, wird sich ein wenig von Ihrem Prototyp-Gerät unterscheiden. Aber Sie werden in einer viel besseren Position sein, als herauszufinden, was Sie beschaffen müssen (oder irgendwie mit spezialisierten Fähigkeiten, die Sie erwerben oder einstellen, etwas leisten müssen).

Überlegen Sie nicht, wo Sie am Ende des Projekts stehen werden. Konzentrieren Sie sich darauf, so schnell und so gut wie möglich dorthin zu gelangen. Dann blicke zurück und sieh dir den Weg an, dem du gefolgt bist, und überprüfe, was du gelernt hast, indem du ihn gegangen bist. Dann weißt du ganz genau, was du willst.

Manchmal führt der Weg zu einer Menge Arbeitsprodukt, das Sie sich nicht leisten können, vollständig wegzuwerfen, was ein wirklich enger Fokus auf das Endprodukt Ihnen sagt, dass es tatsächlich benötigt wird.

Zum Beispiel brauchen Sie vielleicht wirklich etwas so viel Kleineres, mit so viel weniger Funktionen und so viel besser in der Energieverwaltung, dass Sie, wenn Sie tatsächlich eine Einheit mit der richtigen Größe und korrekter Anordnung beschaffen würden, völlig andere Entwicklungstools verwenden müssten und Ihnen bleibt fast nichts von der ursprünglichen Arbeit übrig, abgesehen von all dem viel besseren Wissen, das Sie jetzt darüber haben. Es passiert. In diesem Fall müssen Sie nur eine Wahl treffen und entscheiden, ob Sie Ihr Produkt lahmlegen und Ihre bisherige Arbeit schützen oder ob Sie ein wirklich wettbewerbsfähiges Produkt herausbringen und einige ernsthafte Arbeit wegwerfen. (Die Rettung hier ist, dass Sie zumindest genau wissen, was Sie noch einmal replizieren müssen.)

Denken Sie jetzt nicht zu viel nach. (Es sei denn, Sie haben etwas noch nicht erwähnt.) Konzentrieren Sie sich einfach darauf, die Ziele zu erreichen. Schauen Sie zurück und sehen Sie, was Sie ändern müssen, und hoffen Sie das Beste, aber seien Sie offen für ernsthafte Nacharbeiten, wenn dies angebracht ist.


Wenn Sie es noch nicht herausgefunden haben, sollten Sie jetzt erkennen, dass ich die Frage "Gibt es eine bessere/einfachere Lösung?" nicht beantworten kann. Nur Sie haben die notwendigen Informationen, um auch nur den Versuch einer Antwort darauf zu unternehmen. Alles, was ich tun kann, ist, einige Gedanken anzubieten, die auf dem Weg berücksichtigt werden sollten.


Je besser Sie werden und etwas Erfahrung hinter sich haben, desto besser können Sie Projektunbekannte antizipieren und identifizieren und ihre Lösungen ganz nach vorne im Projektzyklus schieben. Dies wird dem Zyklus sehr zugute kommen, indem es sehr früh eine GO / NO GO-Entscheidung bereitstellt, wo es viel weniger kostet, es zu treffen, und es wird auch viel mehr Informationen liefern, die verwendet werden können, wenn und wann dann die Entscheidung getroffen wird, voranzukommen (die GO-Entscheidung.) Sie nutzen diese Zeit schnell und klug, um alle erforderlichen Informationen für eine GO/NO-GO-Entscheidung zusammenzustellen und auf Anfrage die nächsten Schritte darzulegen.

Dabei kommt es nicht so sehr auf Ihre anfängliche Auswahl eines Entwicklungssystems an. Tatsächlich wählen Sie möglicherweise ein Entwicklungssystem mit dem vollen Wissen, dass es niemals im Endprodukt verwendet wird. Es wird stattdessen gewählt, um diese Unbekannten zweckdienlich und angemessen zu überwinden, und Sie verschwenden nicht einmal einen Moment damit, sich Gedanken darüber zu machen, ob es gewählt wird oder nicht, wenn dann die GO-Entscheidung getroffen wird.

Aber es kann auch sein, dass in einem bestimmten Projekt " Projektunbekanntes antizipieren und identifizieren und ihre Lösungen ganz nach vorne im Projektzyklus schieben" tatsächlich bedeutet, eine ziemlich enge Auswahl an Optionen für den Mikrocontroller und die zugehörige Hardware zu identifizieren, weil sich diese Projektunbekannten entwickeln dieser Projektgrenzen, die die begrenzte Reichweite bestimmen. Beispielsweise kann ein extrem niedriger Strombedarf mit extrem schnellem „Sleep to Full-Operation“ erforderlich sein, und dies begrenzt Ihre Prozessorauswahl a priori auf genau einen: den MSP430. In diesem Fall könnte die Unbekannte eher darin bestehen, ob die restlichen Ziele mit einem solchen Gerät überhaupt erreicht werden können. In diesem Fall KÜMMERN SIE SICHdarüber, was Sie zu Beginn des Projektzyklus verwenden, um Unbekannte aufzuspüren und aufzulösen, die direkt mit dieser Vermutung zusammenhängen, dass der Prozessor Ihre einzige Wahl ist. Möglicherweise müssen Sie nach dieser frühen Untersuchung eine bestimmte Grenze verschieben, wenn Sie feststellen, dass der MSP430 ein anderes erforderliches Ziel nicht erreichen kann.

Es ist also nicht immer so, dass die Prototypenbasis keine Rolle spielt. Manchmal tut es das. Aber es braucht Erfahrung, um zu wissen, ob dies der Fall ist.