Mosconi UART Commands - wie saubere Erkennung?

5ea5e7eaf5078cfd72b2528282012a4a.jpg


ff03da743a2a75eff59c1dc53182166a.jpg



Der erste Teil steht schon mal! :)
 
Super geil Martin, ich nehme dann auch eine Remote :thumbsup::thumbsup:
 
Nicht vergessen - ich mach nur die Umsetzung auf CAN-Bus, das komplette Thema GUI ist eine Sache des CANchecked-Displays, die Lorbeeren gehören also jemand anderem. ;)

Kann jemand ein Buchsenkontaktgehäuse mit passenden Crimpkontakten im Rastermaß 2,00mm empfehlen?

Alternativ würde mir der RJ-12 sogar fast besser gefallen, da kann ich einfach ein Telefonkabel opfern…
Dürfen wir davon auch die Pinbelegung haben? *lieb guck*
 
Die Idee mit dem RJ12 hatte ich auch schon, aber lt Frank ist die Kommunikation dort nicht UART, sondern AI Net

Ich werde mir aber nen Adapter bauen, damit ich das Kabel der RC Mini für meine DIY Remote nutzen kann...
 
Alternativ würde mir der RJ-12 sogar fast besser gefallen, da kann ich einfach ein Telefonkabel opfern…
Dürfen wir davon auch die Pinbelegung haben? *lieb guck*

Der Stecker ist Rj12 6p6c. Übertragung ist RS485.

Von vorne geguckt:
GND GND Data(+) Data(-) +5V +5V

Protokoll ist J1850 mit Generatorpolynom 0x1C (AI-Net).
Muss mal schauen ob ich parallel hier noch eine Soft-UART reinkriege.....

VG Frank
 
@Frank_GM: Das wäre klasse! :liebe:

@Spacelord: Ein CANchecked MFD28 Gen2.
 
Ja, siehst du richtig.
EDIT: Das war die alte Gen1. Die Gen2 kostet 499€.

Find ich für den Funktionsumfang mehr als fair.
 
Zuletzt bearbeitet:
Läuft :liebe:

bd0a34a78af018315c6588cdedaa1853.jpg


@Frank_GM:
Nach dem Presetwechsel scheint er ne Gedenksekunde zu brauchen, oder liegt das an meinem Code? ;)
Stört mich jetzt nicht weiter, aber wenn es an mir liegt, kann ich das ja noch beheben.
 
wow. wird es in eurem Szenario nur als mosconi Bedienung genutzt oder auch andere Sachen?
 
Ich überwache damit alle relevanten Motor-, Getriebe-, Bordnetzdaten sowie Fahrzeugparameter wie Lenkwinkel, ABS/ESP/EDS Eingriff und sowas….
Außerdem meine Balgdrücke vom Airride und jetzt eben noch die Bedienung des DSPs.
 
Um das vielleicht mal heraus zu arbeiten, weil das missverstanden werden könnte:

Die Jungs von CANchecked haben mit dem Projekt nichts zu tun, und wollen sich auch nicht im Car-Audio-Bereich tummeln, da die Nachfrage dafür (leider) einfach zu gering ist.
Die sind im Motorsport zuhause und das ist auch gut so. ;)
Das ist hier eine rein private Bastelei von mir, weil ich ziemlich allergisch auf das siebenhundertunddrölfteste Display / Drehregler / was weiß ich im Auto reagiere. :lolschild:
 
Alles gut :) Ich hab nur schon mal so was gemacht und will es für Mosconi auch probieren. JoMoSCon quasi :D
Aber auch n Display für EmuBlack hab ich mal programmiert. Und Airride. nur nicht alles zusammen
 
Woran ich aktuell noch knabbere: Die saubere Erkennung der einzelnen Bytes in der Antwort vom DSP - ab und zu kommt das aus dem Tritt.
Ich habe es versucht mit

if ((UART-receive[0] == 0x08) && (UART-receive[1] == 0xCF)) {
übergebe die Werte;
}

Aber die Bedingung scheint niemals erfüllt zu werden - scheinbar kann ich nicht so auf einzelne Array-Werte prüfen... :kopfkratz:
 
Woran ich aktuell noch knabbere: Die saubere Erkennung der einzelnen Bytes in der Antwort vom DSP - ab und zu kommt das aus dem Tritt.
Ich habe es versucht mit

if ((UART-receive[0] == 0x08) && (UART-receive[1] == 0xCF)) {
übergebe die Werte;
}

Aber die Bedingung scheint niemals erfüllt zu werden - scheinbar kann ich nicht so auf einzelne Array-Werte prüfen... :kopfkratz:

Ich kenne Deine Abfrage der UART nicht, aber wartest Du denn lange genug bis das Array gefüllt ist?
Lass Dir doch nach der Abfrage deinen Buffer mal anzeigen.

Eine "Gedenksekunde" beim Preset-Wechsel ist normal. Dabei werden ziemlich viele Daten umgeschaufelt, währenddessen ist der UART Interrupt abgeschaltet.

VG Frank
 
Guten Morgen Frank,

ich rufe mit "0x08 0xCF" ab und lese aus dem UART 15 Bytes ein, das funktioniert (scheinbar ;) ) auch.
Aber ich habe dein Eindruck, als ob ab und an (vorrangig bei Bedienung) die Reihenfolge nicht stimmt - deswegen wollte ich irgendwie die Reihenfolge auf Plausibilität prüfen.
Dass (aktuell) der Beginn 0x08 0xCF und die letzten drei Bytes 0xFF sind, ist ja schon mal hlifreich - aber anscheinend ist meine Prüfung falsch.....

Bezüglich Presetwechsel - hatte ich schon vermutet, passt also so. :thumbsup:
 
Nachdem Martin hier bereits ordentlich vorgelegt hat, kann ich zumindest, wenn auch keinen Code, den ersten Platinen-Entwurf (erstellt mit fritzing) zeigen.

Die Version 1 ist auf zwei Platinen aufgeteilt, einmal das "Mainboard", welches den Arduino, den Spannungswandler sowie den Anschluss für den DSP + 12V Bordnetz beheimatet und das "Display", welches das OLED sowie den Rotary Encoder aufnimmt. Beide Platinen werden mit einem 7pol (Flachband) Kabel verbunden.

Die beiden Widerstände sind ein Spannungsteiler für die Boardspannung, damit ich diese via Arduino messen kann.

Die Aufteilung auf zwei Platinen erfolgte aus purem Egoismus :lolschild: , da sich zwei kleine Gehäuse einfacher bei mir in der Mittelkonsole unterbringen lassen. Mal sehen wann ich zum Fräsen der Platinen komme....

Zum DSP gehen nur drei Strippen, RX, TX und GND. @Frank - sollte so mit der Kommunikation klappen oder ?

OMR V1.PNG
 
Zuletzt bearbeitet:
Ja also bei mir läuft es damit. Pegelwandler auf 3,3V hab ich aktuell nicht dazwischen, muss ich noch besorgen….

Wie du die Frame-Erkennung machst würde mich natürlich interessieren, da hakelts bei mir noch etwas. ;)
 
Zurück
Oben Unten