C: Stack sicher, Funktion verlassen, wieder rein, Stack herstellen

[Silvu (Gast)]

Hallo,
ich habe ein bestehendes C (GCC) Projekt in der Form:

void b()
{
  ...
  PAUSE
  ...
}

void a()
{
  ...
  b();
  ... 
}

a();

und möchte gerne da wo PAUSE steht das Programm unterbrechen, 
rausspringen und später wieder an die Stelle PAUSE, um dann b() 
abzuschließen, und danach auch a().
Ich müsste also beim Aufruf von a(); mir den Stackpointer merken, bei 
Pause dann alles bis zurück zum gemerkten Stackpointer wegsichern, 
Stackpointer zurücksetzen und dann return. Und beim Fortfahren ein goto 
PAUSE, Stack wieder füllen und weiter machen. Geht sowas?
Ich habe Bedenken, dass Interrupts das alles durcheinander bringen. Die 
könnte ich aber ja währen der Stackmanipulation mal kurzzeitig sperren.

[Klaus (Gast)]

Aus Pause eine Funktion machen

pause() {
}

und dann statt PAUSE

pause()

MfG Klaus

[nicht mit goto (Gast)]

Silvu schrieb:
> rausspringen und später wieder an die Stelle PAUSE

Silvu schrieb:
> Und beim Fortfahren ein goto
> PAUSE

goto sieht nur labels mit function scope. Raus- /reinspringen mit goto 
geht nicht

[leo (Gast)]

Silvu schrieb:
> und möchte gerne da wo PAUSE steht das Programm unterbrechen,
> rausspringen und später wieder an die Stelle PAUSE, um dann b()
> abzuschließen, und danach auch a().

Im Prinzip geht das mit setjmp(3) / longjmp(3), ABER ich wuerde das 
Konzept deines Programmes dringend ueberdenken.

leo

[Dirk B. (dirkb2)]

Das sollte longjmp() und setjmp() machen.

[main (Gast)]

Silvu schrieb:
> und möchte gerne da wo PAUSE steht das Programm unterbrechen,
> rausspringen und später wieder an die Stelle PAUSE

Programm beenden oder wie?

[Einer K. (Gast)]

Silvu schrieb:
> und möchte gerne da wo PAUSE steht das Programm unterbrechen,
> rausspringen und später wieder an die Stelle PAUSE, um dann b()
> abzuschließen, und danach auch a().

Ein kleiner µC?
Dann könntest du dir an den Protothreads ein Beispiel nehmen.
Bei mehr Speicher, auch FreeRTOS

Dirk B. schrieb:
> Das sollte longjmp() und setjmp() machen.
Auch eine Variante.

[Stefan F. (Gast)]

Arduino Fanboy D. schrieb:
> Dann könntest du dir an den Protothreads ein Beispiel nehmen.

Die sichern auch keinen Stack, sondern zwingen dich dazu, alle Daten 
woanders (z.B. Heap) zu speichern.

Silvu, du bist an dem Punkt angekommen, wo ein Betriebssystem Sinn 
macht. Das genannte FreeRTOS ist ein guter Anfang.

Das Betriebssystem kümmert sich darum, dass jeder Task seinen eigenen 
Stack bekommt. In reinem C kann man das soweit ich weiß nicht 
implementieren, dazu muss man schon ein bisschen Assembler verwenden.

[Einer K. (Gast)]

Stefan ⛄ F. schrieb:
> Die sichern auch keinen Stack, sondern zwingen dich dazu, alle Daten
> woanders (z.B. Heap) zu speichern.

Stack wird gerne überbewertet!
;-)

[DPA (Gast)]

In C++ gibt es mittlerweile coroutines: 
https://en.cppreference.com/w/cpp/language/coroutines

Es gibt ja nicht viel, was ich in C vermisse, aber generatoren, und 
coroutines / async funktionen gehören dazu...

[Silvu (Gast)]

longjmp / setjmp.
Perfekt. Genau das hab ich gesucht. Danke euch!!

[Stefan F. (Gast)]

> In C++ gibt es mittlerweile coroutines

Da werden die Daten auch nicht auf dem Stack gespeichert, sondern auf 
dem Heap. Also prinzipiell nichts neues, kein Hexenwerk. Das kann man 
auch in C implementieren, wenn man will.

[Stefan F. (Gast)]

Silvu schrieb:
> longjmp / setjmp.
> Perfekt. Genau das hab ich gesucht.

Das bezweifle ich.

[Silvu (Gast)]

oh Stefanus. Du meinst auch zu allem dein Kommentar abgeben zu müssen.
Hast lange gebraucht, bis du dich an die STM32 getraut hast und dann 
kurze Zeit später hast dich als STM32 Experte verkauft. Komm mal runter 
von deinem hohen Ross.

[🐧 DPA 🐧 (Gast)]

Also mit dem longjmp hat er recht, das wird höchst wahrscheinlich nicht 
das richtige für dich sein:

http://cplusplus.com/reference/csetjmp/longjmp/
> If env was not filled by a previous call to setjmp or *if the function*
> with such call has terminated execution, it causes undefined behavior.

[Wolfgang (Gast)]

Silvu schrieb:
> Ich habe Bedenken, dass Interrupts das alles durcheinander bringen.

Wenn ich deinen Roman so lese, solltest du erstmal deine Aufrufstruktur 
graphisch darstellen. Dann siehst du, was wie verschachtelt ist und 
kannst dann über SW-Interrupts nachdenken.

[Stefan F. (Gast)]

Wer oder was unterbricht denn deinen Programmablauf an der Stelle PAUSE?

Normalerweise würde das genau so ablaufen, wie der Klaus in der ersten 
Antwort schrieb. Du rufst da ganz einfach irgendeine Funktion auf. 
Sobald sie fertig ist, läuft das Programm wie gewünscht weiter.

Da wärst du sicher von alleine drauf gekommen. Also hast du wohl etwas 
komplexeres vor, jedoch vergessen, es ausreichend zu beschreiben. Die 
Diskussion hier läuft deswegen so wenig hilfreich ab, weil alle nur wild 
herum raten (müssen), in der Hoffnung dass du irgendwann sagst "ja 
genau, das wollte ich".

Das hast du beim Vorschlag zu setjmp/longjmp gemacht. Aber warum du 
meinst, dass dies deine Lösung sei, hast du mit keinem Wort erklärt. 
Deswegen bezweifle ich, dass dies wirklich deine Lösung ist. Ich kann 
nicht nachvollziehen, ob setjmp/longjmp hier das tun, was du brauchst.

Was ich damit eigentlich erreichen wollte ist, dass du mal erklärst, was 
du genau vor hast und wie du dort setjmp/longjmp einsetzen willst. 
Danach können mir alle mit denken und überlegen, ob das so klappen 
könnte.

Solange du uns hier an Infos verhungern lässt, kann diese Diskussion 
nicht erfolgreich enden.

[Stefan F. (Gast)]

Silvu schrieb:
> oh Stefanus. Du meinst auch zu allem dein Kommentar abgeben zu müssen.
> Hast lange gebraucht, bis du dich an die STM32 getraut hast
> und dann kurze Zeit später hast dich als STM32 Experte verkauft.
> Komm mal runter von deinem hohen Ross.

Ich habe jetzt lange genug darüber geschlafen, ohne überkochende Emotion 
darauf antworten zu können:

Du hast Recht, ich habe lange gezögert, die Anwendung von STM32 zu 
versuchen. Und zwar, weil es sie nicht im Lochraster und Steckbrett 
freundlichem DIP Format gibt. 8 Bit Controller gibt es aber in dem 
gewünschten Format und waren mir bisher auch stets leistungsstark genug.

Dennoch bin auch ich nicht völlig blind, zu bemerken, dass die 32 Bit 
Controller mit vielen interessanten Extrafunktionen aufwarten und zudem 
teilweise nicht einmal teurer sind, als 8 Bit. Zusammen mit 
Adapterplatinen und Montageaufwand sind sie allerdings für mich doch 
wieder teurer. Bis auf die Bluepill Boards. Diese waren für mich bis 
Anfang dieses Jahres noch äußerst attraktiv, sind sie aber nicht mehr 
weil man offenbar fast nur noch schlechte Fälschungen bekommt.

Was den Experten und das Hohe Ross angeht:

Lass mich bitte meine Sichtweise darstellen. Ich habe hier von Experten 
großartige Hilfe zum Einstieg bekommen. Alles, was ich dabei gelernt 
habe, habe ich ordentlich notiert und veröffentlicht, damit andere auch 
davon profitieren können. Wenn danach jemand passende Fragen dazu hatte, 
habe ich auf meine Homepage verwiesen. Das ist mein Art, der Community 
etwas zurück zu geben.

Ich habe niemals behauptet, dass ich STM32 Experte sei. Ich habe hier 
lediglich persönliche Meinungen kund getan und geholfen, wo ich glaubte, 
dies zu können.

Auf einem "hohen Ross zu sitzen" bedeutet für mich, andere Menschen als 
minderwertig zu behandeln. Ich behandle nur Menschen schlecht, die genau 
das tun oder sich anderweitig schlecht benehmen. Keine Ahnung zu haben 
oder sich zu irren, ist kein Grund, jemanden schlecht zu behandeln. So 
sehe ich das.

Falls jetzt jemand vor hat, Gegenbeweise zu suchen, wo ich meine eigenen 
Prinzipien missachtet habe: Da wird er sicher etwas finden, denn ich bin 
ein unvollkommener Mensch. Ich bin nicht so nett, wie ich gerne wäre. 
Das ist mir durchaus bewusst.

[Apollo M. (Firma: @home) (majortom)]

Stefan ⛄ F. schrieb:
> Dennoch bin auch ich nicht völlig blind, zu bemerken, dass die 32 Bit
> Controller mit vielen interessanten Extrafunktionen aufwarten und zudem
> teilweise nicht einmal teurer sind, als 8 Bit. Zusammen mit
> Adapterplatinen und Montageaufwand sind sie allerdings für mich doch
> wieder teurer. Bis auf die Bluepill Boards.

dann schau dir auch mal pic32 an! ein mips z.b.
PIC32MX270F256B im pdip28 mit 256MB flash, 64K ram und 2.3V@50MHz

[DS3 (Gast)]

Apollo M. schrieb:
> 256MB flash

Sicher?

[Apollo M. (Firma: @home) (majortom)]

Stefan ⛄ F. schrieb:
> Dennoch bin auch ich nicht völlig blind, zu bemerken, dass die 32 Bit
> Controller mit vielen interessanten Extrafunktionen aufwarten und zudem
> teilweise nicht einmal teurer sind, als 8 Bit. Zusammen mit
> Adapterplatinen und Montageaufwand sind sie allerdings für mich doch
> wieder teurer. Bis auf die Bluepill Boards.

dann schau dir auch mal pic32 an! ein mips z.b.
PIC32MX270F256B im pdip28 mit 256MB flash, 64K ram und 2.3V@50MHz

DS3 schrieb:
> 256MB flash

256KB! danke für den Hinweis, soviel zu Wunsch und Wirklichkeit!