SAM4E oder SAM7x

Alexxx schrieb:
> Werte eines 24Bit-ADCs

Wieviele Kanäle? Welchen ADC verwendest du?

Alexxx schrieb:
> 62kSPS

Das bedeutet du hättest jede 16,129µs einen neuen Datensatz.

Egal ob du nun 1 oder 8 Kanäle hast, alle Berechnungen müssen unter 16µs 
liegen, jedoch braucht dein µC (Firmware) ja auch noch Ausführungszeit.

Alexxx schrieb:
> SAM7x

Meinst du damit die SAMS7x/SAME7x/SAMV7x?

Edit:
Ich muss mal kurz neue Zeitmessungen machen, die vorherigen waren 
falsch.

SAM4E mit 120MHz.

1)
x & y: uint32_t
y = (x*x) + x + 0xFFFF;
Dauer: 0,1µs

2)
x & y: uint32_t
y = (x*x*x*x) + (x*x*x) + (x*x) + x + 0xFFFF;
Dauer: 0,1µs

3)
x & y: float
y = (1.5 * (x*x)) + (5.25 * x) + 0xFFFF;
Dauer: 40ns (Dank der FPU)

Alexxx schrieb:
> Aber dass 1.) und 2.) trotz unterschiedlicher umfangreicher Berechnungen
> gleich lange brauchen???

Hat mich auch gewundert, aber der LogicAnalyser liefert diese 
Zeitangaben.
Habe die Berechnungen extra im SysTick Handler durchgeführt,
dass die Berechnung nicht von anderen Interrupts unterbrochen wird.

Alexxx schrieb:
> Hat diese SAMs schon mal einer benutzt??

Wir haben den SAMV71Q21B noch im Einsatz, aber da kann ich dir jetzt 
sponatan keine Zeitangaben sagen.
Könnte dir morgen mal Messungen machen.

Was die Peripherie und den Umgang damit betrifft, kann ich dir leider 
nicht sagen, da nicht meine Baustelle.

Alexxx schrieb:

>>> Meinst du damit die *SAMS7x/SAME7x/SAMV7x*?
> Ja genau, wegen der double-precision FPU.
> Hat diese SAMs schon mal einer benutzt??

Wir haben sie im Einsatz, funktionieren gut, wenngleich die Appnote für 
den Übergang von SAM4E auf SAME70 einiges zu wünschen übrig lässt. 
Ärgerlichstes Detail: es gibt wieder nur 16-bit-Timer, obwohl der SAM4E 
32-bittige hatte. Muss man dann wieder verketten wie anno dunnemals beim 
SAM4S.

Wie viel die 64-bit-FPU wirklich bringt, kann ich dir nicht sagen. Weiß 
nur, dass sie vorhanden ist. :) Ärgerlich für uns ist, dass die CMSIS 
DSP library nach wie vor nur für float32 existiert, nicht für float64. 
Die hätte uns sonst wirklich interessiert, so rechnen wir unseren 
DSP-Krams nach wie vor mit 32-bit-Floats.

Der CPU-Takt ist doppelter Systemtakt, insofern arbeitet die CPU 
volldampf nur aus dem Cache, oder du spendierst ihr einen Teil des RAMs 
als tightly coupled memory (TCM). Da muss man aber dann zu gleichen 
Teilen RAM sowohl für Daten als auch Befehle opfern. Haben wir bislang 
noch nicht.

Alexxx schrieb:
> @Adam P.
> Meinst du damit die *SAMS7x/SAME7x/SAMV7x*?
>
> Ja genau, wegen der double-precision FPU.
> Hat diese SAMs schon mal einer benutzt??

Da läuft mein CAN-LAN-Gateway drauf. Ich hatte auch mal zusätzlich eine 
FFT mit float und 1024 ausprobiert. Ich mein ich war die FFT war 
schneller als 22 ms, bin mir aber nicht sicher.

Board war das SAM E70 XPLD.

Gruß JackFrost

Alexxx schrieb:

> Na toll. Das bedeutet dann aber, dass die FPU64 eigentlich nicht nutzbar
> ist, traurig, traurig.

Für die DSP-Library nicht.

> Unterstützt GCC / Atmel Studio eigentlich "Float64" oder double?

Ja, sicher, also ganz normales "double". Hat er auch bei der 32-bit-FPU, 
dort dann halt als Software-Lib.

Gerade mal schnell in eine C-Datei hier ein

1

double x;

2

3

…

4

   x *= 2;

reingeschrieben:

1

        ldr     r3, .L20

2

        vldr.64 d7, [r3]

3

        vadd.f64        d7, d7, d7

4

        vstr.64 d7, [r3]

5

…

6

.L20:

7

        .word   x

Rudolph schrieb:
> Um noch was dazwischen in den Ring zu werfen das neuer ist: SAMD51

Ist aber eine völlig andere Liga.

Hier wurde über 32- und 64-bit-FPUs geredet, da kann der kleine 
Cortex-M0+ nun wirklich nicht mitreden.

Allerdings halte ich die Peripherie der kleinen SAMD & Co. insgesamt für 
eleganter, nicht so dinosaurierhaft.

Oh, sorry, dann habe ich mich durch das SAMD täuschen lassen. :) Man 
lernt nie aus.

Ist mit 120 MHz nicht ganz so flink wie die großen Boliden, aber die 
Peripherie klingt interessant.

Tonne schrieb:
> Die (Zeit-)Werte kannst du alle in die Tonne treten.
> Da hat der Compiler doch zum Schluss nur das Ergebnis
> in das Register geladen, aber nichts ausgerechnet!

Dann erkläre mir mal bitte wie & wo sich der Compiler ALLE Ergebnisse
die zur Laufzeit auftretten können, speichert? :-/
Vllt. solltest du erstmal alles lesen, bevor du so einen sinnlosen 
Beitrag verfasst:


Adam P. schrieb:
> Habe die Berechnungen extra im SysTick Handler durchgeführt

1

void SysTick_Handler(void)

2

{

3

  static uint32_t x = 0;

4

  uint32_t y;

5

6

  y = (x*x) + x + 0xFFFF;

7

  x++;

8

}

temp schrieb:
> Mach mal aus deinem y eine globale volatile Variable, dann sieht die
> Welt sicher anders aus.

Ja...ansich hast du recht, nobody is perfect, es dauert länger, was 
bei mir falsch war sind auf jeden fall die Werte für float, bei uint32_t 
gehts eigentlich.

Tonne schrieb:
> Da hat der Compiler doch zum Schluss nur das Ergebnis
> in das Register geladen, aber nichts ausgerechnet!

War durch diese Formulierung verwirrt...Da es ja ohne rechnen kein 
Ergebnis geben kann.

Also hier die neuen Werte:

1

//volatile uint32_t y;

2

//uint32_t x;

3

4

volatile float y;

5

float x;

6

7

void SysTick_Handler(void)

8

{

9

  ioport_set_pin_level(PIN_DBG_0, 1);

10

  // y = (x*x) + x + 0xFFFF;

11

  y = (1.5 * (x*x)) + (5.25 * x) + 0xFFFF;

12

  x++;

13

  ioport_set_pin_level(PIN_DBG_0, 0);

14

}

Für uint32_t:
Anstatt 0,1µs sinds nun 0,25µs.

Für float:
Anstatt 40ns sinds nun 7,18µs.

Alexxx schrieb:
> Das kann doch auch nicht sein (ist OHNE FPU?)!!!

Ist mit FPU.

Was mich jedoch wundert:

- In der Debug Config. kann ich "-mfloat-abi=hard -mfpu=fpv4-sp-d16"
nutzen.

- In der Release Config. bekomme ich da jedeoch 1000 Fehler, da
funktioniert nur "-mfloat-abi=softfp -mfpu=fpv4-sp-d16".

Wobei laut GCC ist es ja mit HW-Unterstützung:
"Use -mfloat-abi=softfp with the appropriate -mfpu option to allow the 
compiler to generate code that makes use of the hardware floating-point 
capabilities for these CPUs."

Im Anhang ist das *.lss für folgendes:

1

volatile float y;

2

float x;

3

4

void SysTick_Handler(void)

5

{

6

    y = (1.5 * (x*x)) + (5.25 * x) + 0xFFFF;

7

    x++;

8

}

Adam P. schrieb:
> bekomme ich da jedeoch 1000 Fehler

Dann linkst du gegen die falsche(n) Bibliothek(en). Soft-FP und Hard-FP 
muss für alle gemeinsam zu linkenden Objekte gleich sein, wenn du die 
FPU nutzen willst, müssen folglich auch all deine Libs so compiliert 
worden sein.

Hatten wir auch mal.

Der Cortex-M4 hat aber nur eine 32-bit-FPU. Wäre die Frage, inwiefern 
sich die 64-bit-FPU des Cortex-M7 im Timing unterscheidet.

@Larry:
Welche IAR Version ist denn das?
Die 8.3er hat unter W7 und W10 noch nicht sone komische Schrift.

@Larry
Das ist durchaus Geschmackssache, aber wenn das nicht der neue default 
ist, dann bin ich beruhigt ;)

Larry schrieb:
> Die ist bzgl. ihrer
> eindeutigen Lesbarkeit schon auf Grund ihres Einsatzzwecks
> mit Sicherheit besser als jede Courier, Andale oder Consolas.

Eindeutige Lesbarkeit ist das eine, aber danach bewerte ich die Optik 
meines Editors nicht so sehr. Da spielen schon auch ästhetische 
Gesichtspunkte eine Rolle.

Die Schrift in meinem Editor ist auch eindeutig lesbar (bspw. werden 
Null und O gut unterschieden), auch wenn es keine OCR-Schrift ist.

Wenn du damit zufrieden bist, ist es ja aber OK.

Jörg W. schrieb:
> Dann linkst du gegen die falsche(n) Bibliothek(en). Soft-FP und Hard-FP
> muss für alle gemeinsam zu linkenden Objekte gleich sein, wenn du die
> FPU nutzen willst, müssen folglich auch all deine Libs so compiliert
> worden sein.

OK, ich bin echt davon ausgegangen, dass ich die FPU nutze.
Aber man lernt ja zum Glück nie aus.

Was mich jedoch wundert, ich habe mir mal die FFT und FIR Besipiele im 
AtmelStudio angeschaut, dort wird auch nur "softfp" benutzt und bei 
"hard" scheint es wirklich so zu sein wie du sagtest:

(Ein Fehler von vielen)

1

src/ASF/sam/utils/cmsis/sam4e/source/templates/system_sam4e.o uses VFP register arguments, EXAMPLES_ARM_FFT_BIN_EXAMPLE1.elf does not

2

3

c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld.exe  0

Aber wie bekomme ich es nun richtig hin?
In der Appnote steht auch nur das wie ich es auch habe:
http://ww1.microchip.com/downloads/en/AppNotes/Atmel-42144-SAM4E-FPU-and-CMSIS-DSP-Library_AP-Note_AT03157.pdf

Wäre toll, wenn mir das jmnd erklären könnte, da ich die FPU ebenfalls 
für Filter nutze (bzw. nutzen möchte) - würde ich es auch gern richtig 
machen (dazulernen).

Edit:
Vllt. hat ja jmnd ein Mini-Projekt (3 Zeiler) welches richtig für SAM4E 
mit FPU konfiguriert ist, dann könnte ich mir da die Unterschiede 
heraussuchen.

Proprietäres großes Projekt, kann ich nicht posten.

Kurz-Zusammenfassung der Compiler-Kommandozeilen:

1

arm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -D__SAM4E16E__ -DARM_MATH_CM4=true -mfpu=fpv4-sp-d16 -mfloat-abi=hard -ffast-math -D__FPU_PRESENT=1 -I something -Wall -Werror -mlong-calls -g3 -Wundef -std=c99 -Os -o foobar.o foobar.c

2

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -D__SAM4E16E__ -DARM_MATH_CM4=true -mfpu=fpv4-sp-d16 -mfloat-abi=hard -ffast-math -D__FPU_PRESENT=1 -nostartfiles -Wl,--gc-sections -Wl,-Tflash.lds board_cstartup_gnu.o foobar.o -L../CMSIS/Lib/GCC -larm_cortexM4lf_math -lm -o foobar.elf

Möglicherweise ist da noch etwas „Voodoo“ drin, bspw. bin ich mir nicht 
sicher, ob man __FPU_PRESENT tatsächlich selbst definieren muss, oder ob 
-mlong-calls wirklich sinnvoll ist. Manches an diesem Projekt ist 
einfach nur „historisch gewachsen“.

Kalle schrieb:
> Du meinst es sicher gut, aber ich denke Du bist (noch?) nicht der
> richtige um zu Performance-Fragen aussagekräftige Messungen zu machen
> und einen anderen hilflosen zu beraten.

Naja...es lag einfach nur an mehreren Dingen die dafür gesorgt haben, 
dass so komische Zeiten entstanden sind.
Danke für den Tipp mit dem Suffix!

Nun sollte ich es haben.

1)
Hab es nun auch mit "hard" kompiliert bekommen, aber wie Atmel und GCC 
sagt:
"softfp" und "hard" nutzen die "Hardware floating-point instructions".

Da ist kein Unterschied messbar.

2)
Der fehlende Suffix "f", hat dafür gesorgt, dass er double angenommen 
hat,
somit hat man in der *.lss...

Adam P. schrieb:
> Im Anhang ist das *.lss

...keine HW-Float Befehle gesehen.

3)
y = (1.5f * (x*x)) + (5.25f * x) + 65535.0f;
x += (x * 1.25f);

Laufzeit nun 0,26µs, entspricht bei 120MHz - 32 Clocks

Und im *.lss ist es nun wie zu erwarten war auch richtig:

1

...

2

  400af6:  ed93 7a00   vldr  s14, [r3]

3

  400afa:  edd3 6a00   vldr  s13, [r3]

4

  400afe:  edd3 7a00   vldr  s15, [r3]

5

  400b02:  ee27 7a26   vmul.f32  s14, s14, s13

6

  400b06:  eef1 6a05   vmov.f32  s13, #21  ; 0x40a80000  5.250

7

  400b0a:  ee67 7aa6   vmul.f32  s15, s15, s13

8

  400b0e:  eef7 6a08   vmov.f32  s13, #120  ; 0x3fc00000  1.5

9

  400b12:  eee7 7a26   vfma.f32  s15, s14, s13

10

  400b16:  ed9f 7a0d   vldr  s14, [pc, #52]  ; 400b4c <SysTick_Handler+0x68>

11

  400b1a:  ee77 7a87   vadd.f32  s15, s15, s14

12

  400b1e:  eeb7 7a04   vmov.f32  s14, #116  ; 0x3fa00000  1.250

13

  400b22:  edc0 7a00   vstr  s15, [r0]

14

  400b26:  edd3 6a00   vldr  s13, [r3]

15

  400b2a:  edd3 7a00   vldr  s15, [r3]

16

  400b2e:  eee6 7a87   vfma.f32  s15, s13, s14

17

  400b32:  edc3 7a00   vstr  s15, [r3]

18

...

Nun ergibt das auch alles Sinn :-)

Adam P. schrieb:
> Der fehlende Suffix "f", hat dafür gesorgt, dass er double angenommen
> hat,

Ja, da muss man beim SAM4E bisschen aufpassen.

Beim SAME70 darf man da schlampiger sein. ;-)

Gibt es eine alternative für folgende Berechnung:

1

float tmp;

2

float tmp_v;

3

...

4

tmp = 0.2731f * pow(tmp_v, 1.1531f);

Da er dafür 0,15ms benötigt.

powf() statt pow()?

Jörg W. schrieb:
> powf() statt pow()?

Werde ich mal ausprobieren...
pow() hat ja nämlich double parameter.

Gibt es ein Grund warum mir aber die Funktion pow() rot unterstrichen 
wird, also nicht definiert, aber trotzdem kein Fehler beim compile 
entsteht und es auch funktioniert.

Da macht es auch kein unterschied, ob ich
math.h oder arm_math.h einbinde.

Adam P. schrieb:
> Gibt es ein Grund warum mir aber die Funktion pow() rot unterstrichen
> wird, also nicht definiert

Das musst du die IDE deines geringsten Misstrauens fragen. Die macht das 
schließlich.

Du meinst die Berechnung in ner Funktion machen?

Mh... Gute Idee, werde ich mal ausprobieren, klingt interessant ?

Wobei, wenn ich so drüber nachdenke... Sollte es kein unterschied 
machen.
Da man ja eh nur 32bit Register hat und float nur interpretation ist.
Bei einer normalen Berechnung, nutzt man auch die Register, der 
Umterschied
wäre, das man den stack nicht benutzt...

Oder meinst du was anderes?