Nibo 2 Magazin

[geekalert]

Ich war gestern nach wenigen Stunden schon so unzufrieden mit dem Status Quo, dass ich nun unerwarteter Weise bereits begonnen habe, an meiner eigenen Lib/API zu arbeiten.
Es wäre schon mal halb so wild, wenn die API besser dokumentiert wäre, oder noch besser, im Source vollständig offenliegen würde. So sagt der Hersteller zwar, es sei möglich einen eigene Motorsteuerung zu entwickeln, aber nicht wie. Disassembliert enthält initializer2.hex etwa 10000 Zeilen. Das wird mich eine Weile beschäftigen. Dagegen wird der Rest der Lib ein Klacks.
Das es damit schwieriger für andre wird, meine Programme zu nutzen, ist zwar wahr, aber zumindest theoretisch bleibt die Möglichkeit, eine Kompatibilitätsschicht zu entwickeln, wenn das wirklich gewünscht wird. Die Coprozessor-Firmware von nicai ist nicht sonderlich groß, meine wird es wahrscheinlich auch nicht. Daher könnte man beide auf den Coprozessor flashen und mit einem SPI-Befehl umschalten. Da ich gerade an der Original-Firmware dran bin durchaus eine Option. Das Umschalten übernimmt dann die copro_init()-Funktion der Kompatibilitätsschicht.
Das NDS3-Modul habe ich auch, I2C steht damit ganz klar auf der Liste. Ein großes Problem sehe ich darin aktuell aber nicht. Für die Übertragung auf den PC werde ich erst mal WLAN verwenden, da ich die passende Hardware gerade rumliegen habe.
Langfristig wünsche ich auch noch einen AVR32 + FPGA und eine Omnivison CMOS-Kamera draufzusetzen.

Aber eins nach dem anderen ... ich hab Nibo doch erst ein paar wenige Tage.

Flo

[oberallgeier]

Hallo Flo,

die NIBO-Lib(s) kenne ich nicht, ich habe die Nibobee mit deren Libs. Die Libs der bee sind umfangreich und sehr gut dokumentiert. Als Tester der Bee hatte ich die etwas aufwendig - meist nicht wirklich bzw. wirklich nicht anfängergerecht - strukturierte Libdokumentation angemerkt, weil ich meine, dass der schiere Umfang der Library - nee, der Umfang der Dokumentation so groß ist, dass es den üblich gebildeten Anfänger einfach erschlägt. Wenn das beim Nibo genauso ist, kann ich mir den schnellen Frust vorstellen.

Ich war gestern nach wenigen Stunden schon so unzufrieden mit dem Status Quo ... theoretisch bleibt die Möglichkeit, eine Kompatibilitätsschicht zu entwickeln ...

Ich fände eine Kompatibilitätsschicht eigentlich unabdingbar - mehr noch. Wenn ich mir meine Spezialanfertigungen (autonome Coladose, WALL R und so) ansehe, dann habe ich ja auch zumindest streckenweise eine ähnliche Struktur zu bedienen. Nun könnte ich mir vorstellen, dass das Entwurfs-/Pflichtenheft die gleichen Funktionsaufrufe und Parameterlisten - und die gleichen Effekte - enthält für die originale und für Deine Library.

Dass unter Umständen umfangreichere Funktionen in einer neuen Bibliothek nicht mehr auseinanderklabüsert werden - und daher Unterfunktionen fehlen - dürfte nicht unbedingt von Nachteil sein. Im Gegenteil: dadurch könnte sich die Anzahl der Funktionsaufrufe straffen lassen - und damit natürlich die Bedienung übersichtlicher werden.

Aber es ist DEINE Bibliothek und dies sind nur meine Anmerkungen dazu im Vorfeld - noch dazu werde ich mir nen Nibo nie kaufen. Nix für ungut für diese Anmerkungen.

[geekalert]

Als Tester der Bee hatte ich die etwas aufwendig - meist nicht wirklich bzw. wirklich nicht anfängergerecht - strukturierte Libdokumentation angemerkt, weil ich meine, dass der schiere Umfang der Library - nee, der Umfang der Dokumentation so groß ist, dass es den üblich gebildeten Anfänger einfach erschlägt.

Ich möchte das noch etwas konkretisieren. Rückgabewerte sind nicht dokumentiert. Es fehlen Angaben, ob Funktionen sofort zurückkehren oder blockieren. Bei Funktionen der Motorsteuerung, wie copro_setTargetRel(), die Nibo ein gewisses Stück fahren lässt, ist beides denkbar. Meine Lib wird hier jedenfalls klar unterscheiden und beide Funktionalitäten bieten.
Anfängerfreundlichkeit ist für mich zweitrangig, Einsteigerfreundlichkeit hingegen erstrangig. Soll bedeuten: Wer gerade mit C anfängt wird es nicht leicht haben. Erfahrene C-Entwickler sollen aber schnell einsteigen können. Für mich setzt das klare Konventionen voraus und eine Dokumentation, die nicht nur blind die API beschreibt, sondern einen klaren Leitfaden bietet.

Und noch eine Korrektur zu meiner vorigen Aussage: Der Source von libnibo2.a liegt in der Tat vor. Aber ich gehe lieber unvoreingenommen an meine Eigenentwicklung heran.

Flo

[oberallgeier]

... Aber ich gehe lieber unvoreingenommen an meine Eigenentwicklung heran ...

Stimmt Flo, das ist eine ziemlich gute Möglichkeit etwas gut zu machen - dass man sich den eigenen Blick nicht von bestehenden Lösungen beeinflussen lässt.

WENN ich zu meiner Testzeit der nibobee schon PFleury´s Help-Manual gekannt hätte, hätte ich so einen Aufbau ja den nicai-Leuten empfehlen können (wär aber sicher, wie manche andere Testkommentare untergegangen). Aber das ist ja immer so ne Sache mit dem wenn und dem hätt ...

Jedenfalls wünsche ich Dir viel Erfolg (Geduld, Überblick, einen guten Wirkungsgrad ...) für Dein Projekt - und bin mal gespannt

[geekalert]

Jedenfalls wünsche ich Dir viel Erfolg (Geduld, Überblick, einen guten Wirkungsgrad ...) für Dein Projekt - und bin mal gespannt

Danke dir.
Im Moment komme ich gut voran. Die initializer2.hex brauche ich auch nicht weiter zu zerlegen, da ich mittlerweile alle Infos zusammen hab, um den Coprozessor selbst programmieren zu können.
Flo

[Hero_123]

Hallo geekalert

Dass Du eine eigene NiboLib kreieren willst, finde ich ganz interessant; mir als NIBO2-User wäre daran gelegen, eine einfache Schnittstelle zum CoProz zu haben - sprich: man sollte den CoProz ALLEINE und unabhängig vom Hauptproz programmieren/flashen können - derzeit geht das ja nur über das initializer2-hex (mit der unterlagerten tool-chain boost-lib, hex2carray.c usw) und als "simpler user" habe ich leider keine Möglichkeit, den CoProz alleine zu programmieren (außer ich installiere die tool-chain...)

Also wenn Du da was "auf die Beine stellst", womit man problemlos den CoProz alleine programmieren kann - DAS(!!) WÄRE hilfeich!

Hero_123

[Achim S.]

Hallo
ich kann mich der Meinung von Hero nur anschliessen. Es sind viele Sachen unklar. Da kommt so etwas gerade recht. Ich mit der Schnittstelle währe es sehr gut. Kannst uns ja ein bisschen teilhaben lassen an deinen Erfolgen. Mit Hero und mir hast du gleich die richtigen Tester gefunden. Bin gespannt was weiter kommt.
achim

[Hero_123]

Hallo geekalert

Lass mal sehen, wie Du das machst: "Für die Übertragung auf den PC werde ich erst mal WLAN verwenden, da ich die passende Hardware gerade rumliegen habe." => wie sieht da der Code aus, wleche HW verwendest Du denn?

Hero_123

[geekalert]

Das Gerüst habe ich zwischenzeitlich schon mal in ein Inkubations-Projekt auf github gesteckt (https://github.com/falbrechtskirchinger/jdp-incubator).

mir als NIBO2-User wäre daran gelegen, eine einfache Schnittstelle zum CoProz zu haben - sprich: man sollte den CoProz ALLEINE und unabhängig vom Hauptproz programmieren/flashen können - derzeit geht das ja nur über das initializer2-hex (mit der unterlagerten tool-chain boost-lib, hex2carray.c usw) und als "simpler user" habe ich leider keine Möglichkeit, den CoProz alleine zu programmieren (außer ich installiere die tool-chain...)

Tatsächlich arbeite ich aktuell daran den Coprozessor zu programmieren. Neben mir sitzen momentan ein ATmega2560 auf einem STK600 und ein ATmega8 auf einem STK500. Ziel ist es den ATmega8 über den ATmega2560 zu programmieren. Kompliziert ist das ISP-Protokoll nun ja nicht. Ich rechne mal vorsichtig morgen Abend mit ersten Ergebnissen.
Nach erfolgreichem Test möchte ich dann Nibos Coprozessor selbst programmieren.
Später wäre es durchaus interessant den Coprozessor direkt vom PC zu programmieren. Da fallen mir spontan mehrere Möglichkeiten ein. Für den Anfang würden sich wohl IR + Bootloader auf dem Coprozessor anbieten.

Lass mal sehen, wie Du das machst: "Für die Übertragung auf den PC werde ich erst mal WLAN verwenden, da ich die passende Hardware gerade rumliegen habe." => wie sieht da der Code aus, wleche HW verwendest Du denn?

Das WLAN-Modul stammt von Avisaro. War zumindest vor ein paar Jahren im Vergleich zu XBee noch unverschämt teuer, aber lohnt sich aus meiner Sicht, da ich nun von jedem PC/Smartphone aus darauf zugreifen kann. Angesprochen wird es über USART, SPI, I2C oder CAN. Die Datenrate ist jedoch mit maximal 1 MBit/s nicht berauschend.
Flo