Plenz

Ich habe brickd und brickv von der alten Vorjahres-Version auf die 2.0.3 aktualisiert, aber wenn ich auf CONNECT klicke, passiert nichts. Es ist, als ob ich keine Hardware angeschlossen hätte. - 2 x installiert, deinstalliert - Registryeinträge gelöscht, Registry gesäubert - alles neu installiert alles ohne Erfolg. Komme mir total bescheuert vor, aber ich habe keine Idee, was ich noch versuchen könnte.

Ja, das wäre wirklich ein Traum, wenn man mit Tinkerforge-Bricks das machen könnte, was man z.B. mit der C-Control schon seit Jahren kann: Programm in BASIC schreiben kompilieren Brick flashen USB-Kabel abziehen Brick laufen lassen

Also, das Kompilieren und Flashen funktioniert jetzt. Aber wie es nun weitergehen soll, ist mir schleierhaft. C programmieren? Kein Problem: printf("Hallo Welt\n"); ist doch schnell geschrieben. Aber der hier vorliegende Dschungel aus Code ist undurchdringlich. Das soll keine Kritik sein, ein solches Projekt wie Tinkerforce muss so aufgebaut sein. Aber für Außenstehende ist es kaum möglich, eine Routine zu finden, weil sie in irgend einer von einem Dutzend Dateien stecken kann. Selbst wenn ich nur eine Stoppuhr programmieren möchte, die nach einem Pegelwechsel an einem Eingang des IO4 einen laufenden Zähler abfragt und dessen Stand per Interrupt an den angeschlossenen Computer ausgibt, sehe ich mich mit einem Haufen von Configs, Definitionen und Structs konfrontiert, die ich nicht ergründen kannn. Deshalb: Wir brauchen eine API!

Ich hab's heute noch mal radikal versucht: nicht nach der try-und-error-Methode einzelne Dateien ausgepackt und kopiert, sondern (nachdem ich nun wusste, was gebraucht wird), ganze Verzeichnisse aus der ZIP-Datei auf die Festplatte gezogen. Und siehe da: es ging! Testweise mal schnell die Versionsnummer geändert, kompiliert und geflasht. Mein IO4 hat jetzt die Version 7.0.0 So und das alles steht jetzt im Wiki unter "Firmware".

Ich bastele gerade an einer Anleitung zum Kompilieren von Firmware. Leider bin ich stecken geblieben und muss erst mal Fehler beseitigen. Edit: Fehler beseitigt, Wiki-Artikel fertig. Naja, ich weiß nicht... Leute mit dem Motto "Erst kaufen und dann überlegen, wozu das Zeug gut sein könnte" motivieren mich äußerst wenig.

So einfach ist das nicht. Mein Segelboot schwebt gern 50 Meter über der Ostsee trotz reichlich Satelliten. Die Höhenangabe ist immer viel ungenauer als die Koordinatenangabe.

Das mit dem Verzeichnis hat sich schon erledigt, es lag daran, dass ich in der BAT-Datei beim Rumexperimentieren ein ".\" gelöscht hatte. Meine bisherigen Erkenntnisse habe ich im Wiki abgelegt: http://www.tinkerunity.org/wiki/index.php/Firmware Aktuell würde ich gern wissen, woher die Fehler in CMakeLists.txt kommen. Ich habe das auf dem ZIP-Paket des Bricklets genommen.

Ich bin auch gerade beim Herausfinden, siehe Software, Programmierung und externe Tools --> Bricklet umprogrammieren. Mühsames Geschäft... Meine bisherigen Erkenntnisse habe ich ins Wiki gestellt: http://www.tinkerunity.org/wiki/index.php/Firmware Fortsetzung folgt, wenn die unter dem o.g. Forumeintrag dargestellten Probleme beseitigt sind.

Nun, das scheint noch eine relativ kleine Hürde gewesen zu sein. Also cmake runtergeladen und installiert. Dann wieder generate_makefile.bat aufgerufen. Fehler: cmake vermisst ein Verzeichnis "build". Wie was wo? Zum Glück wird es etwas tiefer auf der Seite "Firmware und Plugins" erwähnt. Also "\build" im Verzeichnis ...\software angelegt. Dann wieder generate_makefile.bat aufgerufen. Fehler: cmake vermisst im Verzeichnis \build eine Datei names CMakeLists.txt. Nach einigem Suchen finde ich sie in der ZIP-Datei des IO4. Dann wieder generate_makefile.bat aufgerufen. Fehler: Could not find toolchain file: toolchains/arm-none-eabi.cmake Auf meinem Computer gibt es kein Verzeichnis "toolchains". Meine letzte Hoffnung: die ZIP-Datei. Tatsächlich: unter dem Verzeichnis "build". Schön, dann weiß ich ja sogar, wo das Zeug hingehört. Dann wieder generate_makefile.bat aufgerufen. Ha! Mein Computer ist richtig am arbeiten! Zu früh gefreut: CMake Error at CMakeLists.txt:30 (ADD_EXECUTABLE): add_executable called with incorrect number of arguments -- Configuring incomplete, errors occurred! CMake Error at CMakeLists.txt:32 (SET_TARGET_PROPERTIES): set_target_properties Can not find target to add properties to: io4-bricklet.elf CMake Error at CMakeLists.txt:35 (SET_TARGET_PROPERTIES): set_target_properties Can not find target to add properties to: io4-bricklet.elf CMake Error at CMakeLists.txt:40 (SET_TARGET_PROPERTIES): set_target_properties Can not find target to add properties to: io4-bricklet.elf Ich glaube, ich muss an dieser Stelle mal wieder um Hilfe bitten.

Mal ganz dumm gefragt: wozu brauchst du einen Taster? Das Kit hängt sowieso per USB am Computer, und der Computer hat eine Tastatur...

Der Luftdruck kann ständig durch alle möglichen Ursachen verändert werden. Der Wind kann Luft in ein offenes Fenster drücken. Jemand öffnet oder schließt eine Tür. Die Heizung beginnt zu arbeiten, warme Abgase steigen aus dem Schornstein und erzeugen einen Unterdruck im Haus. Etc etc...

Runterladen? Danke für den Hinweis. In der Anleitung steht über den GCC, dass man ihn benötigt und runterladen muss. Über CMake steht da nur, dass er benötigt wird. Deshalb dachte ich, bei dem, was ich runtergeladen hatte, müsste alles dabei gewesen sein.

So weit, so gut. Ich habe ein bisschen im Forum herumgesucht und bin auf dieses Thema gestoßen. Ich habe die dort erwähnte Installationsdatei arm-2011.09-69-arm-none-eabi.exe runtergeladen und installiert. Was mir immer noch fehlt, ist das in generate_makefile.bat aufgerufene "cmake". Stattdessen gibt es ein cs-make, das aber die benutzen Optionen -E und -G bemeckert. Was tun?

Ich glaube, ich habe es rausgekriegt, und zwar anhand der #include-Zeilen in io.c. Demnach habe ich mir auch noch das Archiv "bricklet.lib" runtergeladen und so in meine Verzeichnisstruktur kopiert, dass die #include-Zeilen passen.

Noch eine Frage: wie setze ich dies um, ohne GIT zu benutzen? "Dann wird noch die bricklib benötigt, diese muss in den software/src/ Ordner der Firmware geclont werden (ein Symlink funktioniert auch)" Ich habe die ZIP heruntergeladen und habe ein Verzeichnis "Tinkerforge-bricklib-2b5c016" mit Unterverzeichnissen und Dateien. Was genau davon soll ich in mein Projekt io4\software\src\ kopieren? Wenn es mir gelungen ist, eine funktionierende Firmware zu kompilieren (erst mal ohne Modifikationen), schreibe ich gern eine Schritt-für-Schritt-Anleitung ins Wiki.

Danke, aber zum Rückgängigmachen genügt mir die Backup-Funktion meines Editors, und meinen Code braucht sowieso niemand, es geht um die Decodierung von 4 Tasten einer bestimmten Fernbedienung.

Ich kann mit einigen der ausgegebenen Werte nichts anfangen. Ist vielleicht die aktuelle Genauigkeit bzw. mögliche maximale Entfernung vom gemessenen Standpunkt dabei? Wenn nein, dann würde ich das mal als weiteres Feature vorschlagen. Insbesondere für Höhenangaben wäre das wichtig, die stimmen sowieso nie.

Ich würde mich gern mal vorsichtig an die Aufgabe herantasten, mein IO4-Bricklet mit ein paar speziellen Funktionen zu erweitern. Sprich: private Extrawurst ohne öffentliches Interesse. In der Docus steht etwas von Github und Clonen - aber muss ich das erstens verstehen und zweitens machen? Ich kann doch einfach die C-Sources so runterladen, wie sie dort zugänglich sind. Oder würde mir ohne das Clonen etwas fehlen? Und wo ich beim Thema bin: wieviel des verfügbaren Speicherplatzes belegt die jetzige Firmware?

Falls jemand in anderen als den hier angebotenen Sprachen programmiert: ich habe eine DLL erstellt, mit deren Hilfe man z.B. in BASIC das IO4-Bricklet ansteuern kann: Ausgänge schalten und Eingänge abfragen. Der Programmieraufwand beschränkt sich auf DLL-Aufruf definieren, UID des Bricklets angeben und DLL mit Pin-Maske der Ausgänge aufrufen bzw. DLL aufrufen und Wert der Pin-Maske der Eingänge erhalten. Bei Interesse lade ich die DLL gern hoch.

Ich hab's jetzt anders gelöst: einfach den Text aus ip_connection.c und bricklet_io4.c in mein Programm reinkopiert und doppelte Definitionen gelöscht. Ich habe auch den Versuch aufgegeben, init und exit getrennt aufzurufen, init-output-exit in einem Rutsch geht schnell genug. Die DLL ist zwar über 777 kB groß, aber sie funktioniert

Eigentlich programmiere ich nicht in VB (höchstens mal VBA für Excel), sondern in Rapid-Q. Das ist für kleine Projekte ideal, weil es einen nicht zwingt, sich mit Modulen und Modulgrenzen auseinanderzusetzen und weil das gesamte Projekt mitsamt den Definitionen für Form, Buttons, Schiebereglern etc. mitsamt dem Code in einer einzigen Datei abgespeichert werden kann. Und ich mag DLLs. Ich habe mich schon sehr ungern mit Python beschäftigt, nur weil ich mangels DLLs meine Bricks zum Laufen bringen wollte. Aus dem selben Grund nun in VB.Net einzusteigen, scheint mir genau so wenig verlockend. Momentan benutze ich für ein Projekt ein Rapid-Q-Programm, das meinen Input auswertet und Befehle für das IO4-Bricklets generiert und als kurze Textdatei ablegt, sowie ein primitives Python-Programm, das diese Dateien einliest und das Bricklet steuert. Funktioniert, aber es ist im Grunde genommen Krampf, auch wenn es viel besser läuft als mein Versuch, das alles in einem Python-Programm zu realisieren. Ich muss nur rauskriegen, wie ich den GCC aufrufe, und das Thema ist gegessen.

Ich kann mich mit Python nicht recht anfreunden, mit C noch weniger (wenn es um komplexe Aufgaben geht). Am liebsten programmiere ich in BASIC-Dialekten. Aber ein VB-Programm, das Bricklets ansteuern soll, braucht eine passende DLL. Nachdem ich nun das Beispielprogramm für den IO4 mit Hilfe von MingW zum Laufen gekriegt hatte, hatte ich versucht, es in die Aufgaben init, exit, input und output zu unterteilen und als DLL zu kompilieren. Natürlich ergebnislos, denn ich kriege nicht raus, wie ich die ganzen Komponenten einbinden soll. So kompiliert man eine einfache DLL: gcc -DBUILD_DLL -c test.c gcc -shared -o test.dll test.o test.def -Wl,--out-implib,testcmp.a So kompiliert man das Beispielprogramm: gcc -o example_configuration.exe brick_stepper.c ip_connection.c example_configuration.c -lws2_32 Aber wie kriege ich diese Vielzahl von C-Programmen in die zwei Kompilierungsaufrufe für die DLL eingebunden?

Argh! Das war's, vielen Dank! Ich hatte ja gleich so eine Ahnung, dass ich das nicht unter "Programmierung" posten sollte, sondern unter "Anfänger".

Och, das würde ich nicht so sehen. Die Tinker-Bausteine sind ja dafür da, damit man sich das bauen kann, was es noch nicht fertig zu kaufen gibt. Und was es nicht fertig zu kaufen gibt, hat auch noch niemand programmiert.

Es geht um die Ansteuerung des IO4 unter Win7 mit dem C-Beispiel. Richtig installiert ist alles, mit dem Brick-Viewer kann ich die Ausgänge des IO4 ein- und ausschalten. Das Kompilieren des Programms example_output.c funktioniert fehlerfrei mit dem MinGW gemäß der Anleitung in API_Bindings.html. Aber wenn ich das kompilierte Programm starte, erscheint "Could not connect to Bricklet" (was immerhin bedeutet, dass die IP-Verbindung funktioniert hat). Irgendeine Idee, was ich versuchen könnte?