Bitte um Hilfe für RaspberryPi per Kabel am Notebook

Das Raspberry Pi mit seinen 2 UARTs als UART-Recorder für die eine oder andere Platine zu nutzen sollte doch gehen. Dachte ich - sozusagen das RPi als Protokollator. Es gibt ja das schöne, ausführliche Tutorial von Kampi zum RPi und Kampi selbst hatte mir zwischendurch auch ein paar Hinweise gegeben - vielen Dank für Beides.

Also will ich als Linux-Newbie (absoluter Newbie in Linus, aber nicht direkt ein Noob) das RPi ingang setzen, da grad ein bisschen Leerlauf da ist.

Meine Aufgabenstellung:
1) RPi ingang setzen
2) RPi per Kabel am Notebook betreiben,
... d.h. RPi ohne Tastatur/Maus/Monitor, mit
... SD 8GB, 2013-02-09-wheezy-raspbian.img
... am Notebook: WIN7, Ethernet-Kabel, PuTTY
3) RPi für Allein-Sofortanlauf einrichten
4) UART-einlesen = Einlesestrings
5) Einlesestrings fortlaufend in einem File speichern
6) Zeitstempel für Einlesestrings generieren
7) Wie 5) aber Strings mit vorgespannten Zeitstempel

Problem:
Ich hänge schon bei 2.

Was bisher geschah.
- Mein "normaler" Monitor mit DVI-Anschluss (Fujitsu-Siemens SCENICVIEW A19-2A) funktioniert mit HDMI-DVI-Kabel am RPi selten, das nervt.
- Der TV läuft mit dem normalen HDMI-Kabel am RPi zuverlässig.
- Punkt 1) funktioniert.
- Vorbereitungen zu 2) nach Kampis Tutorial "Embedded Linux Einstieg leicht gemacht" bis zu "Ändern von Hostname und IP", in meinem Fall nur statische IP, geht nicht. Ich komme bis zum Ändern von '/etc/network/interfaces", lösche dort die DHCP-Zeile und edidtiere nach der Tutorial-Empfehlung ein:
"Diese muss wie folgt editiert werden.
iface eth0 inet static
--- address 192.168.0.100
--- network 192.168.0.0
--- netmask 255.255.255.0
--- broadcast 192.168.0.255
--- gateway 192.168.0.1"

Das geht, wird weggespeichert, beim Neuladen (ohne shutdown von RPi) ist auch alles da wie es das Terminal vorschreibt.

Jetzt $ sudo shutdown now -r

und nach der üblichen Anmeldung kommt mit:
$ ip addr

brrrrrrrrrrrrrrrr!! mal die letzen paar Zeilen:
$ ip addr
1: lo: <LOOPBACK> ntu 16436 qdisc noop state DOWN
----link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO_CARRIER,BROADCAST;MULTICAST;UP> mtu 1500 qdisk pfifo_fast state DOWN qlen 1000
----link/ether b8:27:eb:f0:6a_4e brd ff:ff:ff:ff:ff:ff
pi@raspberypi ~ $ _

War gestern Nacht so, ist heute noch so, obwohl ich DHCP-Zeile entfert hatte und GENAU den Text von Kampi übernommen hatte:
"
iface eth0 inet static
----address 192.168.0.100
----network 192.168.0.0
----netmask 255.255.255.0
----broadcast 192.168.0.255
----gateway 192.168.0.1
"

Die von mir eingetragenen Adressen sind also nicht übernommen worden. Dadurch ist es mir auch nicht möglich, mit PuTTY das am Notebook mit Ethernetkabel hängende RPi anzusprechen - ich hab ja keine existierende Adresse fürs PuTTY . . .


Bitte um Hilfe. Oder notalls auch den Ratschlag: lass es :-/

Was hast du denn für ein Betriebssystem auf dem Raspberry Pi? Raspbian?

Bewegst du dich nur in der Konsole, oder hast du eine grafische Oberfläche? Falls ersteres, gib mal "startx" in der Konsole ein und probiere, ob du grafisch weiter kommst.

Im übrigen musst du nicht neustarten, um neue Netzwerkeinstellungen zu übernehmen. Es müsste auch mit "/etc/init.d/networking restart" funktionieren. (müsste, weil ich grad vor keinem raspbian sitze und mir nicht 100% sicher bin. Aber wenn der Befehl "etwas" macht, ist es der richtige)

Zitat:

---

Zitat von -schumi-

Was ... für ein Betriebssystem ... Raspbian? ... musst du nicht neustarten ...

---

Danke - und sorry für die Nachlässigkeit: ich habe das 2013-02-09-wheezy-raspbian.img , das hat der Win32DiskImager auf die SD-Karte geschaufelt. Trage ich gleich oben noch nach. Den Rest probiere ich mal.

Mit der graphischen Oberfläche komme ich mal ein bißchen weiter: mittlerweile habe ich nach ip addr wenigstens u.a.
inet 192.168.0.100/24 brd...
das stimmt also mit meiner Eingabe überein.

NUR auf
sudo mv /boot/boot_enable.ssh.rc /boot/boot.rc
bekomme ich die Antwort
mv: cannot stat '/boot/boot_enable.ssh.rc /boot/boot.rc' : No such file or directory

... und das PuTTY (am LAN-Kabel) findet auch keine Reaktion/Verbindung.

Trotzdem danke für Deine Mühe. ETWAS bin ich ja weiter!

Nachtrag: nach dem Verlassen der graphischen Oberfläche gabs wieder keine "Erinnerung" an die Änderungen. Also wieder startx und da steht in networks:

default 0.0.0.0
loopback 127.0.0.0
link-local 169.245.0.0

:-/

Nach exit GUI und ip addr kommt wieder so ein ähnlicher (habs nicht verglichen) Text wie anfangs, hier wird das
inet 192.168.0.100/24 brd ...
nicht mehr gezeigt.

Ich hab mal kurz gegoogelt und anscheinend ist das mit dem "mv..." nicht mehr aktuell. Versuche mal "sudo raspi-config", dort sollte es entsprechende Optionen geben um SSH zu (de)aktivieren.

broadcast und network habe ich nicht in meiner config.

Code:

---

auto lo

iface lo inet loopback
iface eth0 inet static
address 192.168.2.38
netmask 255.255.255.0
gateway 192.168.2.1

---

Mit welchem Editor bearbeitest Du die Dateien?

Ich bin immer als root angemeldet. Bist Du nicht root, dann brauchst Du sudo.

sudo nano /etc/network/interfaces

Falls Du eine Fritzbox oder einen Linux NAS hast, dann sollte die SD-Karte auch in einem Kartenleser darüber erreichbar sein. Dann die Datei einfach mit Notepad++ direkt bearbeiten. Als Sprache einfach Shell einstellen, dann passen die Zeilenendezeichen.

Die Dateien unter /boot sind auf der ersten Partition der SD-Karte und direkt unter Windows zugänglich. Da einfach beide Dateien umbennen.

Wie man die Grundvorraussetzungen für UART schafft, steht auch in meinem Internetradio Tutorial.

Du musst aufpassen.
Alle Verzeichnisse die vom Verzeichnissbaum UNTER /home/pi sind, kannst du nicht mit dem User Pi betreten/ändern.
Dafür brauchst du den root/sudo.
Wenn du die Datei in der Konsole öffnest....speicherst du die dann auch mittels Strg + X und anschließend mit j/y (je nach Layout) bestätigen?
Weil sonst verwirfst du die Einstellungen wieder :)

Endlich.

Ein wesentlicher Tipp kam auf der maker faire. Und es läuft. Nicht zuletzt wegen dieses Blogs. So kann ich also bei der Spätnachmittags- /Frühabend- Sonne auf der Terrasse sitzen und mich über das RPi-Logo auf meinem Notebook freuen. Es läuft wirklich die Kommandozeilenvariante und die graphische Oberfläche prächtig und problemlos - aber ich tu ja auch nix - bisher. Inzwischen hängt der RPi am Router irgendwo in der kühlen Wohnung. Leider kommt der RPi-Grafik-Bildschirm als Vollbildformat über den ganzen Bildschirm bei mir an, das Teilbild ist dann auch wirklich nur ein Teil des Ganzen - wenn auch mit Scrollmöglichkeit. Da wäre mir eine geringe Reduzierung des vollen Bilds in einem Teilfenster des Notebooks lieber. Aber - es geht so auch.

Jetzt könntesolltewird es weiter gehen, da kommt der eher schwierige Teil der Arbeit (für den Linux-Noob-DAU): die serielle(n?) Schnittstelle(n) ingang setzen und den RPi als Protokollator nutzen, der mir Informationen von einer Platine fortlaufend und möglichst schnell in eine Protokolldatei schreibt. D.h. ich muss wohl ein Terminal mit Log-Möglichkeit/-Funktion unter Linux finden. Und wer weiß, vielleicht bekomme ich auch die Geschichte mit der Cam und der einfachen Bildauswertung hin. Man träumt an Sommerabenden eben.

Könnte mir bitte jemand ein paar Tipps geben? Besonders zum Thema UART (1 oder 2?) mit Schreiben in eine fortlaufende Protokolldatei. Jedenfalls danke für die Hilfe bisher.

Hey,

wie willst du den UART den verwenden (der UART ist als ttyAMA0 unter /dev verfügbar)? In C, Python, Shell etc.?
Ansonsten kann ich dich nur hier hin verweisen :)

http://kampis-elektroecke.de/?page_id=1682

Alternativ kannst du auch Python und das Modul "serial" verwenden:

$ apt-get install python-serial

Hier ist dann ein Python Programm, welches die beim Aufruf übergebenen Parameter per UART sendet:

http://kampis-elektroecke.de/wp-cont...ART-Python.zip

Zitat:

---

... wie willst du den UART den verwenden ...

---

Ich bin wieder mal am RasPi dran - an dessen UART.

Gibt es fürs RaspberryPi (evtl. Linux allgemein??) ein brauchbares Terminalprogramm (bin vom Terminal von bray recht verwöhnt). Damit will ich dann erste Erfahrungen mit dem UART beim Raspi machen mit Senden und Empfangen von UART-Sequenzen von und zu Controllern.

Ich benutze gern "minicom", wenn du es mit "minicom -s" aufrufst bekommst du auch ein Konfigmenü

Zitat:

---

Zitat von -schumi-

Ich benutze gern "minicom" ... auch ein Konfigmenü

---

Danke für die schnelle Antwort.

Ist das "minicom" auch auf der graphischen Oberfläche zu erreichen (ich fahre den RPi gern über remote desktop von meinem Notebook, eher weniger gern über Putty)?

Was ist der Unterschied zwischen microcom und minicom bzw. deren Vorteile bzw. Nachteile ?

Zitat:

---

Zitat von oberallgeier

Ist das "minicom" auch auf der graphischen Oberfläche zu erreichen

---

Ja, ist es. Öffne einfach ein Terminal (irgendwo im Programme-Menü versteckt) und gib "minicom" bzw. "minicom -s" ein (genauso wie wenn du über Putty auf dem Raspi bist)

Zitat:

---

Was ist der Unterschied zwischen microcom und minicom ?

---

Ich habe microcom noch nie benutzt, kann dir also keine genauen Details erklären.

Eine Auszug aus der Programmauswahl:
Im Terminal (kannst du also auch auf der grafischen Oberfläche nutzen, ist aber nicht so komfortabel wie mit Buttons etc.):

• minicom
• screen
• microcom

Mit grafischer Oberfläche:

• cutecom
• moserial
• gtkterm

Im Prinzip tun sie aber alle das Gleiche, nimm was immer dir am besten gefällt :)

Soweit ich das sehe ist minicom die Möglichkeit auf der Rechner zuzugreifen über ein Terminal - im Prinzip ähnlich wie über die Konsole, putty oder einfach Tastatur und Bildschirm.

ABER meine Absicht ist anders:

Aktueller Zustand: ich sitze am RasPi mit Tastatur und Bildschirm, meist über remote-desktop am Grafikbildschirm, ausnahmsweise putty.

Aufgabenstellung:
Kommunikation vom RasPi zum Mikrocontroller und zurück

Soweit ich das jetzt durchgehechelt habe mit minicom geht das damit nicht. Soweit ich das gelesen habe, muss sich der Nutzer der minicom-Verbindung am RasPi (auch) identifizieren - das sollte mein Kontroller nicht müssen. Oder bin ich zu bl..d - blind mein ich ! ? Die Aufgabenstellung entspricht etwa der von üblichen Terminalprogrammen, mit denen man vom Rechner aus dem Mikrocontroller Sequenzen schreibt oder von ihm UART-Ausgaben bekommt, bei Windows eben br@y-Terminal, evtl. HTERM oder so.

HA! Das neue Jahr fängt gut an (trotzdem wieder Fragen, siehe unten).

Auf dem raspi habe ich cutecom installiert und es läuft (derzeit noch ohne Hardwareinitialisierung der UART-Pinne). Vorlage von hier.

Konfiguration:
Notebook (WIN7 Home Prem) mit WLAN und remotedesktop als Ein-/Ausgabe fürs raspi
Raspberry Pi am Router mit LAN-Kabel

Das Fenster bekomme ich in der graphischen Oberfläche auf und es sieht gut aus, etwa so:

Bild hier  

Nicht notwendig - aber sinnvoll wäre es jetzt am Linux-Desktop einen Button zum Start des cutecom zu haben - das krieg ich schon mal nicht hin. Dagegen bin ich erstmal sicher, dass ich die serielle Schnittstelle hardwaremässig schaffe und wohl auch deren Installation in Linux.

Frage:
Wie bekomme ich einen Startbutton für cutecom auf den Raspi-Desktop ?

Danke für die Hilfen.

Hach verdammt, habe vergessen dir noch zu antworten #-o
Und ja, ich schätze du hast Recht; minicom unterstützt nur Terminalemulation und die kann man anscheinend nicht deaktivieren...


Cutecom geht aber auf jeden Fall, das habe ich selbst schon zur Kommunikation mit Mikrocontrollern verwendet.

Zu deiner Frage: Normalerweise ist cutecom jetzt schon in deinem Startmenü. Bei mir ist es in der Kategorie "Other" (allerdings benutze ich keinen LXDE-Desktop, es könnte bei dir also auch wo anders sein). Ich weis nicht ob das unter LXDE geht, aber du könntest dann versuchen einfach den Menüpunkt "CuteCom" auf den Desktop zu ziehen.

Wenn das nicht geht, kannst du das Startsymbol auch selbst auf den Desktop kopieren. Das was man unter Windows als "Verknüpfung" kennt, sind unter Linux Dateien, die auf ".desktop" enden, und die wiederum befinden sich alle im Ordner "/usr/share/applications/". Du kannst also Entweder mit einem Dateimanager die Datei "/usr/share/applications/kde/cutecom.desktop" auf deinen Desktop kopieren, oder zu machst es im Terminal:
"cp /usr/share/applications/kde/cutecom.desktop ~/Desktop/"

Danke schumi, nu läuft cutecom wie erhofft (noch ohne aktive Serielle).

Zitat:

---

... Cutecom geht aber auf jeden Fall, das habe ich selbst schon zur Kommunikation mit Mikrocontrollern verwendet ...

---

Prima zu wissen, dass dies läuft/laufen müsste.

Zitat:

---

... Normalerweise ist cutecom jetzt schon in deinem Startmenü. Bei mir ist es in der Kategorie "Other" ...

---

Other - gesucht, gefunden, cutecom (gibt zwei Symbole :-/ ) rübergezogen - nix. ABER da gibts noch die rechte Maustaste - deren flyout zeigt Add to desktop und Properties. Add lag nahe. Und eins von den beiden Symbolen akzeptierte einen Doppelklick mit nem Fenster "wie es erwartet wurde".

Danke!

Hallo oberallgeier,
falls bei dir das Problem der angezeigten Displaygröße immer noch aktuell ist:

ich bin dem Link aus Deinem Post#7 gefolgt und hab habe xrdp auf dem Pi installiert. Noch auf dem Rechner über Zubehör die Remotdesktpverbindung hergestellt...und dabei vorher einmal in die "Optionen einblenden" unten links geklickt - siehe da im Reiter Anzeige steht die Displaygröße auf "vollanschlag" als default.

Auch ohne in den configs die "Grafische Oberfläche" angewählt zu haben, kann ich mich nun über xrdp einlogen.
Vielleicht hilft es ja weiter.

Zitat:

---

Zitat von HeXPloreR

... falls bei dir das Problem der angezeigten Displaygröße immer noch aktuell ist ...

---

Danke HeXPloreR, das Problem (ist ja nur ne Schönheitsoperation gewesen) ist keins mehr. Ich habe im Windwos Remotdesktopfenster ne Einstellmöglichkeit gefunden.

Code:

---

Remotedesktopverbindung
Karteikarte /Anzeige/
Schieberegler aktuell "Groß"
      Teilbild z.B. mit 1280 mal 768 Pixel

---

Und das läuft sehr gut.

Aktueller Stand ist also:
- Raspi per LAN am Router mit fester Adresse
- Remotedesktop (oder Putty) vom Notebook (WIN7 Home Prem) über WLAN
- Remotedesktop startet automatisch incl. Benutzer- und Passworteingabe das GUI, also GENAU das, was ich immer wollte: das Notebook ist Bildschirm und Tastatur des (entfernten) Raspi.
- Putty startet mit einem üblichen Login - das geht so ok, da ich praktisch nur das GUI möchte.

ABER ich kriegs nicht hin, dass auch automatisch das Cutecom gestartet wird. Im Remotedesktopfenster (am Notebook, unter WIN7 habe ich eingegeben:

Code:

---

Karteikarte /Programme/
[x] Folgendes Programm bei Verbindungsherstellung starten

Programmpfad und Dateiname
[Cutecom    ]

Im folgenden Ordner starten:
[/home/pi/Desktop  ]

auch:
Programmpfad und Dateiname
[/home/pi/Desktop/Cutecom    ]

---

... und das startet das Raspi-GUI OHNE dass Cutecom gestartet wird - als stünde nix in der Remotedesktopeinstellung (im Notebook) :-/


Sorry wenn ich mich mit so vielen elementarenr Problemen an euch wende . . . aber Linux ist für mich einfach ein böhmisches Dorf.

Zitat:

---

Zitat von oberallgeier

ich kriegs nicht hin, dass auch automatisch das Cutecom gestartet wird. Im Remotedesktopfenster (am Notebook, unter WIN7 habe ich eingegeben:

Code:

---

Karteikarte /Programme/
[x] Folgendes Programm bei Verbindungsherstellung starten

Programmpfad und Dateiname
[Cutecom    ]

Im folgenden Ordner starten:
[/home/pi/Desktop  ]

auch:
Programmpfad und Dateiname
[/home/pi/Desktop/Cutecom    ]

---

... und das startet das Raspi-GUI OHNE dass Cutecom gestartet wird - als stünde nix in der Remotedesktopeinstellung (im Notebook) :-/


Sorry wenn ich mich mit so vielen elementarenr Problemen an euch wende . . . aber Linux ist für mich einfach ein böhmisches Dorf.

---

Also die Verknüpfung die du starten möchtest ist nicht das Programm, desshalb wird das (abgesehen davon dass die Verknüpfung cutecom.desktop heißt) nicht funktionieren. Das richtige Programm ist hier: /usr/bin/cutecom (auf Groß/Kleinschreibung achten!)

Was unter Linux in welchem Ordner ist kannst du auch hier nachlesen: http://wiki.ubuntuusers.de/Verzeichnisstruktur
Das ist zwar auf den ersten Blick recht zerstreut, macht aber auf den zweiten doch Sinn ;)

Zitat:

---

... die Verknüpfung ... ist nicht das Programm ... ist hier: /usr/bin/cutecom ... nachlesen ...

---

Danke -schumi-, es klappt, das cutcom-Fenster erscheint gleich beim Anwerfen des remote desktop. Zwar ist das GUI jetzt ne grau karierte Fläche, war bisher weiß, und die früheren Buttons fehlen, aber das cutecom-Fenster ist da.

Dumm wenn einem die grundlegensten Dinge fehlen und man kein Tutorial findet, nach dem man das versteht; jetzt hab ichs verstanden. Und der Link ist auch prächtig für tiefere Einblicke ins Linux.

Beim Stöbern bin ich über einen U S B zu T T L serieller U A R T-Wandler für den Raspi gestolpert. Nun stelle ich (mir, besser Euch) die Frage, warum ich das teure Teil kaufen soll, wo ich doch einen solchen U S B-nach-UART-Wandler dauernd nutze, um mit meinen Atmels von PC-gestützten Terminals zu kommunizieren. U S B ist doch U S B !? Nein, schon klar, da brauche ich noch nen Treiber dazu, der z.B. von FTDI geliefert wird oder von po lolu oder so - und der läuft (bei mir) nur auf Windowsrechnern.

Frage:
Kennt jemand dieses spezielle Raspi-Teilchen? Wie wird das am Raspi installiert? Läuft das einfacher/besser als die GPIO-RX-TX-Lösung am Raspi?

Hintergrund: da ich mein Raspi per remote desktop betreibe, sind beide U S B-Anschlüsse frei *gg*

Einziger Vorteil dieses Adapters ist, dass du keinen Pegelwandler von 3.3V auf 5V brauchst, da der GPIO-UART mit 3.3V läuft. (einen Pegelwandler kann man aber mit 2 Transistoren und 4 Widerständen bauen, da braucht es den Reichelt-Mondpreis nicht..)

Ansonsten bringt dir das nichts. Da brauchst du auch treiberbedingt keinen speziellen Raspi-Adapter, denn USB-Seriell-Wandler ist eine der Sachen, bei denen Linux Windows um Welten voraus ist, da sämtliche Treiber schon im Kernel eingebaut sind ;) (vorausgesetzt sie wurden nicht mit Absicht rausgeschmissen..).

Wenn du schon einen solchen Adapter hast, brauchst du den nur am USB anzustecken, schon erscheint im Ordner /dev (für Devices) eine Datei mit dem Namen ttyUSB0. Wenn du dann einen zweiten ansteckst ttyUSB1 usw.. Der GPIO Uart heißt /dev/ttyAMA0

Ahja, und wenn du den GPIO-Uart verwendest musst du vorher deaktivieren, dass Linux diese Schnittstelle als Terminal nutzt, sonst brabbelt es dir ständig dazwischen.. http://elinux.org/RPi_Serial_Connect...he_serial_port

Zitat:

---

... Vorteil ... dass du keinen Pegelwandler von 3.3V auf 5V brauchst, da der GPIO-UART mit 3.3V läuft ...

---

Ja, das hatte ich vermutet. Auch wenn mir der Aufbau des Pegelwandlers wirklich simpel erscheint.

Zitat:

---

... den GPIO-Uart verwendest musst du vorher deaktivieren ... sonst brabbelt es dir ständig dazwischen ...

---

So ungefähr hatte ich es auch aus den Installationsratschlägen verstanden. Danke für die Bestätigung.

Zitat:

---

... Wenn du schon einen solchen Adapter hast, brauchst du den nur am USB anzustecken ...

---

Ok, dann muss ich das mal versuchen. Irgendwie schön, dass mein Raspi allmählich in sinnvollen Betrieb kommt.

Zitat:

---

... am USB anzustecken, schon erscheint im Ordner /dev ... eine Datei mit dem Namen ttyUSB0 ...

---

Ok, auf gehts.

Für nen babyorangutan/328 ne kleine Testausgabe geschrieben : 'CR''Tab'#12345*, Ausgabe mit 1Hz, 115200, 8N1. Läuft am PC wunschgemäß.

Am RPi die /dev gesucht und gefunden, - - - ahh, da ist die /ttyUSB0 *freu*. Im cutecom als device eingetragen /dev/USB0 und die zugehörigen Parameter (gelassen, die waren schon ok) - und weder mit Stecker "linksrum" noch "rechtsrum" irgend etwas. :-/. Als Reaktion auf [Open device] kommt das Flyout : Could not open /dev/USB0 - - - noch mehr :-/.

Auch die Eingabe von "sudo stty 115200 -F /dev/ttyUSB0" auf der Konsole brachte anschließend keine Besserung. Diese Sequenz hatte ich mir auf meinem Linux-Spickzettel notiert unter "Ingangsetzen der seriellen Schnittstelle" - nur mit "AMA0" für die GPIO-Pinns statt jetzt "USB".

Ergebnis: deutliche Zweifel am Selbstbewusstsein.

MIST!
Es läuft jetzt - NACHDEM ich im cutecom die Schnittstelle mit /dev/ttyUSB0 eingetragen habe. Ist ja klar. Denn ich DACHTE anfangs nur, ich hätte da tty.. geschrieben . . .

Selbstbewusstsein ist wieder gestiegen!

Letzter Nachtrag zur "seriellen Schnittstelle" am RasPi - warum sehe ich unter "Serielle Schnittstelle" nur die Hinweise mit dem GPIO-Gepopel, wenns mit dem USB-UART-Adapter sooooo easy geht *kopfschüttel*. Dass ich so lange brauchte lag ja nur an meinen totalen Linux-Unkenntnissen.

Es geht weiter. Aufgabe: RasPi soll per WLAN-Stick arbeiten, das LAN-Kabel will ich endlich los sein mit diesem Lösungsansatz.

EDIMAX gekauft. Die Einbindung ins WLAN mithilfe der Ratschläge im genannten Link versucht. Ging erstmal nicht. Ich stelle fest, dass WLAN ohne WLAN-Adapter nicht läuft, mit schon. :-/ Und damit also wieder einen Schritt weiter.

Zur Kommunikation mit dem RasPi über WLAN zu meiner/meinen Platine/n.

a) eigentlich wollte ich die Kommunikation über RasPi-UART machen, also über dessen GPIO. 3,3V nach 5 Volt ist ja nicht soo schwer. b) Meine aktuelle Lösung finde ich wesentlich besser: USB<=>UART(TTL). In der Schublade sind mehrere von den Dingern, zwei davon auf FTDI-Basis, einer gekauft, eine selbst gelötet (der Schaltplan).

Einstecken im Raspi, im CuteCom (RasPi GUI-Terminalprogramm) die USB-Schnittstelle angewählt - und schon läufts ohne Pegelwandler und ohne Gefahr für die GPIOs des RasPi. Auch die atmeltragenden Platinen sind total zufrieden. Sehr empfehlenswert.

Was ich noch nicht getestet habe: mehrere USB-Adapter per Hub anschließen und mit mehreren Platinen "gleichzeitig" kommunizieren. Aber diese Möglichkeit behalte ich im Auge.

Das CuteCom läuft gut und ich kann über WLAN+RasPi+USB-UART meine Platinen steuern. Läuft bestens. Dumm, dass es das HT (ASCII 09) nicht dekodieren kann. Weiß jemand ob es dazu einen Schalter gibt - ich habe den nicht gefunden.

Beispielhafte Anzeige vom CuteCom in den unteren vier Zeilen. Im Terminal von br@y steht kein \0x09, da wird wirklich ein Tabulator geschaltet. Sieht halt im CuteCom jetzt etwas ungewöhnlich aus - gewöhnungsbedürftig. Und ich würde das gerne ändern.

\0x09Kmd: d,Mnvkk,W,Z0,(Tn)
\0x09KOMM MOST erkannt
\0x09Regeltest sspeed = 30
\0x09IZdiff0/1 = 84/82\0x09KOMM MOST erkannt

Danke im Voraus für die Hilfe.

Für mich unerklärlich ist eine gestörte WLAN-Verbindung zum RasPi bei "gemeinsamer" Stromversorgung.

Aufbau:
Master-Slave-Verbund mit RNControl/M1284-20MHz als Master.
Drei Slaves aktiv, einer davon MotorControl mit RN-VN2_DualMotor/m328/20MHz.
Zwei Motoren - im Test gelegentlich lastlos laufend, dann nur ca. 0,2A/13,2V.
RasPi mit EDIMAX-WLAN-Stick und FTDI-UART - Verbindung zum Master 115,2kBd.

Spannungsversorgung:
Gesamtbedarf des Aufbaus ca. 1A, etwas mehr bei langsam laufenden Motoren.
A) 13,2V-Block, laut Datenblatt "Maximum Continuous Discharge 50A" für >Alles<
B) 13,2V-Block wie vor für alles ausser RasPi, 9,9V-Block max-50A für RasPi
Die Versorgung des RasPI geht über 78S05 hinter einer 2A-Diode. Die Spannung wurde kontrolliert (ohne Oszilloskop), sie ist ruhig und stabil bei ca. 5,05^±0,1 V.
C) Ähnlich wie A) und B) aber teils Netzteile und teils Akkublocks/Netzteile gemischt.

Problem:
Bei getrennter Versorgung des RasPi ist WLAN/remote desktop einwandfrei aktiv, es können UART-Telegramme vom PC über remote desktop vom RasPi an den Master gesendet werden, die werden per TWI z.B. an die MotoControl weitergeleitet. Alles nach Plan, egal ob Motoren laufen oder nicht. GND ist verbunden.
Bei gemeinsamer Versorgung von Raspi und Rest-Aufbau ist der Wlanempfang vorzugsweise gestört, gelegentliches Aufflackern der WLAN-Anzeige am EDIMAX-Stick. WLAN/remote desktop ist sehr selten aktivierbar, stürzt meist gleich ab. GND ist hier erst recht verbunden *ggg*.

Knapp ausgedrückt: bei gemeinsamer Versorgung der Platinen UND des RasPi ist WLAN-Empfang gestört, bei getrennter Versorgung ist alles ok.

Frage:
Was ist als Ursache für den gestörten WLAN-Empfang denkbar? Spannungseinbrüche können es schlecht sein, die Kabel sind für mehrere Ampere gut.

Danke für eure Hilfe.

Kann es sein dass du die Versorgungsspannung doch irgendwie zum "schwingen" bringst? Hängt sonst was am Usb vom Raspberry? Wo speist du die 5v für den Raspberry ein, am MicroUsb oder über die GPIO?
Joa das war erstmal alles was mir einfällt...

Zitat:

---

Kann es sein dass du die Versorgungsspannung doch irgendwie zum "schwingen" bringst? ...

---

Genau das fürchte ich, obwohl ich einen völlig gesonderten Spannungsregleraufbau (78S05, Kondensatoren) benutze. Ich werde das prüfen.

Zitat:

---

... Hängt sonst was am Usb vom Raspberry? ...

---

Es sind beide Anschlüsse belegt: EDIMAX-WLAN-Stick und FTDI-UART für Verbindung zum Master 115,2kBd. Und WENN der RasPi-Hub zwei Anschlüsse hat, so sollten die ja beide nutzbar sein.

Zitat:

---

... Wo speist du die 5v für den Raspberry ein, am MicroUsb oder über die GPIO? ...

---

Am MicroUSB.

Derzeit vermute ich, dass ich eben als Simpellösung, ohne weitere Fehlersuche, einen zweiten 9,9V/2,5Ah-Block nur für den RasPi besorge. Wollte eigentlich nur einen für die gesamte Controllerbestückung verwenden. Aber das ist kein Problem. Besser drei Blöcke mit Funktion als zwei mit Störung.

Vielleicht eine Störung von den Motoren ausgehend. Sind die Motoren ausreichend entstört? Oder vielleicht zu nahm am WLAN-Stick?

Hast Du denn schon den Gesamtverbarauch auch mit dem RasPi gemessen? - der alleine benötigt ja schon ca. 700mA + WLAN. Vielleicht bist Du bei dem 78S05 mit max 2A schon raus.

Danke Sebas, danke HeXPloreR für eure Ratschläge.

Zitat:

---

Vielleicht eine Störung von den Motoren ausgehend ... entstört? ... zu nah am WLAN ...

---

Die Motoren sind nicht entstört aber durch ein Metall-U (Motorträger) in Richtung RasPi abgeschirmt. Egal - das WLAN ist gestört d.h. es läuft nicht, auch wenn die Motoren still stehen, d.h. PWM auf 0 und beide Steuerpins gleiches Niveau. WENN die Versorgung des RasPi durch den separaten Block oder das separate Netzteil erfolgt -- jeweils mit rund 9,9V und Netzteil auf 3A limitiert -- dann läuft WLAN auch wenn die Motoren laufen und der RasPi zieht vom Netzteil (Netzteildisplay) rund 0,5 A. Das Netzteil-Amperemeter (bei meinen beiden Netzteilen) hatte ich vor ein paar Wochen mit dem DMM überprüft und für gut befunden.

Zitat:

---

... Gesamtverbrauch auch mit dem RasPi gemessen? ...

---

Ja, das sind die oben genannten ca 0,5A - RasPi inclusive FTDI-UART und EDIMAX - bei funktionierendem WLAN. Bei gemeinsamer Versorgung - die drei controllerbestückten Platinen UND das RasPi an einem Energiestrang, d.h. fehlerträchtige Konfiguration - liegt der Verbrauch um die 1A, etwa die Summe der Teilverbräuche bei Netzteilbetrieb an zwei getrennten Netzteilen.

Bin grad auf einem Kongress bis Fr, werde die Motorentstörung aber am Wochenende prüfen - oder besser die Motoren ganz abklemmen. Irgendwie stört mich ein entdeckter Fehler ohne bekannte Ursache.

Da dachte ich zum 6000er (Beitrag) Jubiläum könnte ich ne Antwort auf eine zwar einfache, aber auf den ersten Blick relativ einfache Frage finden. Warum eben der Raspi nicht mit anderen Controllern an einer gemeinsamen Versorgung zusammen arbeiten will, kann, tut. Na ja, er arbeitet, aber WLAN tuts nicht.

Egal ob mit oder ohne angeschlossene Motoren, es geht nicht. Stromaufnahme des Raspi-Zweiges gemessen - die ist sozusagen beliebig hoch - anfangs, wenn WLAN kurz aufflackert, bis knapp ein halbes Ampere. So viel wie eben der normale Verbrauch ist. Aber das Wlan stellt den Betrieb nach kurzen Wechselgefunke mit dem Router wieder ein und damit sinkt auch der Stromverbrauch. Ne separate Versorgung des Raspi bringts dann wieder.

Die Untersuchung auf Masseschleifen brachte auch nichts, eine masselose UART-Verbindung Raspi-Master ergab nur sinnloses Zeugs am Raspi-Terminal, sofern WLAN lief.

Fazit: Separate Versorgung des Raspi wird gestellt. Meine Frage ist nicht beantwortet aber eine technische Lösung ist realisiert. Eher unbefriedigend.

Die Lösung ist so simpel, dass es peinlich ist für mich.

Aktuell läuft das Raspi, mit WLAN-Dauerfeuer!!, am großen Akkublock seit rund eineinhalb Stunden störungsfrei. Am Steckbrett-Spann ungsregler, ein 7805 mit überkompletter Beschaltung, wurde ein Kühlkörper ca. 5cm x 5 cm von einer Pentium 1oder2oder3-CPU provisorisch angeklemmt. Beharrungstemperatur aktuell ca. 50°C. Keine weiteren Bemerkungen.

Weil du von Akkus schreibst: Den 7805 kannst du 1:1 durch den hier ersetzen: https://secure.reichelt.de/TSR-1-245...450&SEARCH=tsr Super wirkungsgrad und pinkompatibel. So versorge ich auch meinen Pi auf dem RP6 (und inzwischen auch den RP6 selbst).

Auf dem Archie habe ich als simple WLAN-Anbindung meinen RasPi Nr1. RasPi mit WLAN ƩDIMAX und einem selbst gelöteten USB-FTDI-UART-Wandler zum Archie-Master. Das läuft bestens z.B. mit RemoteDesktop vom PC.

Den RasPi Nr2 habe ich besorgt für sonstige Übungen. Der Bequemlichkeit halber beide vom GLEICHEN TYP! Also -- als ersten Test -- vom funktionierenden RasPi Nr1 die SD-Karte in den RasPi Nr2 gesteckt, dazu den ƩDIMAX. Power dran, die LEDs blinzeln - aber wenig - und sonst nix. Keine Aktivität am ƩDIMAX, kein Signal im WLAN-Netz erkannt . . . Gestern nachts dann die "/etc/network/interfaces" im Bildschirm-Tastatur-Maus-Modes kopiert von der RasPi-Nr1-SD auf ne neue erstellte und aktualisierte SD. Wieder . . . nix.

Frage:
Kann man eine konfigurierte und funktionierende SD-Karte von einem RasPi auf nen andern stecken und die gleiche Funktion erwarten?
Sind die SD-Karten nach der Konfiguration "gebrandet" ?
Gibts ne einfache Lösung für die skizzierte Anwendung?

Danke für die Antwort auch wenns hier im Thread schon lang ohne Kabel geht.

Neuere Raspis fahren von älteren Images nicht hoch. Dazu müssen in der Boot-Partition der SD-Karte (das ist die, die auch Windows mit etwa 50 MB sehen kann) einige Dateien ausgetauscht werden. Die älteren Raspis fahren auch mit den neuesten Dateien hoch. Welche Dateien das genau sind, habe ich vergessen.

Zitat:

---

Neuere Raspis fahren von älteren Images nicht hoch ...

---

Na ja, ein bisschen Wurm ist wohl schon in den Himbeeren drin. Nun läuft wenigstens nach neuerlichem Aufsetzen und WLAN-Installation Kitty, aber die Raspi gleich als GUI über Remotedesktop springt nicht an. Schlimmer: Remotedesktop lehnt jeglichen Kontakt mit dem Raspi ab, behauptet dass es den garnicht gäbe. Damit hab ich einen (den "Alten") Raspi der auf Win7HPrem-64-Notebook und Win7Pro-64-Desktop mit Kitty/Putty und MS-Win-Remotedesktop mit GUI geht und einen Kuchen (mit Wurm *gg*) der NUR mit Kitty läuft. Zum Würmer - ähhhh - Mäuse melken!

Kopier mal vom neuen Image die Dateien der Boot-Partition auf die PC-Festplatte. Dann das komplette Image des neuen Raspis sichern. Dann das Image des alten auf die Karte des neuen und diese Boot-Partition in einem anderen Ordner auf dem PC sichern. Dann eine Datei nach der Anderen ersetzen und gucken, ob der neue Raspi mit dem alten Image und den ersetzten Dateien hochfährt.

Zitat:

---

Zitat von peterfido

Kopier mal vom neuen Image die Dateien der Boot-Partition auf die PC-Festplatte ...

---

Danke für die Hilfe. Die war auf Umwegen hilfreich. A: habe ich etwas zu/für/mit Linux gelernt und B: ist mir nach den ersten vergeblichen Aktionen aufgefallen, da war ja noch was . . . und nach Installation des xrdp-Servers liefs und endlich war im RemoteDesktopFenster die Himbeere zu sehen.

Danke für Hilfe und Geduld