wait states ARM Cortex-M0

Marvin0807 schrieb:
> Wie kann ich die wait states auf 0 setzen?

Bei der STM32L0 und STM32F0 Serie ist das standardmäßig bereits 
deaktiviert.

SET_BIT(FLASH->ACR, FLASH_ACR_LATENCY); // 1 Wait state

CLEAR_BIT(FLASH->ACR, FLASH_ACR_LATENCY); // 0 Wait states

Der Flash Speicher fällt aber aus, denn du mit mehr als 24 MHz ohne 
Wait-State taktest.

Welchen Mikrocontroller verwendest du denn?

Ich hatte mal einen M0, bei dem mußte man die Waitstates hochsetzen, 
falls er mit 48 statt 32 MHz betrieben hat.
Stand ab Revision 1 dann auch im Handbuch.

Meistens sind die CPUs aber schnell genug. Daher vermute ich, dass der 
Programmierer nicht genau weiss, was er tut.

PittyJ schrieb:
> Meistens sind die CPUs aber schnell genug.

Klar, aber die Wait States sind für die Peripherals, das Zeugs was an 
der superschnellen CPU hängt.

Jörg W. schrieb:
> Nein, die sind für den Flash.

Der in der CPU wohnt, der direkt an die ALU getackert ist???

Ist der Speicher ist extern über einen BUS aun die CPU gekoppelt!

Markus M. schrieb:
> Doch

Ironie, Markus, Ironie ...

In einem deiner vielen Threads zu der WS2812 Ansteuerung hatte ich 
schonmal geschrieben das der LPC die auch gut per SPI treiben kann, da 
entfällt die taktabhängige Zyklenzählerei.

Marvin S. schrieb:

> Wenn ich es gefunden hätte, würde ich hier nicht fragen..

Guckst Du UM10398 Kapitel 3.12: 
http://www.keil.com/dd/docs/datashts/nxp/lpc11xx/lpc111x_lpc11cxx_um.pdf

Du setzt die Waitstates natürlich, BEVOR Du die Frequenz mittels PLL 
raufsetzt.

Was auch noch schiefgehen kann, ist die PLL umzukonfigurieren, während 
der Chip schon von der PLL läuft. Oder die PLL konfigurieren und 
aufzuschalten, ohne zu warten, bis sie überhaupt eingeschwungen ist.

Ich habe beim LPC11C24 die Erfahrung gemacht, dass es auch eine Rolle 
spielt wie und wo der Code der delay() Routine am Ende im Flash steht. 
Das hat sicher mit den Caching-Stategien zu tun die es das auch gibt. 
Bei mir äußerte sich das so, dass die Zeiten des Delays sich bei 
manchmal nach Codeänderungen völlig verändert haben obwohl an der 
Routine selbst nichts gemacht wurde. Ich habe mir dann so geholfen:

1

// Microsecond delay loop-

2

void DelayuS(uint32_t uS)

3

{

4

  uint32_t CyclestoLoops;

5

6

  CyclestoLoops = SystemCoreClock<<1;

7

  if (CyclestoLoops >= 2000000) 

8

    {

9

    CyclestoLoops /= 1000000;

10

    CyclestoLoops *= uS;

11

    } 

12

  else

13

    {

14

    CyclestoLoops *= uS;

15

    CyclestoLoops /= 1000000;

16

    }

17

18

  if  (CyclestoLoops <= 100)

19

    return;

20

21

  CyclestoLoops -= 320; // cycle count for entry/exit should be measured

22

  CyclestoLoops /= 8;   // 

23

24

  if (!CyclestoLoops)

25

    return;

26

27

  // Delay loop for Cortex M3 thumb2

28

  // das align 4 ist extrem wichtig, sonst 

29

  // sind Unterschiede im faktor 2 möglich jenachdem

30

  // wie der Code erzeugt wird

31

  __asm volatile 

32

    (

33

    // Load loop count to register

34

    " mov r3, %[loops]\n"

35

    " .align 4\n"

36

    "loop: sub r3,#1   \n" 

37

    "      bne loop  \n\n"

38

39

    : // No output registers

40

    : [loops] "r" (CyclestoLoops) // Input registers

41

    : "r3" // clobbered registers

42

    );

43

}

Entscheidend war das .align 4\n im Assemblercode. Das schaffte dann 
Reproduzierbare Ergebnisse.

temp schrieb:
> if  (CyclestoLoops <= 100)
>     return;
>
>   CyclestoLoops -= 320; // cycle count for entry/exit should be measured

Ich würde die 100 oben durch 320 ersetzen. Falls 100 < CyclestoLoops < 
320, wird das sonst wegen wrap-around eine sehr lange Delay-Loop.

Marvin S. schrieb:
> Da hatte ich ein wenig Probleme durch eine zu
> große Lücke zwischen der Übertragung von aufeinanderfolgenden Bytes. Das
> ganze beruht auf dem Beispiel von LPCOpen.

LPCOpen baut da eventuell zuviel Sicherheit ein, oder arbeitet mit 
Interrupts? Ein WS Bit muss in 3 SPI Bits gesendet werden, macht 24 Bit. 
Die kann man in 2x12 Bit @ 2,4 MHz verschicken. Beim Senden Pollen ob 
das Statusregister ready sagt, dann einfach die Daten ins DR schreiben.

Nop schrieb:
>> if  (CyclestoLoops <= 100)
>>     return;
>>
>>   CyclestoLoops -= 320; // cycle count for entry/exit should be measured
>
> Ich würde die 100 oben durch 320 ersetzen. Falls 100 < CyclestoLoops <
> 320, wird das sonst wegen wrap-around eine sehr lange Delay-Loop.

Da gebe ich dir völlig Recht.

Markus M. schrieb:
> Grundsätzlich sollte man - wie schon oben erwähnt - grundsätzlich
> überdenken ob man die ws2812 nicht per SPI ansteuern möchte.
>
> Ich finde dieses Bitbanging ist eine absolute Krücke die es eigentlich
> zu vermeiden gilt.

Oder nimm ein Bluepill Board und schieb die Daten per DMA raus, das hab 
ich auch schon mal für 8 Kanäle gleichzeitig gemacht.