Hallo miteinander, bin grade dabei ein Multi-Mess und CAN Datenlogger zu entwickeln. Dazu verwende ich einen LPC 1768 von NXP. Die Peripherie läuft soweit. Nun steh ich son bischen auf dem Schlauch mit der Datenkommunikation. Brächte wahrscheinlich einfach mal nen Denkanstoss. Ein Protokoll habe ich bereits erstellt und es lassen sich auch Daten empfangen und versenden. Das Problem ist nun das mein Protokoll (Basis dafür ist das CAN Calibration Protokoll) immer eine Art Anfrage schickt und nun an die Antwort eine PID angehängt wird. Diese PID muss dynamisch also wenn zuerst der ADC Wert abgefragt wird bekommt der die PID 0x01 was auch immer als nächstes abgefragt wird dann 0x02 usw. Diese PID soll dann für diesen Wert beibehalten werden. Um dann am PC zu wissen das zu einer bestimmten PID ein bestimmter Wert gehört. Die Frage ist nun wie ich es geschickt anstelle diese zuordnung im uC abzuspeichern? Hoffe ihr versteht wie ich das meine... war gar nicht so einfach zu beschreiben das Problem PS Dachte da evtl. an eine Liste aber das is irgendwie recht aufwendig für so einen eigentlich einfachen kram
Sind die PIDs Mangelware? Oder warum bekommt nicht jede Messaufgabe eine eigene PID fest zugewiesen?
Ja könnte man so sagen es stehen nur 255 zur verfügung wovon einige z.b. 0xFF für antworten das die nachricht richt angekommen ist verplannt sind. Und das ganze geschichte soll halt möglichst dynamisch einsetzbar sein.
Aufbohren. Es ist eine selbstgemachte Beschränkung, oder irre ich?
>Nein leider ist die Beschränkung so vorgegeben...
Wie schön für dich.
Wenn man sich mal vorstellt das mit einer
11 Bit ID 2048 verschiedene Adressen für
eine Aufgabe zur Verfügung stehen und mit einer
29 Bit Extended ID sogar 536 Millionen, dann frag
ich mich ob da nicht eine komplette Fehlplanung
vorliegt.
Ich nehme mal an, das der PC, bei jedem Kommando das er sendet, die ID um eins erhöht. Das hat nichts mit der ID/Adresse des CAN zu tun, sondern ist nur ein Zähler. Schickt der PC 2 Kommandos: ID 1 Messe Ananlog ID 2 Wert Digital Eingang 1 Kann der Mess Datenlogger Antworten: ID 2 Wert 5 ID 1 Wert 70 und der PC kann diese immer noch zuordnen. Das wird bei vielen Geräten so gemacht. Ich würde das aber trotzdem so implementieren, das du einen Eingangspuffer hast und dort Schritt für Schritt ausführst. Das dauert zwar etwas länger, der Analogwert muss ja erst beschafft werden, aber auch hier kann man die Werte ja Zyklisch Sampeln und intern vorhalten. Eine Schleife beschafft alle Werte und speichert diese Intern in einem Puffer. Kommt eine Anfrage rein, Daten nehmen und Antwort zurück zum PC. Dann musst Du nie mehr als eine ID merken, der Rest steht ja noch in deinem Eingangspuffer der Seriellen. Hoffe das war verständlich. Gruss J.Sachs
Ja ist schon richtig aber hier gehts nicht um die CAN Spezifikation 2.0A bzw. 2.0B sondern ums CCP... Und es geht auch nicht darum ganze CAN Frames zu loggen sondern wenn dann nur einzelne Messwerte z.b. Position Drosselklappe etc. Und dafür reichen dann 255 - x PIDs. Wenns nur darum gehen würde CAN Daten zu loggen sowas hätten wir schon da.
So wie Jürgen das beschrieben hat gehts schon in die richtige Richtung. Hatte mir das auch jetzt schon so ähnlich überlegt. Nur sollen einige Daten auch in einem Zyklus Abfragbar sein. Und dann bekomm ich denke ich so langsam echt bischen Probleme wennn ich das alles in einen Buffer packe.
SDC schrieb: > Abfragbar sein muss natürlich heißen gesendet werden. Soll heißen das nach einer Anfrage dieser Wert dann zyklisch gesendet werden ohne erneute Anfrage.
LIste ist sicherlich overkill. Ich würde mir da ein Array machen aus, Hausnummer, 10 'Jobs'. Jeder Job besteht aus der PID, was zu tun ist (und im Falle des Arrays ob dieser Eintrag gerade frei ist oder ob er schon in Arbeit ist). Wenn über CAN was reinkommt wird versucht einen freien Jobeintrag zu finden um den Job dort 'zu erzeugen'. Ist nichts frei, dann muss der Job eben warten (dazu gibt es einen fixen freien Eintrag der als Zwischenspeicher dient). Solange es einen wartenden Job gibt, wird nichts mehr aus dem CAN Buffer heruasgeholt. In der Hauptschleife wird das Array abgegrast auf der Suche nach einem Job der noch nicht bearbeitet wird. Wird einer gefunden, so wird seine zugehörige Aktion auf den Weg gebracht (zb der ADC gestartet). Einige dieser Aktionen (wie zb Portpin abfragen) werden sofort ein Ergebnis haben, ander brauchen länger. Wie auch immer: Wenn das Ergebnis vorliegt dann schicke ich das zusammen mit der im Job vermerkten PID zurück und setzte den Job-Eintrag wieder auf verfügbar. Edit: Ooops, da ist noch etwas dazu gekommen. Zyklisches Senden des Wertes. Kann man aber in das Schema einbauen.
Nachtrag: Was genau bekommst du vom PC? Da muss ja sowas wie eine ANfrage kommen, was zu tun ist und welche PID dieser Aktion zugeordnet wird. Das bedeutet aber auch: du kannst maximal immer genau soviele PIDs im µC haben, wie du überhaupt Messstellen hast. D.h. du brauchst diesen ganzen Job Kram doch gar nicht. Einfach nur ein Array, dass dir die Zuordnung von Messstelle zur dynamischen PID macht. Und eine fixe Durchnummerierung deiner Messstellen, damit du einen Index in dieses Array hast. Oder kann es vorkommen, dass du denselben Messwert mit mehreren PIDs verschicken musst?
Ist richtug vom PC kommt eine Anfrage diese enthält: 1 Byte HEADER 1 Byte CMD also Kommando 8 Byte Parameter hier steht die Adresse des Wertes der Abgefragt werden soll 1 Byte XOR halt XOR aus allen anderen und dann 1 Byte End of Frame Als nächstes schickt der uC nachdem er die empfangenen Daten überprüft hat eine bestätigung und vergibt dabei die PID oder wenn ein Fehler auftrat eben eine Anforderung das vorherige nochmal zu senden Nun snedet der uC die eigentlichen Daten die nun immer die gleiche PID haben sollen etweder nur einmal oder eben in einem Zyklus von 10ms, 20ms oder 100ms Was noch passieren könnte ist, dass vom PC ein Befehl kommt zum Beispiel den Duty Cycle der PWM zu ändern. Hier muss dann halt keine PID vergeben werde.
> 8 Byte Parameter hier steht die Adresse des Wertes der Abgefragt > werden soll OK. Aber dein µC hat ja nicht allzuviele abfragbare Werte. Also erst mal Inventur machen, welche Messwerte es gibt. Für die dann ein Array aufbauen, in dem die zugeordnete PID abgelegt wird. Dynamische Liste würde ich da nicht machen. Ist nur Platzverschwendung für Verpointerungen. Und soviel SRAM hast du dann auch nicht zur Verfügung, dass du da verschwenderisch damit umgehen kannst.
Ich hab das jetzt einfach so gemacht:
typedef struct {
uint32_t Adress
uint8_t PID
} PID_ADR;
Von dem ganzen dann noch ein Array und dann pack ich den Kram da einfach
rein und hab immer ne eindeutige Zuordnung....
Thread beobachten
Seitenaufteilung abschaltenBitte 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.