photron

Brick Viewer 1.1.12 speichert sich jetzt die letzten 5 Hosts.

Brick Viewer 1.1.12 hat jetzt einen Check-for-Update Dialog.

Brick Viewer 1.1.12

• Automatically restart Bricks after successful flashing a new firmware
  
• Check for invalid characters in SSID and key for WIFI Extension, only ASCII without the quotation mark is allowed
  
• Show WIFI encryption mode correctly
  
• Show version numbers in flashing dialog
  
• Remember the last 5 hosts
  
• Add Check-for-Updates functionality for connected Bricks and Bricklets
  

Downloads: Windows, Linux, Max OS X

Brick Viewer 1.1.12

• Bricks werden nach erfolgreichem Flashen automatisch neugestartet
  
• SSID und Key für die WIFI Extension werden vor dem Speichern auf ungültige Zeichen überprüft, es ist nur ASCII ohne das Anführungszeichen erlaubt
  
• Der gewählte WIFI Encryption Modus wird jetzt korrkt angezeigt
  
• Der Flashing Dialog zeigt nun Versionsnummern an
  
• Es werden jetzt die letzten 5 Hosts statt nur der letzte gespeichert
  
• Check-for-Updates für verbundene Bricks und Bricklets hinzugefügt
  

Downloads: Windows, Linux, Max OS X

Funktioniert hier mit

echo -n -e "\x01\x28\x04\x00" | nc -q1 localhost 4223

Hast du denn auch Firmware 1.3.5 und versorgst den Brick über USB?

Muesste man dann den brickd stoppen oder deinstallieren, damit man mit dem brick_flash_cmd das Brick flashen kann?

Nein, brickd und Flashen haben nichts mit einander zutun. Abgesehen, davon dass das Flash Script initial einmal über brickd mit dem Brick reden muss um ihn in den Bootloader bringen zu können, wenn das Script vollautomatisch Flashen können soll.

Der Ablauf wäre: flash.py verbindet sich mit dem lokalen brickd und ruft auf dem zu flashenden Brick die Funktion zum Wechsel in den Bootloader auf (diese Funktion gibt es im Moment noch nicht). Dann taucht der Brick als Seriel Port auf und flash.py schreibt die neue Firmware in den Flash. Zuletzt löst flash.py ein Reset des Bricks aus und er startet mit der neuen Firmware.

Dieses automatische Neustarten nach dem Flashen wird auch schon die nächste brickv Version können.

In der Doku ist es schon, nur haben wir noch keine neune Bindings veröffentlicht. Kommt in kürze, vielleicht heute noch wenn ich noch dazu komme.

Ich habe deinen Aufbau hier nachgestellt, kann das Problem aber nicht reproduzieren. Das Barometer funktioniert hier. Möglicherweise hängt diese Problem mit dem Sprungproblem zusammen und eine Lösung des Sprungproblems löst auch dieses Problem hier.

Okay, jetzt verstehe ich das Problem. Flashen per Kommandozeile ist auf der TODO Liste. Wird dann ein Python Script werden.

Ich kann das beschriebene Problem reproduzieren. Es hängt mit dem Schreiben aufs LCD zusammen. Dei genau Ursache ist noch nicht klar. Ich untersuche das grade noch.

Zum ° Zeichen: Das LCD hat einen speziellen Zeichensatz, der auch in der Dokumentation der write_line Funktion verlinkt ist:

https://github.com/Tinkerforge/lcd-20x4-bricklet/raw/master/datasheets/standard_charset.pdf

Der Zeichensatz beinhaltet ein Katakana Zeichen, das man als ° Zeichen verwenden kann.

Wie zwischen Unicode un dem speziellen LCD Zeichensatz abgebildet werden kann kannst du dem Unicode Beispiel entnehmen:

http://www.tinkerforge.com/doc/Software/Bricklets/LCD20x4_Bricklet_C.html#unicode

Mit brickd hat das Flashen von Bricks ja nichts zu tun. Du musst nur auf deinem 100km entfernten Rechner brickv starten.

Ja, genau das passiert dann. Der Unterschied bei der WIFI Extension ist, dass diese Callbacks immer an alle verschickt.

Einen Brick per Brick Viewer in den Bootlader zu bringen ist wohl möglich, braucht aber neue API. Ist auf der TODO Liste.

 

Remote FW update??? Bitte.

Auch das automatisiertere Flashen wird noch eine USB Verbindung zwischen Brick und Rechner mit brickv brauchen. Aber ja es sieht so aus als könnte man es so bauen, dass man zum Flashen eines Bricks keinen Knopf mehr am Brick selbst drücken müsste.

Reconnect ist für den Fall gedacht, dass die Association der WIFI Extension zum Access Point abreist und die Chance besteht das sie wiederkommt. Dabei tritt dann ein ECONNRESET Fehler (das ist der C Error Code) auf. Daraufhin versucht sich die IP Connection neu zu verbinden. Abgesehen von ein Paar Timeouts ist das für den Benutzer der API transparent.

Das da nicht zwischen brickd und WIFI unterschieden wird liegt daran, dass die IP Connection das nicht unterscheiden kann. Das Protokoll ist dahingehend transparent.

Dein Problem mit brickd ist, dass Callbacks nicht automatisch an alle ausgeliefert werden, sondern nur an die die es potentiell interesiert. Wer das ist erkennt brickd an den GetStackID Aufrufen. Wenn du brickd jetzt neustartest hat er das vergessen. Die Bricks versenden immer noch Callbacks nur stellt sie brickd nicht mehr zu.

http://www.tinkerforge.com/doc/Low_Level_Protocols/TCPIP.html#callbacks

Daher ist brickd hier ein schlechter Test für Reconnect. Bei der WIFI Extension passiert das nicht

Oder vielleicht besser, das angezeigt wird wenn neue Firmware-Versionen zur Vergügung stehen. Es wäre auch schön wenn man den Brick über den BrickletViewer in den Modus zum Flashen setzen könnte.

So ein "Check for Updates" im Brick Viewer ist geplant und da das mittlerweile mehrere Leute gewünscht haben wird das jetzt in Kürze kommen.

Einen Brick per Brick Viewer in den Bootlader zu bringen ist wohl möglich, braucht aber neue API. Ist auf der TODO Liste.

Was auch geht ist den Brick automatische nach dem Flashen neuzustarten. Das habe ich gerade in den Brick Viewer eingebaut

Barometer Bricklet Plugin 1.1.1

• Fix overflow in altitude calculation
  

Download: Plugin

Barometer Bricklet Plugin 1.1.1

• Überlauf in der Höhenberechnung korrigiert
  

Download: Plugin

Eine kleine Herausforderung war, den Temperatursensor auch auf meinem Smartphone Nokia N900 (Maemo-Linux) abzufragen, da dieses Python 2.5 hat, wo doch Python 2.6 gefordert wird (http://www.tinkerforge.com/doc/Software/API_Bindings.html#python).

 

Zum Glück war nur eine kleine Änderung notwendig:

In ip_connection.py musste ich an 3 Stellen "current_thread" durch "currentThread" ersetzen. Dies als kleine Anregung an die tinkerforge-Entwickler - Python 2.5 und Python 2.6 sind gar nicht so unterschiedlich.

Ist eingebaut, wird in der nächsten Release der Python Bindings drin sein.

Ohh, kann es sein das ich den ToggleButton erst in der Mainmethode setzen darf, oder sowas in der Art?

Sieht so aus. Wenn ich das Log richtig verstehe löst der Aufruf von findViewById die Exception aus:

private ToggleButton openclose = (ToggleButton) findViewById(R.id.openclosedoor);

Spontan ins Blaue geraten würde ich sagen du solltest den Aufruf in onCreate nach dem Aufruf von setContentView machen.

In der Gefahr den Hinweis darauf übersehen zu haben:

Warum sind lat/lon jeweils arrays? Was bedeuten sie?

Erwartet hätte ich double ^^

Die Koordinaten werden in DD°MM.mmmm’ Format ausgegeben, dabei ist DD°MM im ersten Wert des Arrays und mmmm’ im Zweiten. Bei genauerer Betrachtung verwenden wir sonst eigentlich eine andere Darstellung für Floatzahlen. Ich werde das zu einem Wert ändern, der sich dann so zusammensetzt: DDMM * 10000 + mmmm. Den Wert hier wirklich als float zu übergeben ist nicht drin, da floats zusätzlichen Code brauchen und das die Größe des Plugins sprengt.

Per Programm, Java 6 auf MacOSX Snow Leopard funktioniert alles!

 

Nun habe ich es als App umgeschrieben, Problem: Er installiert die App auf beiden Handys (Ein Emulator Android Froyo 2.2 und einmal SGS2 IceCream 4.0.4) die App, stürzen beim aufrufen jedoch ab.

Bekommst du dazu genauere Informationen? Einen Stacktrace der Exception? Oder wie äußert sich, dass es abstürzt?

Es wäre vielleicht wirklich eine gute Idee an einem gewissen Punkt zu sagen "das ist die API, was sagt ihr?"

http://www.tinkerunity.org/forum/index.php/topic,886.0.html

Was aber auch toll wäre ist, wenn man die Brick/lets per Software simulieren könnte; d.h. man könnte sich eine Hardware-Konstellation (per Config?) zusammenstellen und dann dagegen implementieren/testen ohne die Hardware schon zu haben (zB. GPS-Brick).

 

Stimmt,  die Plattformübergreifende Lösung dafür wäre ja ein am Brickd simuliertes Gerät ^^ Bzw. ein Simulationskit das nen brickd enthält.

 

Die Light-Variante wäre, dass in Sprachen wie C# und Java erstmal Interfaces für alle Devices erzeugt werden. Dann kann ich meinen Code gegen die Interfaces bauen und beliebige Bricklets durch Mocks austauschen (die dann auch nur das Interface implementieren müssen).

 

Möglicherweise mache ich da demnächst mal nen Pull Request draus

Das Problem daran ist dass dafür erstmal jemand die Logik der Bricks und Bricklets nachprogrammieren müsste.

Das GPS Bricklet ist gerade in Arbeit. Nach einem Vorschlag von AuronX möchte ich dessen API hier zur Diskussion stellen. Hier als Beispiel C/C++ und ja die Beschreibung fehlt noch. Falls etwas nicht aus der Signatur ersichtlich ist einfach fragen

http://www.tinkerforge.com/doc/Software/Bricklets/GPS_Bricklet_C.html

Oha. Kannsch die gefixte schon mal zum einbinden bekommen?

Du musst nur in bricklet_gps.c diese Zeile

typedef void (*coordinates_func_t)(char, uint16_t, char, uint16_t, uint16_t, uint16_t, uint16_t);

durch diese ersetzen

typedef void (*coordinates_func_t)(char, uint16_t[2], char, uint16_t[2], uint16_t, uint16_t, uint16_t);

Die Timeline sagt KW45 für GPS Bricklet. Im Moment testen wir einen Prototypen.