Code von Bascom nach C

>       If Data_in(n + 1) = 12 Then

Hier ist ein Bug: Buffer Overflow.

Tatsächlich Danke. Aber das erklärt leider noch nicht warum die C 
Variante nicht geht, in Bascom geht es ja (der Bug trat vermutlich 
deshalb nicht auf weil die 88 am Anfang gesendet wird.

Gruß

> int main(void)
> ...
>  Freq_rfm12(868.300);
> ...
> void Freq_rfm12(double freq)

Hier sollte eine Warnung kommen.

Die C Source ist ja keine 1:1 Übernahme (Abweichung z.B. Freq_rfm12).
Funktioniert die 1:1 Übersetzung (s. Anhang)?

Ich werd sie nachher ausprobieren bin nur grad in der Arbeit und habe so 
keine Möglichkeit zum testen.
Bin aber so gegen halb 4 daheim.
Danke schonmal

Gruß

Ein Problem in deiner C-Source ist die Indizierung der Arrays und die 
Anzahl der Schleifendurchläufe mbei Berechnungen mit diesen Arrays.

Du hast oft FOR N=1 TO 10 (BASCOM) nach for (N=0; N<=10; N++) umgesetzt: 
Das sind in C aber 11 Durchläufe!

In meiner 1:1 Übersetzung ist das Array um +1 vergrössert und das 
Element mit Index 0 wird nicht benutzt, dafür sind die Schleifen 1:1 von 
1 bis <=10 d.h. 10 Durchläufe.

@Paul: ja werde ich machen
@Stefan: Ja stimmt das habe ich nicht bedacht daran könnte es liegen. 
Wie gesagt werde es so bald wie möglich testen.

Danke und Gruß

Also erstmal vielen vielen Dank an Stefan! Der Code läuft und die Zahlen 
werden erkannt. Habe mich wohl doch mit den Arrays vertan.
Zur Frage der Code größe:

AVR Studio liefert mir, wenn ich Stefans Code kompiliere ohne vorher 
aufzuräumen:

Programm: 4090 bytes (25.0% Full)
(.text + .data + .bootloader)

Data: 36 bytes (3.5% Full)
(.data + .bss + .noinit)

Bascom sagt mir beim kompilieren nur 18% Flash used.
Meiner Rechnung nach mit 16Kbyte Flash sind 18% 2880 byte. Kann das 
sein? Damit wäre ja die Bascomversion deutlich kleiner als die mit C??

Gruß

> Bascom sagt mir beim kompilieren nur 18% Flash used.
> Meiner Rechnung nach mit 16Kbyte Flash sind 18% 2880 byte. Kann das
> sein?

Bascom erzeugt eine Report-Datei (*.RPT), darin kannst Du das genau 
nachlesen.

...

Ok da steht unter anderem folgendes:

Compiler     : BASCOM-AVR LIBRARY V 1.11.9.8,  DEMO Edition
Processor    : M168
SRAM         : 400 hex
EEPROM       : 200 hex
ROMSIZE      : 4000 hex

ROMIMAGE     : B98 hex  -> Will fit into ROM
ROMIMAGE     :  2968 dec
FLASH USED   :  18  %
BAUD         : 9600 Baud
XTAL         : 20000000 Hz
BAUD error   : 0.16%

Stack start  : 4FF hex
Stack size   : 80 hex
S-Stacksize  : 80 hex
S-Stackstart : 480 hex
Framesize    : 80 hex
Framestart   : 3FF hex
Space left   :  614  dec

Ist der Code dann quasi 2968 byte groß? Wäre immer noch kleiner als die 
C Variante

Auch in C kann man uneffizienten Code schreiben. Und nein, ich habe mir 
den Code nicht angesehen, beide nicht. Ich bevorzuge die direkte Art. 
;-)

...

Hst du dem C Compiler das Optimieren erlaubt?

Hannes Lux schrieb:
> Auch in C kann man uneffizienten Code schreiben. Und nein, ich habe mir
> den Code nicht angesehen, beide nicht. Ich bevorzuge die direkte Art.
> ;-)

:D ja da stimme ich dir zu. Ich habe auch nie behauptet, dass der Bascom 
Code effizient ist. Und der C Code ist ja nur ne 1:1 Übersetzung. Da ich 
aber keine zeitkritische Anwendung hab ist es mir um ehrlich zu sein 
wurscht ^^ ich werde noch ein bisschen aufräumen und Funktionen 
auslagern aber das soll mehr die Lesbarkeit erhöhen ;)

Karl heinz Buchegger schrieb:
> Hst du dem C Compiler das Optimieren erlaubt?

Bei den Optionen steht bei Optimization -Os was immer das auch heißen 
mag?

> D = Freq / 0.0050;

Mit dieser einen Berechnung ziehst du dir wahrscheinlich Unmengen von 
Code rein.

Ersetzt das durch

  D = Freq * 200;

(rechnet sich auch schneller)

Mathias Dubdidu schrieb:
> Karl heinz Buchegger schrieb:
>> Hst du dem C Compiler das Optimieren erlaubt?
>
> Bei den Optionen steht bei Optimization -Os was immer das auch heißen
> mag?

-Os  ist ok.
Das ist ein oftmals vernünftiger Kompromiss in der Optimierung

Mathias Dubdidu schrieb:
> Programm: 4090 bytes (25.0% Full)
> (.text + .data + .bootloader)

Ja, die default Compiler Optimierung ist nicht so dolle.
Man muß ihm etwas auf die Sprünge helfen.
Nimm mal diese Optionen:

1

-Os

2

-std=gnu99

3

-lm

4

-fno-inline-small-functions

5

-fno-move-loop-invariants

6

-Wl,--relax

7

--combine

8

-fwhole-program

Dann komme ich auf 1186 Byte.

Es waren aber noch 3 Fehlermeldungen in dem Programm von Stefan.


Peter

Karl heinz Buchegger schrieb:
>> D = Freq / 0.0050;
>
> Mit dieser einen Berechnung ziehst du dir wahrscheinlich Unmengen von
> Code rein.
>
> Ersetzt das durch
>
>   D = Freq * 200;
>
> (rechnet sich auch schneller)

Vergiss das.
Freq ist ja auch ein float.

Allerdings erhebt sich die Frage: Warum ist das ein float?
Beim schnellen drüberschauen, hab ich nichts gesehen, was float hier 
rechtfertigen würde.

Tausche ich den float gegen einen uint16_t und passe die Berechnungen, 
die mit Freq gemacht werden auf 1 Nachkommastelle fixed Point an, dann 
lande ich mit -Os bei 1490 Bytes

Karl heinz Buchegger schrieb:
> Allerdings erhebt sich die Frage: Warum ist das ein float?
> Beim schnellen drüberschauen, hab ich nichts gesehen, was float hier
> rechtfertigen würde.

Stimmt und ich habe ich schon gewundert, warum im Assemblerlisting die 
float Lib fehlt.

Die Rand-Lib braucht den meisten Code.


Peter

Peter Dannegger schrieb:
> Karl heinz Buchegger schrieb:
>> Allerdings erhebt sich die Frage: Warum ist das ein float?
>> Beim schnellen drüberschauen, hab ich nichts gesehen, was float hier
>> rechtfertigen würde.
>
> Stimmt und ich habe ich schon gewundert, warum im Assemblerlisting die
> float Lib fehlt.

Die hat anscheinend deine

-fwhole-program

Option erkannt und eliminiert. Hätt ich dem gcc gar nicht zugetraut.
Nehme ich die Option im Originacode raus, schnalzt der Flash Verbrauch 
wieder in die Höhe.

Quelltext von Stefan:
Beitrag "Re: Code von Bascom nach C"

+ oben genannte Optionen
+ im Quelltext:

1

int __attribute__((OS_main)) main(void);

ergibt:

1

WinAVR 20090313

2

GCC 4.3.2

3

AVR Memory Usage

4

----------------

5

Device: atmega168

6

7

Program:    1152 bytes (7.0% Full)

8

(.text + .data + .bootloader)

9

10

Data:         28 bytes (2.7% Full)

11

(.data + .bss + .noinit)

Peter

Peter Dannegger schrieb:

>

1

> int __attribute__((OS_main)) main(void);

2

>

>

Und was bewirkt dann diese Option?