Display fällt in unregelmäßigen Abständen aus

Hallo Florian,

wieviel SRAM besitzt der ATMEGA8 und wieviel SRAM verbraucht Dein 
Programm?
Wenn Du die 500 Bytes der Variablen "log" erheblich reduzierst, dann 
dürfte das Programm vielleicht laufen.

Ein Tip am Rande: Informiere Dich über Speicherklassen in "C".


Bernhard

Flash hab ich 8kB davon sind laut Eclipse 6792 Byte belegt, SRam hat der 
Käfer 1kB davon sind laut Eclipse 417 Byte belegt.

Das Programm läuft ja auch, nur steigen die Segmentanzeigen aus.

Die log[] Variable soll demnächst auch komplett verschwinden, da ich das 
einlesen on-the-fly implementieren möchte.

Gruß Florian

Bestätige: 6468 Flash, 917 SRam.

Inwiefern würde ein Speicherüberlauf zum Versagen des Multiplexens 
führen?
Das eingelesene Protokoll ist immer gleich groß und kürzer als die 500 
Byte.
Es kommt etwa alle 1-4 Sekunden ein Protokoll rein und es läuft über 
mehrere Tage stabil, wieso sollte es dann plötzlich nach x tausend 
Paketen einen überlauf geben?

Auch ist die im Einlese abschnitt

1

    for(i=0;i<500;i++){

2

      log[i]=readchar();

3

      if(log[i]=='!')

4

        break;

5

    }

in der Bedingung festgemacht, das es nicht zu einem Speicherüberlauf 
kommen kann, nach 500 Zeichen bricht er einfach ab.

Aus meinem Blickwinkel kann es an diesem Stück zu keinem Überlauf 
kommen, oder übersehe ich was essentielles?

Florian


Edit: @Werner:
Müsste ich auf den nächsten Ausfall warten und mich dann mal mit nem 
Multimeter dransetzen. Wenns soweit ist werde ich das dann hier posten.

g457 schrieb:
> Wenn das mal nicht kommt müllst zu
> möglicherweise fröhlich fremden Speicher voll

Da steht aber immer noch die Abbruchbedingung im Weg, das Array soll im 
Endeffekt sowieso rausfliegen, steht auch irgendwo im Code also TODO 
markiert.

Und selbst angenommen ich mülle fremden Speicher zu, warum sollte dann 
das Display ausfallen? Überschreibe ich die Multiplexfunktion? Kaum 
sonst würde ja nach einem reset nicht alles wieder gehen.
Soweit ich das beurteilen kann funktioniert das restliche Programm auch 
bei spinnen der Anzeige richtig, sprich ich sehe sowohl den im Quellcode 
als "Einlesepunkt" als auch den "Verarbeitungspunkt" bezeichneten DP auf 
den Anzeigen aufblitzen wenn er liest und verarbeitet

Florian

Hallo nochmal, hatte grad wieder einen Ausfall, das Programm ist 
mittlerweile umgeschrieben, das on the fly funktioniert nicht, aber das 
log[] array wurde um 340 Byte verkleinert, also noch 160 Byte groß.

Hab mir dann auch gleich mal ein Multimeter geschnappt und geguckt was 
an den Pins los ist, n Oszi hab ich noch nicht deshalb Multimeter.
Ergebniss der Messungen: An den Pins tut für die Transistorsteuerung tut 
sich gar nichts mehr, kein Strom keine Spannung, sind also auf GND 
Niveau.

Werner schrieb, dass man sowas via Watchdog "retten" kann, wie soll das 
Funktionieren?

Florian

So ein Interrupt-Aufruf brauch immer etwas Speicher auf dem Stack.
Sollte nun das Programm bedingt durch Stacküberlauf diesen Speicher 
verheizt haben, wird zwar trotzdem ein Interrupt immer noch ausgelöst, 
aber der Stackpointer sitzt im Nirvana und eine Rücksprungadresse wird 
nicht sinnvoll abgespeichert.
Wird die Rücksprungadresse dann gelesen aus dem Nichtdefinierten 
Speicherbereich gibts einen Crash.

Wenn es dir nicht zuviel Aufwand ist, könntest du in der ISR ja mal 
(vorausgesetzt ein ISR wird immer ausgelöst) einen Punkt auf dem Display 
setzen wenn der Stackpointer seinen legalen Bereich verläßt.

Das ist ne Idee, allerdings hab ich keine Ahnung wie man sowas 
implementieren soll, kannst du mir da mal einen Denkanstoss geben?
Wie würde ich denn raus kriegen, dass er seinen legalen Bereich 
verlässt?

Florian

Edit: Spannung ist mit Kondensatoren stabilisiert und Reset wird mit 10k 
auf VCC gezogen, GND ist allerdings nicht über nen Kondensator mit RESET 
verbunden, warum sollte das so sein?

Der Legale Bereich beim AVR Mega8 ist zwischen 0x0060 und 0x045F.
Dieser Beinhaltet natürlich dann auch noch alle global angelegten 
Variablen im unteren Bereich.
Hat aber so noch keinen Einfluß auf den ISR selbst.

Die Passenden IO-Register des Stackpointers sind SPL & SPH für Low und 
HighByte.
Was mir aber gerade nochmal einfällt, der SRAM-Bereich zwischen 0x0000 
und 0x005F sind die üblichen IO-Register endend mit S-REG und SPL/SPH.
Du solltest dann vielleicht schon den Stackpointer < 0x0065 oder ähnlich 
prüfen.

Ein Stack-PUSH bei Stackpointer Adresse 0x005F löst noch lange keinen 
Fehler aus, überschreiben aber schon SREG & SPH/SPL (den Stackpointer 
selbst).
Wenn der Stackpointer natürlich schon 0x005F ist, ist schon alles zu 
spät.
Alle Globalen Variable sind verhunzt.

Ich würde sogar sagen, wenn der Stack dein Problem wäre, würdest du das 
früher bemerken.
Durch Überschreiben der Globalen Variablen müßte da viel Falsch 
berechnet werden etc.

Ich werd bei nach meiner letzten Klausur am Mittwoch mal deinen 
vorgeschlagenen Test implementieren.

Du sagst aber das es eher was anderes ist, weil es erst sehr spät 
auftritt?
Würde sich mit meiner Unschuldsvermutung decken, da bisher immer 
sinnvolle Werte angezeigt werden, außer wenn er sich halt grad mal 
getötet hat.

ISR(TIMER0_OVF_vect){
  icount++;
  PORTC=0;
  PORTD=show[display[pos]];
  PORTC|=(1<<pos);
  if(pos==0&&einspeisen==1) /*Punkt ob eingespeist wird oder nicht*/
    PORTD&=~(1<<7);
  if(pos==1&&powered==1)  /*Punkt ob WP gepowered oder nicht*/
    PORTD&=~(1<<7);
  pos++;
  if(pos>3)  /*Display hat nur 4 Elemente*/
    pos=0;
}

Die globalen Variablen dürften erst spät überschrieben werden.
Den Inhalt von display[pos] solltest du vielleicht vor show[ prüfen.

Ein paar Ideen zur Optimierung:

Die Variable pos wird außerhalb des Refresh-LED-ISR genutzt ?
Wenn nicht mach es als static mit in den ISR.

- ein "if(pos>3)pos=0" kann man auch als "pos &=3" schreiben.
- volatile unsigned char show[11] kannst du in den ROM verschieben. 
(PROGMEM) oder mindestens als const deklarieren (volatile wird 
überflüssig, da es sich nicht ändert)


  while(1){
    icount=40;   /*Protokoll einlesen und Auswerten dauert etwa 40 
Interrupts die nicht gezählt werden*/
    sei();
    while(PINC&(1<<5));
    cli();

ist es möglich das dieses sei() nicht mehr erreicht wird im Fehlerfall ?

Hab die Optimierungen mal umgesetzt und werd das ganze bei Gelegenheit 
mal auf den Käfer packen.

Bei der PROGMEM optimierung bin ich mir unsicher, muss ich da nicht 
pgm_read_byt verwenden um da dann drauf zuzugreifen?

Florian

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Programmspeicher_.28Flash.29

Dein
volatile unsigned char 
show[11]={0b11000000,0b11111001,0b10100100,0b10110000,0b10011001,0b10010 
010,0b10000010,0b11111000,0b10000000,0b10010000,0b00000000}; 
/*Segmentcodes für Display*/

ist ja eh nur ein Byte.

const unsigned char show[11] PROGMEM = 
{0b11000000,0b11111001,0b10100100,0b10110000,0b10011001,0b10010010,0b100 
00010,0b11111000,0b10000000,0b10010000,0b00000000  };

in der ISR dann

PORTD=show[display[pos]];
wird zu
PORTD=pgm_read_byte(show+display[pos]);

Ah super genauso hab ichs gemacht, außer das da nicht 
PORTD=pgm_read_byte(show+display[pos]);
sondern
PORTD=pgm_read_byte(show[display[pos]]);
steht ich nehme an das + war ein Tippfehler?

Werde zusätzlich mal vergleiche etwas kleiner machen, auf 7, das spart 
dann 12 Floats ein, also 12*32 Byte. Das ganze auf den Käfer und 
beobachten.

Florian

Nach kurzem Schockmoment (auf einmal zeigte er Sachen wie n und P an), 
hab ich nochmal genauer nachgelesen und gesehen, dass da ein 
Adressoperator fehlt, läuft jetzt erstmal mit den ganzen Optimierungen.
Mal schauen ob er immer noch zu schwachsinn übergeht oder nicht.

Florian

Da bin ich wieder, hatte vorhin nach etwa 23 Std Laufzeit wieder einen 
Ausfall.
Angezeigt wurde wie immer nur noch das rechte Display. Was mir 
aufgefallen ist, dass ein nicht vorhandener Segmentcode angezeigt wird. 
Quasi eine 6 ohne Segment a.
Datenempfang findet immer noch statt, ich sehe sowohl den DP vom ganz 
linken Digit aufblinken wenn empfangen wird, also auch den DP vom Digit 
rechts daneben wenn die Daten verarbeitet werden.
Habe auch direkt nochmal die Pins vermessen, komplett tot! Bis ich ihn 
resette, dann geht wieder alles.

So langsam hab ich Lust es auf den Controller zu schieben, Datenpakete 
kommen im Takt 1-4 Sekunden, das heißt die Main ist zwischen 82800 und 
20700 mal durchgelaufen ohne Probleme zu machen. Die ISR ist in den 23 
Stunden etwa 20 Millionen mal durchgelaufen.
Spannungseinbrüche können mMn auch kein Problem sein, da zum einen die 
Versorgungsspannung per Kondensator stabilisiert ist und ich die Brown 
out detection anhabe und diese auf 4.8 Volt steht.
Angenommen es wäre ein Stack-Problem, dann müsste ich ja irgendwo 
Datenmüll erzeugen, der den Stack mit der Zeit wachsen lässt. Nicht 
sicher ob das überhaupt geht.

Florian

Schreibe mal auf die letzten paar Bytes des Stackbereiches bekannte 
Werte. Wenn die Kiste wieder abschmiert, lässt Du dir die Werte nach 
Tastendruck zuschicken und vergleichst die mit den reingeschriebenen 
Werten. Wenn da was anderes drin steht, dann hast Du (d)ein Problem.

unn tschuess
Bernhard

Hab Bernhards Variante mal ausprobiert (schön das man bei nem Steckbrett 
einfach alles umsortieren kann).
Ergebniss: Stack läuft nicht über.
Habe mir jetzt einen Watchdog in die ISR eingebaut, da die ja 
Auszufallen scheint. Es wird ja nur das erste Digit angezeigt.
In der ISR wird der Watchdog jetzt beim Anzeigen der 3. Digit resettet.
In der Main ist der Watchdog leider nicht zu realisieren, da die bis zu 
4 Sekunden für einen Durchlauf braucht.
Des weiteren hab ich noch eingebaut, dass nach 30k Programmdurchläufen 
resettet wird, durch den Watchdog, einfach Interrupts aus und 
_delay_ms(2000) bei ner anschlagzeit von 500ms.

Hätte noch eine Frage zum Hund und zwar bleibt das ja an nachdem durch 
ihn resettet wurde.
Jetzt steht im Tutorial, dass ich den nach Möglichkeit früh kille weil 
er ansonsten zubeißt bevor er zurückgesetzt wird und der uC dadurch auf 
ewig im Watchdogreset festhängt.
Laut Tutorial soll der Reset/abschalten des Hundes vor der 
Variableninitialisierung passieren.
Ich hab aber im Kopf, dass die initialisierung das erste ist was im C 
Code passieren muss, wie soll ich den WD also vorher abschalten?

Florian

Das könnte natürlich ein Problem sein, das Ding hängt immerhin mitten im 
Stromkasten drinne, hab ich bisher gar nicht dran gedacht. Das Kabel ist 
allerdings lang genug, dass ich den Käfer da mal raus holen kann.
Lief bisher die letzten 3 Tage ohne Probleme.
Danke für den Hinweis

Florian

Undefinierte Kabel oder sonstige Sachen die da dran kommen kann ich 
Glücklicherweise ausschließen, es sei denn die Meinzelmännchen kommen 
nachts um mich zu ärgern :)
Werd ihn mal aus dem Zählerschrank rausnehmen und gucken wie er sich 
dann macht. Könnte es ja schon gewesen sein.

Florian

Florian T. schrieb:
> Da bin ich wieder, hatte vorhin nach etwa 23 Std Laufzeit wieder einen
> Ausfall.
> Angezeigt wurde wie immer nur noch das rechte Display. Was mir
> aufgefallen ist, dass ein nicht vorhandener Segmentcode angezeigt wird.
> Quasi eine 6 ohne Segment a.
> Datenempfang findet immer noch statt, ich sehe sowohl den DP vom ganz
> linken Digit aufblinken wenn empfangen wird, also auch den DP vom Digit
> rechts daneben wenn die Daten verarbeitet werden.
> Habe auch direkt nochmal die Pins vermessen, komplett tot! Bis ich ihn
> resette, dann geht wieder alles.
>
> So langsam hab ich Lust es auf den Controller zu schieben, Datenpakete
> kommen im Takt 1-4 Sekunden, das heißt die Main ist zwischen 82800 und
> 20700 mal durchgelaufen ohne Probleme zu machen. Die ISR ist in den 23
> Stunden etwa 20 Millionen mal durchgelaufen.
> Spannungseinbrüche können mMn auch kein Problem sein, da zum einen die
> Versorgungsspannung per Kondensator stabilisiert ist und ich die Brown
> out detection anhabe und diese auf 4.8 Volt steht.
> Angenommen es wäre ein Stack-Problem, dann müsste ich ja irgendwo
> Datenmüll erzeugen, der den Stack mit der Zeit wachsen lässt. Nicht
> sicher ob das überhaupt geht.
>
> Florian


Ich versuchs mal so auszudrücken.
Die ISR läuft ja noch ( sonst wären die Dots nicht mit aktualisiert ).
Ich tippe da immernoch auf nicht legale Werte für die Segmentdaten.
Warum auch immer.

Was hälst du davon diesen Teil

PORTD=show[display[pos]];

zu reduzieren auf reines

PORTD=display[pos];

und in "display" nur noch die fertigen Segmentdaten hälst ?

Dein Fehler muß irgendwie in der Main liegen.
Bereichsüberlauf o.ä.


(vielleicht sowas hier http://www.bbc.co.uk/news/uk-12751404)

Dennis Heynlein schrieb:
> Ich versuchs mal so auszudrücken.
> Die ISR läuft ja noch ( sonst wären die Dots nicht mit aktualisiert ).

Das stimmt so nicht ganz, die Dots die ich sehe werden von der Main 
gehandelt.
Mit den ungültigen Segmentcodes hab ich schonmal mit einer if Bedingung 
geguckt gehabt. Sprich if dispay>10 dann gib mir nen Errorcode aus. Hat 
aber nichts gebracht gehabt, sprich ist auch ausgestiegen ohne 
entsprechenden Errorcode anzuzeigen.

/*Timeroverflowinterrupt für das Multiplexen der 4 7-Segment Anzeigen*/
ISR(TIMER0_OVF_vect){
  icount++;
  PORTC=0;
  PORTD=show[display[pos]];
  PORTC|=(1<<pos);

************************************************************************
  if(pos==0&&einspeisen==1) /*Punkt ob eingespeist wird oder nicht*/
    PORTD&=~(1<<7);
  if(pos==1&&powered==1)  /*Punkt ob WP gepowered oder nicht*/
    PORTD&=~(1<<7);
************************************************************************


  pos++;
  if(pos>3)  /*Display hat nur 4 Elemente*/
    pos=0;
}


ohne die Zeilen in der ISR wären deine DOTs nicht an.
Die ISR läuft also schon.

Kannst du vielleicht den SRAM beim nächsten Absturz mal rausspielen 
(über U(S)ART und Main+Taste z.b.).
Eine Zuordnung welche SRAM-Adresse welche Variable ist sollte nicht so 
schwierig sein.

Muß ja nicht UART sein, solange du weißt wie es codiert ist, kannst du 
es an jeden beliebigen Port rausspielen.

SoftUart liese sich einfach realisieren, zumal es nur ums ausgeben geht 
mit womöglich fester Bitrate. (Ein Pegelwandler wäre vielleicht aber 
dann notwendig)

Und neben SRAM-Zustand wäre auch der Zustand
- des I-Bits im Statusregister nach dem "Absturz".
- des Timer-Interrupt-Freigabe TIMSK
- des Timer-Control-Registers TCCR0
interessant.


Poste mal deine neuesten Sources wenns geht.

Welche Ports sind noch frei ?

Frei ist noch PORTB bis auf B0, aktueller Quelltext ist im Anhang.
Habe inzwischen einen Watchdog eingebaut der nach beim hängenbleiben 
einspringt.
Außerdem ist noch ne Eepromnutzung hinzugekommen, er soll immer wenn er 
zwischen powered/unpowered wechselt den Status ins Eeprom schreiben, 
sodass er wenn der Watchdog zubeißt immer wieder im selben Zustand neu 
startet.
Diese Funktion funktioniert allerdings noch nicht, keine Ahnung warum.

Florian

Edit: Der Code frisst inzwischen 90% des Flash, ist zu überlegen da auch 
auf nen größeren Käfer umzusteigen? atmega16 bzw atmega32?

Vielleicht kannste auf Fliesskomma verzichten und eher zu Festkomma 
greifen ?


Thema Watchdog. Mich würde diese Angstlösung nicht ruhen lassen und ich 
würde unbedingt den Fehler finden wollen ;)

Auf Fließkomma verzichten geht, dann brauch ich aber trotzdem 32 Bit 
Variablen, Speichergewinn gibts es dadurch also eher nicht.

"Angstlösung" ist nicht wirklich die richtige Bezeichnung eher: 
"Damit-ich-weitermachen-kann" Lösung xD

Hast du eine Idee warum der Eeprompart nicht funktioniert?
Prinzipiell soll er den ersten Eintrag suchen der 255 ist und dann den 
Wert davor als powered nehmen, wenn der 0. Eintrag schon 255 ist nimmt 
er einfach 0 an.
Zum schreiben sucht er den ersten Eintrag der 255 ist und schreibt da 
dann den aktuellen status rein. Zumindest in meinem Kopf^^ Wenn im 511. 
also letzten Eintrag kein 255 ist das Array voll und er schreibt es 
einmal komplett neu mit 255 bevor er ins erste wieder den Status 
schreibt.

Eine mögliche Fehlerquelle die ich heut morgen noch gefunden hab ist der 
Phototransistor, der ist über die Zeit immer weiter weg vom Zähler 
gewandert und je weiter weg der war, desto öfter stand da nur 
schwachsinn.

Florian

Die Fliesskomma-LIB frisst ziemlich viel Platz.

Eine mögliche Fehlerquelle die ich heut morgen noch gefunden hab ist der
Phototransistor, der ist über die Zeit immer weiter weg vom Zähler
gewandert und je weiter weg der war, desto öfter stand da nur
schwachsinn.

Das Passt dann gut zur Überlauftheorie in der Main.
Du prüfst auch nicht direkt, ob deine Zahlen wirklich Dezimalzeichen 
sind und nicht fehlerhaft gelesenes irgendwas.

Dann mach ich mich mal dran in die Protokollauswertung noch ne 
Überprüfung einzubauen die schaut das da wirklich 0-9 steht und nichts 
anderes.

Das ganze auf unsigned long umstellen müsste auch gehen. Ich meld mich 
dann nichmal wenn ichs soweit am laufen hab.

Florian

So ein EEPROM-Schreibzyklus braucht ne weile.

"EEPROM Write (from CPU) 8448 CLKrc 8.5ms"

Hoffentlich wird nicht während deinem Schreiben der Watchdog ausgelöst.

Ich behaupte mal, dass das nicht passieren kann weil

1

    if(powered!=laststate){

2

      wdt_disable();

3

      writestatus();

4

      wdt_enable(WDTO_500MS);

5

    }

Edit: Denke ich hab in der write funktion nen Fehler gefunden wenn 
Eintrag 0 255 ist, dann geht er gar nicht erst in die Schleife erhöht 
also auch gar nicht i, also versucht er dann in eintrag -1 bzw da es ein 
unsigned int is in eintrag 65000 oder so zu schreiben.

Hallo, arbeite grade am loswerden der ganzen floats, habe allerdings das 
Problem, dass ich keine Idee habe wie ich den float bei der Zeit 
loswerden kann, denn angenommen bei der Multiplikation kommt was kleiner 
1 raus, dann hab ich da auf einmal 0 stehen und durch 0 teilen ist 
ungesung, auch kann ich denn nicht mehr zwischen 1 und 1.9 
unterscheiden. Ideen wie ich das Lösen kann?

Florian

Ich denke ich habs jetzt, allerdings zeigt das Display einen gefühlten 
Faktor 5 zu wenig an, ich möchte einfach nicht glauben, dass wenn die 
Anlage 6kW bringt nur 1kW eingespeist werden obwohl nur mein PC als 
großer Verbraucher läuft ;)

Änderungen sind, alle floats sind unsigned long gewichen

Das hier

1

      if(klammern==3){

2

        i++;

3

        kaufen+=(log[i]-48)*100000;

4

        i++;

5

        kaufen+=(log[i]-48)*10000;

6

        i++;

7

        kaufen+=(log[i]-48)*1000;

8

        i++;

9

        kaufen+=(log[i]-48)*100;

10

        i++;

11

        kaufen+=(log[i]-48)*10;

12

        i++;

13

        kaufen+=(log[i]-48);

14

        i+=2;

15

        kaufen+=(log[i]-48)/10.;

16

        i++;

17

        kaufen+=(log[i]-48)/100.;

18

        i++;

19

        kaufen+=(log[i]-48)/1000.;

20

        i++;

21

        kaufen+=(log[i]-48)/10000.;

22

      }

ist dem hier gewichen

1

      if(klammern==3){

2

        i++;

3

        kaufen+=(log[i]-48)*1000000000;

4

        i++;

5

        kaufen+=(log[i]-48)*100000000;

6

        i++;

7

        kaufen+=(log[i]-48)*10000000;

8

        i++;

9

        kaufen+=(log[i]-48)*1000000;

10

        i++;

11

        kaufen+=(log[i]-48)*100000;

12

        i++;

13

        kaufen+=(log[i]-48)*10000;

14

        i+=2;

15

        kaufen+=(log[i]-48)*1000;

16

        i++;

17

        kaufen+=(log[i]-48)*100;

18

        i++;

19

        kaufen+=(log[i]-48)*10;

20

        i++;

21

        kaufen+=(log[i]-48)*1;

22

      }

die Verarbeitung sieht jetzt anstelle so

1

    time=icount*0.004096;

2

    timea[eintrag]=time;

3

4

5

6

    /*Differenz zum letzten Verkaufenwert ermitteln, auf Joule umrechnen und ins passende Array schreiben*/

7

    verkaufendiff=(verkaufen-verkaufenalt);

8

    verkaufendiff*=1000;

9

    verkaufendiff*=3600;

10

    vkauf[eintrag]=verkaufendiff;

so aus

1

    time=icount*0.04096;

2

    timea[eintrag]=time;

3

4

5

6

    /*Differenz zum letzten Verkaufenwert ermitteln, auf Joule umrechnen und ins passende Array schreiben*/

7

    verkaufendiff=(verkaufen-verkaufenalt);

8

    verkaufendiff*=3600;

9

    vkauf[eintrag]=verkaufendiff;

hierbei sind sowohl der time Multiplikator also auch die 3600 um den 
Faktor 10 zu groß, so erschummel ich mir eine größere genauigkeit bei 
der Zeit.

Die todisplay Funktion wurde auf die unsigned longs angepasst.

unsigned longs entsprechen 32 bit Variablen, sollte also Werte bis 4 
Milliarden halten können.

Ich seh grad nicht wo dieser Faktor 5 Verloren gehen soll.

Florian

i++;
  kaufen+=(log[i]-48)*1000000000;

Teste mal log[i] auf >=48 && <=57

und eventuell haste noch ein paar Testausgaben :) um mal einen Simulator 
damit zu füttern.