On Device Programming Interface

Hi,

wie gesagt bin ich ja neu auf dem Gebiet - möchte mich aber damit auseinander setzen und plane, meine Dachfenster automatisch zuziehen zu lassen sobald es regnet (Feuchtigkeitssensor und Motorsteuerung mit Spule/Winde).

Wie ich jetzt aus den Tutorials erfahren habe, lassen sich die Bricks lediglich mittels einem PC steuern. Ich ging ursprünglich davon aus, dass man den compilierten Code auf den Chip überträgt und er dort ausgeführt wird. Autarges System also.

Da ich keinen PC unter mein Fenster stellen will, frage ich mich wann die API für das "On Device Programming" fertiggestellt wird? Wird es dann sehr viel aufwendiger, soetwas zu realisieren (Sensoren auslesen, darauf reagieren etc)?

Vielen Dank für eure Hilfe!

Genau für solche Fälle habe ich mir die Funkerweiterung zugelegt.

Das ist richtig,allerdings muss ja dann trotzdem ein PC laufen,auf dem das Programm/Script ausgeführt wird. Ich will meinen Pc aber nicht 24/7 laufen lassen.

Nun ja, auf den Standalone-Betrieb warten sicher noch mehrere. Dazu müsste TF sich äußern.

Allerdings kann man von einem 3 Mann Unternehmen nicht zu viel erwarten.

Davor sind sicher noch andere Dinge wichtiger, die gelöst werden müssten.

Wieso kann ein PC nicht 24/7 laufen ? Das machen gewiss zahlreiche Media-Server oder File-Server in vielen Haushalten. Nettop-PC haben geringen Verbrauch 15-30 Watt...

Und dann ist da noch der Raspberry-PC, den es noch nicht so richtig zu kaufen gibt. Ev. hängt das eine mit dem anderen zusammen.

Ein Zeitplan für des Low Level Interface würde mich auch interessieren. Ich warte da drauf.

Möchte nicht unverschämt sein aber so eine Grobübersicht, wann und womit mittel- und langfristig zu rechnen ist - also eine Roadmap - würde sehr helfen, um das eine oder andere auf Kundenseite selber einplanen zu können oder entsprechend zu reagieren.

Wow, von dem Raspberry-PC habe ich noch nie gehört...jetzt bin ich auch scharf auf so ein Teil 

Idee: wenn es so einen "PC" bereits so klein gibt, wäre es dann nicht möglich ein Brick zu entwickeln, auf dem der Daemon läuft und die Steuerung der Bricks übernimmt? Also ein Zusatz-Main-Brick, der als PC dient.

Dann müsste man die Firmware nicht flashen, bräuchte keinen 24/7 PC und es wäre ein absolutes Standalone-System!

Verstehe noch nicht ganz was dein Wunsch ist.

Du könntest jeden Brick direkt an den Raspberry anschließen (per USB) und es sollte laufen (weil der brickd ja auch auf dem Pi installiert werden kann).

Ansonsten ist auch noch eine Master Extension geplant die WLAN/Ethernet hat. Diese soll dann wohl den Daemon quasi selbst ausführen, man kann sie also direkt per IP ansprechen. Dazu habe ich auch schon den Wunsch nach Power-over-Ethernet gelesen, aber kA ob das auch umgesetzt wird, es wäre aber sehr geil, um das mal so zu sagen ^^

Du könntest ja direkt die Firmware bearbeiten und das Brick (heißt das "das Brick"?) neu flashen. Dann gehts auch ohne PC. Ist ja im Grunde ein einfacher Microcontroller.

@Auron

Power-over-Ethernet ?

Powerversorgung geht doch mittlerweile auch über USB direkt, wenn man daran nur eine 5V Quelle anschließt.

@bauerb

Ist das so einfach möglich für uns Kunden, wie Du schreibst ? Wenn ja, warum wurde es noch nicht von TF umgesetzt, und wir alle könnten mit unseren Master-Bricks den Standalone Betrieb nutzen ?

Steht doch alles auf der HP (http://www.tinkerforge.com/doc/Software/Firmwares_And_Plugins.html).

Alles was du brauchst ist der C-Compiler, SAM-BA (Tool von Atmel um den Controller über USB zu flashen), CMAKE als Build-Tool und die Sourcen, die, da sie Open Source sind, auf github zugänglich sind.

Technisch ja, aber so ein Standalone-Betrieb muss erstmal ausprogrammiert werden. Wie gesagt wenns so einfach ist, warum hat es TF noch nicht umgesetzt, aber Du kannst Dich auch gerne daran wagen.

Ja klar... So einfach, wie ein Python-Programm auf dem PC zu schreiben ist es nicht. Das ist Low-Level-Programmierung mit allem Drum und Dran.

Es ist definitiv nicht für einen Anfänger empfehlenswert selbst an der Firmware rumzufummeln... würde ich behaupten wollen...

Wegen Power over Ethernet: Das wäre dann eine Alternative, wenn du irgendwo anders nen PC zu stehen hättest der villt doch schon läuft oder wenn deine Dachfenster so weit auseinander sind, dass du ansonsten zwei Rechner bräuchtest. Dann würde der PC die Bricks über Netzwerk ansteuern und die Bricks hätten nur ein Kabel nötig, nämlich das Netzwerkkabel.

Aber klar, wenn du den PC direkt am Brick hast, dann ist USB sinnvoller.

P.S.: PC meint hier auch sowas wie den Raspberry Pi ^^

Möchte nicht unverschämt sein aber so eine Grobübersicht, wann und womit mittel- und langfristig zu rechnen ist - also eine Roadmap - würde sehr helfen, um das eine oder andere auf Kundenseite selber einplanen zu können oder entsprechend zu reagieren.

Stimme voll zu:

Das mit der Roadmap hatte ich ganz am Anfag (noch im alten Forum) auch mal vorgeschlagen. Ich fänd das auch immer noch sehr hilfreich. Es wäre in meinen Augen gar nicht schlimm, wenn dann letztlich Deadlines etc. nicht eingehalten werden würden oder mal eine spontane Umplanung stattfänd. Es soll euch nicht die Flexibilität nehmen und irgendwodrauf festnageln. Aber für uns Kunden fänd ich es sehr angenehm, eine grobe Vorstellung von euren groben PLanungen zu haben :-)

@AuronX

Also haben wir damit die gleiche Situation wie mit USB, Daten wie auch Stromversorgungsleitung.

http://de.wikipedia.org/wiki/Power_over_Ethernet

Ich meinte, falls man vom PC entkoppelt ist, aber dennoch den Brick mit Strom zu versorgen hat, reicht es eine 5V Stromquelle über USB anzuschliessen.

@NIC

Ich denke auch, daß es so einfacher ist. Die Stacks über Funk ansteuern, dann müssen keine zusätzlichen Kabel verlegt werden. Strom müsste ja vor Ort verfügbar sein, denn die Dachfenster brauchen ja auch eine Motorisierung.