STM32 Echtzeitproblem

"Gleichzeitig" ist natürlich ein (zeitlich) dehnbarer Begriff bei nur 
einem Core...
Wie hattest Du Dir vorgestellt, dass das funktioniert?

(Free)RTOS löst das Problem auch nicht wenn nur eine Recheneinheit da 
ist...
VG, Stephan

Walt N. schrieb:
> Zum meinem bedauern musste ich festellen dass ich mein Signal
> kontinuierlich senden muss

Wobei jetzt GLEICHZEITIG und KONTINUIERLICH Begriffe aus 
unterschiedlichen Domänen sind...

Wenn ich Dich trotzdem zu verstehen versuche:
Du willst von einem System (1x Core) GEICHZEITIG über 2 Interfaces 
(SPI/I2C) Daten rausschicken... (die Empfängerseite mal ganz aussen 
vor).
Das wird nicht funktionieren, wenn Du mit GLEICHZEITG tatsächlich ein dt 
von 0 vorgibst...

Walt N. schrieb:
> Wie sieht es aus mit multi core µC's aus? Sind diese genau für diesen
> Zweck da?

Nein eher nicht. Die Kerne teilen sich gewisse Ressourcen deswegen hast 
du da noch weniger unter Kontrolle, wann genau was passiert.

Möglicherweise ist noch nicht klar, was du machen willst. Es könnte die 
synchrone Übertragung von Daten auf unterschiedlichen Schnittstellen 
sein oder auch die parallele kontinuierliche Übertragung (aber nicht 
zwingend Synchron).

Höre mal mit den Geheimnissen auf und lege die Karten offen auf den 
Tisch. Was hast du vor zu erreichen und wozu ist das gut?

> Meine I2C/SPI Verbindung funktioniert einwandfrei!

Und doch wohl nicht so, wie du es brauchst. Deswegen ist dieser Hinweis 
vollkommen wertlos. Wenn wir wüssten, was du brauchst und eine 
Vorstellung von deinem bestehenden Lösungsansatz haben, der angeblich 
"einwandfrei" funktioniert, könnten wir Dir vielleicht hilfreiche Tipps 
geben.

Aber so sagst du nur: Ich habe alles richtig aber aber es geht nicht. 
Sagt mir nicht, was ich falsch gemacht habe, denn es ist ja alles 
richtig. Hä?

Adam P. schrieb:
> Da hat meine Klaskugel heute wohl einen guten Tag

Ja, vermute ich auch. Wir müssen abwarten, was der TO dazu sagt.

Walt N. schrieb:
> Was ich machen möchte ist ein Phasenmoduliertes Signal über einen DAC
> (MCP4922) an einen Piezo schicken der mir dann ein Ultraschallsignal
> erzeugt. Daher muss ich aber nun eine statische Wertetabelle erzeugen um
> den DMA modus zu nutzen? Oder kann ich die während dem DMA auch ändern?

Natürlich.

SPI und I^2C  sind aus Core Sicht ja langsame Ereignisse
mit DMA, Interrupts, Timer kann man sehr viele Dinge parallel machen.

nur eine geht gar nicht: busy waiting

Multicore macht die Sache übrigens nicht einfacher da man auch noch die 
Cores synchronisieren muss

Zeig doch mal, wie deine I2C Kommunikation funktioniert. "Funktioniert" 
ist erstmal nicht viel wert, denn es gibt unterschiedliche Ansätze wie 
es funktionieren kann.

Wenn du etwas blockierend schickst, was in vielen Tutorials der erste 
und schnellste Schritt zum ersten Erfolg ist, kannst du in der Zeit eben 
nix anderes machen, der µC wartet.

Es gibt aber viele Methoden, Sachen quasiparallel zu machen.

Komplett analog kann das Ganze ja eh nicht sein, weil dein ADC ja auch 
nur diskrete Werte zu diskreten Zeitpunkten bekommt. Klar 
mittelt/interpoliert der das dann, aber erstmal kannst du nichts 
wirklich kontinuierlich erzeugen. Die Frage ist, welcher Minimalabstand 
zwischen den neuen Werten erlaubt ist und ab wann es Probleme im 
Ultraschall gibt.

Glaube mir, du möchtest keinen Multicore.

Walt N. schrieb:
> Adam P. schrieb:
>> - Was für ein Signal?
>> - Entschlüsseln?
>
> Meine I2C/SPI Verbindung funktioniert einwandfrei! Ich sende eine Signal
> über Ultraschall. Damit muss meine SPI Schnittstelle ohne unterbrechung
> senden. Dazwischen befindet sich natürlich noch ein bisschen Elektronik
> und aufgrund analoger Aktoren muss ich mein Signal ohne unterbrechung
> senden.

Für Audioanwendungen wird gewöhnlich der I2S Bus, mit 192KS wäre US 
vermutlich kontinuierlich machbar.

NichtWichtig schrieb:
> Für Audioanwendungen wird gewöhnlich der I2S Bus, mit 192KS wäre US
> vermutlich kontinuierlich machbar.

Was bedeutet "US"?

Walt N. schrieb:
> Aber wo ziehe ich das CS Signal am besten auf LOW?

Ich würde mal sagen, direkt vor dem Start der DMA Übertragung.

Stefan ⛄ F. schrieb:
> Ich würde mal sagen, direkt vor dem Start der DMA Übertragung.

Walt N. schrieb:
> Wenn ich mit meiner DMA Übertragung eine Wertetabelle übertrage kann ich
> ja nicht nach jeden 16 bit ( wie es das Datenblatt vom MCP4922 verlangt)
> das Chipselect Signal dazwischen schalten. Der überträgt ja die Ganze
> Wertetabelle auf einmal.

Kannst du nicht und sollst du nicht. Warum willst du es denn tun?

Adam P. schrieb:
> Sieht im Datenblatt irgendwie echt danach aus

Was steht wo in welchem Datenblatt? Zitiere es bitte.

Wenn dein Peripherie-Chip alle 16 bit so einen Impuls braucht, dann 
taugt er nicht für DMA.

Ja Kacke, dann geht DMA halt nicht.

Da wäre ein Wandler mit I²S Schnittstelle wohl besser geeignet gewesen. 
DMA scheint mir hier inzwischen sinnlos. Ich würde die Kommunikation mit 
einem Timer-Interrupt machen und dafür sorgen, dass dieser niemals 
gestört (unterbrochen) wird.

Adam P. schrieb:
> Meinst dass alles passt zeitlich in dieses Zeitfenster?

Wenn du ein Rechteck-Signal mit 40kHz ausgeben willst, dann brauchst du 
80.000 Werte pro Sekunde, also Intervalle von 12,5 Mikrosekunden.

Aber Rechteck-Signale gibt es in der Natur nicht, dein Signal wird durch 
die Übertragungsstrecke mit mehreren Oberwellen stark verzerrt. Ich 
hoffe, du hast das bedacht.

Wenn das CS Signal vom SPI erzeugt wird  und nicht als DIO kann man 
i.d.R es auch über DMA erzeugen. ( Ich hab zumindest noch kein µC 
gesehen bei dem das nicht geht)

Sonst muss man einen Interrupt verwenden der vom SPI ausgelöst wird wenn 
sein Sendebuffer leer ist.  Der Interrupt kann Daten direkt in die 
Senderegister schreiben oder den DMA neu aufsetzen. Und auch Pins 
setzten.

@Volle: Guter Hinweis!

Ich habe gerade mal ins Datenblatt des STM32F303 geschaut, der scheint 
das zu können. Man kann die Größe des Frames auf 4 bis 16 bit einstellen 
und die NSS Einheit erzeugt automatisch Impulse alle n Bits.

Interessant, das Feature kannte ich noch nicht.

Dann ist mein Kommentar

> Ja Kacke, dann geht DMA halt nicht.

wohl nicht richtig gewesen.

Walt N. schrieb:
> mcp4922 ein 40Khz Signal und an ihn sende ich entweder 0x3fff oder
> 0x3000

Das bedeutet, du erzeugst mit dem DAC ein binäres Signal bestehend aus 
den beiden Spannungswerten
1.  Vref * 4095/4096 ~= Vref * 100% = Vref
2.  Vref * 0/4096 = Vref * 0% = 0V

Warum benötigst du für diese Aufgabe einen DAC?
Das kann ein Portpin von deinem uC doch auch. Ein passend gesetzter 
Timerausgang erzeugt dir auch so ein PWM Signal mit 50% duty und den 
Phasenwechsel bekommst du, wenn du den Timerausgang invertierst.

Walt N. schrieb:
> Den Phasenwechsel bekomme ich dann aber nicht unabhängig von den anderen
> Prozessen hin oder?

In dem Punkt unterscheidet sich die Nutzung von einem per SPI angebunden 
DAC und einem Timerausgang nicht.

Den Timer stellst du auf 50% duty, passende Periode und Erzeugung von 
Timer overflow Interrupt. In jeder ISR zählst du mit, wie oft diese 
schon aufgerufen wurde. Beim 20. Aufruf der ISR investiert du den 
Timerausgang. (Zum Register update des Timers basierend auf dem Timer 
overflow interrupt könnte man natürlich noch den DMA nehmen, aber das 
würde ich nicht ohne Not machen.)

Die Unabhängigkeit von anderen Prozessen ergibt sich durch die 
Bearbeitung dieser Aufgabe vollständig innerhalb der ISR.

void schrieb:
> Die Unabhängigkeit von anderen Prozessen ergibt sich durch die
> Bearbeitung dieser Aufgabe vollständig innerhalb der ISR.

Hallo Walt, hier noch einmal etwas anschaulicher mit Pseudo-Code für 
Atmega328P (Arduino Nano).

1

void timer0_init_fastpwm(void) {

2

    DDRD |= (1<<DDD6);     // OC0A = pin PD6

3

    PORTD &= ~(1<<PORTD6);

4

    TCCR0A=0b10100011;     // fast pwm mode (COM0A1=1, COM0A0=0, Clear OC0A on Compare Match, set OC0A at BOTTOM, (non-inverting mode).)

5

    //TCCR0A=0b11100011;   // fast pwm mode (COM0A1=1, COM0A0=1, Set OC0A on Compare Match, clear OC0A at BOTTOM, (inverting mode).)

6

    TCCR0B=0b00000010;     // prescaler - 8 (results in 8kHz)

7

    OCR0A=128;             // duty cycle 50% for OC0A = pin PD6

8

    TIMSK0 = 1 << OCIE0A;  // OCIE0A: enable Interrupt by timer compare

9

}

10

11

void timer0_invert_mode_fastpwm(void)

12

{

13

    /* switch PWM on OC0A between inverting and non-inverting mode */

14

    TCCR0A ^=0b01000000;   // (toggle bit COM0A0 0<->1)

15

}

16

17

ISR(TIMER0_COMPA_vect) {

18

    static uint8_t countPwmCycles;

19

    countPwmCycles++;

20

    if (countPwmCycles >= 20) {

21

        timer0_invert_mode_fastpwm();

22

        countPwmCycles = 0;

23

    }

24

}

25

26

int main(void) {

27

    timer0_init_fastpwm();    /* init timer */

28

    sei();                    /* enable global interrupts */

29

    while(1) {

30

        DoAnotherTaskAtTheSameTime();

31

    }

32

    return 0;

33

}

Wie gesagt, in der ISR liegt hier die komplette Arbeit für die CPU.
Die ISR wird zwar verhältnismäßig oft aufgerufen, ist aber sehr kurz. 
Das unterbricht andere laufende Prozesse daher nur minimal.
Im Anhang ein Oszillogram
- gelb: Timerausgang mit 8kHz PWM und Phasen-Wechsel wie gewünscht nach 
20 Perioden
 (40kHz passte hier vom Vorteiler nicht, 64kHz ging und lief auch 
problemlos)
- blau: Ein anderer Prozess (schickt das Wort "task" per Uart)


Der Trick ist eben in der ISR nur zwischen invertiertem und 
nicht-invertiertem PWM mode(output compare) hin und her zu schalten.
> /* switch PWM on OC0A between inverting and non-inverting mode */
>     TCCR0A ^=0b01000000;   // (toggle bit COM0A0 0<->1)

Bei deinem STM32F411xC/E bietet sich da z.B. der General-purpose Timer 
(TIM2..TIM5) an.
Das äquivalente Register-Bit ist dann TIMx_CCMR1.OC1M.
siehe RM0383 Kapitel 13.4.7
> TIMx capture/compare mode register 1 (TIMx_CCMR1)
>
> bits 6:4 OC1M: Output compare 1 mode
>  110: PWM mode 1 - In upcounting, channel 1 is active as long as 
TIMx_CNT<TIMx_CCR1 else inactive. (..)
>  111: PWM mode 2 - In upcounting, channel 1 is inactive as long as 
TIMx_CNT<TIMx_CCR1 else active. (..)