Posts by ah114088

Quote from dreamshader

Hi ah114088,

ich kann mich ja mal umgucken, wenn ich mal wieder im Suchmodus unterwegs bin.
Ich hab auch Aussagen gelesen, dass diese Hardware-Unterstützung langsamer sein soll, als die Software-Lösung.
Andere Stimmen sagen, dass die Schnittstelle sehr kompliziert sein soll ...

Also alles in allem viel Spekulation, eher wenig Fakten.

cu,
-ds-

Ich denke, daß es vor allem sehr kompliziert ist. Die Ausführung des Bytecodes durch Hardware mag schneller sein. Der Engpass ist aber meistens ja nicht die CPU, sondern der Zugriff auf den Speicher (Von Neumannscher Flaschenhals). Vermutlich hat sich die Hardware-seitige Java-Unterstützung deshalb nicht durchgesetzt.

Grüße,
ah114088

ARMs Jazelle kommt übrigens auch bei den Android-Handys nicht zum Einsatz. Der Java-Bytecode wird dort von Dalvik (=Software) interpretiert.

Quote from dreamshader

Naja ... so ganz klar ist mir das alles trotzdem nicht. Du hast ja auch die MPEG2-Unterstützung zu aktivieren, obwohl in der CPU sicher kein kompletter DVD-Decoder enthalten ist ...
Vielleicht hat diese Java-Unterstützung ja auch nur was mit der Floating-Point Geschichte zu tun?

Ist ja auch egal ... deshalb hab ich ja auch geschrieben dass ich das spontan so interpretieren würde und die CPU wohl für Handy & Co. gedacht war, wo Java doch eher verbreitet ist.

cu,
-ds-

Wenn Du Informationen zu dieser vorgestellten CPU-basierten Java-Unterstützung auf dem RPi hast, würde mich das interessieren. Besonders interessieren würde mich, wie die CPU mit Java-Bytecode-Anweisungen umgeht, die dynamischen Speicher anfordern oder freigeben (Garbage-Collction). Außerdem frage ich mich, wie Jazelle mit Bibliotheks-Aufrufen über JNI umgeht. Da müßte dann ja irgendwie zwischen den verschiedenen CPU-Befehlsmodis hin- und hergeschalten werden ...

Solange niemand diese Fragen beantworten kann, dürfen wir wohl davon ausgehen, daß es keine besondere Unterstützung für Java-Programme auf dem RPi gibt. Ich habe bei meinen Recherchen dazu nichts Greifbares gefunden.

Was ich gefunden habe waren Aussagen wie diese:

Quote

No, it isn't. Jazelle (DBX) is pretty useless. It's much slower than a decent VM, but (from what I've heard) complicated to implement and use, and requires licensing from ARM. I don't know of any up-to-date VM that can use Jazelle, which says a lot already. It has been abandoned on Cortex cores for good reason.

Das war eine Antwort auf die Frage, ob Jazelle auf dem RPi verwendet werden kann:

Quote

One of the 'interesting' questions is if we can use the JAVA (Jazelle) instruction engine which is part of the ARM1176 core.

Es mag ja sein, daß es irgendeine theoretische Möglichkeit gibt, diese Hardware-seitige Unterstützung zu aktivieren. Nur hilft das eben nichts ...

Akademisch ist das Thema sicherlich hochinteressant. Hier z.B. eine Präsentation auf den Seiten der Universität Hannover. Es wird darin aber nur auf die Eigenheiten der ARM-CPU im Jazelle-Modus eingegangen. Nicht erwähnt wird, wie daraus eine standardkonforme Java-Virtual-Machine entstehen soll ...

Quote from dreamshader

Hi ah114088,

mag sein, dass das so ist ... mag sein, dass es anders ist ...

Mir ist das, ehrlich gesagt, ziemlich egal.
Es wird wohl immer wieder diesen Glaubenskrieg geben, was jetzt wofür besser ist.
Es gab einen C++-Hype, einen VB-Hype, einen C#-Hype, einen Java-Hype, ... und derzeit ist halt der python-Hype in.
Ich bin der Meinung, jeder sollte mit der Sprache arbeiten, die ihm am besten zusagt.

Ich bin, zugegebenermassen, ein absoluter Fan von Assembler und C, und das schon seit PCs in Deutschland langsam in Mode kamen.

Ich habe auch durchaus Vorteile in C++ und dem objektorientierten Ansatz erkannt ... aber nur im Kopf ...
Vom Gefühl her kann ich das aber irgendwie nicht so recht akzeptieren ...

In einem Punkt muss ich dbv ohne Einschränkungen recht geben (hat er mal in irgendeinem Thread hier geschrieben):
Wenn man verstanden hat, was man tut, ist die Sprache eher nebensächlich.

Ist so ähnlich wie mit der ewigen Diskussion Windows <-> Linux ...

Aber danke für die Aufklärung,

ciao,
-ds-

Display More

Ich mag diese Glaubenskrieger auch nicht, obwohl ich selbst C und Unix bevorzuge. Ich mache auch nicht alles in C. Wenn ich schnell mal etwas hinbiegen muß, dann greife ich gerne auf Ruby zurück. Wer Java mag, der soll in Java programmieren. Mein Beitrag war ja auch nicht gegen Java als Programmiersprache gerichtet, sondern nur gegen die falsche Annahme einer besonderen Java-Unterstützung auf dem RPi

Quote from dreamshader

Wenn ich mir das hier:

anschaue, dann würde ich spontan sagen, dass Java die integrierte Programmiersprache für den Pi ist. Ist ja auch kein Wunder, die CPU stammt ja ursprünglich aus dem iPhone.

Nur mal so nebenbei bemerkt,
-ds-

Java ist unter Android *die* Sprache, beim iPhone muß sie dagegen erst installiert werden.

Und nur weil die RPi-CPU Java-Bytecode ausführen kann, heißt das noch lange nicht, daß das bei Java-Programmen auf dem RPi auch wirklich geschieht. Damit Java-Programme direkt von der CPU ausgeführt werden, braucht es weitergehende Unterstützung. Meines Wissens nach wird die Verwendung von Jazelle von der Debian-Distribution noch nicht unterstützt. Der Java-Bytecode wird wie in anderen Fällen auch von einer Software interpretiert.

Quote from dreamshader

Ich hatte bis vor einigen Tagen noch keinen Plan zum I2C-Bus - bis mich dieses EEPROM geärgert hat

Macht jedenfalls irgendwie Spaß und SPI kommt auch noch dran ;> ...

1. EEPROMs über I2C ansteuern ist gar nicht so einfach. Ein Kollege von mir hat sich kürzlich auch damit rumgeärgert.

2. Und was willst Du mit SPI ansteuern?

(Habe mir gerade die kostenlose Lite Edition der CodeSourcery Toolchain für Linux-PC runtergeladen (arm-none-linux-gnueabi) und installiert. Ein einfaches Hello-World-Programm ließ sich ohne irgendwelche Probleme auf dem Linux-PC übersetzen und auf dem RPi starten. Auch ein pthreads-Programm hat funktioniert. Bin am Überlegen, ob ich mir mal selbst einen Kernel für den RPi übersetze. Das könnte man zwar auch mit dem gcc auf dem RPi machen. Nur dauert das halt ewig ...

Die CodeSourcery-Toolchain gibt es übrigens auch für Windows.)

Quote from dreamshader

Hi auch,
naja ... so ähnlich war das auch gedacht und so ist das Ganze auch schon aufgebaut.
Nach aussen sichtbar sind lediglich:

Code

extern struct i2c_eeprom_t *eeprom_init(int eeprom_type);
extern void eeprom_release(struct i2c_eeprom_t *eeprom);


extern int i2cee_open(struct i2c_eeprom_t *eeprom , int busno, int slaveaddr, int force);
extern int i2cee_close(struct i2c_eeprom_t *eeprom);
extern int i2cee_read(struct i2c_eeprom_t *eeprom, int rd_len, int page, int offset, unsigned char* buf, int retries);
extern int i2cee_write(struct i2c_eeprom_t *eeprom, int wr_len, int page, int offset, unsigned char* buf, int retries, int verify);


extern int i2cee_read_plain(struct i2c_eeprom_t *eeprom, int rd_len, unsigned long address, unsigned char* buf, int retries);
extern int i2cee_write_plain(struct i2c_eeprom_t *eeprom, int wr_len, unsigned long address, unsigned char* buf, int retries, int verify);

Display More

Und ich nutze auch den I2C-Bus über die passenden Funktionen.
So ist das im Moment einfacher für mich, weil es seitens I2C noch ein paar kleine (aber bekannte) Ungereimtheiten gibt.

Möglicherweise mache ich mal ein LKM draus ... aber ich denke so ist das auch schon ganz hilfreich.

Danke aber für Deinen Hinweis ...

-ds-

Display More

Ich weiß ja nicht woran's beim Zugriff auf I2C über "linux/i2c-dev.h" hakt. Es mag naiv sein, aber vielleicht löst sich das Problem ja in Luft auf, wenn der EEPROM-Treiber als Kernel-Modul geschrieben ist.

Bei SPI gibt es auch so einen Treiber zum Zugriff aus dem User-Mode. Als ich die Anbindung der SD-Karte über SPI gemacht habe, habe ich den aber nicht hergenommen. Das wäre auch viel mehr Arbeit gewesen, weil bereits Treiber zur Ansteuerung von MMC/SD-Karten über SPI und ein SPI-Treiber für den SPI-Controller in meinem Mikrocontroller vorhanden war.

Hier hat übrigens schon jemand anderes mit 24LC16 über I2C gerungen. Laut Kommentar im Quelltext lassen sich damit aber nur die ersten 256 Bytes des EEPROMs ansprechen. Dafür ist es als Kernel-Modul implementiert.

Quote from dreamshader

Liebe Gemeinde-Mitglieder und alle die es werden wollen,

ich war vor Kurzem noch fast am Verzweifeln, nur weil ich ein popeliges I2C-EEPROM beschreiben und auslesen wollte.

Ich habe mich daher dazu entschlossen, mal eine einfache API zu stricken, die den Zugriff auf EEPROMs vereinfacht.
Das Teil ist im Moment sozusagen noch in der pre-alpha Phase, funktioniert aber mit einem 24LC16 einwandfrei, soweit ich das bis jetzt beurteilen kann.

Nach Fertigstellung der Doku und weiteren, ausgiebigeren Tests werde ich alles in github einpflegen. Die Adresse des Repository gebe ich dann hier bekannt.
Als Anhang findet ihr hier den aktuellen Stand als gzippten tarball.
Falls sich jemand berufen fühlt ein bisschen damit herum zu spielen so kann er das gerne tun.
Und wenn jemand noch Ideen dazu hat oder Fehler findet -> einfach hier rein damit.
Außerdem dachte ich mir, dass dieser Thread evtl. als eine Art Plattform für einen Erfahrungsaustausch dienen könnte.

So, genug gelabert ....

Ach, was ich vergaß:

Code

cc -o eetest eetest.c i2c_core.c i2ceecore.c i2ceeprom.c 24lc16.c -lrt

viele Grüße aus dem sonnigen Süden,
-ds-

Display More

Ich meine, das ließe sich schöner machen, wenn die Ansteuerung des EEPROMs über I2C als Kernel-Modul implementiert wäre. Die Anwendung könnte dann über open()/close()/read()/write()/lseek() auf das EEPROM zugreifen.

Ich hatte selbst vor kurzem so ein Kernel-Modul zum Zugriff auf ein EEPROM geschrieben:

EEPROM-Gerätetreiber für µClinux

Die Ansteuerung ist da zwar einfacher, weil das EEPROM nicht über I2C angebunden ist. Wenn aber bereits ein I2C-Treiber vorhanden ist, dann könnte der EEPROM-Treiber den bestimmt irgendwie verwenden.

Schau Dir mal JNI (Java Native Interface) an. Damit lassen sich C-Funktionen aus einem Java-Programm heraus aufrufen. Mit JNI können Daten von Java an C-Funktionen als Parameter übergeben werden und umgekehrt. JNI wird auch unter Android zur Verwendung von C-Bibliotheken aus Java heraus verwendet.

Du könntest versuchen make mit der -d Option zu starten. Da bekommst Du zusätzliche Informationen von make ausgegeben, die das Problem verstehen helfen könnten.

Sollte das nichts bringen, startest Du make mit vorangestelltem 'strace -f'. Da bekommst Du dann alle Systemaufrufe ausgegeben, die make oder die von make gestarteten Programme machen. Auf die Weise findest Du heraus, was zu diesem "Command not found" führte.

Quote

# strace -f make
execve("/usr/bin/make", ["make"], [/* 23 vars */]) = 0
brk(0) = 0x46c000
uname({sys="Linux", node="raspberrypi", ...}) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fcd000

Display More

Da kommt natürlich noch viel mehr Output.

Quote from ah114088

Den PC hatte ich mir gekauft, weil ich einen Linux-PC brauche. Hintergrund ist, daß ich plane mir dieses Evaluation-Board mit uCLinux zu kaufen, um damit zu experimentieren.

Das Board ist mittlerweile da und natürlich auch im Netz. Es ist noch einen Tick kleiner als der RPi. Basis für den Mikrokontroller ist eine Cortex-M3 CPU von ARM mit nur 120 MHz. Die restlichen Angaben zu Speicherausbau usw. hier. Der vielleicht wichtigste Unterschied zum RPi ist, daß das System keinen virtuellen Speicher (NO-MMU) hat. Deswegen kann auch nur μClinux darauf laufen.

Hier das erste größere Projekt, das ich mir vorgenommen habe.

Quote from Martin

Nun möchte ich die Temperaturwerte gerne von unterwegs übers Internet anschauen.
Ein Webserver ist soweit ich weiß realisierbar.

Ja, ist realisierbar. Hier mein kleiner Webauftritt. Die Websteiten werden von Apache2 bereitgestellt. Für die dynamischen Seiten verwende ich Ruby. Hier z.B das CGI-Skript, das diese Webseite generiert:

Quote

#!/usr/bin/ruby

def myip()
IO.popen(%+curl http://www.ip-secrets.com/ 2>/dev/null+).each do |line|
next if ! line.include? 'Your current IP-Adress'
return line[/[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/]
end
return "<unknown>"
end

puts "Content-type: text/html\n\n"
puts "<html><p>My external IP is: " + myip() + "</p></html>"

exit 0

Display More

Statt dem Kommando curl würdest Du irgendwas anderes aufrufen und das Skript entsprechend anpassen. Statt Ruby könntest Du freilich auch eine andere Sprache verwenden, z.B. Perl.

Um die Webseiten von außen (d.h. im Internet) zugänglich zu machen, habe ich Port Forwarding in meinem DSL-Router für Port 80 aktiviert und Dynamisches DNS bei noip.com eingerichtet. Das ist dort kostenlos.

Auf dem PC ist mittlerweile neben Windows 8 auch Ubuntu Desktop 13.4 installiert. Beide Systeme kommen sehr gut mit meinem Netzwerk zurecht.

Probleme hatte ich nur mit der Einrichtung von Dualboot. Hier mein Posting im Forum von ubuntuusers.de ... falls das jemand interessiert.

Jetzt bin ich baff. Ich habe doch keinen WLAN-Adapter im PC. Die Internetverbindung funktioniert aber trotzdem. Der MacBook fungiert als Bridge. Beweis: Wenn ich WLAN auf dem Mac ausschalte, hat der PC plötzlich kein Internet mehr.

Man kann auf den Macs in der Systemsteuerung unter "Freigaben" auch "Internetfreigabe" anwählen und "Airport" (d.h. WLAN) für Computer über "Ethernet" freigeben. Das hatte ich vor ein Tagen mal eingeschaltet (ohne es eigentlich zu testen) und es dann erst mal vergessen ...

Zum Browsen ist die Verbindung über den Mac allemal zu gebrauchen. Für Downloads aber eher nicht. Ist halt doch recht langsam.

Quote from framp

Wieso? Wenn das Defaultgateway Deines PCs auf die Pi zeigt und das Defaultgateway der Pi auf den Router zeigt kommst Du ohne Probleme vom PC ins Internet.

Glaube ich nicht.

Allerdings hat sich das Thema sowieso gerade erledigt. Habe festgestellt, daß mein PC doch einen eingebauten WLAN-Adapter hat. Der Verkäufer meinte, es wäre kein WLAN-Adapter drin. Ich brauche also gar nicht über den RPi gehen.

Quote from dreamshader

Hi,

na prima ...
Aber einen hab ich noch - nachdem ich Deine Skizze betrachtet habe.
Ohne routings auf dem/den PC(s) über den MAC bzw. den Pi (und bei denen mit entsprechendem Forwarding) kommst Du nicht mehr auf Deinen ALICE-Router. Es sei denn, der/die PC(s) hängen auch über WLAN dran. Dann aber erscheint mir Dein Konstrukt zwar funktionsfähig und verwirrend - lässt aber irgendwie den Sinn vermissen.
Das zweite Netz brauchst Du nämlich gar nicht und Du machst Dir dadurch nur das Leben schwer ...

Oder hab' ich da was übersehen?

cu,
-ds-

Stimmt natürich, daß ich mit dem PC so nicht auf den Alice-Router komme. Das ist aber nicht tragisch. Wenn ich mit dem PC ins WLAN kommen will, kann ich meinen USB-WLAN-Stick vom Raspberry in den PC umstöpseln. Genau das habe ich vor wenigen Minuten gemacht, um mir dort Cygwin auf Windows 8 zu installieren — quasi die erste Amtshandlung nachdem ich den heute erst gekauften PC in Betrieb genommen habe.

Nun könnte ich mir noch einen zweiten WLAN-Stick kaufen, damit ich den Raspberry nicht vom Internet abklemmen muß, wenn ich mit dem PC mal online gehen will. Nur will ich den PC ja gar nicht als Desktop verwenden. Für Internet-Zugang habe ich den Mac und ich bin auch sehr zufrieden damit.

Den PC hatte ich mir gekauft, weil ich einen Linux-PC brauche. Hintergrund ist, daß ich plane mir dieses Evaluation-Board mit uCLinux zu kaufen, um damit zu experimentieren. Als Hostsystem (d.h. zum Compilieren usw.) wird da nur ein Linux-PC unterstützt und Boot-Images kann man auch nur über Ethernet aufspielen — deswegen brauche ich Ethernet.

Da hat sich mir dann natürlich die Frage gestellt, wie ich diesen PC in meine bestehende Umgebung integrieren kann. Eine Lösung, bei der ich nur vom PC auf dieses Board komme, macht irgendwie keinen Sinn.

Mit der jetzigen Struktur wird das Board ein ganz normaler "gleichberechtigter" Teilnehmer in meinem Ethernet-Netzwerk sein. Ich könnte damit irgendeine Anwendung schreiben, bei der der RPi der Server und dieses Board der Client ist. Wenn es eine Möglichkeit gibt die Temperatur dieses Boards abzufragen, könnte bspw. der Client diese Temperatur regelmäßig dem Server auf dem RPi mitteilen und der RPi könnte diese Information auf einer Webseite veröffentlichen

dreamshader

Ich hatte dem eth0 schon eine IP-Adresse zugewiesen. Sie war nur eben falsch ...

Wie es scheint, läuft mein Szenario jetzt:

Ich kann mich — bei ausgeschaltetem WLAN(!) — vom Mac auf dem RPi mit ssh einloggen und von dieser Shell aus dann den Mac pingen. Das heißt die Ethernet-Verbindung funktioniert. Ebenso kann ich mich immer noch über WLAN vom Mac auf dem RPi einloggen und den Mac pingen.

Ob ich über WLAN oder Ethernet gehe, unterscheide ich mittels der IP-Adresse. Über WLAN errreiche ich den RPi mit 192.168.1.2 (die bekommt er über DHCP von der Alice-Box), über Ethernet erreiche ich ihn mit 192.168.2.100.

Hier das Bild mit den IP-Adressen:

Meine /etc/network/interfaces auf dem RPi:

# the loopback network interface 
auto lo
iface lo inet loopback


# use wlan as pimary network interface
auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf


# use ethernet as secondary network interface
auto eth0
iface eth0 inet static
address 192.168.2.100
netmask 255.255.255.0

Auf dem Mac habe ich unter Netzwerke bei Ethernet diese Einstellungen:

IPv4 konfigurieren: manuell
IP-Adresse: 192.168.2.101
255.255.255.0

Soweit ich das verstehe, sind das nun zwei Netzwerke.

Das WLAN-Netzwerk ist 192.168.1.0, d.h. alle Hosts haben dort als IP-Adressen 192.168.1.x.

Das Ethernet-Netzwerk ist 192.168.1.0, d.h. die Hosts haben IP-Adressen 192.168.2.x.

Was so natürlich nicht geht, ist, daß Rechner, die nur im Ethernet-Netzwerk sind, das Internet verwenden können. In der deutschsprachigen RPi-Facebook-Gruppe hat man mir geraten den RPi als Bridge aufzusetzen. Ich sehe das aber als separaten Schritt an. Meine Frage sehe ich daher als beantwortet an.

Hallo Miteinander!

Ich bin seit zwei Wochen stolzer Besitzer eines Raspberry PI, Modell B mit 512 MB.

Erst hatte ich Schwierigkeiten den Internet-Zugang via USB-WLAN-Stick zu meiner Alice-Box zum Laufen zu bringen. Nachdem das funktionierte, habe ich den Apache2 installiert und ein bisschen mit HTML und CGI-Skripten in Ruby experimentiert. Als nächstes habe ich auf der Alice-Box Port Forwarding für Port 80 aktiviert, damit ich auf diese Webseiten auch von außen zugreifen kann. Weiterhin habe ich mir bei noip.com DDNS eingerichtet (das gibt es da kostenlos), damit mein RPi unter einem festen Hostnamen erreichbar ist.

Das funktioniert alles wunderbar.

Nun will ich meinen RPi zusätzlich mit meinem MacBook Pro via Ethernet-Kabel verbinden.

RPi und Mac können zwar schon per WLAN miteinander kommunizieren. Ich will es aber so einrichten, daß der Datenverkehr zwischen Mac und RPi nicht unbedingt über die Alice-Box gehen muß. D.h. ich will ein zweites Netzwerk haben, das über Ethernet läuft. An dieses zweite Netz will ich später dann noch einen PC anschließen, weswegen ich mir noch einen Switch zugelegt habe.

Insgesamt hätte ich dann diese Struktur:

RPi und Mac sind nun also über Ethernet-Kabel und Switch verbunden, aber ich kann den Mac nicht anpingen ...

Im WLAN hat der RPi 192.168.1.2 als IP-Adresse, die er über DHCP von der Alice-Box zugewiesen bekommt:

[44] sudo ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:d3:ab:7d  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:456 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:72396 (70.6 KiB)  TX bytes:0 (0.0 B)


lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:31 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3088 (3.0 KiB)  TX bytes:3088 (3.0 KiB)


wlan0     Link encap:Ethernet  HWaddr 80:1f:02:8f:1f:2d  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4602 errors:0 dropped:4682 overruns:0 frame:0
          TX packets:2852 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:532420 (519.9 KiB)  TX bytes:582871 (569.2 KiB)

So sieht meine /etc/network/interfaces derzeit aus:

[45] cat /etc/network/interfaces
# the loopback network interface 
auto lo
iface lo inet loopback


# use wlan as pimary network interface
auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf


# use ethernet as secondary network interface
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0

Die statische IP-Adresse 192.168.1.100 brauche ich (glaube ich), damit ich den RPi auf zwei Wegen erreichen kann: Als 192.168.1.2 über WLAN und als 192.168.1.100 über Ethernet.

Wie muß ich das einrichten, damit es funktioniert? Brauche ich da vielleicht noch eine Netzadresse?