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
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
@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
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
