Gratulation erstmal zu diesem Projekt!
Sehr schön, dass ihr auch mit C# gearbeitet habt. .NET wird immer so stiefmütterlich behandelt, da freut mich das besonders.

Ich habe mir mal euer Entwicklerhandbuch zu Gemüte geführt. Allerdings hab ich mich auf das Protokoll und die Lowlevel-Sachen beschränkt.

Dazu habe ich auch ein paar Anmerkungen:

Protokoll

Ihr schreibt, dass das Protokoll 256 Befehle unterstützt. Das klingt erstmal sehr viel, mit der Zeit wird das aber ganz schön knapp werden.
Es ist bei Protokollen immer gut, Platz für Erweiterungen zu lassen.
Mein Vorschlag: 127 statt 256 Befehle. Warum? So bleibt ein Bit für zukünftige Erweiterungen reserviert. Dafür kann man z.B. das MSB verwenden.
Ist es null, bedeutet es, dass es sich um einen 7-Bit Befehl handelt. Ist es eins, würde ein 15-Bit Befehl folgen.

Ihr habt eine "senderID", warum habt ihr keine Empfänger ID vorgesehen? So könnten mehrere Bots über einen Kanal kontrolliert werden.

Ich habe in der Dokumentation gar keine "Management" Befehle gefunden. Ein paar Beispiele für sehr nützliche Befehle:
-Auslesen einer Device Id / eines Device Namens => Identifizierung der Bots
-Abfragen der Firmware-Version => Kompatibilitätserkennung, Erkennung unterstützter Befehle
-Status Read => Unter Umständen ist es sinnvoll, den Status bestimmter Komponenten auslesen zu können (Ist der Pin als Ausgang gesetzt?, Läuft Timer x? etc)

Man kann das Protokoll schlank und viel flexibler gestalten, wenn man zusätzlich noch einige "generische" Befehle einbaut. Ich meine damit sowas wie
I²C-Read/I²C-Send, SPI-Read/SPI-Send. So kann ohne eine Protokollerweiterung eine große Menge an verschiedenster Hardware angesprochen werden.


Klassen und Methoden

Ich finde eure Eventnamen etwas unglücklich gewählt. Ihr bezeichnet eure Events mit OnIrgendwas. In der .NET-Welt werden damit üblicherweise die Methoden bezeichnet, die die entsprechenden Events auslösen.
Beispiel: Event: DataReceived => Trigger: OnDataReceived

Es ist also genau umgekehrt, was bei den Anwendern des Frameworks für Verwirrung sorgen dürfte.

Mir ist noch die Klasse "Micro" aufgefallen. Der Name ist ziemlich irreführend. Ich dachte zuerst an ein Mikrofon, als ich die Überschrift gesehen habe.
uController, MCU oder einfach MicroController wären aussagekräftiger.

Die Dokumentation eurer Klassenbibliothek habe ich nur überflogen. Mich würde die Kapselung der Klassen interessieren.

Mit wie vielen Klassen muss sich der Entwickler beschäftigen? Muss er alle Klassen nutzen oder kann er sich einfach
ein "Roboter-Objekt" erstellen und dieses mit Attributen versehen?


Ich wünsche euch viel Spaß und vor allem viel Erfolg bei der Weiterentwicklung und der Nutzung eures Frameworks!

Mfg