long Variable auf SD Karte schreiben

[Nitram E. (slexx)]

Guten Abend, ich versuche gerade eine Variable long auf die SD-Karte zu 
schreiben.

long CodeLamp[2] = {83203, 92145};

Int und andere Variablen funktionieren. Ich benutze die SDFat.h

Hier mal ausschnitt für das Schreiben:

myFile.print(CodeLamp);

für das lesen:

if(lineNo==12){sscanf(netBuffer,"%u %u",&CodeLamp[0],&CodeLamp[1]);}

CodeLamp wird später im Programm geändert und soll dann auf die SD 
gespeichert werden. Warum klappt es mit einer INT-Var. aber nicht mit 
der long? Er zeigt zwar Zahlen an aber die falschen....was muss ich tun 
damit das funktioniert. LG

[Nop (Gast)]

Also Deine Deklaration "long" ist erstens mal signed. Das würde ich auf 
"unsigned long" ändern. Noch besser wäre es, gleich die C99-Datentypen 
zu nutzen, weil die Breite von "int" in C nur mit "mindestens 16 bits" 
definiert ist. Also hier uint32_t nehmen.

Zweitens ist Dein Formatstring "%u", das ist ein unsigned integer. Der 
richtige Firmatstring für unsigned long int wäre aber "%lu".

Drittens sollte man embedded auf scanf, printf und Konsorten sowieso 
verzichten.

[Nitram E. (slexx)]

Nop schrieb:
> Also Deine Deklaration "long" ist erstens mal signed. Das würde ich auf
> "unsigned long" ändern. Noch besser wäre es, gleich die C99-Datentypen
> zu nutzen, weil die Breite von "int" in C nur mit "mindestens 16 bits"
> definiert ist. Also hier uint32_t nehmen.
>
> Zweitens ist Dein Formatstring "%u", das ist ein unsigned integer. Der
> richtige Firmatstring für unsigned long int wäre aber "%lu".
>
> Drittens sollte man embedded auf scanf, printf und Konsorten sowieso
> verzichten.

Danke danke danke :) mit Formatstring

%lu

 funktioniert es jetzt.

Den Rest den du geschrieben hast ist sehr Interessant. Aber die long 
oder unsigned long ist doch auch 32bits lang!?!?!?!

[Nop (Gast)]

In der Praxis schon, aber die ganze Definition der Datentypen in C ist 
da echt schwammig, deswegen gibt's ab C99 ja endlich vernünftige 
Datentypen, auf die man sich auch verlassen kann.

Mit "long int" haste genau dasselbe Problem wie bei "int" auch schon: 
Das ist MINDESTENS 32 bit.

Aber cool, daß Dein Programm jetzt funktioniert. :-)

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Nop schrieb:
> Drittens sollte man embedded auf scanf, printf und Konsorten sowieso
> verzichten.
Warum denn das?

[Wolfgang (Gast)]

Reginald L. schrieb:
> Warum denn das?

Guck mal auf den Umfang des erzeugten Codes (mit vs. ohne printf u.ä.)

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Wolfgang schrieb:
> Guck mal auf den Umfang des erzeugten Codes (mit vs. ohne printf u.ä.)
Naja, klar. Meiner Meinung nach hinkt deine Begründung aber. Demnach 
müsste jeder Code auf einem µC vom Umfang her klein sein.

Also mich stören die 130 - 400kB auf meinem STM32 nicht.
Auf einem ATTiny würde mich das schon eher stören :)

[Wolfgang (Gast)]

Reginald L. schrieb:
> Also mich stören die 130 - 400kB auf meinem STM32 nicht.

Es gibt aber auch Anwendungen, bei denen dieser Code auch abgearbeitet 
werden muss. Wenn das dazu dann noch zeitkritisch ist, kann das sehr 
wohl ausgesprochen störend sein und über läuft/läuft nicht entscheiden.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Wolfgang schrieb:
> Es gibt aber auch Anwendungen, bei denen dieser Code auch abgearbeitet
> werden muss. Wenn das dazu dann noch zeitkritisch ist, kann das sehr
> wohl ausgesprochen störend sein und über läuft/läuft nicht entscheiden.
ACK. Trotzdem kann man printf und Co im embedded Bereich benutzen. Auch 
in zeitkritischem Code, wenn man weiß was man tut.
Ansich ist es ja schon besser, sich für jeden Kleinscheiss im 
embedded-Bereich selber was zu schreiben, da geb ich dir andererseits 
schon recht. Da weiß man dann wenigstens was man hat.

[Nop (Gast)]

Alles, was mit dynamischer Speicherallozierung abgeht, hat noch ganz 
andere Probleme im Gepäck als "nur" die Ausführungszeit und den 
Codeumfang. Speicherfragmentierung ist fies, weil nach einigen Wochen 
oder so dann unmotivierte Allozierungsfehler auftreten können. Kein 
Programmiererlatein, habe ich in realen Projekten schon gesehen.

Testbar ist so ein System dann auch nicht mehr, weil der interne Zustand 
nicht mehr reproduzierbar ist.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Daran habe ich gar nicht gedacht.

Bei mir laufen, während das System hochfährt, verschiedene printf's, 
strlen's, etc pp durch. Im normalen Programmablauf dann nicht mehr. Was 
ist davon zu halten?

[Mark B. (markbrandis)]

Nop schrieb:
> Alles, was mit dynamischer Speicherallozierung abgeht, hat noch ganz
> andere Probleme im Gepäck als "nur" die Ausführungszeit und den
> Codeumfang. Speicherfragmentierung ist fies, weil nach einigen Wochen
> oder so dann unmotivierte Allozierungsfehler auftreten können. Kein
> Programmiererlatein, habe ich in realen Projekten schon gesehen.
>
> Testbar ist so ein System dann auch nicht mehr, weil der interne Zustand
> nicht mehr reproduzierbar ist.

Die Aussage ist so pauschal natürlich Quatsch. Dann wären ja Geräte mit 
Betriebssystem und/oder jeglicher Art von SW-Library gar nicht testbar. 
Selbstverständlich kann man auch solche Systeme testen.

[Mark B. (markbrandis)]

Reginald L. schrieb:
> Daran habe ich gar nicht gedacht.
>
> Bei mir laufen, während das System hochfährt, verschiedene printf's,
> strlen's, etc pp durch. Im normalen Programmablauf dann nicht mehr. Was
> ist davon zu halten?

Wenn durch Tests nachgewiesen ist, dass das System das tut was es soll, 
sehe ich da erstmal kein Problem. Klar ist damit keine hundertprozentige 
Fehlerfreiheit nachgewiesen. Das ist sie allerdings nie.