digitemp-ipkg

Freifunk Firmware, Programme für den Router, Entwicklungen, Fragen und Anleitungen
Antworten
4huf
Beiträge: 677
Registriert: 19.04.2007 14:56
Wohnort: Zscherben

digitemp-ipkg

Beitrag von 4huf »

Auch das digitemp habe ich mal für die Router bauen lassen.
Digitemp ist für die Temperaturmessung mit den OneWire-Bus-Sensoren z.b. DS18S20.
Die gibts für wenig €, brauchen keinen Ableich und haben eine Genauigkeit von 0,5°C (Auflösung ca. 0,05° !).
Für den Anschluss an der 2. seriellen Schnittstelle braucht man nur einen
Widerstand und eine Schottky-Diode (und 3 statt 2 Leitungen).
Man kann an diesen BUS mehrere Sensoren anschließen.
Es gibt auch Feuchte-Sensooren und AD-Wandler, die habe ich aber noch nie
getestet.

Für den Anschluss an der 1. seriellen ist etwas mehr Aufwand (2. Widerstand +
MosFET + GPIO-Leitung + inittab-Änderung ) notwendig weil dort die Bootmeldungen kommen.
Für die Buffalos hab ich das aber hier laufen. Bitte mal melden wer das möchte.

http://www.ipb-halle.de/~ronald/freifun ... mipsel.ipk

Es ist nur das Binary. Scripte für rrd-Grafiken gibts noch nicht.
. eine Antenne ist der beste HF-Verstärker
.funktionierende Antennen : Short-Backfire, AMOS-5, AMOS-3, Doppelquad, 4fach-Quad
bitcrawler
Beiträge: 3
Registriert: 13.06.2007 18:11

Beitrag von bitcrawler »

Hi!

Hab grad euer Forum durchgeblättert und bin auf die Sache mit dem DS1820 gestoßen. Sowas ähnliches hab ich auch vor, nur wollt ich das mit ner fonera machen. Sprich: die hat nur _eine_ serielle. (richtig?)

Somit wär ich über deinen Tipp mit der 2. Seriellen sehr dankbar. Ich kam noch nicht dazu, es auszuprobieren und weiß also auch nicht, wo genau es hängt wenn die fonera mit der 1-wire-Beschaltung bootet. Kriegt 1-wire oder die fonera Probleme?

Danke dir schonma, 4huf!
4huf
Beiträge: 677
Registriert: 19.04.2007 14:56
Wohnort: Zscherben

Beitrag von 4huf »

Also bei meinen WHR´s (die auch nur eine serielle haben) wird die serielle
soweit blockiert das sie dann unter nicht mehr ansprechbar ist.
Das betrifft den RX-Teil.
Durch die OneWire-Beschaltung wird ja praktisch der TX mit dem RX verbunden und das kann der RX offenbar nicht ab.
Mein Trick besteht darin den RX wärend des booten tot zu legen.
Das passiert durch den zusätzlichen Transistor, der den RX auf 0V zieht.
Erst wenn ich ihn für das OneWire brauche wird er freigegeben.
(teilweise schaltet irgend ein Prozess den betreffenden GPIO wieder um, aber
mit einem script das den GPIO vor dem digitemp setzt geht das).

Die Error-Ausgabe des Kernels geht zwar weiterhin auf den seriellen Ausgang, aber das stört nur wenn da viel kommt (z.B. firewall-Meldungen).
Es wird dann der OneWire-Bus gestört und Messungen erzeugen Müll oder
Fehlermeldungen.
. eine Antenne ist der beste HF-Verstärker
.funktionierende Antennen : Short-Backfire, AMOS-5, AMOS-3, Doppelquad, 4fach-Quad
bitcrawler
Beiträge: 3
Registriert: 13.06.2007 18:11

Beitrag von bitcrawler »

Ah, ok.

Was hälst du davon, wenn man einfach den Transistor per RC-Glied ansteuert, sodass er den RX (oder TX) solange auf 0V zieht, bis der Bootvorgang vorbei ist? Dann hätte kein Prozess während init die Möglichkeit, das rückzusetzen. Und die Kernelmedlungen während des Betriebs könnte man doch sicherlich nach /dev/null schicken, mal überlegen . . .

Gruß und danke für die Info!
mono
Beiträge: 458
Registriert: 20.09.2006 09:14
Wohnort: Halle

Beitrag von mono »

Das müsste aber ein große Kapazität sein, oder irre ich mich?
Wie lange dauert der Bootbvorgang?
4huf
Beiträge: 677
Registriert: 19.04.2007 14:56
Wohnort: Zscherben

Beitrag von 4huf »

Upps, ich sehe gerade das mein Beitrag von gestern garnicht da ist :(
Offenbar hab ich ihn nicht abgesendet bevor der Browser mal geschlossen
wurde.


Also mit dem Transistor ist sicher denkbar. Der Bootvorgang dauert allerdings so 7..10min bis er bei S99done angekommen ist.
Das hängt mit mehreren Pausen wegen Zeitsynconisation und rrd-Grafiken zusammen.
Mit einem FET sollte das aber machbar sein.
Außerdem kommt nach dem olrsd glaube nicht mehr so viel.
Wichtig ist auf jeden fall im /etc/inittab die Zeile "tts/0::askfirst:/bin/login" auszukommentieren.
Ich werde das mit dem RC-Glied mal testen. Hätte den Vorteil das ich dann wieder 2 freie GPIOs habe und
den I2C-Bus versuchen könnte (wenn ich raus bekomme wer an den GPIOs rumfummelt)

Die Kernel-Meldung zu unterdrücken ist deutlich auswendiger denn die gehen auf die Console.
Für den ADM5120 gabs hier mal das Thema :

http://midge.vlad.org.ua/forum/viewtopi ... c&start=17

Man muss also einen neuen Kernel bauen und damit dann eine neu Firmware.
Wenn nicht dauernd Firewall-Meldungen oder sowas ausgegeben werden sollte das aber nicht weiter stören.
Es gibt vom digitemp sonst Fehlermeldungen oder im schlimmsten Fall unsinnige Werte.
Wenn man die Temperaturen in eine RRD schreiben will sollte man das
also ein wenig prüfen.

Wenn die 252.36 mal online ist ( ich hoffe in den nächten 1..2 Wochen)
ist auf der Home-Seite die aktuelle Temperatur zu sehen.
Die 250.47 hats schon , kommt nächste Woche aufs Dach und die 250.45
wird auch in den nächsten Tagen nachgerüstet.
Für ne schöne Grafik muss ich noch die Syntax des rrd-collect "knacken".
. eine Antenne ist der beste HF-Verstärker
.funktionierende Antennen : Short-Backfire, AMOS-5, AMOS-3, Doppelquad, 4fach-Quad
4huf
Beiträge: 677
Registriert: 19.04.2007 14:56
Wohnort: Zscherben

Beitrag von 4huf »

Ich hab das am WE mal mit dem RC-Glied testen wollen. Dabei ist mir
ein gundsätzliches Problem aufgefallen : wie soll das RC-Glied bei Software-Reboot getriggert werden ?
Die Diag-LED missbrauche ich schon als WLAN-LED um die eigentliche WLAN-LED frei zu bekommen.

Für die Firewall-Meldungen gibts dagegen eine einfache Lösung.
Im /etc/init.d/S45firewall wird auf die Variable "ff_debug=0" getestet.
Bei mir war die garnicht vorhanden. Also mit "nvram set ff_debug=0; nvram commit" erstellt und die Log-Regeln werden nicht erstellt.
. eine Antenne ist der beste HF-Verstärker
.funktionierende Antennen : Short-Backfire, AMOS-5, AMOS-3, Doppelquad, 4fach-Quad
bitcrawler
Beiträge: 3
Registriert: 13.06.2007 18:11

Beitrag von bitcrawler »

Da hast du wohl recht. An einen Soft-Reboot hatte ich auch nicht gedacht.
Muss wohl doch die GPIO-Lösung her. Aber sag mal, wie steuerst du die GPIOs an? Mit Kernelmodul, oder geht das auch anders?
4huf
Beiträge: 677
Registriert: 19.04.2007 14:56
Wohnort: Zscherben

Beitrag von 4huf »

Es gibt ein Tool mit Namen gpio, damit kann man die GPIO´s auf Low/High setzten oder abfragen.
Ich weis aber noch nicht wie das Teil intern arbeitet.
Auch werden offenbar einige GPIO´s (DIAG, WLAN, POWER) von Kerneltreibern "festgehalten" und können nicht mit dem Tool umgeschaltet werden.
Mit einem kleinen Trick hab ich die WLAN-Led frei bekommen.
In den NVRAM-Variablen steht offenbar welche LED der WLAN-Treiber verwenden soll. Das habe ich auf die DIAG-Led verbogen.
Die DIAG-Led wird normalerweise vom MMC-Treiber verwendet, das geht bei
mit nicht.
Außerdem werden die GPIO´s offenbar vom "ff-diag.o"-Modul beeinflusst.
Ich glaube das legt den Eintrag "/proc/sys/diag" an. In der S99done wird da
0x00 rein geschrieben.

Leider weis ich noch nicht woher dieses ff-diag.o kommt. Vermutlich eine
abgespeckte Version des openwrt diag.o
Ich hab auch noch nicht Quelltext gefunden ...

Alles in allem also noch entwicklungsfähig.
. eine Antenne ist der beste HF-Verstärker
.funktionierende Antennen : Short-Backfire, AMOS-5, AMOS-3, Doppelquad, 4fach-Quad
FreiFunk-Fan
Beiträge: 1
Registriert: 21.02.2008 17:56

Re: digitemp-ipkg

Beitrag von FreiFunk-Fan »

Hi,

wie sieht die Projektentwicklung den aus gibt es Fortschritte?
Ich möchte das gern am FONera realisieren.
Leider hat der nur einen RS232-Anschluß so weit ich weiß. Oder?
Wenn man jetzt die eine RS232 / TTL nimmt dann laufen ja dort noch die ganzen Fehlermeldungen lang. Wie kann ich das umgehen?

Gruß Freifunk-Fan.
4huf
Beiträge: 677
Registriert: 19.04.2007 14:56
Wohnort: Zscherben

Re: digitemp-ipkg

Beitrag von 4huf »

Hier mal die Schaltung wie ich sie bei den Buffalo´s WHR-HP-G54 verwende.
Die haben nur einen seriellen Anschluss und da laufen alle Boot- und Konsolenmeldugen drauf.
Außerdem kann man da nach dem Booten mit einem Terminal (115000Baud/8bit) drauf und
etwas richten wenn das Netzwerk nicht mehr geht (3,3V -> RS232 Wandler nicht vergessen !)

Um das digitemp hier nutzten zu können muss man die Schnittstelle vom Login frei machen.
Dazu ist die /etc/inittab zu editieren und die Zeile "tts/0::askfirst:/bin/login" zu löschen oder
ein # davor zu setzten.
Nach einem Reboot ist die Schnittstelle "/dev/tts/0" FAST frei.
Es laufen immer noch alle Boot und Kernel-Fehlermeldungen drauf.
Die Bootmeldungen bekommt man praktisch nicht weg und die Kernelmeldungen nur mit
einem speziellem Kernel. Aber für das digitemp sind sie nicht wirklich störend wenn
man dafür sorgt das so wenig wie möglich kommt.
(z.B. iptables-Meldungen abschalten)

Leider gibt es bei den Buffalo´s noch das Problem das der sich wärend des Booten aufhängt
wenn zu viel Daten über die RXD kommen.
Aus diesem Grund ist der FET in der Schaltung.
Er wird von einem Ausgang geschaltet, der nach einem Reset auf 3,3V liegt und später
per Software ( mit dem Tool "gpio" ) umgeschaltet werden kann.
Somit ist der RXD wärend des Booten auf 0V und "hört" nix mehr.
Ich verwende den einzig noch freien gpio 0 (AOSS-Taste) dafür.
Außerdem müssen noch die boot-scripte um den Aufruf "gpio disable 0" ergänzt werden.
Ob das gpio auf dem Fonera läuft weis ich nicht. es ist speziell für die Broadcom-CPU.
Als FET geht jeder "Wald- und Wiese" N-Kanal-FET mit einem Schwellspannung von 2..3V.

Wenn man einen 2. seriellen Anschluss hat (WRT54GL oder WHR-G54S) entfällt der FET
und man kommt mit dem Widerstand, der Schottky-Diode und ein paar Drähten aus.
Dateianhänge
gpio.tar
als /usr/bin/gpio entpacken
(6 KiB) 239-mal heruntergeladen
digitemp.png
digitemp.png (3.43 KiB) 8062 mal betrachtet
. eine Antenne ist der beste HF-Verstärker
.funktionierende Antennen : Short-Backfire, AMOS-5, AMOS-3, Doppelquad, 4fach-Quad
Antworten