Car-PC.info

cPOS - Schnittstelle CPOS zu externem Display
opelomega2.5v6 - Mi 31 Okt, 2007 20:56
Titel: Schnittstelle CPOS zu externem Display
also ich beschäftige mich zur Zeit mit der Anbindung des original Displays meines omegas aber das soll hier nicht der punkt sein.

CPOS kann ja sendrs232 bzw. senmessage wobei ich nirgends finden kann was cpos da genau senden kann und da müssen ja dan eben events kommen das es sendet (od. alle sekunden oder so)

mir geht es darum das wir irgendetwas vereinheitlichen falls noch nichts definiert ist falls das schon implementiert ist tut mir leid

es gibt ja schon versuche mit LCDHype und HD44780 displays die sind aber alphanummerisch kann man dafür aber am LPT hängen
find ich aber ein bisschen naja da man sich die möglichkeit nimmt mal eben ein anderes lcd evtl auch grafik oder hersteller displays einzubinden ohne es im cpos source implementieren zu müssen.

was ich mir dachte wäre folgendes:
cpos gibt in einer definierten art und weise via rs232 sämtliche daten aus
ein externer µC bereitet die Daten für das Display auf welches auch immer HD44780, OPEL MID/TID, AUDI FIS ..............
die aufbereitung übernimmt der µC evtl auch mit ein zwei tasten um zwischen den Infos durchzuzappen wenn das display kleiner ist

interessant wäre meiner meinung nach
Titel
Interpret
Album
evtl. daten vom PC Temp. und so
sensor daten
dann noch:
daten vom NAVI
daten von PHOCO
mir ist klar das das externe programme sind und besonders die Navi progs dafür eigentlich keine schnittstelle bieten phoco ist aber in cpos eingebunden die daten wären da oder???
ich bin kein pc programmierer bei der navi geschichte müsste man erkennen welche sounds er abspielt oder iregendwie was er in der gafik anzeigt (L,R, Xmeter) aber das wär dann auch wieder bei jeder soft anders das ist mir klar und sicher kompliziert.

ich hoffe das man da gemeinsam eine lösung erarbeiten kann
denn interessieren tut das doch einige

ich mache definitiv eine Anbindung ans Opel MID
wahrscheinlich auch HD44780 evtl. auch kleines Grafik
MacG - Mi 31 Okt, 2007 22:01
Titel:
LCDHype kann auch andere Displaycontroller ansteuern, darunter verschiedene grafische. Ich selbst nutze es auch, aber am HTPC.
Als Naviprogramm kommt wohl nur das FreeDrive in Frage, das kann senden. Ansonsten kann jedes Frontend wohl die Daten senden, die es selbst anzeigt.

Die Versuche mit LCDHype muß ich mir mal anschauen.
MR Action - Mi 31 Okt, 2007 22:32
Titel:
Dieser Post wurde vom User entfernt
MacG - Mi 31 Okt, 2007 22:44
Titel:
Bei Directions Navigator wohl aber nur mit der Professional Version. Ich glaube nicht, daß das SDk auch bei der einfachen Variante geht.
opelomega2.5v6 - Mi 31 Okt, 2007 23:37
Titel:
zwecks navi glaub ich das das Desti_pack als auch Navigon NCK5 + neues wichtig wären jetzt rein von der userseite betrachtet die vorraussetzungen die diese programme haben kenne ich nicht

weiß jemand was zwecks phoco?

wegen der anderen "controller per dll an LCDHype" halte ich es für schwierig ohne mich jetzt eingelesen zu haben Displays von fahrzeugherrstellern einzubinden besonders interessant bei fahrzeugen ohne can bzw. wo nach wie vor das original display nicht über can läuft (viele OPEL modelle alle das selbe display92-06) ebenso Audi + VW &co und da sind die displays bereits in den fahrzeugen und liegen ohne radio brach!!!
da bin ich mir sicher würde es viele interessenten geben wenn es eine einfache möglichkeit gibt etwas Hardware einzubauen und dann das display verwenden zu können
die ext. hardware wäre für diese displays ohnehin notwendig!!
und die kann dann je nach soft auch an standard displays angepasst werden und entlastet die cpu deutlich denn anscheinend ist LCDHype sehr CPU hungrig
wobei ich ehrlicherweise sagen muss das das OPEL protokoll I2C ähnlich ist + eine weitere datenleitung bei audi physikalisch ähnlich es wäre denkbar auch das aus dem LPT zu fahren scheint mir aber eine ideologie frage zu sein ob das in den PC gehört oder in einen µC (ich tendiere zu 2tem) und dann wäre die frage wiederum alles ins CPOS oder ext. LCDHype oder eben ganz raus aus dem PC sprich
progis...->CPOS->RS232->µC->Display(von klein groß, farbe, OLED......)
MR Action - Do 01 Nov, 2007 00:02
Titel:
Dieser Post wurde vom User entfernt
opelomega2.5v6 - Do 01 Nov, 2007 08:37
Titel:
aja nun ob das per rs232 oder per bonuscan aus dem pc wandert is ja ziemlich wurscht nur braucht man halt bei can im ersten moment mehr / aufwändigere / teurere hardware aber hat dafür unbegrenzte möglichkeiten das find ichs absolut wert vorallem würden sicher ziemlich schnell hier im forum diverse bus-aktoren entstehen ich las da schon einiges sogar über bootloader via can wurde gesprochen

nunja wie siehts den aus mit dem BONUSCAN
nordlicht_68 - Do 01 Nov, 2007 08:43
Titel:
opelomega2.5v6 hat folgendes geschrieben:
weiß jemand was zwecks phoco?


Moin,

neben den jetzt schon funktionierenden Infos wie Batteriepegel, Netztqualität, Provider, Anzahl neuer SMS, Bluetooth connect wird es in der nächsten Version weitere Informationen von PhoCo in cpos zur Verfügung gestellt:
Mir bekannt und getestet ist zZ. Ob batterie geladen wird, gewählte, versäumte und angenommende anrufe.
Natürlich nur soweit, wie diese informationen von deinem Handy über PhoCo zur Verfügung stehen.

Gruss
sTEPHAN
opelomega2.5v6 - Do 01 Nov, 2007 08:50
Titel:
na das macht ja dann richtig sinn mit phoco
und jedes feature mach den ganzen CARPC noch attraktiver wer braucht da noch I-drive MMI und co.
MR Action - Do 01 Nov, 2007 16:25
Titel:
Dieser Post wurde vom User entfernt
opelomega2.5v6 - Do 01 Nov, 2007 21:47
Titel:
ja was soll ich sagen passieren kann soooo viel auch ein nicht E zertifizierter CARPC könnte eine EMV Störfeld aufbauen und zum beispiel das airbag steuergerät motivieren mal eben die airbags zu zünden wird zwar nie passieren kann aber.
weiters ohne mich tatsächlich mit der CAN architektur im KFZ auseinandergesetzt zu haben scheint es ja eine deutliche Trennung zwischen MOTORCAN SICHERHEITSCAN und KOMFORTCAN zu geben.
weiters ist ja fakt das man nicht e zertifizierte produkte ohnehin im auto nicht verbauen darf und kein einziges der hier relevanten bauteile die wir ja dann zum größten teil selbst herrstellen wird jemalls eine e zetifizierung haben das heißt egal ob es nun gefährlich sein könnte oder nicht man hätte es nie einbauen dürfen das wiederum wirft die frage auf kann das dann überhaupt ein konflikt für CPOS oder jede andere Sofware sein wenn etwas funktioniert was man im bereich der STVO definitiv nicht verwenden darf und ich denke das ein CARPC sowieso quasi illegal ist LEIDER

aber auch das ist eine Grundsatz frage die im prinzip die entwickler mit sich und untereinander ausbaden müssen aber ich denke das eine gute carpc software auch eine gute und überlegte schnittstelle braucht ob das jetzt CAN sein muss??? aber gscheit wärs wahrscheinlich

zu letzt eine sehr simple idee wäre beim software mäßigen IBN der schnittstelle entsprechende warnungen und vorsichtshinweise auszugeben und bestätigen zu müssen

LIEBE DEVELOPER was sagt ihr dazu

guten abend

ANDREAS
philipp_c - Do 01 Nov, 2007 21:54
Titel:
Ich sehe es genauso wie Du. Jeder normal denkende Mensch würde wohl eh die Finger davonlassen damit dann etwas in sicherheitskritische Bereiche zu senden.
Aber wenn Du Dir hier im Forum mal die Posts ansiehst, zB mit den immer wieder kehrenden Fragen usw muss man sich manchmal wirklich fragen wieviel "normal denkende" Leute hier sind und ob es nicht echt gefährlich sein könnte, wenn CPOS das unterstützt.

Gruß Philipp

PS: Ich wäre ja eh für einen kleinen Test bevor man hier Mitglied werden kann, aber ein Forum mit nur einer Handvoll Leuten bringt ja auch nicht soviel Wink
MR Action - Do 01 Nov, 2007 23:04
Titel:
Dieser Post wurde vom User entfernt
philipp_c - Do 01 Nov, 2007 23:06
Titel:
Ja für so eine einheitliche Schnittsstelle wäre es natürlich schon klasse wenn CPOS da den Bonus CAN unterstützen würde. CAN ist ja genau das was man für sowas haben will. Vielleicht könnte man sich ja mit den Entwicklern drauf einigen das die Datenrate auf 125kbit/s festgelegt wird fürs senden oder sowas, damit es halt im KFZ CAN nicht funzt
opelomega2.5v6 - Fr 02 Nov, 2007 08:11
Titel:
eine daten rate oder sonst irgendeine kastration des buses um nicht nach KFZ senden zu können wäre sicher denkbar aber die FRAGE ob man das wikrlich habn will ?????
kann aber ich nicht entscheiden und verantworten aber ich nehme an das es eigentlich keiner verantworten muss (wie oben dargelegt)
Das ist ja ein glaubenskrieg!
philipp_c - Fr 02 Nov, 2007 08:28
Titel:
Auf eine Datenrate sollte man sich aber ohnehin einigen (und auf noch ein paar Sachen mehr), wenn man beliebige "Bonus CAN" Module verwenden können will. Von daher seh ich da kein so großes Problem.
Naja, ich bin froh nicht auf Cpos oder sowas angewiesen zu sein Smile

Gruß Philipp
opelomega2.5v6 - Fr 02 Nov, 2007 11:02
Titel:
mir welcher software arbeitest du philipp ???
philipp_c - Fr 02 Nov, 2007 11:07
Titel:
Mit was eigenem
Sevensworld - Mo 05 Nov, 2007 22:47
Titel:
Bin auch immer noch dafür, kann aber leider nur Ideen dazu beisteuern und leider nix programmieren Sad
Sevensworld - Sa 17 Nov, 2007 21:48
Titel:
Hmmm .. schade das der Thread hier wieder eingeschlafen ist.

Ich weiß das unsere cPOS Entwickler ein wenig Bedenken haben was das Schreiben auf den CAN Bus an geht. Sicher auch verständlich, aber wenn es wenigstens eine Art Schnittstelle geben würde, dann wäre doch allen geholfen, oder etwa nicht?
Die Schnittstelle geht dann nur nach außen und nicht direkt auf den CAN. Somit wären die Entwickler außen vor und jeder könnte sich eine Lösung extern basteln.

Als Vorschlag wäre da z.B. das man in den Skineinstellungen Möglichkeiten zur Verfügung stellt und zusätzlich über den Eventhandler .. oder aber nur über die Events, allerdings kommen da dann sicher lange Listen vor Wink
MR Action - So 18 Nov, 2007 02:41
Titel:
Dieser Post wurde vom User entfernt
philipp_c - So 18 Nov, 2007 12:12
Titel:
Problem ist nur, wenn man sich den Cpos 1.0 Source untern Nagel reißt und von da beginnt CAN zu implementieren, dann werden die Trees da wohl auseinanderlaufen und die Cpos CAN Version wird von anderen Neuerungen in Cpos nicht mehr profitieren können. So wie ich das bisher mitbekommen habe ist Cpos wohl nicht so wirklich modular
Sevensworld - So 18 Nov, 2007 13:29
Titel:
Soso .. das ist also Quatsch ... ich denke schon das ist Ansichtssache. Und wenn sich die Entwickler nun mal aus Sicherheitsbedenken gegen das Schreiben auf den CAN entschieden haben, dann sollte das respektiert werden.
Eine externe Lösung halte ich immer noch für relativ einfach zu realisieren und würde das auch nicht als "Bastellösung" bezeichnen.
Damit kann dann jeder machen was er möchte.

Außerdem weiß ich nicht was du mit Wünschen meinst, denn das Schreiben auf den CAN selber gab es ja schon! :)


Davon mal ganz abgesehen, habe ich im Wiki folgendes entdeckt:

# sendRSCAN_<message>
# sendRSOBD_<message>
# sendRSPhone_<message>


Was genau kann man damit anstellen?
MR Action - So 18 Nov, 2007 22:00
Titel:
Dieser Post wurde vom User entfernt
Sevensworld - Mo 19 Nov, 2007 06:01
Titel:
Sevensworld hat folgendes geschrieben:


Davon mal ganz abgesehen, habe ich im Wiki folgendes entdeckt:

# sendRSCAN_<message>
# sendRSOBD_<message>
# sendRSPhone_<message>


Was genau kann man damit anstellen?



Hmmm .. aha, gut zu wissen!

Und was ist mit den 3 send Dingern? Was geht damit?
MR Action - Mo 19 Nov, 2007 12:35
Titel:
Dieser Post wurde vom User entfernt
naruto - Mo 19 Nov, 2007 13:34
Titel:
Hi Mr Action,

can senden geht wie oben beschrieben mit statischen befehlen.

Für das FIS senden reicht so etwas aber nicht, die Implementation wäre nicht gerade sehr einfach Sad

Ich habe für das MFA schreiben ein eigenes Programm, das so ähnlich wie die TV Tuner Emulation die ich schon mal veröffentlicht habe funktioniert.
naruto - Mo 19 Nov, 2007 13:39
Titel:
Ach bevor ich es vergesse das can beschreiben ist nicht ohne, ich habe beim testen mein auto schon richtig lahmgelegt Sad

Man kann so ziemlich alles steuern und überschreiben auch Sicherheitsfunktionen, auch wenn das nicht so ohne weiters gehen sollte aber stellt euch mal vor es wird der Beschleunigungssensor wert aus versehen überschrieben und ein Steuergerät denkt Unfall Airbag auslösen oder ABS greift ein usw.....

Immer daran denken ein Auto ist keine Spielzeug sondern in den falschen Händen eine Tödliche waffe Sad
philipp_c - Mo 19 Nov, 2007 15:33
Titel:
Wie auch in diesem Thread bereits x mal erwähnt will damit auch niemand auf den CAN des Autos schreiben
MR Action - Mo 19 Nov, 2007 17:34
Titel:
Dieser Post wurde vom User entfernt
Sevensworld - Mo 19 Nov, 2007 17:54
Titel:
@Naruto: ich denke ich mache mal per PN weiter ... Wink
philipp_c - Mo 19 Nov, 2007 17:56
Titel:
Warum postest dann hier noch dass Du lieber niemanden an weiteren Dingen teilhaben lassen möchtest?
Slavi - Mo 19 Nov, 2007 18:50
Titel:
Das ist ein Thema das alle interessiert vorallem mich
da wen ich FIS nicht beschreiben kann ich ziemlich traurig werde zumal ich ja auch mein MFL weiter nutzen will
philipp_c - Mo 19 Nov, 2007 19:06
Titel:
Sevensworld redet halt nicht mit jedem Wink
Sevensworld - Mo 19 Nov, 2007 19:06
Titel:
@philip_c: Weil ich eine Detailfrage zu einer Zwischenlösung habe.

Bei mir sieht es zur Zeit eben so aus, das ich mit einem sich wiederholenden Signal mein FIS aktivieren kann und mit 2 weiteren IDs einen Teil des FIS auch beschreiben kann. Also relativ einfach und problemlos ... (in einem Bereich, der keine Sicherheitsrelevanten Sachen steuert) was aber nicht heißen muss, das es bei anderen genau so einfach geht!

@Slavi: Wenn ich Naruto richtig verstanden habe, dann kann man auf den CAN schreiben, aber man sollte schon wissen was man da tut!

Ansonsten bin ich natürlich weiterhin an einer externen Lösung interessiert.
philipp_c - Mo 19 Nov, 2007 19:09
Titel:
Mit dem FIS ist das natürlich so eine Sache, da kann ich naruto schon verstehen. Da verschwimmen dann langsam die Grenzen wo es wirklich ungefährlich ist
C1500 - Mo 19 Nov, 2007 19:23
Titel:
so, jetzt geb ich auch mal meinen Senf dazu:
Image

Spass bei seite..

Ich hab gerade mal wieder das Sendmessage versucht.
In der Changelog steht ja, das es den Befehl "sendRSCAN_<message> "
Leider ist nicht beschrieben, wie die "<message>" aussehen muss.

In Fuchs´s alter Verison sah es z.B. so aus: "sendmessage_can:t3886000300000000"
(Das würde mein Fenster schliessen)
t=11Bit (T=29Bit)
388=Adresse
6=Anzahl der Byte
000300000000= Die eigendliche Nachricht

Ich hab dann einfach mal folgendes Versucht:
sendRSCAN_t3886000300000000
und
sendRSCAN_3886000300000000

Beides aber ohne Erfolg.

@Naruto: könntest du bitte kurz beschreiben wie die Message aussehen muss?

Gruss Peer
Alle Zeiten sind GMT + 1 Stunde
Powered by phpBB2 Plus and Kostenloses Forum based on phpBB