Hallo,

na prima, so bauen wir alle unsere eigenen Libs für die Biene Ich baue ja auch daran herum - noch ein bißchen für mich selber, weil sie meines erachtens noch nicht so den Stand zur Veröffentlichung hat. Vielleicht liege ich damit auch falsch und sollte einfach ein freies Repository auf sourceforge anlegen, damit wir alle daran herumbauen können?

Jetzt aber zu Deiner Lib:

Mir ist gerade noch etwas wichtiges aufgefallen:

_Alle_ Variablen, die sowohl in den IRQs als auch in anderen Programmteilen verändert werden, mit "volatile" deklarieren! Sonst kann das unvorhersehbare Ergebnisse liefern: Der Compiler optimiert sonst unter Umständen unzulässig. Die atomaren Blöcke ersetzen _nicht_ volatile. Außerdem empfehle ich, alle vermeidbaren atomaren Blöcke wirklich wegzulassen.

Zitat Zitat von s.frings
Da passieren einige Dinge, die mit unnötig aufwendig erscheinen, manches ist wohl auch etwas konfus umgesetzt.
Dazu kann ich nur den Tipp geben: Genau darüber nachzudenken, was der Autor uns wohl damit sagen wollte. Denn bei einigen Dingen hatte ich auch immer zuerst das Gefühl "Was macht er es sich so schwer???". Aber nachdem ich das Datenblatt des ATmega gelesen hatte, wusste ich oft genug, warum

Zum Beispiel die PWM Steuerung: Wenn man die Fahrtrichtung ändert, wird der Motor zuerst gestoppt und erst beim nächsten Interrupt die neue Fahrtrichtung und Geschwindigkeit eingestellt. Das klingt ja erstmal sinnvoll, aber beim nächsten Interrupt steht der Motor noch lange nicht. Also muss man entweder viel länger warten oder man lässt es ganz bleiben.
Prima Beispiel für das, was ich oben meinte. Der Original-Code ist an dieser Stelle tadellos korrekt, alles andere ist mutig. Denn: Es wird nicht gewartet, bis der Motor stoppt, sondern bis der Motor nicht mehr durch die PWM bestromt wird, bevor die Fahrrichtung gewechselt wird. Und das finde ich durchaus sinnvoll, den Motor nicht mitten im bestromten Zustand andersherum zu polen. Wo ich Dir recht gebe: Der Kommentar an den ISRs ist etwas blöde - denn er wartet in der Tat nicht, bis der Motor steht.

Irgendwie nervt mich auch, dass die eigentlich winzigen Funktionen über mehrere include-Files und mehrere (nicht gleich lautende) Libraries (*.a files) verstreut sind.
Dazu habe ich zwei Anmerkungen: Zum einen gebe ich Dir recht, dass die Lib etwas konfus aufgeteilt ist - vor allem auch die Aufteilung auf mehrere .a-Dateien habe ich gar nicht verstanden. Sinn solcher Archive ist ja gerade die Zusammenfassung mehrerer Object-Dateien ist ( .o ).

Zum anderen sind verfolgen Libs einen anderen Ansatz als "normale" Programme. Deshalb ist es durchaus üblich und sinnvoll, die einzelnen Funktionen für die verschiedenen Peripherieteile in eigene C-Dateien zu schreiben, so etwas nennt man auch modulare Software. Das hat viele Vorteile: Wenn irgendwo ein Fehler bei einem Peripherieteil auftritt, weiß man sofort, in welcher Datei man suchen muss. Wenn mehrere Leute an einem Projekt arbeiten, hat jeder "seine" (bzw. "ihre") Dateien. Wenn man ein neues Projekt mit ein paar (aber nicht allen) gleichen Aufgaben / Peripherieteilen und ein paar neuen Teilen hat, kann man die Teile aus dem alten Projekt durch einfaches Kopieren übernehmen - und muss den Code nicht noch filetieren - welche Teile gehören jetzt wie wozu? Des weiteren sind in der Lib-Datei weiterhin die einzelnen .o-Dateien vorhanden. Der C-Compiler bindet in ein Projekt nur die .o-Dateien aus der .a-Datei ein, die wirklich eingesetzt werden. Bei nur einer .o-Datei also immer alles.

Wenn Du also eine _echte_ Lib bauen willst, die nicht jeder für sich anpasst und so wie sie ist weiter genutzt werden können soll, rate ich Dir unbedingt zu einem modularen Aufbau.

Übrigens ist in der Modularität und der Übernahme aus einem anderen Projekt auch die leichte Konfusität der Codes zu entnehmen: Übereinstimmende Funktionen sind von dem Nibo2 übernommen worden - schaut euch einfach mal dessen Sourcecode an

Und ich vermisse, dass der serielle Port als standart Eingabe und Ausgabe für stdio.h eingerichtet wird, so dass Befehle wie fgets, puts, prinf, etc.funktionieren.
Tja, klingt nach einer prima Idee An dieser Stelle müsste ich dann mal überlegen, wie das bei meiner Lib funktionieren könnte. Denn ich nutze die USART ganz anders, als eigentlich gedacht... Wie man dazwischen hin und herschalten kann - mal drüber nachdenken.

Überhaupt stecken in Deinem Code gute Ideen, mal sehen, ob ich etwas übernehmen kann

Viel Spaß noch beim weiter entwickeln

Ciao bantyy