Hallo zusammen!
Wir sind über einen seltsamen Fehler gestolpert.
Wir nutzen die avr-libc Funktion dtostre zum Formatieren
von Float Zahlen (und Ausgabe über die serielle Schnittstelle).
Die Zahlen werden mit Precision = 3 ausgegeben.
Bei verschiedenen Zahlen funktioniert die Funktion aber nicht:
Beispiel:
#include <stdlib.h>
int main(void)
{
float zahl=1e-15;
char txt[20];
dtostre(zahl, txt, 3, 0);
while(1) {};
}
Im Buffer txt steht als Ergebnis ":.000e-16".
Haben wir was falsch gemacht, oder ist das ein Fehler der Funktion?
Klaus
Eine Reihe derartiger Fehler habe ich eigentlich vor langer Zeit schon beseitigt, kann dir aber gerade nicht sagen, ob es dtostre() oder dtostrf() damals war, möglicherweise Letzteres. Deinen Bugreport habe ich gesehen (danke!), das wird dann mit bearbeitet.
Erst nach der Anfrage im Board ist mir eingefallen dass es ja ein Bug Tracker auf der avr-libc gibt (hoffe meine Eingaben waren korrekt). Ich habe die avr-libc Realease 1.2.1 noch nicht probiert. Aber der Sourcecode der dtostre Funktion scheint sich zur Version 1.0.4 nicht geändert zu haben. Klaus
@Jörg Habe mir die Version avr-libc-1.2.1 nochmal angeschaut. Mir ist aufgefallen, dass es keine Test Verzeichnisse (TestSuite, Testcases o.ä.) gibt, in denen die Ergebnisse der Funktionen geprüft werden. Wie prüft ihr ob eine Funktion das macht, was sie soll? Habt ihr eine Art Testsuite/Framework? Klaus
Nein, es gibt beginnende Aktivitäten für test suites, aber bei weitem noch nichts Vollständiges. Im Moment ist es wohl so, dass der GCC bald auch eine AVR-Testsuite bekommen kann (zusammen mit einem Simulator), sodass die GCC-Entwickler den AVR-Teil künftig auch in einem standardisierten Verfahren werden testen können. Eine ,,vollständige'' test suite zu bauen, dürfte weit mehr Mannstunden benötigen, als bislang in der avr-libc drinstecken.
Momentan programmiere ich ein ARM System (unter C/Cpp) und ein kleines System mit AVR (Atmega16/32 unter C). Ein großer Teil der AMR Software wird unter Windows zuerst programmiert und mittels CPPUnit getestet. Zuerst haben wir nur Klassen damit getestet. Nachdem ich einige Fehler entdeckt hatte (und restlos begeistert von automatischen Testtools war) nutzte ich das System auch um die "alten" C Routinen von mir zu checken. Bäng, Treffer: da nutze ich doch seid Jahren tatsächlich eine selbstgeschriebene Formatierfunktion um int Zahlen schnell in Strings zu wandeln, die aber einzelne fehlerhafte Werte liefert! Damals hatte ich natürlich die Funktion "getestet", aber eben nur stichprobenhaft ohne automatisierte Tests. Ich habe gestern mal im "QuickNDirty" Verfahren ein kleines Testcase Programm geschrieben. Ist nicht fertig aber ausbaufähig. Dabei habe ich mehrere Werte gefunden, für die dtostre falsche Ausgaben liefert (gilt das als Déjà-vu Erlebnis :-)? Im Anhang schicke ich dir das Testcase File. Momentan nutze ich nur zwei Makros TX_ASSERT(condition) und TX_FAIL(msg). Man könnte aber das ganze natürlich noch wie in der CPPUnit erweitern um Makros TX_ASSERT_EQUAL(),TX_ASSERT_EQUAL_STRING() usw. Fehlerhafte Test können über die serielle Schnittstelle ausgegeben werden. Der Clou: Man kann das Programm aber auch so kompilieren, dass die Daten im AVR Simulator auf PortA geschrieben werden. Das mitgeloggte File konvertiert man mittels VBScript in ein lesbares Textfile. Beispiel: Start of test Tests\d2stre_Testcase.c: 43: error: Tests\d2stre_Testcase.c: 47: error: Tests\d2stre_Testcase.c: 48: error: End of Test Nr. of Errors: 32 ------------------ Hast du Interesse an dem Programm? Wie gesagt, nix kompliziertes. Es ist noch kein komplettes AVR-Test-Framework, aber es sind oft die einfachen Dinge im Entwicklerleben... Klaus
Nicht ganz uninteressant, allerdings ist dtostre() natürlich eher eine unbedeutende Funktion. ;-) Soll heißen, für den großen Rest der Bibliothek wären automatisierte Tests wichtiger. Dass es für so viele Fälle statt "1.00eXX" ein :.00eYY" ergibt mit YY = XX - 1, ist natürlich ein systematischer Fehler. Da bin ich gerade am Gucken. Das Ganze ist halt gruseliger Assemblercode, der zwar sparsam mit ROM ist, aber alles andere als sparsam mit der Debug-Zeit für den Entwickler :-( (zumal die benutzten Register teilweise zweifach indirekt mittels #define obfuscated sind). Was sind die anderen Fehler, wo nur `fail' dransteht? An einer gut ausgebauten Testsuite wäre schon Interesse, aber dann bitte nicht hier im Forum diskutieren, sonder auf avr-libc-dev at nongnu.org. Außerdem bitte dran denken, dass nur ein Mitglied der Entwicklergemeinde der avr-libc überhaupt ein Windows besitzt, es muss also alles auch unter Unix laufen. Nix VBscript oder so. Wenn du Lust hast, kannst du dir ja mal die Testsuites angucken, die Dmitry K. für seine Verbesserungsvorschläge geschrieben hat (die machen aber wieder das andere Extrem, die sind komplett auf bash-Shell getrimmt), er hat dort sehr viel auch über den Simulator geschickt und das Ergebnis der Simulation dann über das vom Simulator hinterlegte ``Core-File'' (Zustand der CPU am Ende der Simulation) ausgewertet.
> Dass es für so viele Fälle statt "1.00eXX" ein :.00eYY" ergibt mit > YY = XX - 1, ist natürlich ein systematischer Fehler. Ja, denke ich auch. >Was sind die anderen Fehler, wo nur `fail' dransteht? Hab die testresults mal umformatiert, siehe Anhang. > An einer gut ausgebauten Testsuite wäre schon Interesse, aber dann > bitte nicht hier im Forum diskutieren, sonder auf avr-libc-dev at > nongnu.org. Ok, bin noch nicht ganz up to date mit der avr-libc-dev Liste. > Außerdem bitte dran denken, dass nur ein Mitglied der > Entwicklergemeinde der avr-libc überhaupt ein Windows besitzt, es muss > also alles auch unter Unix laufen. Nix VBscript oder so. Das ist nicht das Problem. Das kleine VBScript kann ich auch in Python schreiben. Bash, mmmh, lang ist's her. Habe zum Testen übrigends den AVR-Studio Simulator genutzt. Deshalb Windows. > Wenn du Lust hast, kannst du dir ja mal die Testsuites angucken,... > er hat dort sehr viel auch über den Simulator geschickt und > das Ergebnis der Simulation dann über das vom Simulator hinterlegte > ``Core-File'' (Zustand der CPU am Ende der Simulation) ausgewertet. Ok, werde ich mir mal anschauen. Wenn ich die Diskussion richtig verstanden habe läuft alles auf Basis der Simulation. Meine Intension ist eine etwas andere, ich hätte gern eine Testsuite, die - auf der Hardware oder dem Simulator läuft - also (fast) Platform-/Prozessorunabhängig - keine komplizierte Core-Dumps auswertet - sehr einfach ist, sonst wird sie nicht benutzt Ich möchte ja auch meinen Code im System (mit angeschlossener Peripherie) testen können. Kann ich dir noch irgendwie helfen? Klaus
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.