2010-04-16 10 views
5

Ich schreibe eingebettete Anwendungen für verschiedene Hardware (avr, arm7, tms55xx ...) und verschiedene rtoses (freeRTOS, rtx, dsp/bios). Und jede Sekunde von ihnen muss mit PC oder einem anderen digitalen Gerät kommunizieren. Manchmal ist Interaktionen Logik sehr fortgeschritten. Ich bin also interessiert an der gemeinsamen Methodik (wie dem Programmierstil der Zustandsmaschine), der Protokollspezifikation oder der Bibliothek, die die Entwicklung solcher Dinge vereinfachen könnte.Gibt es leichte Analoga zu CORBA/RPC für eingebettete Programme?

Antwort

6

Ich bin sehr glücklich mit googles protocol buffers auf eingebetteten Systemen für Datenübergabe und RPC-Mechanismen. Sie sind ein wenig leichter als Systeme auf XML-Basis, da die übertragenen Daten binär codiert sind und die Decodierung der gesendeten Daten eine minimale Verarbeitung erfordert, was ein großer Vorteil bei der CPU-Nutzung auf der eingebetteten Seite der Verbindung ist.

Es gibt leicht verfügbare Bibliotheken für verschiedene Sprachen, aber am wichtigsten C für eingebettete Anwendungen.

+0

Können Sie bestimmte Implementierungen für Embedded C empfehlen? –

+0

http://code.google.com/p/protobuf-c/ – Mark

1

Here ist ein Artikel über Embedded.com auf CORBA auf eingebetteten Systemen und "leichte" oder minimale Implementierungen. Die genannten kommerziellen Lösungen sind für QNX, VxWorks und LynxOS. Und another article auf RPC auf Embedded.com (dieser von einem TI DSP-Trainer und speziell Verweis auf DSP Autorisierte, so kann für DSP/BIOS relevant sein).

Ich empfehle dringend, dass Sie Embedded.com Artikelsuche verwenden, gibt es wahrscheinlich viele ähnliche Artikel, die Sie nützlich finden werden.

VxWorks supports RPC, wie auch QNX Neutrino.

"Roll your own" war schon immer meine Lösung, wo die Einhaltung von Standards und Kompatibilität zwischen Systemen kein Problem ist (d. H. Meine Systeme sprechen mit meinen Systemen). Doing nur genau was Sie brauchen, ist der beste Weg, um "leicht" zu erreichen, vielleicht auf Kosten von Flexibilität und Wartbarkeit.

+0

ich diese Artikel gelesen habe. CORBA ist für viel fortgeschrittenere Interaktionen gedacht als meine Programme. RPC-Protokoll von TI Codec-Engine ist leicht genug, aber sehr spezifisch und passt nicht zu meinen Anwendungen. – Mtr

0

Protokolle sind eine natürliche Ergänzung für State-Maschinen, also könnten Sie vielleicht die sehr leichten Open-Source-QP-State-Machine-Frameworks (state-machine.com) verwenden. Es sind sofort einsatzfähige QP-Ports und Beispiele für verschiedene Compiler für AVR, MSP430, ARM7/ARM9, TMS320C28x, PSoC, HC08, M16C/R8C, H8, 8051, PIC18, PIC24/DSPIC, ARM Cortex-M3/M0 und viele weitere verfügbar Andere.

Hinweis: Ich arbeite für http://state-machine.com

+0

Nicht ganz Spam. Miro, wir verwenden keine Signaturen auf SO. Ich habe Ihre Antwort bearbeitet, um eine Möglichkeit zu zeigen, die gleichen Informationen zu erhalten. Ich werde auch die Antwort abwerten, weil ich nicht denke, dass sie die Frage direkt anspricht. –

+0

Ja, es war meine Absicht zu zeigen, dass ich für state-machine.com arbeite. –

2

OpenJAUS.

Es ist reflektierend, zusammensetzbar und standardisiert (ish) Works Cross-Language-Cross-Plattform.

Bietet viel mehr Rahmen als Protokollpuffer (was ein sauberer Nachrichtenstapel ist) Es konzentriert sich auf Robotik, funktioniert aber für Kontrollsysteme.

Theoretisch kann eine JAUS-Benutzerschnittstelle jedes JAUS-kompatible Gerät bedienen, und JAUS-Systeme sollen zu einem System-System zusammengestellt werden.

Wenn diese Dinge keinen Sinn machen, dann ignorieren Sie bitte diesen Vorschlag.

Verwandte Themen