-         

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 13

Thema: Rechenproblem (Syntax?)

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    13.05.2007
    Alter
    26
    Beiträge
    183

    Rechenproblem (Syntax?)

    Anzeige

    Hallo.

    Ich habe hier einigen Code, der ein anderes Ergebnis auspuckt, als mir logisch erscheint. Ich vermute ein Syntaxproblem, da ich noch nicht allzulange mit C arbeite:
    Code:
    #define MinValue 0
    #define MaxValue 1024
    ...
    uint16_t val11,val12,val21,val22,resval1 = 0,resval2 = 0;
    char result;
    ...
    result = (char)(((resval2-MinValue)*128)/MaxValue);
    wenn resval2 512 ist, kommt Null raus, obwohl 64 rauskommen sollte.

    Vielleicht kann mir jemand auf die Sprünge helfen.
    Danke,
    Bääääär

  2. #2
    Benutzer Stammmitglied
    Registriert seit
    03.11.2004
    Ort
    Süderlügum
    Alter
    36
    Beiträge
    86
    Ja, das liegt an dem uint16_t. Der ist zu klein.
    512*128=65536 (Hex wäre das 0x10000). uint16_t kann nur bis 65535 (0xFFFF, also 2 Byte = 16 Bit, daher uint16). Also Überauf, er fängt dann wieder bei 0 an. Und 0/1024 ist 0.

    Edit: Lange Erklärung, kurzer Sinn... nimm nen uint32_t, dann passts wieder.

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    13.05.2007
    Alter
    26
    Beiträge
    183
    Joh, stimmt, das war's. Ich hatte das ganze auch schon andersherum (erst dividieren, dann multiplizieren) aber da hat der Compiler wahrscheinlich ein und dasselbe draus gemacht.

    Danke, jetzt weiß ich zumindest beim nächsten Mal, wo ich den Fehler suchen kann ^^

    Bääääär

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    15.02.2008
    Beiträge
    27
    Will jetzt keinen neuen Thread erstellen, da ich ein ähnliches Problem wie
    Bääääär habe.
    Code:
    void Int7print(void)
    {
    uint32_t hi_time,low_time;
    
    
    hi_time = (high_pulse *64);
    low_time = (low_pulse *64);
    
    
    itoa(high_pulse,Portt,10);
    Printat(0,2,Portt);
    
    itoa(low_pulse,Portt,10);
    Printat(7,2,Portt);
    
    double freqq = (1 / (hi_time + low_time)) *1000000;  
          
     
    dtostrf(freqq,4,2,Portt);
    Printat(12,2,Portt);
    
    int7=false;
    Dort sollte eine aus den Timer Werten (vom ext INT7 die Frequenz berechnet werden.
    Habe einen ext. Funktionsgenator an INT 7 PIN.
    Die angezeigten Timer Werte (Low/High) sind plausibel.

    Als Frequenz wird mir aber immer 0.00 angezeigt ? warum ?
    Printat(x,y,wert) schreibt ins LCD

    Bin ein Umsteiger von Pascal auf C

    Gruß

  5. #5
    Benutzer Stammmitglied
    Registriert seit
    10.08.2007
    Beiträge
    47
    Hi,

    hi_time und low_time sind Integer. Du fuehrst eine Division mit Integern durch (1/Integer). Dabei kommt immer 0 raus. Erst am Ende wird diese Integer-0 in eine Double-0 umgewandelt ...
    Du musst entweder die 1 oder das Ergebnis deiner Addition zuerst in einen Float/Double Wert umwandeln. Diese Art Fehler wurde hier schon mehrfach angesprochen.
    Wenn Dir diese Aussage allein nicht weiterhilft, kannst Du ja noch etwas hier suchen. Du wirst bestimmt fuendig. Zusaetzlich sind da noch viel mehr Erklaerungen zu finden.

    hth
    Kay

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    33
    Beiträge
    2.382
    ich möchte hier ma anmerken was ich mit dem GCC erlebt habe, gut möglich das ihr damit auch manchmal probleme habt
    uint32_t hi_time,low_time;
    nachdem ich jede variable EINZELN deklariert habe (also nicht durch komma getrennt) haben sich bei unserem kleinen asuro-projekt urplötzlich ALLE undefinierten verhalten in wohlgefallen aufgelöst!

  7. #7
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    12.11.2004
    Ort
    Hvalstad, Norwegen
    Beiträge
    140
    Versuch es doch mal mit einem sogenannten Cast, das heißt du nimmst die Integer-Werte und wandelst sie vor der Berechnung in Double-Werte um. Das geschieht durch das "double" in Klammern.

    Und ganzzahlige Konstanten, die Fließkommazahlen bzw. Double-Werte enthalten immer mit nem ".0" abschließen, sonst sind es Integer-Werte.

    Und wie schon gesagt die Deklarationen für Variablen immer an den Anfang der Funktion, der GCC mag das nicht so gerne und das ist auch übersichtlicher.

    Code:
    void Int7print(void)
    {
    uint32_t hi_time,low_time; 
    double freqq;
    
    hi_time = (high_pulse *64);
    low_time = (low_pulse *64);
    
    
    itoa(high_pulse,Portt,10);
    Printat(0,2,Portt);
    
    itoa(low_pulse,Portt,10);
    Printat(7,2,Portt); 
    
    freqq = (1.0 / ((double) hi_time + (double) low_time)) * 1000000.0;
    Gruß Lorcan

  8. #8
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    33
    Beiträge
    2.382
    vorsicht mit dem casten, die variable wird dann nur INTERPRETIERT aber wenn du mit einer gecasteten variable rechnest, wird ihr speicher dadurch NICHT größer!!! aber auf double zu casten hilft ungemein wenn du die nachkommastellen mitnehmen willst ...

    Code:
    ((double) hi_time + (double) low_time)
    schmeckt mir iwie nicht, da kommt am ende was undefiniertes bei raus möchte ich meinen ... evtl. die ganze klammer nochmal casten.
    aber ob da nicht signifikante bits unter den tisch fallen ??? notfalls die berechnung vorher in einer echten double zwischenspeichern und dann mit dieser rechnen ... ich vertrau dem GCC nicht mehr so recht was klammern und deklarationen angeht

  9. #9
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    15.11.2004
    Ort
    Aachen
    Alter
    32
    Beiträge
    246
    Sobald du das als double castest, rechnet er damit auch als double. Auch mit dem entsprechenden Platzbedarf!

    Und wieso sollte da etwas undefiniertes rauskommen? Klar, wenn hi_time um einen bestimmten exponenten größer ist, fällt low_time unter den Tisch. Aber das hast du genauso, wenn du diese Variablen als double vorliegen hast...
    Das liegt ganz einfach an der internen Speicherung des Datentyps.

    Pro Berechnung verwendet der GCC immer den größten Datentyp der einzelnen Summanden/Multiplikatoren.

    So wie Lorcan es geschrieben hat, sollte s also keine Probleme geben.

    Gruß
    zerush

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    33
    Beiträge
    2.382
    jut, danke für die lehrstunde, ich klopf auf holz, der GCC hat mir schon so einiges serviert, wo es keine warnings gab aber das prog total rumgesponnen hat .... liegt wohl daran das ich meine programme nicht immer wohlüberlegt schreibe sondern lieber 10min ins debuggen investiere ... blöd nur bei nem mega8 gibs kein debugging ^^ nur simulation und die geht nur bedingt ohne die hardware XD

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •