Mein Projekt nähert sich seinem Ende. :-) Sämtliche AD-Wandlungen, Vollgrafikausgabe auf 2,5" Display über Graph und Bargraph, Uhren, Stopuhren, Menuesteuerung etc, alles ist(auch dank dieses Forums) am Laufen. Einzig die Kommunikation meines ATM128 und dem ELM323 funktioniert noch nicht richtig. Die Verbindung ist über die RS232 realisiert, ich kann vom µPC aus zwar den ELM ansprechen (z.B. mit "ATZ" resetten, Abfragen schicken etc.) er reagiert auch, sendet auch zurück, allerdings kommen nur Hyroglyphen an. Es sollten nach dem Hersteller-Datenblatt aber Hex-Daten kommen. Habe parallel zum µPC auch versucht über versch. Terminalprogramme mit dem ELM zu kommunizieren-gleiches Ergebniss, nur irgendwelche nicht identifizierbare Zeichen. Bei erneuter Abfrage sind diese dann aber reproduzierbar, d.h. es kommen die gleichen wieder zur zurück. Die Terminalprogramme melden hierbei "Zeichenfehler". Die Schaltung um den ELM323 ist entsprechend der Herstellerempfehlung aufgebaut. Steh ich auf dem Schlauch? SIND das bereits die richtigen Daten, und ich muß sie irgendwie "interpretieren / umrechnen" ? Wie bekomme ich Klartext auf die Terminalprogramme? Welches Prog. würdet ihr hierzu empfehlen? Danke für die "Starthilfe" :-) Micha B.
>allerdings kommen nur Hyroglyphen >an. Es sollten nach dem Hersteller-Datenblatt aber Hex-Daten kommen. Dann solltest du dir ein Terminalprogramm besorgen, dass aus "Hyroglyphen" für dich lesbare HEX-Zahlen macht. Das, was du da siehst, sind IMHO die ASCII-Zeichen, die dem gesendeten Byte entsprechen. Ich benutze gerne Comtest (B&B-electronics). BrayTerm (oder so ähnlich) wird auch gerne benutzt (keine eigene Erfahrung). In der Codesammlung findet man noch HTerm.
OK, angenommen, das ist der Grund (kanns leider erst heut Nacht testen, da ich solange bei der Arbeit bin), wie komme ich dann µPC intern vom Hyroglyphen zum ASCII / Hex ? Anbei mal ein Return-String, über Zwischenablage in ne txt kopiert. Viele der Zeichen werden ja erst garnicht angezeigt, wie bekomme ich da die ASCII / HEX-Daten raus? Danke :-)
Du benutzt zur Kommunikation mit dem ELM aber schon einen Schnittstellenwandler bzw. die Levelkonverter Schaltung des Herstellers zwischen PC und ELM? Zur kommunikation zwischen ATmega und ELM ist kein Pegelwandler erforderlich, da beide mit TTL pegeln arbeiten. /Michael
In C ginge sowas mit itoa(): http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html Sowas sollte es unter Bascom auch geben. Bleibt nur die Frage wie sinnvoll das Wandeln von integer zu string ist. Wenn damit noch gerechnet werden soll, wuerde ich die "hex"-Variante bevorzugen. Zum Anzeigen ist ASCII natuerlich einfacher. gruss, bjoern.
Der ELM323 sendet grundsätzlich ASCII Zeichen die sich mit jedem Terminal Programm lesen lassen. Das was der OP hier bekommt ist mit Sicherheit nicht das was kommen soll. Das heist erst mal sollte das Problem gefunden werden, warum keine ASCII Zeichen kommen. Dann kann man sich mit der Wandelung beschäftigen. Auch die Hex Daten kommen als 2 Byte ASCII. @micha b Auf meiner Page http://www.mictronics.de findest Du einen ELM322 Clone basierend auf AVR. Im Source Code (main.c) ist eine Funktion drin, die dir 2 Byte ASCII in 1 Byte Hex umwandelt. Musst Du halt umsetzen in Bascom. /Michael
sorum wird ein schuh draus(hex-wert als 2 ascii-zeichen). der zeichensalat sieht nach falscher baudrate bzw verfaelschtem signal aus. am einfachsten waere es, ein speicheroszi dranzuhalten und die baudrate auszumessen, bzw. sich die signalqualitaet anzusehen. alternativ tuts zumindest um nen groben ueberblick zu erhalten der eingang von ner soundkarte: http://www.google.de/search?q=sound+card+scope gruss, bjoern.
@Rahul: Das mit dem HTerm hat zumindest insoweit geholfen, daß ich jetzt in ASCII-Zeichen sehe, daß was nicht stimmt. Eine Rückmeldung endet immer mit 03Hex, insofern arbeitet der ELM wohl schon richtig... @Michael Wolf: Die Schaltung ist gemäß Hersteller aufgebaut, also mit Konverter. Nach Tests mit verschiedenen Terminalprogrammen (unter anderem HTerm) habe ich feststellen können, daß die Anzahl der ankommenden Bytes schon dem entspricht was kommen sollte. Nur der eigentliche Inhalt (auch übersetzt nach Hex) entspricht in keinster Weise dem Soll. Verschiedene Baudraten habe ich ebenfalls durchprobiert. Ob der Quarz vielleicht ausserhalb der Toleranz liegt? Aber würde dann der ELM überhaupt antworten? Also, heute abend Signalqualität prüfen... :-( Mal ne ganz dumme Frage... Ist für den Betrieb eines ELM der Anschluß an die OBD2 zwingend erforderlich? Kann es sein, daß der Mist zurückgesendet wird, weil der Ausgang NICHT an der OBD2 hängt solange ich im Arbeitszimmer progge? Sagt mir bitte nicht das das die Lösung ist... grmmmlll
Du must halt den ELM über die OBD Stecker mit Spannung versorgen (oder anderweitig). Die OBD Datenleitungen sind für die Grundfunktionen des ELM nicht notwendig, der geht auch so. Das heist AT Z usw. muss immer gehen. /Michael
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.