mikrocontroller.net

Forum: Compiler & IDEs Fehlerhafte dtostre Funktion


Autor: Klaus Hummel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Hummel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups, Version vergessen: avr-libc aus WinAVR-20040720

Klaus

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Hummel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Hummel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Hummel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Hummel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.