Aktuelle Zeit: So 19. Nov 2017, 10:48




Ein neues Thema erstellen Auf das Thema antworten  [ 274 Beiträge ]  Gehe zu Seite Vorherige  1 ... 10, 11, 12, 13, 14
Project MG Bordcomputer 
Autor Nachricht
Benutzeravatar

Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 247
Beitrag Re: Project MG Bordcomputer
Glaube ich hab jetzt die zündende Idee, wie ich ein Nacht-Design verwirklichen werde.


Das Problem.

Das Grundproblem war/ist ja, dass die meisten Grafiken auf dem Chip des Display-Moduls gespeichert werden sollen. Zumindest alle Ziffern und die kleinen Icons wie die Kopfzeile oder sowas wie Tankinhalt oder Reichweite, was man auf den vorigen Bildern sehen konnte. Das hat einfach den Grund, dass somit sehr viel schneller auf sie zugegriffen werden kann, als wenn sie von dem im TFT-Bildschirm integrierten MicroSD-Laufwerk geladen werden. Habe ich irgendwelche sich sehr schnell ändernden Zahlenwerte auf dem Display darzustellen, dann kann es da regelrecht zu "Datenstau" kommen. Außerdem kann eine SD-Karte versagen, und wenn man dann Lesefehler hat, funktioniert gleich das ganze Bordcomputer-Display nicht mehr.

So weit, so gut. Auf dem Chip selbst stehen aber im Speicher nur 64 KB für soetwas zur Verfügung. Ein Überschreiten dieser Schwelle führt zu Fehlfunktionen. Und mit meinen "Tag-Design"-Grafiken liege ich zusammen schon bei ca. 54 KB. Ein kompletter Satz Nacht-Design-Grafiken nach gleicher Machart hätte darauf schlicht und einfach keinen Platz.

Farbige Pixel sind in der Welt der Computer meistens mit ihren Rot-, Grün- und Blau-Werten definiert. Meine bisherigen Grafiken und Ziffern im "Tag-Design" sind definiert als RGB 565, das ist eine "abgespeckte" Farbdefinition für solche Zwecke wie diesen hier.

Der Farbton jedes einzelnen Pixels ist im Farbschema RGB 565 direkt mit einem zwei Byte bzw. 16 Bit langen Hexadezimalwert definiert. Etwa so:

Code:
0xce18, 0xcc0e, 0xe676, 0xf799, 0xf799, 0xf758, 0xd490, 0xd42e, 0xd3cd, 0xe739, 0xdeb7, 0xbb2a, 0xaaa7, 0xa3ee, 0x6081, 0x8268, 0xcdce, 0x9369, 0x5082, 0xad55, 0xd69a, 0xbdd7, 0xd69a, 0xd6ba,


Man hat mit 16 Bit pro Pixel zwar 65536 mögliche verschiedene Farbtöne, was auf TFTs schon zu sehr nett aussehenden Farbfotos führt (zum Vergleich: Desktop-PCs arbeiten heute meist mit 32 Bit und nicht mit 16) . Aber für ein Display mit wenigen Grundfarben zum überwiegenden Anzeigen von Zahlenwerten braucht man das nicht.

Was also tun? Wir brauchen die Farbwerte in 16-Bit wie in dem obigen Code-Beispiel, um sie auf dem TFT darzustellen, aber wir wollen keine so großen Bilddateien.

Man könnte auch versuchen, einzelne Farbwerte zu ersetzen während ein Pixel auf dem Bildschirm dargestellt wird. Ein weißer Pixel wird dann meinetwegen zu einem schwarzen umgerechnet um von Tag- auf Nacht-Design umzustellen. Das ist aber nicht praktikabel, und wird den Mikrocontroller deutlich verlangsamen. Denn es muss ja quasi bei jedem einzelenen Pixel überprüft werden, bist du ein schwarzer Pixel oder ein weißer Pixel? Und wenn ja, dann muss der komplette Farbwert neu in den Speicher geschrieben werden. Für jeden einzelnen Pixel.


Die Lösung.

Die Lösung ist, eine Farbpalette der am häufigsten vorkommenden Farben eines Bildes zu errechnen. Wir können also - meistens - bis zu 256 Farben definieren, die in einem Bild vorkommen sollen. Ihr kennt das vielleicht von GIF-Bilddateien, die genauso eine reduzierte Farbanzahl mit bis zu 256 Farben haben.

Besonders bei flächigen Grafiken mit wenig verschiedenen Farben bietet sich sowas an. Hier einmal eine Gegenüberstellung:

Bild

Wie Sie sehen, sehen Sie nichts... :D Denkt man dann noch daran, dass TFT-Displays ohnehin oft nicht so kontrastreich sind, wird man nachher auf dem Bildschirm noch weniger einen Unterschied merken.

Wie läuft sowas dann praktisch ab? Wie bekommen wir die 256 Farben dargestellt, die ja für sich genommen immer ein 16 Bit großer Wert sein müssen, obwohl wir Speicherplatz sparen wollen/müssen? Nun, indem wir nicht in jedem Pixel eines Bildes die komplette Farbinformation hinterlegen, sondern nur einen Verweis auf einen Eintrag in einer Farbtabelle.

Das ist in etwa so wie früher in der Schule oder in der Vorlesung. Als Lehrer kann ich entweder einen Sachverhalt bis ins kleinste Detail zehn Mal hintereinander erklären, oder ich sage (nach dem ersten Mal Erklären) nur noch "Lesen Sie das bitte auf Seite 115 im Buch nach". Ich werde mir mit letzterem selber eine Menge Rederei ersparen, aber das Ergebnis ist das gleiche, nämlich dass der Student an Ende die gewünschte Information (hoffentlich :D ) im Kopf gespeichert hat, ohne dass ich jedesmal wieder neu runterbeten muss was denn nun auf Seite 115 in diesem Buch steht.


Der Code.

Wir legen also in unserem Programmcode eine Farbtabelle fest. Die kann in etwa so aussehen, hier mal stark vereinfacht anhand einer Farbtabelle mit 12 verschiedenen Farben:

Code:
const uint16_t colorTable[11] PROGMEM = { 0xbdf7, 0x91c4, 0xe71c, 0xb5b6, 0xb596, 0xdedb, 0xbdd7, 0xe73c, 0xd638, 0xd638, 0xe676, 0xf778}


Jeder dieser Werte steht für eine bestimmte Farbe, in der ein Pixel wahlweise auf dem Bildschirm dargestellt werden kann.

Und meine Pixel sind dann nur noch definiert als ein Verweis auf einen bestimmten Wert in dieser Farbtabelle. Das kann dann so aussehen:

Code:
const uint8_t* const testImage[14] PROGMEM = 7, 5, 9, 9, 5, 6, 2, 4, 8, 7, 0, 11, 7, 3, 5 }


Jeder Eintrag in dieser Tabelle ist ein Pixel. An dritter Stelle steht wie man sehen kann eine 9. Pixel Nr. 3 verweist also z.B. auf den 9. Farbton in der obigen Tabelle colorTable[], also auf 0xd638. Somit weiß ich als Mikrocontroller, ich soll den Pixel Nr. 3 in 0xd638 darstellen. Aber eben ohne dass mir jedesmal der Farbwert neu gesagt wird, sondern indem ich nachschaue welche Farbe an 12. Stelle in meiner Farbtabelle hinterlegt ist.

Das Ergebnis ist, dass wir eine Menge Speicherplatz im Programmcode sparen. Denn das schöne ist, diese Farbtabelle muss ich im Grunde nur ein einziges Mal für alle meine Grafiken festlegen, und jede meiner Grafiken verweist dann je Pixel einfach nur auf einen bestimmten Wert in der gemeinsamen Farbtabelle.

Das Festlegen dieser Farbtabelle benötigt zwar auch Speicherplatz. Bei 256 Farben haben wir 16 Bit bzw. 2 Byte mal 256 Farben = 512 Byte. Aber die Grafiken selbst benötigen halt nur noch die Hälfte des Speicherplatzes gegenüber der Speicherung mit kompletten Farbwerten, da jeder Wert in dieser Grafik nur zwischen 0 und 255 ist, was einem Byte entspricht anstatt zweien.


Hoffe ich komme dann demnächst dazu, das auch in die Tat umzusetzen. Wird ein ziemlicher Aufwand, alle Grafiken nochmal neu zu layouten fürs Nacht-Design. Deshalb muss ich das erstmal vertagen, so wie den Rest des Projekts.

_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)

'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)


Mo 13. Nov 2017, 19:42
Profil
Benutzeravatar

Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 247
Beitrag Re: Project MG Bordcomputer
Hab noch ne Idee für die Dinge, die angezeigt werden sollen.

Ich erhebe mit meinem Motordaten-Messmodul die Drehzahl, aber in Wirklichkeit tue ich nix weiter damit, als diese als Zahl auf dem Display dann so wie sie ist auszugeben. Dafür haben wir aber eigentlich schon den Drehzahlmesser an sich, der die gleiche Information darstellt.

Aber man könnte was anderes damit machen, nämlich die Drehzahl zusammen mit dem Momentan-Spritverbrauch und der gefahrenen Geschwindigkeit nutzen, um daraus eine "Gangschaltungs-Empfehlung" zu machen. Sicher, wenn ich sehe dass ich 14 Liter Momentanverbrauch habe, dann werde ich auch selber darauf kommen, dass ich vielleicht mal nen Gang hoch schalte.

Andererseits, so ne "Schalt-Empfehlung" könnte man schnell mit ein paar kleinen Codezeilen verwirklichen.

Bin mir aber noch nicht sicher, nach welchen Kriterien die Empfehlung dann berechnet werden soll.

Wir haben als Variablen wie gesagt Motordrehzahl, Spritverbrauch und Geschwindigkeit in km/h.

Vielleicht habt ihr ne Idee.

Auf dem Display könnte das zum Beispiel so aussehen:

Bild


Bei modernen Autos sind zusätzlich in der Gangschaltung (auch bei Handschaltung) Sensoren, die per CAN den gerade eingelegten Gang an die Bordelektronik melden, aber sowas sparen wir uns hier... :D :D

_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)

'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)


Do 16. Nov 2017, 17:50
Profil
Benutzeravatar

Registriert: Sa 3. Dez 2016, 12:50
Beiträge: 101
Wohnort: Warendorf
Beitrag Re: Project MG Bordcomputer
Wofür brauchst du bei einem MGF/TF eine Schaltempfehlung. Entwerder cruist du gemütlich durch die Gegend oder bist sportlich unterwegs. Bei beidem ist meiner Meinung nach eine Schaltempfehlung überflüssig.
Denke auch das zuviele Infos den BC unübersichtlich machen. Baust du eigentlich ein Menü ein wo man bestimmen kann welche Infos aufs Display kommen?

_________________
MGF MK2, VIN530865, anthrazit, LHD
mit ein paar kleinen Änderungen


Do 16. Nov 2017, 21:39
Profil
Benutzeravatar

Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 247
Beitrag Re: Project MG Bordcomputer
Ja, es wird ein "Settings"-Menü geben, in dem man zum Beispiel einstellen können wird ob man Kilometer- oder Meilenmodus möchte. Hab ich ja weiter oben schon geschrieben. Die Einstellungen werden dann so auf dem Chip (im EEPROM) gespeichert, dass sie jedesmal beim Starten des Bordcomputers wieder neu ausgelesen werden.

Das ganze kann man theoretisch tatsächlich so weit treiben, dass man sich die Menüs komplett selber zusammen stellen kann. Dass ich meinetwegen sage, ok, auf Seite 1 des "Kraftstoff"-Menüs will ich Momentan-Spritverbrauch und Reichweite haben. Oder Durchschnittsverbrauch und Tank-Restinhalt oder so.

Naja, ich habs halt so programmiert im Motordaten-Modul, dass die Motordrehzahl gemessen wird. War ein ziemlicher Aufwand bis das lief, denn die wird direkt am Kurbelwellensensor gemessen. Und jetzt wo der Teil des Codes fertig ist, wäre es ein bisschen schade, wenn man die Drehzahl nur als "redundante" Größe anzeigt, noch dazu auf einem Display das inmitten des eigentlichen Drehzahlmessers montiert ist :D

Wenn man sich darauf einigen könnte, wie man aus Geschwindigkeit, Momentanverbrauch und Drehzahl ne Schalt-Empfehlung errechnet, dann wäre die eigentliche Berechnung ne Sache von zehn bis fünfzehn Code-Zeilen. Und am Ende wird dann einfach als Ergebnis der Berechnung gesagt "Gang rauf" oder "Gang runter".

Ich hatte diese Schalt-Empfehlung im Cockpit bei nem VW den ich dieses Jahr im Urlaub als Leihwagen hatte. Ich fands einfach ganz neckisch. Auf den hügeligen Straßen und Autobahnen auf den Kanaren verbraucht man so oder so ne Menge Sprit, egal ob man die Schalt-Empfehlung befolgt oder nicht. Aber ich fand das irgendwie trotzdem ganz nett, sowas zu haben.

_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)

'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)


Do 16. Nov 2017, 22:21
Profil
Benutzeravatar

Registriert: Mo 5. Jan 2009, 15:06
Beiträge: 759
Wohnort: Erfurt
Beitrag Re: Project MG Bordcomputer
Schaltempfehlung hatte der Ersatzwagen für unsern Firmencaddy . Ich fand albern und überflüssig , weil das hör ich selber wann ich Schalten muss, sowas lenkt nur ab. Wenn ich da laufend wegen irgendetwas auf ein Display schauen sollte lieg ich glaub ich eher im Strassengraben als das ich ankomme .

_________________
Gruß Thorsten
__________________
Home
52er DK /Bastuck/200 Zellen Metallkat/ Porsche Seitenblinker/S 2000 Startknopf/K-Tec Tachoscheiben im LE 500 Design
Vinyl// Gast im Zimmer 15


Fr 17. Nov 2017, 18:02
Profil Website besuchen
Benutzeravatar

Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 247
Beitrag Re: Project MG Bordcomputer
also WENN ich das in den Code einbaue, dann haben sowieso erstmal 1000 andere Sachen Vorrang vor sowas.

Gibt ja eigentlich nur zwei Betriebszustände wo sich rauf- oder runterschalten lohnt. Entweder ich hab nen hohen Verbrauch bei niedriger Drehzahl, dann sollte ich runterschalten. Oder ich hab ne zu hohe Drehzahl und zu hohen Verbrauch, dann muss ich runterschalten.

Werd das trotzdem mal im Hinterkopf behalten. Andere Sachen werden so oder so Vorrang haben erstmal.

_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)

'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)


Fr 17. Nov 2017, 21:07
Profil
Benutzeravatar

Registriert: Sa 3. Dez 2016, 12:50
Beiträge: 101
Wohnort: Warendorf
Beitrag Re: Project MG Bordcomputer
Bei zu hoher Drehzahl runterschalten :shock: :D :D

_________________
MGF MK2, VIN530865, anthrazit, LHD
mit ein paar kleinen Änderungen


Sa 18. Nov 2017, 00:37
Profil
Benutzeravatar

Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 247
Beitrag Re: Project MG Bordcomputer
Der Wolf hat geschrieben:
Bei zu hoher Drehzahl runterschalten :shock: :D :D


:P

Hab mal nachgerechnet... ne Schalt-Empfehlung könnte daran scheitern, dass nicht genug Platz im Flash-Speicher des Mikrocontrollers ist. Alle Icons zusammen für Tag- und Nacht-Design würden sich auf etwa 69 KB belaufen. 64 KB ist das absolute Maximum, darüber startet der Mikrocontroller nicht mehr richtig beim Einschalten.

Also wird das tatsächlich erstmal nix werden. Durch Weglassen aller Icons für so ne Schaltempfehlung komm ich wieder unter 64 KB. Was solls, gibt genug anderes zu tun.

Hat wohl damit zu tun, dass solche Daten quasi am Anfang des Flash-Speichers gespeichert werden. Die meisten Libraries die ich hierfür einbinde setzen voraus, dass die Startadresse des eigentlichen Programmcodes unter 64 KB liegt bei diesem Chip. Man müsste also tief in die Libraries reingehen und sich anschauen wie dort adressiert wird. Da ist es einfacher, man bleibt von vornherein unter 64 KB.

_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)

'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)


Sa 18. Nov 2017, 15:06
Profil
Benutzeravatar

Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 247
Beitrag Re: Project MG Bordcomputer
EDIT: Möglicherweise werde ich bei meinem Display-Modul-Mikrocontroller aber noch an anderen Stellen an Grenzen stoßen bei dem Projekt so wie ich es mir vorstelle.

Ich habe mal geguckt nach Alternativen mit mehr Speicher. Momentan läuft die Software für das Display auf einem 8-bit Atmel 1284P-PU-Controller. Dieser hat 128 KB Flash-Speicher, wovon halt wie gesagt 64 KB nutzbar sind für Grafiken.

Man könnte das ganze aber auch auf nem 32 Bit-Mikrocontroller machen. Es gibt fertige Boards die sich genauso programmieren lassen wie der gegenwärtige Controller. Die haben dann nen ARM Cortex-Mx-Prozessor. Es gibt Varianten mit bis zu 1MB Flash-Speicher, aber für den Bordcomputer würde wohl ein Cortex M4 mit 256 KB reichen.

Sowas hier zum Beispiel:

https://www.sparkfun.com/products/13736

Diese Boards sind von den Abmessungen her sogar noch kleiner als der 1284P-Controller. Das ist besonders bei Montage im Drehzahlmesser-Gehäuse ein Vorteil. Kostet in etwa 10-15€ mehr als ein 1284P. Bei :arrow: Alibaba könnte man sogar bei ner Sammelbestellung solche Boards für 1 Euro das Stück bekommen, wenn ich richtig gelesen hab.

Bezüglich der Funktionen die dieser Chip mit sich bringt, schießt man für ein Projekt wie dieses hier eigentlich mit Kanonen auf Spatzen.

Andererseits, man könnte die Features auch einfach nutzen für weitere Bordcomputer-Funktionen. Diese ARM-Prozessoren haben z.B. eine native Digital Audio-Unterstützung. Heißt, man kann (8 Bit Mono-)Audio-Samples direkt auf dem Chip speichern. Warnungen könnte man dann mit einem richtigen "Gong" ausgeben anstatt nur mit einem Piepton. Und sie haben eine eingebaute Echtzeit-Uhr. Man könnte sich also die Fahrtzeit-Länge anzeigen lassen oder so.

Mit ner Taktfrequenz von 72 MHz (gegenüber 16 MHz beim 1284) dürfte es auch absolut keine Lags/Latenzen beim Bildaufbau geben.

Für jemanden der das ganze nachbauen wollen würde bedeutet das keinen zusätzlichen Aufwand. Das wäre ja alles in dem Programmcode "on board", der komplett von mir kommt. Die eigentliche Schaltung die man für das Display-Modul löten müsste würde sich sogar vereinfachen.

_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)

'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)


Sa 18. Nov 2017, 19:16
Profil
Benutzeravatar

Registriert: Sa 3. Dez 2016, 12:50
Beiträge: 101
Wohnort: Warendorf
Beitrag Re: Project MG Bordcomputer
Wenn der eine Echtzeituhr drin hat, ist es eine Überlegung das Display an der Stelle der Uhr ins Auto zu bauen. Die Uhrzeit könnte man dann mit dem BC anzeigen.
Das hat den Vorteil das man im Auto nichts einfräßen oder großartig umbauen muss.
In dem BC werden Außentemperatur und Innenraumtemperatur angezeigt. Wäre statt der InnenraumTemperatur nicht eine Motorraumtemparatur nicht sinnvoller?
Sind nur Überlegung von mir.

_________________
MGF MK2, VIN530865, anthrazit, LHD
mit ein paar kleinen Änderungen


Sa 18. Nov 2017, 20:08
Profil
Benutzeravatar

Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 247
Beitrag Re: Project MG Bordcomputer
hm... Motorraum-Temperatursensor? Braucht man den? :)

Klar, könnte man machen. Am Motordatenmodul sind noch ein paar Pins frei, wo man den dranpappen könnte.

Hier mal ne aktuelle Gesamt-Skizze von den Modulen:

Bild

Da müsste man dann aber ein Pt100-Element nehmen. Die Temperatursensoren die die Innen- und Außentemperatur überwachen sollen gehen nur bis 120 °C.

Auf die Idee das Display in die Uhr zu machen bin ich überhaupt noch nicht gekommen... :shock: :up:

Klar, könnte man machen. Und auf dem Display könnte man außerdem eine Analoguhr "nachahmen". Da gibt es schon fix und fertig Programmcode für, wie zum Beispiel auf dem Bild hier:

Bild

In das Gehäuse würde sogar das komplette Board mit dem ARM-Prozessor drauf reinpassen was ich oben in dem Link gezeigt hab. Und man könnte statt dem kleinen 1,44-Zoll-Display mit 128x128 Bildpunkten was ich jetzt verwende sogar ein 1,8''-Display mit 160x128 Pixeln verwenden. Das wiederum vereinfacht den Programmcode etwas, da sich in der jetzigen Version bestimmte Anzeige-Elemente quasi wechselnd durch ein- und ausblenden den Platz auf dem Display teilen müssen. Bei 160 Pixeln wäre das nicht nötig.

Durch den leistungsfähigeren Mikrocontroller und den Einbauort im Uhren-Gehäuse mit dem größeren Display könnte sich der komplette Entwicklungsaufwand verringern. Das Projekt wird damit nicht komplizierter, sondern einfacher.

Wie hieß es früher beim A-Team immer... :D

Bild

_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)

'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)


Sa 18. Nov 2017, 21:57
Profil
Benutzeravatar

Registriert: Sa 3. Dez 2016, 12:50
Beiträge: 101
Wohnort: Warendorf
Beitrag Re: Project MG Bordcomputer
Durch den Einbau anstelle der Uhr gibt es noch einen Vorteil. Durch die zurückliegende Einbauposition in dem Schacht hat man auch bei geöffnetem Dach eine gute Lesbarkeit des Displays.

_________________
MGF MK2, VIN530865, anthrazit, LHD
mit ein paar kleinen Änderungen


Sa 18. Nov 2017, 22:26
Profil
Benutzeravatar

Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 247
Beitrag Re: Project MG Bordcomputer
Glaube ich hab die beste Lösung gefunden.

https://eckstein-shop.de/Espressif-ESP-WROOM-32

Das ist ein 32-bit 240 MHz Dual Core- Prozessor mit 16 MB Flash-Speicher.

Für den Bordcomputer hier wäre das gigantisch und um mehrere Grössenordnungen mehr als wir brauchen.

Andererseits, da hat man wirklich alles erdenkliche on board. Selbst ein Bluetooth-Modul, falls es wirklich mal eine App geben wird für den Bordcomputer. Und das ganze kostet mit 6-10 Euro weniger als andere Boards. Man müsste quasi nur noch ein paar Kabel anlöten für Stromversorgung, Datenleitung von den anderen beiden Modulen, und ein paar Kabel rüber zum eigentlichen Display. Wäre somit auch sehr "nachbau-freundlich". Und von den Abmessungen her winzig. Das Board ist nur etwas grösser als ne Briefmarke...

In Sachen "bang for your buck" eigentlich kaum zu schlagen. Und mit 16 MB Flash-Speicher könnte ich mich noch um einiges mehr austoben mit schönen bunten Grafiken... :D

_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)

'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)


So 19. Nov 2017, 02:51
Profil
Benutzeravatar

Registriert: So 9. Jan 2011, 09:18
Beiträge: 5877
Wohnort: Schwalmtal (Niederrhein)
Beitrag Re: Project MG Bordcomputer
MGF74 hat geschrieben:
9.11.: Voraussichtlich wird es jetzt aber die nächsten zwei Wochen erstmal nix neues mehr von dem Projekt geben. Quasi eine kleine "Winterpause".

10.11.: So, jetzt ist aber wirklich erstmal ne Weile "Projekt-Pause" :P

13.11.: Nachtdesign 8-)

16.11.: Schaltpunktanzeige :?

18.11.: Neustart mit anderer Systemhardware … :shock:

Lässt dich einfach nicht los, oder, Gerrit? Dieser MG-Mod Virus ist echt unheilbar. Selbst die rein elektronische Mutation. :up: :lol: :mrgreen:

_________________
MGF:
Mk1 MPI, HAM & Leder schwarz, LHD, 16.12.1997
MGTF:
TF 135 Monogram Spectre, RHD, 18.6.2004, Sommerfahrzeug


So 19. Nov 2017, 09:06
Profil
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 274 Beiträge ]  Gehe zu Seite Vorherige  1 ... 10, 11, 12, 13, 14


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
Powered by phpBB © phpBB Group.
Designed by Vjacheslav Trushkin for Free Forums/DivisionCore.
Deutsche Übersetzung durch phpBB.de