Die Sleep() - Prozedur darf natürlich nicht zu lang sein. In meinem Beispiel habe ich sie auf 500 Sekunden,
was natürlich Quatsch ist. Setze sie auf:
usleep(100000);
Es sind 100 ms. Der Header für usleep() ist unistd.h.
Die Sleep() - Prozedur darf natürlich nicht zu lang sein. In meinem Beispiel habe ich sie auf 500 Sekunden,
was natürlich Quatsch ist. Setze sie auf:
usleep(100000);
Es sind 100 ms. Der Header für usleep() ist unistd.h.
Versuche in der Datei wiringPiISR.c in der for(;; ) Schleife eine Pause zu setzen.
static void *interruptHandler (void *arg)
{
int pin = *(int *)arg ;
(void)piHiPri (55) ;
for (;; )
{
if (waitForInterrupt (pin, -1) > 0)
isrFunctions [pin] () ;
sleep(500);
}
return NULL ;
}
Sonst läuft die Schleife ununterbrochen bis ein Interrupt autritt und blockiert dabei die anderen Prozesse.
Mit der Pause gibst du die Chance den andern Programmen ihre Initialisierung abzuarbeiten.
Ein Zeitrelais reicht doch auch.
Zum Beispiel dieser Timer.
daemonisiert sich dein Programm selbst? Erstellt es auch die Prozess ID?
Wie ist der Status im htop nachdem das Programm über das Skript ausgeführt wird?
Wahrscheinlich läuft es als Kind-Prozess der Shell.
Initializiere und beende das Programm im Init-Skript mit daemon-start-stop Befehl.
Schaue dir auch mal die Datei /etc/init.d/skeleton an.
Runlevel 2,3,4,5 sollen schon gesetzt werden.
RBPi läuft standardmässig in Runlevel 2. Das kannst du auch mit dem Befehl runlevel überprüfen.
Wie sieht den das /etc/init.d Skript aus mit dem dieser daemon gestartet wird?
Hast du vielleicht am Pin A0 ein Masseschluss?
Also laut diesem Datenblatt sind es 8-Adressen und zwar:
0x40 - A0=0, A1=0, A2=0
0x42 - A0=1, A1=0, A2=0
0x44 - A0=0, A1=1, A2=0
0x46 - A0=1, A1=1, A2=0
0x48 - A0=0, A1=0, A2=1
0x4A - A0=1, A1=0, A2=1
0x4C - A0=0, A1=1, A2=1
0x4E - A0=1, A1=1, A2=1
Mit dem PCF8574A sind 16 Adressen möglich.
Um das Ganze sparsamer zu machen könnte sich RBPi nach dem Schnappschuss selbst herunterfahren.
Das Hochfahren könnte dann ein Zeitschalter an der Spannungsversorgung erledigen.
Das hier sind die möglichen.
Hast du die Abhängigkeiten richtig gesetzt unter "Required-Start".
Wenn dein Programm von anderen zuvor initialisierten Modulen abgängig ist,
und diese fehlen, kann es nicht richtig funktionieren.
### BEGIN INIT INFO
# Provides: daemon-name
# Required-Start: $network $remote_fs $syslog
# Required-Stop: $network $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description:
# Description:
### END INIT INFO
Um ein paar Skripte hin und her schieben reicht es.
Deine Platten sind in NTFS formatiert. Es ist leider kein vom Linux direkt unterstütztes Dateisystem.
Was nicht bedeutet Linux kann es nicht. Abhilfe findest du vielleicht hier.
Die Ports freigeben auf dem Router. RBPi soll statische IP haben an die der Router die Ports weiterleitet.
z.B: Router interner Port 80 an RBPi-IP-Adresse:80 usw.
Ja. Richtig. Lies bitte den zweiten Teil meiner Antwort.
Funktioniert es mit dem Terminal?
cd /sys/bus
sudo mkdir pci
Der Ordner sys hat standardmäßig keine Schreibrechte auch für root:
dr-xr-xr-x 12 root root 0 Jan 1 1970 sys
Der bus Ordner schon:
drwxr-xr-x 14 root root 0 Dec 15 00:13 bus
da er aber im für root schreibgeschütztem Ordner liegt kann root nichts erstellen.
mit sudo chmod 755 /sys rechte vergeben, danach müsste es gehen.
Versuche nach dem Ordner Erstellen mit View -> Reload.
Ok. Überzeugt.=(
pi@raspberrypi /usr/bin $ ll pyth*
lrwxrwxrwx 1 root root 9 Sep 28 21:41 python -> python2.7
lrwxrwxrwx 1 root root 9 Sep 28 21:41 python2 -> python2.7
-rwxr-xr-x 1 root root 2674528 Jan 13 2013 python2.7
lrwxrwxrwx 1 root root 9 Oct 21 2012 python3 -> python3.2
lrwxrwxrwx 1 root root 11 Mar 1 2013 python3.2 -> python3.2mu
-rwxr-xr-x 1 root root 2814320 Mar 1 2013 python3.2mu
lrwxrwxrwx 1 root root 11 Oct 21 2012 python3mu -> python3.2mu
pi@raspberrypi /usr/bin $ python3
Python 3.2.3 (default, Mar 1 2013, 11:53:50)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
pi@raspberrypi /usr/bin $ python2
Python 2.7.3 (default, Jan 13 2013, 11:20:46)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
Ich bin mir nicht ganz sicher, aber ich glaube Python 3 ist auf der ARM-Architektur noch nicht verbreitet.
Es gibt keine offizielen Distros soweit ich weiß. Bitte korrigiert mich wenn ich mich täusche. Also auf allen Geräten die ich zu Hause mit ARM Prozessor habe ist Python 2.x vorinstalliert. Auf meinem PC (Ubuntu 12.04) ist dagegen die 3.x.