skippi

Hi, ich glaube ja das der WARP-Charger das interessantere Projekt ist, aber gibt es hier auch Neuigkeiten ?

Im Shop hat der Status der Servo-Brick von 'Discontinued' auf "Nicht auf Lager" gewechselt, muß einem das zu denken geben ?

Gibt es schon einen aktualisierten Zeitplan, oder vielleicht schon mal die API vorab - oder braucht es doch noch ein Redesign ?

Nachdem die Servo-Brick in meiner Fussboden-Heizungsregelung mal wieder den Geist aufgegeben hat, wollte ich gerade nochmal eine Ersatzbestellung einleiten. Lt. Shop ist sie aber wohl nicht mehr verfügbar. Im Moment habe ich ja noch die Reserve Brick im Einsatz, aber wird es ein Nachfolgemodell geben ? (Gern etwas robuster, ist bei mir die Komponente die am häufigsten mal ausfällt - obwohl nur ein Servo angeschlossen)

Es ist wie gesagt ein GL-AR300M. Ich habe den mit den externen Antennen-Anschlüssen, aber nicht die Dualband Version.

Es ist ein 'gepatchtes' OpenWrt drauf (15.05 Chaos Calmer) von:

https://github.com/domino-team/openwrt-cc

Einen Nachtrag hätte ich noch. Ich habe das ganze jetzt mal mit einem gl-ar300m Router aufgesetzt. Mit 128MB Ram und auch Flash gibt es keine Speicherprobleme mehr und das Ding hat auch mehr Rechenpower - braucht aber auch etwas mehr Strom als der TP-Link.

Overlay? Keine Ahnung, das Image war so schon im Auslieferungszustand des Routers drauf.

Um den Speicher zuerweitern müsste ich usb-storage lib nachinstallieren oder?, es sind nur usb-core da, d.h. mangels Speicher keine Chance das nachzurüsten.

Ja usb-storage wäre nötig, bekommst Du aber in dem Rest nicht mehr unter.

Nachteil ist auch das Du dann einen USB-Hub benötigst, der auch manchmal etwas harkt.

Wenn es so passt und noch reicht wäre es optimal ...

Sag mal, wenn Du schon /overlay nutzt warum ist da so wenig Platz ?

Kannst Du keinen größeren USB-Stick nutzen oder ist es bei Dir noch gar nicht aktiv ?

Hm ist schon was her und war ein ziemliches Drama.

Versuche es einfach mal auf die 'schmutzige Tour':

Ich lege die udev lib hier auch mal ab,

damit können die Abhängigkeiten hoffentlich aufgelöst werden -

falls die Library nicht irgendwelche neuen aufreißt, die im Attitude Adjustment noch nicht abgedeckt sind.

Da hilft nur ausprobieren.

(das tar unter /lib entpacken ...)

Ich würde aber nicht versuchen den udev-Mechanismus zu nutzen sondern den brickd über das init-system (bzw. erst mal manuell) zu starten.

udevmips.tar

Kurzer Versuch mal einen OpenWrt Brickd hochzuladen. Ist aber eigentlich zu groß...

brickd

int servo_set_position(Servo *servo, uint8_t servo_num, int16_t position)

 

    Setzt die Position in °/100 für den angegebenen Servo.

 

    Der Standardbereich für die Position ist -9000 bis 9000, aber dies kann, entsprechend dem verwendetem Servo, mit servo_set_degree() definiert werden.

Der Default im brickv entspricht den Defaultwerten in der Firmware.

Da zwei verschiedene Defaults zu haben macht aus meiner Sicht auch nicht wirklich Sinn...

Hm bitte geht in Euch bevor Ihr die Defaults ändert.

Mich hat es eine Woche Fehlersuche und sicherlich merklich Servoverschleiß gekostet bis ich bemerkt habe das das Servo in meiner Heizungssteuerung deshalb nicht mehr funktioniert und dauernd bestromt ist weil der "Position reached" Callback nach dem Update der Firmware plötzlich nicht mehr kommt.

Ein bisschen mehr Kontinuität würde ich mir da schon wünschen...

Die stehen im brick_master.h

Ok, es läuft.

Es waren nicht neuere bindings notwendig, sondern ein neuerer brickd-2.0.

Bei mir leider nicht: (Originalcode von oben)

realtimevm@otcontrol-virtual:~/projects/tinkerforge/fbheatcontrol/tffbcontrol$ make clean

rm *.o tffbcontrol tffbdbg vitolog

realtimevm@otcontrol-virtual:~/projects/tinkerforge/fbheatcontrol/tffbcontrol$ make b2test

cc  -pthread -g -c b2test.c

cc  -pthread -g -c ip_connection.c

cc  -pthread -g -c brick_master.c

cc  -g -pthread -o b2test b2test.o ip_connection.o brick_master.o

realtimevm@otcontrol-virtual:~/projects/tinkerforge/fbheatcontrol/tffbcontrol$ ./b2test

Press key to exit

Braucht es eine spezielle gcc Version ?

Der brickd meldet ein enumerate event

2012-12-18 10:27:36.724534 <I> <network.c:89> Added new client (socket: 14)
2012-12-18 10:27:36.724714 <D> <client.c:85> Got request (U: 0, L: 8, F: 254, S: 1, R: 0) from socket (handle: 14)
2012-12-18 10:27:36.724752 <D> <usb.c:308> Broadcasting request (U: 0, L: 8, F: 254, S: 1, R: 0) to 1 Brick(s)
2012-12-18 10:27:36.724831 <D> <transfer.c:218> Submitted write transfer 0x8cac728 for 8 bytes to Master Brick [6dJgzT]
2012-12-18 10:27:36.724864 <D> <brick.c:477> Forced to sent request to Master Brick [6dJgzT]
2012-12-18 10:27:36.743694 <D> <transfer.c:62> Read transfer 0x8cabe38 returned successfully from Master Brick [6dJgzT]
2012-12-18 10:27:36.743814 <D> <brick.c:60> Got callback (U: 3425828921, L: 34, F: 253) from Master Brick [6dJgzT]
2012-12-18 10:27:36.743895 <D> <network.c:224> Broadcasting callback (U: 3425828921, L: 34, F: 253) to 1 client(s)
2012-12-18 10:27:36.744136 <D> <client.c:186> Forced to sent response to client (socket: 14)
2012-12-18 10:27:36.744216 <D> <transfer.c:218> Submitted read transfer 0x8cabe38 for 80 bytes to Master Brick [6dJgzT]
2012-12-18 10:27:36.744276 <D> <transfer.c:62> Write transfer 0x8cac728 returned successfully from Master Brick [6dJgzT]
2012-12-18 10:27:38.208589 <I> <client.c:57> Socket (handle: 14) disconnected by client

Gibt es neuere bindings ?

Wie hoch wohnst Du denn ?

Die Wetterdienste geben den Luftdruck immer auf Meeresniveau an.

Wenn ich mich recht erinnere must Du etwa pro 8-9m ein mb abziehen.

(Schaum mal im Wiki: barometrische Höhenformel oder ähnlich)

Hm, hat schon mal jemand in C einen erfolgreichen 2.0 enumerate Callback gesehen ?

Bei mir sagt der brickd2.0:

2012-12-17 16:41:01.790983 <D> <client.c:127> Creating client from socket (handle: 14)
2012-12-17 16:41:01.791052 <I> <network.c:89> Added new client (socket: 14)
2012-12-17 16:41:01.792155 <D> <client.c:85> Got request (U: 0, L: 8, F: 254, S: 1, R: 0) from socket (handle: 14)
2012-12-17 16:41:01.792201 <D> <usb.c:308> Broadcasting request (U: 0, L: 8, F: 254, S: 1, R: 0) to 1 Brick(s)
2012-12-17 16:41:01.792314 <D> <transfer.c:218> Submitted write transfer 0x9767728 for 8 bytes to Master Brick [6dJgzT]
2012-12-17 16:41:01.792354 <D> <brick.c:477> Forced to sent request to Master Brick [6dJgzT]
2012-12-17 16:41:01.800577 <D> <transfer.c:62> Read transfer 0x9766f70 returned successfully from Master Brick [6dJgzT]
2012-12-17 16:41:01.800633 <D> <brick.c:60> Got callback (U: 3425828921, L: 34, F: 253) from Master Brick [6dJgzT]
2012-12-17 16:41:01.800662 <D> <network.c:224> Broadcasting callback (U: 3425828921, L: 34, F: 253) to 1 client(s)
2012-12-17 16:41:01.800767 <D> <client.c:186> Forced to sent response to client (socket: 14)
2012-12-17 16:41:01.800840 <D> <transfer.c:218> Submitted read transfer 0x9766f70 for 80 bytes to Master Brick [6dJgzT]
2012-12-17 16:41:01.800899 <D> <transfer.c:62> Write transfer 0x9767728 returned successfully from Master Brick [6dJgzT]
2012-12-17 16:41:28.479791 <I> <client.c:57> Socket (handle: 14) disconnected by client

Die Programmstruktur ist etwa:

   
/* Callback for stack control */
void cb_enumerate(char *uid, char *conn_uid, char position, uint8_t hwv[3], uint8_t fwv[3],
			  uint16_t device_ident, uint8_t enumtype, void *udata) {


    fprintf(stderr," UID: %3.9s connected at UID: %3.9s @ position\n", uid,conn_uid,position);
    fprintf(stderr," Identifier: %2x\n", device_ident);

...}

in main() {
........
   ipcon_create(&Regmem->ipcon);
   if(ipcon_connect(&Regmem->ipcon, HOST, PORT) < 0) {
        fprintf(stderr, "Could not create brickd connection\n");
        exit(1);
    } else {
    	ipcon_register_callback(&Regmem->ipcon,IPCON_CALLBACK_ENUMERATE,cb_enumerate,NULL);
	usleep(100);
    	// Enumerate Bricks and Bricklets
	ipcon_enumerate(&Regmem->ipcon);
    }	
.....
}

Das ganze noch auf x86-linux.

Die brickd Connection klappt offensichtlich, aber der enumerate_cb bleibt aus.

Äh, ja sorry deshalb schaue ich ja auch immer auf die Timeline von der Ethernet-Erweiterung. Den Brickd wollte ich um ein direktes RS485 Protokoll über einen seriellen Treiber erweitert haben, aber das ist eine andere Geschichte.

Ich antworte mal auch wenn ich keines habe:

Prinzipiell sollte es gehen, ich habe bei mir TL-MR3020 und auch 3420 Router - die auch auf mips  basieren und unter OpenWrt laufen können -  als TF-Hosts laufen.

Das Board hätte sogar noch den Vorteil des doppelt so großen Flash-Speichers.

Die TLs benötigen (insbesondere für den Python-basierten brickd) in jedem Fall einen USB-Stick als ROM-Erweiterung. (4MFlash, auch 32M Ram).

Die TLs haben aber schon einen eingebauten USB-Port und der 3020 ist auch recht kompakt. Den USB-Port müsstest Du beim Carambola wohl auf jeden Fall nachrüsten - ausser wenn TF vielleicht irgendwann den brickd so erweitert, dass er (in Verbindung mit der Ethernet Extension) auch direkt über das LAN-Kabel kommuniziert. Für die Protokoll 1 Variante würde ich aber trotzdem auch eine USB-Partition als swap empfehlen, 32MB sind da wirklich hart an der Grenze.

Mit dem 2.0er C-brickd sollten die Speicherprobleme gelöst sein. Ich habe inzwischen den brickd2.0 und meine Sourcen mit dem OpenWrt-SDK kompiliert bekommen. Der Praxistest steht aber noch aus, auch wenn der neue brickd schon positiv angetestet ist. (Das System steuert bei mir Teile der Heizung und damit würde ein Ausfall zur Zeit etwas familiären Stress erzeugen.  Der Ersatzrouter ist aber gerade eingetroffen...

Also mein Prog war auch schon mit Protokoll 1 so aufgebaut, wie Ihr es für Version 2.0 empfehlt:

Das main() hat nur die ip_connection aufgebaut, enumerate() getriggert und danach im Wesentlichen im join_thread  gewartet.

Der weitere interne Ablauf inclusive der Device Initialisierungen läuft zunächst in den enumerate() callbacks ab.

Die eigentliche Programmfunktion resultiert dann aus zyklischen Callbacks, die (mangels entsprechender Fähigkeiten der Masterbrick) mittels der Monoflop Funktionalität des IO-Bricklets realisiert ist.

Mittels alarm() ist dann noch ein Watchdog realisiert, der bellt wenn der Monoflop-Callback ausbleibt.

Damit kann man das 'Echtzeitsystem' der Brick für den ganzen Ablauf nutzen.

Die Alternative wäre es auf dem Host zu realisieren, dann machen aber die Callbacks aus meiner Sicht keinen Sinn mehr.

Ok, also ein Callback mehr und join_thread() gegen pause() austauschen.

Der "disconnected()" kann dann ggf. das Prog. beenden oder auf einen Neuaufbau warten.

Erstmal danke für die Erläuterungen.

ipcon_join_thread habe ich benutzt um mein Program zu beenden wenn der brickd gestorben ist. Wie merke ich das jetzt ?

OOps

tffbcontrol.c: In function 'MasterBrickReset':
tffbcontrol.c:151:10: error: too many arguments to function 'ipcon_create'
ip_connection.h:293:6: note: declared here
tffbcontrol.c:151:10: error: void value not ignored as it ought to be
tffbcontrol.c:157:11: error: too many arguments to function 'ipcon_enumerate'
ip_connection.h:342:5: note: declared here
tffbcontrol.c:192:8: error: too many arguments to function 'ipcon_create'
ip_connection.h:293:6: note: declared here
tffbcontrol.c:192:8: error: void value not ignored as it ought to be
tffbcontrol.c:199:9: error: too many arguments to function 'ipcon_enumerate'
ip_connection.h:342:5: note: declared here
tffbcontrol.c:214:9: error: too many arguments to function 'ipcon_enumerate'
ip_connection.h:342:5: note: declared here
tffbcontrol.c: In function 'trimwhitespace':
tffbcontrol.c:262:3: warning: implicit declaration of function 'isspace' [-Wimplicit-function-declaration]
tffbcontrol.c: In function 'setupLCDDevice':
tffbcontrol.c:840:5: error: too few arguments to function 'lcd_20x4_create'
bricklet_lcd_20x4.h:92:6: note: declared here
tffbcontrol.c:842:5: warning: implicit declaration of function 'ipcon_add_device' [-Wimplicit-function-declaration]
tffbcontrol.c:854:35: error: too few arguments to function 'lcd_20x4_register_callback'
bricklet_lcd_20x4.h:107:6: note: declared here
tffbcontrol.c:857:34: error: too few arguments to function 'lcd_20x4_register_callback'
bricklet_lcd_20x4.h:107:6: note: declared here
tffbcontrol.c: In function 'setupVTempBricklet':
tffbcontrol.c:865:5: error: too few arguments to function 'temperature_create'
bricklet_temperature.h:95:6: note: declared here
tffbcontrol.c:876:35: error: too few arguments to function 'temperature_register_callback'
bricklet_temperature.h:110:6: note: declared here
tffbcontrol.c: In function 'setupRTempBricklet':
tffbcontrol.c:886:5: error: too few arguments to function 'temperature_create'
bricklet_temperature.h:95:6: note: declared here
tffbcontrol.c:899:35: error: too few arguments to function 'temperature_register_callback'
bricklet_temperature.h:110:6: note: declared here
tffbcontrol.c: In function 'setupSTempBricklet':
tffbcontrol.c:909:5: error: too few arguments to function 'temperature_create'
bricklet_temperature.h:95:6: note: declared here
tffbcontrol.c:920:35: error: too few arguments to function 'temperature_register_callback'
bricklet_temperature.h:110:6: note: declared here
tffbcontrol.c: In function 'setupIO16Bricklet':
tffbcontrol.c:949:2: error: too few arguments to function 'io16_create'
bricklet_io16.h:115:6: note: declared here
tffbcontrol.c:966:3: error: too few arguments to function 'io4_register_callback'
bricklet_io4.h:130:6: note: declared here
tffbcontrol.c: In function 'setupIO4Bricklet':
tffbcontrol.c:984:5: error: too few arguments to function 'io4_create'
bricklet_io4.h:115:6: note: declared here
tffbcontrol.c:1001:3: error: too few arguments to function 'io4_register_callback'
bricklet_io4.h:130:6: note: declared here
tffbcontrol.c: In function 'setupServoBrick':
tffbcontrol.c:1115:26: error: too few arguments to function 'servo_register_callback'
brick_servo.h:223:6: note: declared here
tffbcontrol.c: In function 'cb_enumerate':
tffbcontrol.c:1136:7: error: too few arguments to function 'master_create'
brick_master.h:246:6: note: declared here
tffbcontrol.c:1142:5: warning: implicit declaration of function 'master_get_version' [-Wimplicit-function-declaration]
tffbcontrol.c:1161:4: warning: implicit declaration of function 'lcd_20x4_get_version' [-Wimplicit-function-declaration]
tffbcontrol.c:1171:4: warning: implicit declaration of function 'temperature_get_version' [-Wimplicit-function-declaration]
tffbcontrol.c:1204:4: warning: implicit declaration of function 'io4_get_version' [-Wimplicit-function-declaration]
tffbcontrol.c:1215:4: warning: implicit declaration of function 'io16_get_version' [-Wimplicit-function-declaration]
tffbcontrol.c:1225:7: error: too few arguments to function 'imu_create'
brick_imu.h:253:6: note: declared here
tffbcontrol.c:1231:5: warning: implicit declaration of function 'imu_get_version' [-Wimplicit-function-declaration]
tffbcontrol.c:1246:7: error: too few arguments to function 'servo_create'
brick_servo.h:208:6: note: declared here
tffbcontrol.c:1247:4: warning: implicit declaration of function 'servo_get_version' [-Wimplicit-function-declaration]
tffbcontrol.c: In function 'main':
tffbcontrol.c:1324:5: error: too many arguments to function 'ipcon_create'
ip_connection.h:293:6: note: declared here
tffbcontrol.c:1324:5: error: void value not ignored as it ought to be
tffbcontrol.c:1330:6: error: too many arguments to function 'ipcon_enumerate'
ip_connection.h:342:5: note: declared here
tffbcontrol.c:1342:6: warning: implicit declaration of function 'ipcon_join_thread' [-Wimplicit-function-declaration]
make: *** [tffbcontrol.o] Error 1

Da ist ja doch die Wochendarbeit gesichert.

Warum kein ipcon_join_thread mehr ?

....

Na ich schau mir ersteinmal alle notwendigen Änderungen an...

Die Sourcen für udev wurden zum systemd verlegt. Siehe:

http://cgit.freedesktop.org/systemd/systemd

Sag mal für welche arm-Architektur brauchst Du denn das udev ?

Beim Raspberry sind entsprechende Pakete (armhf) vorhanden.

Dort kompiliert der brickd (bei mir) auch problemlos.

Ne udev messages kann ich nicht finden.

Ich schau mal im openwrt Forum nach, ob ich da noch etwas starten muss.

Zumindest die libudev ist da und auch verlinkt:

root@OpenWrt:/home/tfc# ldd ./brickd
libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0x77526000)
libudev.so.0 => /lib/libudev.so.0 (0x77509000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x774e6000)
libpthread.so.0 => /lib/libpthread.so.0 (0x774c0000)
libc.so.0 => /lib/libc.so.0 (0x77454000)
librt.so.0 => /lib/librt.so.0 (0x77440000)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x77542000)
libdl.so.0 => /lib/libdl.so.0 (0x7742c000)

Allerdings habe ich auch festgestellt, das die Bindings noch etwas auf Vervollständigung warten. Zumindest sind Definition und Deklaration von ipcon_enumerate schon unterschiedlich. Da warte ich doch mal die nächste Release ab.