@mifritscher:
nibo lib, nicht niboBEE lib
http://sourceforge.net/p/nibo/code/HEAD/tree/

Erklärung: Auf lange Sicht wollte ich die NIBObee Lib in die NIBO-Lib integrieren. Es wird natürlich weiterhin 2 Quellcode-Verseichnisse geben, aber nur ein Projekt und Installer. Dort soll auch die ARDUINO Version mit integriert werden. Daher ist der NIBObee-Arduino Code schon im NIBO-Lib Repository...

Ah, danke für den Tip mit dem Namen
Eine Lib für alles wäre natürlich genial

Ich kann auch vermelden, dass das Herunterladen von sourceforges SVN, Einrichten unter Ubuntu 12.04 und ein erstes Testprogramm auf der Biene problemlos funktioniert.

Ich habe das arduino-Paket von Ubuntu verwendet und in ~/sketchbox 3 Symlinks auf libraries, reference und Hardware gemacht.

Es gab nur eine Nickligkeit:
Bei meinem Tuningkit war ein ATMEGA 1284 und kein ATMEGA 1284p dabei, zumindest hat er die Signatur 0x1e9706 und nicht 0x1e9705. Das lässt sich in hardware/nicaisystems/programmers.txt mit einem beherzten usbasp.force=true beheben (avrdude in Ubuntu 12.04 kennt zwar einen atmega1284p, aber keinen atmega128).
Wenn es für dich ok ist lade ich das mal hoch.
Eine andere Frage: was machen wir mit Bienen, die zwar einen atmega1284 haben, aber mit einem Quarz von 15 MHz laufen (u.a. damit der programmier-AVR und der Quarz nicht ausgetaucht werden muss?) Kann man sowas noch innerhalb des Sketches richten oder muss dafür eine eigene Board-Variante her? Ich befürchte ja fast letzteres...

Ergänzung:
Ich habe gesehen, dass du bei der nibo2 die i2cmaster (noch? ) weiter verwendest, anstatt auf die Wire-Bibliothek von Arduino zu setzen. Ich würde ja dazu tendieren möglichst viel aus dem Arduino-Universum zu verwenden, schon um Konflikte vorzubeugen, wenn jemand Sketche ausprobiert, die die offiziellen Arduino-Bibliotheken verwenden (z.B. das Auslesen von Sensoren).
Was ist deine Meinung dazu? Oder ist das einfach noch aus "historischen" Gründen so?

Die FORCE Option würde ich nur sehr ungern verwenden, ich denke dass wir ein paar zusätzliche Plattformen schaffen müssen:
nicai-systems NIBObee robot (ATmega 16-15MHz [Standard])
nicai-systems NIBObee robot (ATmega 1284-20MHz [Tuning-Kit])
nicai-systems NIBObee robot (ATmega 1284-15MHz)
nicai-systems NIBObee robot (ATmega 1284P-20MHz)
nicai-systems NIBObee robot (ATmega 1284P-15MHz)

Die i2cmaster Datei würde ich gerne beibehalten - Ich würde auf lange Sicht den Code möglichst zusammenfassen. Dabei sollte
eine C Bibliothek, eine C++ Bibliothek und die Arduino-Version herauskommen, mit möglichst ähnlichen Funktions- und Methodennamen.
Die C Version der Bibliothek in arduino/library/NIBObee/utility und in src/nibobee sollte dann die selbe sein, der C++ Wrapper
aus der Arduino-Version ungefähr der gleiche wie die C++ Variante ohne Arduino. Die Klasse NIBO(bee) hätte dann mit und ohne Arduino
die gleichen Methoden...

Das ist nur ein erses Konzept, falls Du da andere Ideen hast lasse ich mich gerne überreden

Hallo workwind

Ich hoffe doch, dass auch weiterhin eine reine C-Library für den NIBO2 zur Vefügung steht (auch mit Updates), oder ist geplant, die NIBO2-Library (komplett) auf die Arduino-Plattform "hochzuheben" und man ist somit gezwungen, auf die Arduino-Plattform umzusteigen - das würde ich nicht unbedingt wollen; ich würde lieber beim "Urschleim-C" bleiben...

Zwar steht im obigen Post " Dabei sollte eine C Bibliothek, eine C++ Bibliothek und die Arduino-Version herauskommen.." (Zitatende), aber man weiß ja nie...

mfg

Egon

@egon: man kann das Arduino-Zeug auch ohne Arduino kompilieren, wenn man die Libs hat

hmm @i2cmaster.c...
Man könnte einen "Wrapper" bauen, die i2cmaster nach Wire umbiegt. Das sollte (i2c sei Dank ) nicht so viel Aufwand bedeuten. Ja nach Umgebung wird dann die bisherige i2cmaster oder der i2cmaster->Wire Wrapper gelinkt.

Die eigentliche "Logik" würde ich weiterhin in c-Dateien behalten, für c++ und Arduino gibts dann halt kleine Wrapper-dateien, die im Falle von arduino dann auch bevorzugt Bibliotheksteile von Arduino verwenden. Bei letzteres fallen mir auf Anhieb nur I2C und eventuell Timer ein, Port- und A/D Wandler. Zugriffe können wir denke ich auch ans restliche Arduine System vorbei "mogeln". So im Großen und Ganzen entspricht das bis auf die Verwendung von Wire (und später eventuell weitere Libs) grob deinem Konzept.

@Plattformen: Das wäre der sauberste Weg, ja. Ich bin auch kein Freund von "Gewalt" (force), nur gibt es bei arvdude den atmega1284 nur in der p- Variante. Das heißt man muss die avrdude.conf erweitern. Das würde auf eine eigene Version von dieser Datei hinauslaufen, weil ich nicht unbedingt möchte, dass systemweite Konfigurationsdateien geändert werden müssen. Können wir von der Arduino-Plattform aus avrdude mittels -C eine eigene Konfigdatei übergeben? Das wäre glaube ich ein sauberer Weg.