J1850 VPW Erfahrung?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • A8 3B 10 03 00 00 <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>
      A8 3B 10 03 00 00 <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>
      68 FF 10 03 86 <\r><\n>
      68 88 10 83 62 <\r><\n>
      C8 88 10 0E BA <\r><\n>
      28 1B 10 02 00 00 D5 <\r><\n>

      genau das gleiche was der STN sendet. Hab ein Y-Kabel an die ECU angeschlossen und mit 2 HTERM lese ich einmal den STN mit 9600 und einmal den Mega8 mit 38400 aus. Beide senden synchron das gleiche. a_22_9ac28a82

      Hab mit einen Frame zusammengebastelt den ich printe.

      BASCOM Source Code

      1. ' SOF-Inpuls
      2. Case 163 To 239 ' 163µs bis 239µs
      3. If Bus_in = 0 Then ' Pegel ist Low nach SOF-Impuls
      4. Bitcounter = 0
      5. Mybyte = 0
      7. Frame_da = 1 'frame empfangen
      8. Myframe = Dummyframe
      9. Dummyframe = ""
      10. End If
      14. If Bitcounter = 8 Then
      15. Dummyframe = Dummyframe + Hex(mybyte) + " " 'frame zusammensetzen
      16. Byte_da = 1 'Byte empfangen
      17. Bitcounter = 0
      18. End If
      Display All

      Wenn der Frame da ist übergebe ich ihn an eine Proc die ihn bearbeiten soll. Dort werde ich ihn splitten und auswerten. Momentan printe ich ihn da nur.

      BASCOM Source Code

      1. Do
      3. If Frame_da = 1 Then
      4. Frame_da = 0
      5. Frame_bearbeiten
      6. End If
      7. Loop
      10. Sub Frame_bearbeiten
      11. Print #pc , Myframe
      12. End Sub
      Display All

    • Pluto25 wrote:

      Nein , die case fängt ja das Ende (Frame=1) ab.
      Falsch.
      Pac-Man setzt das Frame_da = 1, wenn der Start-Puls erkannt wird (SOF = Start Of Frame).
      Nicht verwechseln mit EOF (End Of Frame).

      Der Timer wäre da, um das Ende des Frames zu erkennen.

      Wenn der Timer nicht verwendet wird, wird das Frame_da erst beim Start des nächsten Frame gesetzt.
      Ist das so gewünscht ???

      Außerdem ist für eine Erkennung von EOF (END-OF-FRAME) der Timer 0 nicht korrekt konfiguriert.
      OC0A hat keinen Wert zugewiesen bekommen. Es bietet sich an, hier den Overflow-Interrupt zu nehmen, das sind dann 256µs in deinem Fall.

      The post was edited 1 time, last by Mitch64 ().

    • Mitch64 wrote:

      Der Timer wäre da, um das Ende des Frames zu erkennen.

      Mitch64 wrote:

      Ist das so gewünscht ???
      Nicht wirklich. Habe es so testweise mal probiert um einen ganzen Frame zu erhalten. Meine Versuche mit Timer brachten nicht den gewünschten Erfolg, zumal ich heute extrem wenig Zeit hatte. Ändert aber nichts daran dass das noch auf dem Plan ist.

      Aber wie Pluto auch geschrieben hat, der Datenstrom ist ständig da und die Verzögerung zeigt sich nicht. Die Werte laufen stundenlang synchron vom STN und vom Mega8.

    • Was ich noch unbedingt los werden muss... Ich habe hier eine ECU und den ganzen Hardwareaufbau liegen mit PC, Terminals, Oskar und allem und tue mich trotzdem schwer. Ihr beide, und hier besonders Mitch macht das aus dem Kopf. Ohne alles guckt ihr euch den Code an, tippt etwas zusammen und es funktioniert. Für mich unbegreiflich!

      VIENEN DANK!

    • Mitch64 wrote:

      Der Timer wäre da, um das Ende des Frames zu erkennen.
      Hab das jetzt geändert.

      BASCOM Source Code

      1. ' EOF erkannt
      2. Case Is < 250 'timer länger wie 250uS=End of Frame
      3. Start Timer0
      5. End Select
      7. Timer_0:
      8. Frame_da = 1 'frame empfangen
      9. Myframe = Dummyframe
      10. Dummyframe = ""
      11. Stop Timer0
      12. Return
      Display All

      Nach 250uS wird der Timer gestartet. Bis 280 kann ich nicht zählen mit Byte. Der Timer signalisiert das EOF und stoppt sich.
      Hoffe das ist so richtig. Funktionieren tut es.

      Dann hab ich die Sub "Frame_bearbeiten" erweitert. Hier prüfen ich die ersten 2 Headerbytes und berechne die Werte die Angezeigt/verarbeitet werden sollen. Das ganze scheint mir zu kompliziert gedacht. Ist das so richtig?

      BASCOM Source Code

      1. Sub Frame_bearbeiten
      3. Local Result As Word : Result = 0 'ergebnis berechnung
      4. Local Anzahl_elemente As Byte
      5. Local Header As String * 4 'zwei ersten headerbytes zur identifikation vom frame
      7. Anzahl_elemente = Split(myframe , Bytewert(1) , " ")
      9. Header = Bytewert(1) + Bytewert(2)
      10. Select Case Header
      11. Case "281B" 'RPM
      12. Result = Hexval(bytewert(5)) * 256
      13. Result = Result + Hexval(bytewert(6))
      14. Result = Result / 4
      15. Print #pc , "RPM " ; Result ; " " ; Myframe
      16. Case "4829" 'Speed
      17. Result = Hexval(bytewert(5)) * 256
      18. Result = Result + Hexval(bytewert(6))
      19. Result = Result / 128
      20. Print #pc , "Speed " ; Result ; " " ; Myframe
      21. Case "A849" 'temp
      22. Result = Hexval(bytewert(5)) - 40
      23. Print #pc , "TEMP " ; Result ; " " ; Myframe
      25. End Select
      27. End Sub
      Display All

    • Pac-Man wrote:

      Nach 250uS wird der Timer gestartet. Bis 280 kann ich nicht zählen mit Byte. Der Timer signalisiert das EOF und stoppt sich.
      Hoffe das ist so richtig. Funktionieren tut es.
      Ob das richtig funktioniert wie gedacht bezweifle ich.
      EOF ist nichts anderes als das ausbleiben weiterer Flanken für eine Mindestzeit.
      Bedeutet, dass durch EOF keine Flanke und damit kein PC-Interrupt auftritt.
      Du kannst nicht in der PC-Int Routine den EOF feststellen. Dafür benötigst du den Timer-Overflow.

      Ich denke dein Programm funktioniert deswegen, weil es ohne deine neue Case-Abfrage auch schon funktioniert hat.

      In deinem letzten Code hattest du auch ein OC0A-Interrupt angedacht, um das Ende zu erkennen.
      Da ein langer Bitpuls aber schon bis zu 239µs dauern darf, ist es bit 250µs nicht weit her. Sollte eigentlich auch 280µs und mehr sein.
      Von daher solltest du deinen Code auf Timer0-Overflow umstricken.

      Pac-Man wrote:

      Dann hab ich die Sub "Frame_bearbeiten" erweitert. Hier prüfen ich die ersten 2 Headerbytes und berechne die Werte die Angezeigt/verarbeitet werden sollen. Das ganze scheint mir zu kompliziert gedacht. Ist das so richtig?
      Wenn du die Paket-Bytes empfängst, ist es einfacher und auch schneller, diese Bytes in ein Byte-Array zu schreiben.
      Damit brauchst du keine umständlichen und zeitfressenden String-Funktionen und hast die Bytes direkt verfügbar.
      Für die Ausgabe wie bisher kannst du eine neue Sub Ausgabe() schreiben, die in einer Schleife die Array-Bytes mit Space dazwischen ausgibt.

      Und Ob das so richtig ist?
      Man kann es so machen, effektiv ist es nicht. Und ich vermute, du hast da schon wieder einen Denkfehler.
      Du willst die ersten beiden Header-Bytes aus dem String extrahieren und in String Header schreiben ?
      Bedenke, dass in dem Quell-String auch ein Leerzeichen zwischen den Hex-Werten ist.

    • Mitch64 wrote:

      Ob das richtig funktioniert wie gedacht bezweifle ich.
      Ich auch aber da es funktioniert. Erstaunlich das er überhaupt wieder startet.
      Clever wenn der timer (per ocxa ) bei 240 stehen bleibt. Dann kann die Case ihn beim nächsten Flankenwechsel (dem Beginn des Sof) starten. Oder er stoppt bei Ovf und behält dann einen Wert von ca 6 die mit Case is < 40 abgefangen werden kann
      Die Eof länge ist irrelevant solange nicht zwei Nachrichten unmittelbar nacheinander gesendet werden. Und dann ist die minimum länge wichtig. Bei 239µs könnte schon das nächste Paket starten. Schlecht wenn er dann 280µs wartet.

      Pac-Man wrote:

      Sprechen braucht er ja nachher nicht
      Dann würde ich ihm auch die Hex/String Verarbeitung ersparen. Mit einem Byte- array hat er es viel einfacher. Solange er noch spricht kann er auch die Daten binär ausgeben. Das Hterm kann sie in Hex darstellen damit sie erkennbar sind.

      Ps Das Ecu liegt auf dem Tisch? Welche Werte für Drehzahl etc gibt es den aus? Fehlt da nicht ein Motor ;)

    • Pluto25 wrote:

      Welche Werte für Drehzahl etc gibt es den aus? Fehlt da nicht ein Moto
      RPM = 0. Die Anderen werden gar nicht angezeigt. Ist aber beim STN genau so. Sobald der Motor startet nimmt der Datenstrom zu.

      Das mit dem Timer muss ich mir nochmal durch den Kopf gehen lassen. Dachte dass der Timer so wie er konfiguriert ist bei 256 überläuft und einen interrupt auslöst.

    • Das macht er beim Ovf. Bei oc0a läuft er bis zum Wert Compare0a (in Deinem Fall 0 - also einmal rund) und führt dann den int aus. Ein Möglichkeit wäre den Compare0a mit 240 zu laden und die selbe isr wie beim Pcint zu verwenden. Dann ruft er sie bei 240 auf und hat 246 wenn das Timerbyte gesetzt wird. Dann kann die case <250 (besser 'case else') ihn Stoppen und der Main mitteilen das eine Sendung vollständig ist. (Frame_da = 1)

    • Hab es jetzt so. Ist das besser oder schon wieder falsch?

      Source Code

      1. Config Timer0 = Timer , Prescale = 8 , Clear Timer = 1 , Compare A = Disconnect '1uS
      2. Ocr0a = 240
      3. Enable Oc0a
      4. On Oc0a Timer_0
      8. Timer_0:
      9. Toggle Led_gruen
      10. Frame_da = 1 'frame empfangen
      11. Myframe = Dummyframe
      12. Dummyframe = ""
      13. Stop Timer0
      14. Return
      Display All
      In der ISR kriege ich es irgendwie nicht hin. Muss weiter schauen.

    • Pac-Man wrote:

      schon wieder falsch?
      Vielleicht. Bedenke das der Timer weiter läuft bis zum Stop Timer0. Daher sollte das gleich vorn stehen damit er nicht rund läuft. Das Toggle und Frame_da geht ruck Zuck aber den Frame zu kopieren dauert ein Weilchen.
      Ich sehe gerade das Compare A = Disconnect damit zählt er nur bis 240 und beginnt dann mit 0 wieder. Ich würde das lassen. Das verkompliziert den Start. Natürlich funktioniert folgendes dann nicht: (vorher geschrieben)

      Dann sollte klar sein wann er wieder startet. Viele Möglichkeiten. Mit dem Oc0a=240 würde ich keine seperate Timer_isr aufrufen sondern gleich die Read_bit Die kann ihn dann stoppen mit:
      Case else
      Stop Timer0
      Timer0=0
      Frame_da=1
      ...
      und ihn starten mit
      Case is <40
      Start Timer0

      Oder separat ohne (oc0a):
      On Timer0 Timer_0 '(fast? das gleiche wie: 'On Oc0a Timer_0' mit Ocr0a = 0)
      Die timer_0 selber sieht richtig aus.

      Reicht es nicht wenn er nach 256µs das Eof erkennt? Kommen wirklich Nachrichten mit minimal Pausen?
      So wie der schon ohne Motor drauflos Quatscht würde mich das nicht wundern wenn er mit Motor dann 'so richtig' loslegt. :D Besteht die Möglichkeit eines Oszillogramms vom "lebenden" Objekt?

      The post was edited 1 time, last by Pluto25 ().

    • Pluto25 wrote:

      Dann würde ich ihm auch die Hex/String Verarbeitung ersparen.
      Hab das jetzt so gelöst:

      BASCOM Source Code

      1. If Bitcounter = 8 Then
      2. 'Byte_da = 1 'Byte empfangen
      3. Bitcounter = 0
      5. Incr Bytecounter
      6. Myframe(bytecounter) = Mybyte
      7. End If
      9. Header = Hex(myframe(1)) + Hex(myframe(2))
      10. Select Case Header
      11. Case "281B" 'RPM
      12. Result = Makeint(myframe(6) , Myframe(5))
      13. Result = Result / 4
      14. Print #pc , "RPM " ; Result
      15. Case "4829" 'Speed
      16. Result = Makeint(myframe(6) , Myframe(5))
      17. Result = Result / 128
      18. Print #pc , "Speed " ; Result
      19. Case "A849" 'temp
      20. Result = Myframe(5) - 40
      21. Print #pc , "TEMP " ; Result
      24. End Select
      Display All
      Denke ist weniger rechenintensiv.


      Das mit "Case else" kriege ich irgendwie nicht auf die Reihe. Lasse es erstmal so dass der Timer bei 240 den Frame zusammensetzt.

      Diagramme folgen noch.

    • Ohne Angabe der Auflösung für x-Achse / Y-Achse kann man damit nicht wirklich was anfangen.

      Hat dein Rigol denn keine USB-Buchse an der Front zum ein Stick reinstecken und Screenshots draufspeichern?
      Dann könnte man deine Einstellungen sehen.

      Pac-Man wrote:

      Hab das jetzt so gelöst:
      Wenn du so zusammenhanglosen Code hier rein stellst, kann man das alles nicht mehr nachvollziehen.