Jump to content
elektro-skateboard.de

Banana4fun


Kai

Empfohlene Beiträge

Geschrieben

Ich nenne jetzt vorerst so :-)

Untertitel: Banana du alte Frucht ich pell dich.

 

GIT Repositiory: git clone

Externe Links nur für Mitglieder sichtbar

Zip Download: .zip

 

Jeder der bereits einen GIT Zugang über SSH hat kann auch schreibend auf das Repository zugreifen.

 

Bis her gibt es nur eine Pseudo README und ein Bash-Script für die automatisierte Konfiguration des Bananas.

 

Der Thread hier dient zur Diskussion, Vorschläge und vor allem Mithilfe.

 

Offene Fragen

 

1.

Welches Image nehmen wir am Besten als Basis. In Fragen kommen nur welche die Debian als zurundeliegende Distribution verwenden.

Es stehen drei zur Auswahl: Lubuntu, Raspbian oder Bananian.

Ich habe als erstes zu Bananian gegriffen aber mir die anderen noch nicht genauer angesehen.

Ich glaube aber das Raspbian weiter verbreitet ist, wegen dem Raspberry PI.

Ist hier jemand der dazu schon mehr sagen kann?

 

2. Eigenes Image bootstrapen?

Ich bin mir noch nicht schlüssig ob wir ein eigenes Image bauen müssen/wollen oder ob es auch ausreicht unser APT Repository hinzuzufügen und die Konfiguration über apt-get install banana_setup4xxxx auszuführen.

Die Entscheidung hängt auch von der Klärung der Frage 1 ab. Bananian ist eine minimal Image und installiert nur was absolut notwendig ist. Das ist schonmal gut.

Eigene Images hätte den Vorteil das man es einfach nur runterladen und auf die SD-Karte spielen muss.

 

3. Für die Web-GUI würde es sich anbieten ein Framework zu verwenden?

Kennt da jemand zufällig das Beste wo gibt.

Sollte gleich auch für Smartphones was haben und eigene Elemente wie Slider, Gauges und so.

 

4. Wie kann ich einen Schalter am Banana anschließen und den Status abfragen?

Ich möchte drei zustände schalten können.

WLAN aus

WLAN im AP Mode

WLAN in Client Mode (verbinden mit eigenen Netzwerk)

 

 

ROADMAP

so oder so ähnlich sieht meine Roadmap aus.

Naja eine richtige Roadmap ist es nicht, eher der Versuch die Entwicklung der Features in eine Reihenfolge zu bringen die Sinn macht.

 

v0.1.0

Grundkonfiguration des Systems (Bash, Tools, Lokalisierung, BananaPro spezifische Einstellungen ...)

 

WLAN

Der Banana wird so konfiguriert das er einen AP aufmacht

wenn er keine bekannte SSID von einem WLAN-Netzwerk findent für das er als Client konfiguriert ist.

Ist man zuhause verbindet er sich automatisch mit dem Heimnetz und hat so auch Internet.

 

GPS

Zeitsynchronisation über GPS

Geo-Daten auslesbar, vorbereitung für späteres Logging.

 

v0.2.0

Dummy Webinterface

Einstellungen des Banana Pros über Webinterface

 

v0.3.0

Anbindung Teensy, Telemetriedaten auslesen und im Webinterface als Live Ansicht anzeigen.

Einfache Logging Funktion

 

v0.4.0

Erweitertes Logging.

Chronologische Ansicht der gespeicherten Daten.

 

v1.0.0

Alle bisherigen Features funktionieren Stabil.

 

 

v1.0.0

Konfiguration des Teensy Controllers über CLI

 

v1.1.0

Konfiguration des Teensy Controllers über Web-GUI

 

...

 

Spielereien wie Hupe über Audio-out mit konfigurierbare Sounddatei.

Sprachausgabe

...

 

 

So der grobe Verlauf, es gibt aber noch ein paar "unbekannte" die in der Roadmap nicht berücksichtigt sind.

Geschrieben

WiringBP installieren

apt-get install git-core sudo make gcc libc6-dev libc-dev
git clone https://github.com/LeMaker/WiringBP.git -b bananapro
cd WiringBP
chmod +x build
./bulid

 

Testen:

gpio -v

gpio version: 2.20
Copyright (c) 2012-2014 Gordon Henderson
This is free software with ABSOLUTELY NO WARRANTY.
For details type: gpio -warranty

Banana Pro Details:
 Type: Banana Pro, Revision: 1.2, Memory: 1024MB, Maker: LeMaker 


gpio readall
+-----+-----+---------+------+---+--Banana Pro--+---+------+---------+-----+-----+
| BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
|     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
|   2 |   8 |   SDA.1 | ALT5 | 0 |  3 || 4  |   |      | 5V      |     |     |
|   3 |   9 |   SCL.1 | ALT5 | 0 |  5 || 6  |   |      | 0v      |     |     |
|   4 |   7 | GPIO. 7 |   IN | 0 |  7 || 8  | 0 | ALT0 | TxD     | 15  | 14  |
|     |     |      0v |      |   |  9 || 10 | 0 | ALT0 | RxD     | 16  | 15  |
|  17 |   0 | GPIO. 0 | ALT4 | 0 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
|  27 |   2 | GPIO. 2 | ALT4 | 0 | 13 || 14 |   |      | 0v      |     |     |
|  22 |   3 | GPIO. 3 | ALT4 | 0 | 15 || 16 | 0 | IN   | GPIO. 4 | 4   | 23  |
|     |     |    3.3v |      |   | 17 || 18 | 0 | IN   | GPIO. 5 | 5   | 24  |
|  10 |  12 |    MOSI |   IN | 0 | 19 || 20 |   |      | 0v      |     |     |
|   9 |  13 |    MISO |   IN | 0 | 21 || 22 | 0 | ALT4 | GPIO. 6 | 6   | 25  |
|  11 |  14 |    SCLK |   IN | 0 | 23 || 24 | 0 | IN   | CE0     | 10  | 8   |
|     |     |      0v |      |   | 25 || 26 | 0 | IN   | CE1     | 11  | 7   |
|   0 |  30 |   SDA.0 | ALT4 | 0 | 27 || 28 | 0 | ALT4 | SCL.0   | 31  | 1   |
|   5 |  21 | GPIO.21 |   IN | 0 | 29 || 30 |   |      | 0v      |     |     |
|   6 |  22 | GPIO.22 | ALT4 | 0 | 31 || 32 | 0 | ALT4 | GPIO.26 | 26  | 12  |
|  13 |  23 | GPIO.23 |   IN | 0 | 33 || 34 |   |      | 0v      |     |     |
|  19 |  24 | GPIO.24 |   IN | 0 | 35 || 36 | 0 | IN   | GPIO.27 | 27  | 16  |
|  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | IN   | GPIO.28 | 28  | 20  |
|     |     |      0v |      |   | 39 || 40 | 0 | IN   | GPIO.29 | 29  | 21  |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
+-----+-----+---------+------+---+--Banana Pro--+---+------+---------+-----+-----+

 

Links:

Externe Links nur für Mitglieder sichtbar

Geschrieben

Der Schalter für das WLAN soll den Modus durchschalten.

Jedes Mal wenn der Zustand vom PIN von LOW auf HIGH wechselt wird in den nächsten Modus gewechselt.

1. AUS

2. WLAN-AP

3. WLAN-Client

 

Mal sehen wie man die Überwachung des Schalters macht.

Ob man das jetzt am besten mit gpio macht oder doch mit inotify bzw. iwatch die virtuelle Datei des GPIO Ports auf Änderung überwacht. /sys/class/gpio/...

Geschrieben

Betriebssystem: Bananian würde ich favorisieren. Der Raspberry hat einen anderen ARM-Prozessor. Da müssen wir uns nicht orientieren.

 

Akkuüberwachung:

Externe Links nur für Mitglieder sichtbar

 

Wiring Pi:

 

I2C:

 

40 Pin Anschluss:

 

 

Zeitsynchronisation GPS ist mit NTP total easy

Geschrieben
Der Schalter für das WLAN soll den Modus durchschalten.

Jedes Mal wenn der Zustand vom PIN von LOW auf HIGH wechselt wird in den nächsten Modus gewechselt.

1. AUS

2. WLAN-AP

3. WLAN-Client

 

Mal sehen wie man die Überwachung des Schalters macht.

Ob man das jetzt am besten mit gpio macht oder doch mit inotify bzw. iwatch die virtuelle Datei des GPIO Ports auf Änderung überwacht. /sys/class/gpio/...

 

Hier würde ich kein Durchtasten favorisieren, sondern absolute Einstellungen, da was man was man hat (oder wollte).

Geschrieben

espeak -vde "wlan verbunden! ei pie ist: $(hostname -i)" --punct="."

 

espeak -vde "accesspoint gestartet! ei pie ist: $(hostname -i)" --punct="."

 

espeak -vde "wlan aus!"

Geschrieben (bearbeitet)

Video:

Externe Links nur für Mitglieder sichtbar

 

Das Script dazu funktioniert auch schon inkl. Konfiguration der Netzwerkschnittstelle und dem Umschalten des WLAN Mode.

 

Als nächstes mache ich das Setup Script fertig.

 

Modul NEO-6 GPS Modul funktioniert auch. Loggen der Daten im gpx Format auch.

Das möchte ich aber noch in mysql bringen damit man es dort zusammen mit den Telemetriedaten abfragen kann.

bearbeitet von Kai
Geschrieben
Cool,

 

das hört sich ja schon fast ein wenig nach Max Headroom an.

( Kennt Du den ?? Der ist noch aus dem letzten Jahrtausend )

 

gRuss Ralf

 

Hey natürlich! Keine Frage, wer denn nicht?

Geschrieben

zu meinen Eingangsfragen nochmal:

1. Welches Image nehmen wir

Also ich bin immer noch bei bananian weil es ein minimal System ausgeliefert wird.

Gute Ausgangsbasis für eigene Anpassungen.

Raspbian hatte ich kurz mal gebootet. Da müsste man halt alle Pakete die man nicht möchte "purgen" was aber kein Problem ist wenn man die erst mal festgelegt hat.

Lubuntu hab ich mir noch nicht angesehen.

 

2. Eigenes Image bootstrapen?

Meine aktuelle Idee ist es das ein original Image zu nehmen und anzupassen (siehe unten gemu chroot)

Das heißt es braucht ein paar Scripte die das original Image automatisiert anpassen.

Im GIT ist das aktuelle Script, welches noch eher als Notiz in Bashscript form betrachtet werden soll :)

Ich möchte am Ende ein komplett vorkonfiguriertes Image anbieten sowie die manuelle Installation über das APT-Repository.

 

3. Für die Web-GUI würde es sich anbieten ein Framework zu verwenden?

Es gab und gibt da schon mehrere Projekte für den Raspberry. Sehr tief bin ich da nicht eingestiegen aber Ideal wäre ein Bananian-WebGui das man mit Add-Ons erweitern kann.

Diese WebGui wäre dann für das Setup des Systems und für den EBoardcontroller.

Eine zweite WebGUI fürs Fahren.

 

4. Wie kann ich einen Schalter am Banana anschließen und den Status abfragen?

Han ich bereits gelöst. Leider erstmal nur mit "Polling" (while schliefe, status abfragen, sleep Kombination) Da das mit inotify und dem sys-fs nicht so funktioniert wie mit richtigen Filesystemen. In der Endfassung soll das noch mit Interuppt gelöst werden. Muss da mal ein Feature request stellen an den WiringPi Entwickler. Er schreibt zwar wie man das Programmiert, hat das aber (scheinbar) in seinem gpio cli tool nicht eingebaut.

 

 

 

kurzes Update was bereits funktioniert:

 

- per script Hardware auf bananapro einstellen

- Powerbutton fährt Bananian runter (ACPI)

- Blinkende Grüne LED abschalten. Blinkt nur noch während dem Booten

- wiringBP per script runterladen und kompilieren

- GPS Modul - Tracks als .gpx speichern

- GPS Modul - Uhrzeit per GPS abgleichen

- Soundausgabe

- Sprachausgabe

- teensy flashen über Shell

- wlan umschalten per Script

- wlan umschalten per (gpio) Button

 

Das alles muss noch schön ordentlich in .deb Pakete verpackt werden die dann über unser (noch zu erstellende) apt repository geladen werden können.

Dazu ein Meta-Paktet das alles in einem Rutsch installiert.

 

wie man angepasste Images erstellen kann hab ich auch schon raus:

Mit einem "qemu architectural chroot"

Genial simpel.

#!/bin/bash

BCH=$HOME/banana_chroot

mount -t ext4 -o loop,offset=$((512 * 104448)) bananian-1501.img $BCH

cp /usr/bin/qemu-arm-static $BCH/usr/bin/

cd $BCH
mount -t proc /proc proc
mount -o bind /dev dev
mount -o bind /dev/pts dev/pts
mount -o bind /sys sys
chroot . /bin/bash

Das reicht um ein chroot auf die root Partition des original bananien Image zu machen und dabei den ARM Prozessor zu emulieren.

 

Das Script ist "vereinfacht" (Offset hardcodiert) und funktioniert mit dem aktuellen 1501 Image.

Es wird noch ausgebaut so das es den Offset der Partition zur Laufzeit ausliest und berechnet.

 

Für eine saubere Build-Umgebung habe ich mir Wheezy in einer VirtualBox VM installiert.

Noch ein bisschen Feinschliff und Cross-Compiling einrichten, dann werde ich es veröffentlichen.

 

 

PS: Max Headroom war das coolste was damals lief :)

SAM_1296.JPG.2937f68a50508a09bc68dced029ccb46.JPG

Geschrieben

Hi Kai,

 

schönes Tempo, was du da vorlegst. Weiter so :thumbsup:

Also nächste Woche ist dann alles betriebsbereit?

 

Welches GPS-Modul hast du genommen?

 

Wie hast du den Teensy geflasht?

 

Habe mich in der letzten Woche mit KiCad auseinander gesetzt, musste leider viel umdenken, heißt aber nicht das es schlecht ist. Es ist halt alles woanders.

 

Viele Grüße

 

Barney

Geschrieben

Wow Ihr beiden seid schneller als der Blitz.

 

Also ein minimales Image um die benötigten Teile aufzubauen hat auf alle Fälle den Vorteil, das man alle zusätzlich benötigten Komponenten kennt und bewusst benutzt.

Man wird also nicht davon überrascht, wenn irgendwelche vorinstallierten Komponenten aus einem "Luxusimage" in einer neueren Version verschwinden.

 

Die Idee den Kernel mit Inotify das Filesystem auf Veränderungen zu überwachen ist eigentlich prima. Ich denke aber, das Du dazu einen Wechsel von dem Staus des Filedescriptors brauchst. Also z.B. einen "Datei wurde gerade verändert und geschlossen" oder " Datei wurde gerade zum lesen geöffnet".

Wenn sich jetzt in der geöffneten Datei gerade ein Bit ändert wird der Inotify noch kein Event abliefern.

 

Was für eine Kernel Version hat den das Banaian.

 

gRuss Ralf

Geschrieben (bearbeitet)
Welches GPS-Modul hast du genommen?

Das Crius NEO-6 GPS. Ich würde beim nächsten Mal wahrscheinlich eins nehmen mit Timepluse / PPS Ausgang.

IMG_7123.thumb.JPG.5e64e6e8c143f88003ddfbf6a3048fe7.JPG

Das erspart das Anlöten eines extra Kabels.

PPS braucht man anscheinend weil die Genauigkeit des Zeitstempels über GPS nicht so toll sein soll. Hab da noch keine Tests gemacht.

Das PPS Kabel ist zwar schon angelötet aber ich habe erstmal nur das GPS Signal in den NTPd gebracht. Mal sehen... ob man PPS zwingend braucht.

 

Wie hast du den Teensy geflasht?

Zuerst das CLI Tool kompliliert und udev rule für den Teensy hinzugefügt.

Wie genau steht in gescripteter Form im Abschnitt

######################################

# Teensy Loader

######################################

in der bananian_mod.sh im git

 

Dann hab ich

Externe Links nur für Mitglieder sichtbar
runtergelden.

 

In den Teensy laden geht dann so

 

schnelles Blinken:

teensy_loader_cli -mmcu=mk20dx128 -v -w blink_fast_Teensy31.hex

 

langsames Blinken:

teensy_loader_cli -mmcu=mk20dx128 -v -w blink_slow_Teensy31.hex

 

Usage: teensy_loader_cli -mmcu=<MCU> [-w] [-h] [-n] [-v] <file.hex>
 -w : Wait for device to appear
 -r : Use hard reboot if device not online
 -n : No reboot after programming
 -v : Verbose output

<MCU> = atmega32u4 | at90usb162 | at90usb646 | at90usb1286 | mk20dx128

For more information, please visit:
http://www.pjrc.com/teensy/loader_cli.html

 

Für den 3.1er Teensy müsste eigentlich mk20dx256 die richtige Angabe für -mmcu sein. Der Test hat aber auch so funktioniert. Man muss da aber im Hinterkopf behalten und ggfls. den Paul fragen wenn das mit größeren Files probleme machen sollte.

 

Debian Paket für teensy_loader_cli hab ich erstellt, ist im Anhang.

Das soll später mal ins Repository rein.

dpkg -i teensy-loader-cli_2.1_armhf.deb

installiert teensy-loader-cli nach /usr/bin und schreibt die udev rules in /etc/udev/rules.d/49-teensy.rules

 

 

Die Idee den Kernel mit Inotify das Filesystem auf Veränderungen zu überwachen ist eigentlich prima.

 

Hat auch funktioniert als ich die Zustände noch per echo geändert hatte :)

echo "1" > /sys/class/gpio/gpio17/value

Als ich den Button angeschlossen hatte änderte sich zwar der Wert aber Inotify bekam das nicht mit.

Jetzt hab ich

inotifywait -qq -e modify /sys/class/gpio/gpio17/value

erstmal ersetzt durch

while [ `gpio -g read 17` = 0 ]; do
 sleep 0.1
done

Ist gar nicht schön aber schön wenn man etwas Verbesserungpotential für die Zukunft aufheben kann. ;-)

 

Was für eine Kernel Version hat den das Banaian.

 

uname -a
Linux bananapi 3.4.104+ #1 SMP PREEMPT Thu Jan 8 15:40:40 CET 2015 armv7l GNU/Linux

IMG_7122.thumb.JPG.d1949dcf22be41c22cf799f1aba0eb56.JPG

teensy-loader-cli_2.1_armhf.deb

bearbeitet von Kai
Geschrieben

Hallo Kai,

wenn Du mit echo in eine Datei/Gerätedatei schreibst dann öffnest Du die Datei zum schreiben, schreibst etwas hinein und schliesst die dann wieder.

 

Wenn du von aussen den Wert verändert, dann schliesst Du die Datei dabei nicht. Den verändeten wert würde inotify erst nach dem schliessen der Datei mitbekommen.

( Wenn du da mit ein Backup steuern oder neue Dateien versenden willst, dann möchtest Du das ja auch erst machen wenn die Datei vollständig geschrieben wurde)

 

Na ein 3.4er ist ja schon ein relativ moderner. Das müsste da ja schon relativ gut in den Kernel integriert sein.

 

gRuss Ralf

Geschrieben

Cool, möchtest du bei der Bananian Konfiguration / Programmierung für das Projekt einsteigen?

 

Für's Flashen ganz normal über USB.

Mehr habe ich noch nicht gemacht, also keine Telemetriedaten ausgelesen.

 

 

@barney wie machen wir das denn jetzt?

Sollen wir auf dem Bananapro zwei GPIO Pins zur Kommunikation zw. Teensy und Banana konfigurieren oooder geht das etwa auch über die USB Verbindung?

Geschrieben
Cool, möchtest du bei der Bananian Konfiguration / Programmierung für das Projekt einsteigen?

 

Für's Flashen ganz normal über USB.

Mehr habe ich noch nicht gemacht, also keine Telemetriedaten ausgelesen.

 

 

@barney wie machen wir das denn jetzt?

Sollen wir auf dem Bananapro zwei GPIO Pins zur Kommunikation zw. Teensy und Banana konfigurieren oooder geht das etwa auch über die USB Verbindung?

 

Beide!

 

Die Serielle Kommunikation über den Umweg Bluetooth am Teensy und Bluetooth-Stick im Banana. Die zweite Möglichkeit sollte die USB-Verbindung sein. Diese wird Teensy seitig wie eine Serielle Schnittstelle gehandhabt. Mit der USB-Verbindung kann dann auch der Teensy geflasht werden. Ich hätte aber nicht vor den Banana mit den Teensy ins Board zu quetschen.

 

Hinweis! Die USB-Verbindung zwischen Teensy und Banana darf nicht die 5V koppeln!

Geschrieben (bearbeitet)

du sagst Beide aber GPIO erwähnst du nicht :D

 

1. BT

2. USB

3. GPIO Serial

 

ok also brauchen wir kein GPIO Serial Port, das ist cool.

Das heißt wir können den Teensy Flashen über die USB Verbindung, können die Telemietrie Daten auslesen und können Daten für das Setup der Motorsteuerung an den Teensy senden.

 

Wenn du noch eine Bootloader Jump Funktion einbaust braucht man den Button auf dem Teensy nicht drücken zum Flashen.

Externe Links nur für Mitglieder sichtbar

Dann können wir auch Teensy updates über das Repository ausrollen und automatisiert flashen.

 

5V Koppeln?

Was meinst du damit? USB Port hat doch 5V Betriebsspannung?

 

Ich hätte aber nicht vor den Banana mit den Teensy ins Board zu quetschen.

Ich schon, da der ja alles Loggen soll.

bearbeitet von Kai
Geschrieben
Das mit den 5V kapier ich nicht was du meinst.

Wie schließt du den Teensy denn an den PC an zum flashen?

 

Entschuldigung Langfassung:

 

Wenn du das derzeitige namenlose Teensyboard hast, bekommt der Teensy seine Spannung vom Spannungsregler der Platine. Wenn du dann einen weitere Quelle anschließt, also die 5V über USB, besteht die gute Möglichkeit den Teensy dabei zu killen. Es darf nur eine geben! (Spannungsquelle)

Geschrieben (bearbeitet)

jetzt hab ich's geschnallt :)

 

Dann nehmen wir beim USB Kabel die Kabel für VBUS und GND raus und gut ist?

Und so ein Kabel hast du dir gemacht zum Flashen? Oder trennst du den Teensy vorher vom Barney Board Controller

bearbeitet von Kai
Geschrieben
Cool, möchtest du bei der Bananian Konfiguration / Programmierung für das Projekt einsteigen?

 

Ich werd damit erst einmal versuchen zu verstehen, was ihr da treibt :o

Geschrieben
jetzt hab ich's geschnallt :)

 

Dann nehmen wir beim USB Kabel die Kabel für VBUS und GND raus und gut ist?

Und so ein Kabel hast du dir gemacht zum Flashen? Oder trennst du den Teensy vorher vom Barney Board Controller

 

Aber ich nicht mehr!

 

Externe Links nur für Mitglieder sichtbar

 

So weit wie ich verstanden habe, wird der USB-Port erst aktiviert wenn VRegin die 5V vom USB-Anschluss bekommt. In diesem Moment springt der Teensy interne Spannungsregler an und versorgt den Vout33 Ausgang mit einer geregelten Spannung. Paul hat Vout33 und Vdd miteinander verbunden. So dass wie auf Seite 114 beschrieben, der gesamte Teensy mit einer Spannungsquelle (3.3V) versorgt wird. Dies passt natürlich nicht zur Situation, dass die 3.3V schon vom LC78_03 kommt. Jetzt ist die Frage, wie der interne Spannungsregler arbeitet.

 

Ab Seite 112:

 

 

Fazit:

 

Wer vor hat, denn Teensy am Banana Pro zu betreiben, sollte die Spannungsversorgung der TeensyBoard Leiterplatte nicht mehr über den LC78_03 erfolgen. Einfach den Spannungsanschluss abziehen. Der Teensy ist in der Lage sich selbst und das Bluetooth Modul, durch die 5V des Banana Pro, zu versorgen. Die LEDs und den Optokoppler natürlich auch. Im zweiten Betriebszustand, Banana Pro im Rucksack, ist durch die Funkschnittstelle Potentialfreiheit zwischen den Teensy und Banana Pro gegeben. :D

Geschrieben

So auf die schnelle überflogen find ich auch erstmal nur "Spuren" denen man weiter nachgehen kann.

 

Was ist damit:

Externe Links nur für Mitglieder sichtbar

Rechts oben: Cut to separate VIN from VUSB...

Ist das nicht das was wir brauchen?

Tritt dem Gespräch bei

Du kannst jetzt posten und dich später registrieren. Wenn du bereits einen Account hast kannst du dich hier anmelden.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...