Hallo, Ich hatte beruflich schon einige Male mit XCP gearbeitet und frage mich, ob es sowas nicht als OpenSource gibt. Bräuchte doch fast jeder, der mit µCs arbeitet. Ganz kurz, was das ist: In die µC-Firmware wird ein zusätzliches (kleines) Softwaremodul eingebunden, dass über die RS232,CAN,USB ... Schnittstelle eine Liste empfängt, welche Variablen (Speicherstellen) gelesen werden sollen. Diese schickt dann den Inhalt zyklisch raus. Ebenso geht auch Schreiben und Schreiben in EEProm. Auf dem PC läuft dann eine Software, die ein MAP File mit den Adressen einlesen kann und auf der man sich dann Variablen zusammenklickt und jede Variable entweder als Wert oder sogar als "Scope" darstellen kann. Mit Logging.
Moin, Den Ansatz mit der ITM/ETM/Trace der Cortexe von ARM finde ich da noch besser als zusätzliche Programm schnippsel. Ich persönlich brauche sowas immer dann wenn ich das Programm nicht anhalten darf/kann und es um sehr Zeitkritische abläufe geht. Aber Opensource kenne ich auch dafür nichts. Lediglich Keil und IAR unterstützen diese Möglichkeit der Controller. Wenns was Opencource gibt bin ich auch daran interessiert, auch wenns Zusatzcode nachsich zieht. MfG Tec
Ich denke auch an etwas universelles. Was wo auf jedem µC läuft. Ich kenne auch ähnliche Systeme, die nur über 2 IO Pins arbeiten.
Einen XCP Slave Treiber gibt es bei Vector zum runterladen. Ist zwar nicht OpenSource in dem Sinne, aber du darfst es wohl auf deinen Controller draufschmeißen und darfst auch im Code rumpfuschen. Problematischer ist wohl der Master, denn soweit ich weis gibts da nix umsonst. Und eine Canape Lizenz ist wohl zuviel des Guten :) Wenn du dir das zutraust kannst du natürlich auch einen Master schreiben :) Grüße, hiko
hyggelig schrieb: > Ich denke auch an etwas universelles. Was wo auf jedem µC läuft. Ich denke da sind die µC zu unterschiedlich, dass das läuft.
Hm....was glaubt ihr eigentlich was gdb und seine stubs sind? Die machen doch genau das gewuenschte und laufen mit fast jedem controller. Olaf
@Olaf Ok. Hab das Wort "Debug" verwendet. Ich dachte eher an debuggen & parametrisieren und vor allem visualisieren. Canape zum Beispiel bietet hier sehr elegante Möglichkeiten zur Darstellung der Daten. Aber ist nix für meinen privaten eher kleinen Geldbeutel.
> In die µC-Firmware wird ein zusätzliches (kleines) Softwaremodul > eingebunden, dass über die RS232,CAN,USB ... Schnittstelle eine Liste > empfängt, welche Variablen (Speicherstellen) gelesen werden sollen. > Diese schickt dann den Inhalt zyklisch raus. Der Begriff Echtzeit ist dabei ziemlich unsinnig. Denn wenn sich eine Variable 1000 mal pro Sekunde ändert, oder gar im Prozessortakt hochgezählt wird, kannst du da mitnichten irgendwas in Echtzeit mit machen, z.B. bei erreichen von 999 anhalten lassen, weil die 999 vielleicht gar nicht übermittelt wird. So eine Speicherstellenüberwachung gibt es eigentlich schon ewig bei fast alles Microcontrollerklassen. Und selbst wenn es kommerziell ein hübsches Programm gibt mit dem du das Ergebnis z.B. auf einem nebenstehenden PC ansehen kannst, ist das noch immer keine Echtzeit-Debug-Möglichkeit. Was für DEINEN uC dann DIR optisch gefällt UND kostenlos ist, wirst du selber rausfinden müssen, ich hab so was schon öfters selbst geschrieben, auch mit andere Art der Anzeige (z.B. simulierte LEDs, Ziffern, Zeigerinstrumente).
Also wenn es um das visualisieren geht dann hab ich einfach eine software rs232 verwendet die ich auf jeden beliebigen pin legen kann, gleich mit dem richtigen Pegel und hau da mein Testbild als vt100 emulation raus. Ansonsten hat Mawin natuerlich recht. Man hackt sich einfach schnell was zusammen. olaf
Ja. Ich habe schon bei einigen Projekten etwas zusammengehackt. Und hab auch schon ähnliches geschrieben. Aber jedes mal war's dann ein PC Programm, das für dieses Projekt erzeugt wurde. Ich will davon weg, immer das Rad neu zu erfinden. Und da das ja etwas ist, was man bei vielen Projekten verwenden werden kann, ob jetzt privat auf nem kleinen PIC oder ATMega, oder in nem Steuergerät, das beim Kunden in Betrieb genommen wird, deswegen dachte ich, es muss ja noch etwas anderes geben, als die Vector-Tools. OpenSource eben.
Hallo, ich entwickle gerade eine PC Software die die Visualisierung und Scripting auf dem PC übernimmt. Als Hardware verwende ich z. Z. das Modul "Octopus" bzw. "OctopusCAN" von Benedikt Sauter. Die PC Software ist zwar nicht OpenSource, aber für privat Anwender künstig zu bekommen (<100€). Für Tester gibt es zeitlich begrenzte aber unlimitierte Lizenzen kostenlos. Die Firmware für die HW wird auch verfügbar gemacht werden, das Lizenzmodell dafür steht aber noch nicht fest. http://www.odis.de/odisLogger Gruß Olaf
Hi Olaf, und wie sieht bei eurem Tool das Datenübertragunsprotokoll aus? Liegt das offen? Hallo alle anderen auch, Da ich beruflich selber mit XCP (über CAN oder FlexRay) zu tun habe kann ich den Wunsch von hyggelig voll nachvollziehen. XCP ist etwas feines universelles wenn es im Kalibrierung und Messen geht. Das Protokoll liegt ja eigentlich offen, nur müsste man sich mal zusammen finden und für denNon-OProfit-Bereich ein Open-Source-Frontend bauen. Warum sollte man sich für jede neue Schaltung die man zusammen strickt auch ein neues Tool bauen, wenn es universal geht. XCP hat eben auch noch den Vorteil, dass es für verschiedene Übertragungsmedien und Schnittstellen definiert ist. Neben den schon erwähnten CAN und FlexRay sind auch RS232 und Ethernet spezifiziert. Wenn die Hardware Abstraktion (zB AUTOSAR kompatibel) anständig gemacht ist könnte man das XCP im Controller auch von einer Architektur auf eine andere portieren. Ach, und der XCP-Treiber im Controller ist normaler Weise nur wenige kB groß. Gruß, TManiac
Hallo TManiac, da das HW-Tool noch nicht released ist, liegt das Protokoll auch noch nicht offen. Es wäre aber denkbar das zu tun. Grundsätzlich ist das Protokoll sehr an das MOST-Protokoll, bzw. INIC-PortMessage-Protokoll angelehnt. Dh. es gibt eine Längenangabe, einen Header (FunctionBlockID, InstanceID, FunctionID, Opcode) und den Payload. Eventuell gebe ich auch das ganze als Lib (AVR zur Zeit) frei. Man könnte dann ganz einfach seine App auf die HW portieren. Ich habe dazu ein mini OS implementiert (angelehnt an die ProtoThreads von Adam Dunkels). Signals, (Quasi-)Threads, Timer. USB ist im BSP des Octopus auch enthalten. Das zeitunkritische kann man dann mit dem odisLogger und seinem eingebauten JavaScript-Interpreter ganz bequem auf dem PC erledigen. Gruß Olaf
Moin, Olaf Dreyer schrieb: > Eventuell gebe ich auch das ganze als Lib (AVR zur Zeit) frei. Und sowas kapier ich zum Beispiel gar nicht (also das in der Klammer bei dir). Warum ist ein Übertragungsprotokoll bitte Hardware-abhängig? In "meiner Welt" wird die Hardware durch eine Abstraktionsschicht entkoppelt. Damit ist jedes Software Modul ab der zweiten Ebene Hardware-unabhängig. Gruß, TManiac
Achso (da nicht eingeloggt, leider als Doppelpost) Das MOST-Protokoll ist auch schön sauber definiert. Da habt ihr euch eine prima Vorlage gesucht, ganz im Ernst ohne Ironie. Aber es ist halt besser für Steuerungsaufgaben geeignet. XCP ist hingegen genau auf Messen und Kalibrieren optimiert. Noch ein Gruß, TManiac
TManiac schrieb: > Warum ist ein Übertragungsprotokoll bitte Hardware-abhängig? Schrieb er doch gar nicht. Er schrieb, dass er es vielleicht als "Lib" freigeben will, und die hat er derzeit für den AVR vorliegen. Ich organisiere mir derartige Traces, sofern der round-trip über den Debugger zu langsam ist, meist über freie Portpins und Aufzeichnung mit einem logic analyzer. Ideal ist es natürlich, wenn man 8 Pins dafür frei hat, dann kann man relativ viel Information auf einmal übertragen, ansonsten muss man halt ein wenig serialisieren.
Hi Jörg, ok da hab ich wohl zuviel hinein interpretiert. Jörg Wunsch schrieb: > Ich organisiere mir derartige Traces, sofern der round-trip über > den Debugger zu langsam ist, meist über freie Portpins und > Aufzeichnung mit einem logic analyzer. Die wenigsten Debugger können aber Live-Graphen anzeigen. Und bei manchen Aufgaben vereinfacht sich die Arbeit ungemein, wenn man Soll und Ist Werte grafisch übereinander legen kann. Parallel dazu ein paar Parameter anfassen und beobachten wie sich die Graphen verhalten. Auf diese Weise kann man einen Stromregler innerhalb ein paar Minuten hinreichend genau abstimmen. Gruß, TManiac
TManiac schrieb: > Auf > diese Weise kann man einen Stromregler innerhalb ein paar Minuten > hinreichend genau abstimmen. Das wäre für mich eine so seltene und spezielle Aufgabe, dass ich mir dazu problemlos ein spezielles Frontend stricken würde, entweder auf dem Debugger aufsetzend oder auf den Traces eines LA. Die Wahrscheinlichkeit, sowas innerhalb der nächsten 5 Jahre nochmal zu brauchen, wäre für mich fast 0. ;-) Klar, wenn jemand sowas immer wieder braucht, sieht das anders aus, aber das wäre dann auch die Zielgruppe, aus der eine Opensource- Implementierung initiiert werden müsste. Darauf zu hoffen, dass es irgendjemanden anders gibt, der ohne eigene Notwendigkeit aus purer langer Weile sowas entwickeln würde, ist müßig. So funktioniert Opensource-Software einfach nicht.
Hallo, da man so was immer mal brauchen kann, habe ich den odisLogger begonnen. Inspiriert wurde ich von CANoe von Vector. Als ViewerObjekt gibt es z. Z. aber nur den Log- und den TraceViewer. Andere Viewer sind angedacht aber noch nicht realisiert. Gruß Olaf
Olaf Dreyer schrieb: > da man so was immer mal brauchen kann, habe ich den odisLogger begonnen. Aber eben offenbar nicht als Opensource. ;-) Damit konkurrierst du letztlich nur mit den bestehenden und nimmst dir die Möglichkeit, dass jemand anders Erweiterungen selbst einbringt, die ihm jetzt gerade wichtig wären, für die du aber keine Zeit hast. Nein, ich will nicht betteln oder sowas (ich brauch' das nicht), aber erklären, warum ein Opensource-Projekt eben auch Sinn haben kann. Du könntest dein Geld dann immer noch mit dem Support kommerzieller Kunden zu machen versuchen. Von den paar Privathanseln wirst du so oder so ohnehin nicht satt. :)
Hallo Jörg, ich habe schon mit dem Gedanken gespielt. Wie schätzt Du denn das ein mit dem Thema Dual-Licence? Würden die Firmen fair sein und bezahlen? Gruß Olaf
Olaf Dreyer schrieb: > Wie schätzt Du denn das ein mit dem Thema Dual-Licence? Du brauchst doch nichtmal eine dual license. Du kannst auch eine GPL oder BSD-Lizenz nehmen. > Würden die Firmen fair sein und bezahlen? Firmen bezahlen dann, wenn sie den Eindruck haben, dass sie für die Bezahlung auch eine Leistung bekommen, und ihr eigener Aufwand für die gleiche Leistung höher wäre. Wenn du also einen guten Support lieferst, dann werden sie dir dafür auch was bezahlen, denn du als Autor kannst die Probleme effektiver (schneller) lösen als ein Mitarbeiter der Firma selbst. Ich würde das also versuchen, über Supportverträge abzuwickeln. Ein dual-license-Projekt, das gar nicht funktioniert, kann ich dir auch auf Anhieb nennen: QCad. Schönes Programm, zweifellos das beste in dieser Richtung, was man (auch) als Opensource erhalten kann. Aber: sie "opensourcen" jeweils die nächst ältere Version, und letztlich nehmen sie sich damit die Möglichkeit, Patches, die aus der Opensource-Variante zurück fließen, in die laufende Entwicklung zu integrieren, weil beides viel zu weit auseinander ist und der Aufwand zu groß wird. So fürchte ich, dass deren aktuelle, kommerzielle Version nach wie vor weder eine automatische Sicherung der gerade bearbeiteten Datei in regelmäßigen Abständen macht, noch dass sie die meiner Meinung nach extrem schwerwiegende Unterlassung korrigiert haben, beim Abspeichern mögliche Fehler auszuwerten (Platte voll!). Beides habe ich in der Opensource-Version gepatcht, letzteres nach einem fatalen Datenverlust, der mich einfach nur gegrämt hat. Gerade mit C++ und dem exception-Konzept muss das nun im 3. Jahrtausend wirklich nicht mehr sein.
Hallo Jörg, > Das wäre für mich eine so seltene und spezielle Aufgabe, dass ich mir dazu > problemlos ein spezielles Frontend stricken würde, Naja mir würden noch andere Beispiele einfallen die ähnlich gestrickt sind. Bei denen es immer darum geht einen Parameter anzupassen und wo man zur schnellen Rückmeldung den Soll und Ist Wert live vergleicht. > Klar, wenn jemand sowas immer wieder braucht, sieht das anders aus, aber >das wäre dann auch die Zielgruppe, aus der eine Opensource-Implementierung > initiiert werden müsste. Das ist soweit schon klar. Nur ich zum Beispiel kann mich nicht wirklich dazu durchringen mal ein PC-Frontend zu programmieren. Dazu hab ich schon genug mit dem Controller an sich zu tun. Man müsste wirklich mal das µC-Projekt beiseite legen und die andere Seite anfangen. Ich bin jedenfalls schon mal froh dass das Thema XCP (oder Alternativen) hier etwas Anklang findet. Ich würde mich auch an der Entwicklung beteiligen, soweit es möglich ist (und auch rechtlich mit der Arbeit kollidiert). Gruß, TManiac
> Das ist soweit schon klar. Nur ich zum Beispiel kann mich > nicht wirklich dazu durchringen mal ein PC-Frontend zu > programmieren. Deshalb einfach als VT100 programmieren und auf dem PC ein Terminalprogramm einsetzen. Olaf
Hallo Olaf, dafür brauchst Du aber eine Menge Speicher. Da ist so ein Binär-Protokoll wie es odisLogger einsetzt resourcenschonender. BTW: Dieses Protokoll findet nur in Verbindung mit dem odisCan (OctopusCAN) Verwendung. Ansonsten ist der odisLogger frei programmierbar. Gruß Olaf
> dafür brauchst Du aber eine Menge Speicher. > Da ist so ein Binär-Protokoll wie es odisLogger einsetzt > resourcenschonender. Und da kommen wir zum naechsten Punkt. :-) Entweder ich habe eine Menge Flash und einen dicken Prozessor, dann kann ich alles einsetzen worauf ich Bock habe. Oder aber ich habe es nicht. Wenn ich es aber nicht habe dann muss ich mit moeglich wenig Resourcen irgendwas hinbasteln. Und dann kann ich ganz sicher eine kommerzielle oder opensource Loesung einsetzen die irgendwann zwar jeden Firlefanz unterstuetzt, aber dafuer auch megafett ist. > BTW: Dieses Protokoll findet nur in Verbindung mit dem odisCan > (OctopusCAN) Verwendung. Ansonsten ist der odisLogger frei > programmierbar. Du machst dir Sorgen um meinen Speicher, aber ich soll extra ein CAN Interface vorhalten? Olaf
An strategisch guenstiger STelle bitte ein 'nicht' einfuegen. .-) Olaf
Nö, sollst Du nicht.
odisLogger ist dafür da, den Embedded-Entwickler schnelle Tests zu
ermöglichen. Er kann seine GUI designen (QT-Designer),
JavaScript-Objekte anlegen, Stream-Filter und Stream-Editoren anlegen,
Kommunikations-Objekte anlegen und miteinander verbinden. Z. B. ein
Umsetzer RS232 <-> Ethernet
kostet nur ein paar Maus-Klicks.
odisCan ist nur eine HW-Firmware von mir, die verschiedene
Schnittstellen bietet (2*RS232, 1*SPI, 1*I²C, 5* bis zu 8 GPIOs, 1*CAN,
1*LIN).
odisCan is für odisLogger ein spezielles Kommunikations-Objekt.
Egal über welches Objekt man senden möchte, im JavaScript-Objekt rufst
Du immer die Funktion `so.sendMessage("Receiver", "Payload")` für einen
einzelnen Empfänger auf, oder `so.sendMessage("Payload")` für eine
Broadcast-Message auf.
Die LogViewer-Objekte können beliebig viele Streams anzeigen und
beherschen Syntax-Highlighting.
Das ganze wird über eine GUI konfiguriert.
Gruß
Olaf
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.