Hello, kann es sein, dass eine längere/aufwendigere Funktion() nicht richtig funktioniert, sobald man mit Interrupts arbeitet (C-Microcontroller)? Beim debugging wird mir sobald ich die ISR einfüge nach ca. 1-4 Cycles in die Variablen (in der Funktion) = not defined angezeigt. Grüße
Gast
#4394141
Joh W. schrieb: > kann es sein, dass eine längere/aufwendigere Funktion() nicht richtig > funktioniert, sobald man mit Interrupts arbeitet (C-Microcontroller)? Ja, kann sein wenn man irgendwo einen Bug eingebaut hat.
Gast
#4394142
Joh W. schrieb: > kann es sein, dass eine längere/aufwendigere Funktion() nicht richtig > funktioniert, sobald man mit Interrupts arbeitet (C-Microcontroller)? > Beim debugging wird mir sobald ich die ISR einfüge nach ca. 1-4 Cycles > in die Variablen (in der Funktion) = not defined angezeigt. Ja, vielleicht. Bei mehr Details wäre u.A. auch eine präzisere Antwort möglich.
Gast
#4394169
Was ist den ein "C-Microcontroller" ?
Karl M. schrieb: > Was ist den ein "C-Microcontroller" ? Eine schlechtere Version der B Variante ;)
Sry, hab die main.c angehängt. Vielen Dank für Eure schnelle Unterstützung! Das Problem bereitet der Madgwick() Filter Zeile 244 Und Zeile 582
@ Joh Wolf (Firma: tet) (hampel) >kann es sein, dass eine längere/aufwendigere Funktion() nicht richtig >funktioniert, sobald man mit Interrupts arbeitet (C-Microcontroller)? Im Normalfall passiert sowas nicht, im Einzelfall ist es aber möglich. >Beim debugging wird mir sobald ich die ISR einfüge nach ca. 1-4 Cycles >in die Variablen (in der Funktion) = not defined angezeigt. Aha. Du hast also ein Problem mit dem Simulator. Das sollte man auch so sagen. Meistens tritt das Problem auf, wenn der Optimierer eingeschaltet ist. Dann muss man die Simulation mit dem compilierten programm ohne Optimierer machen.
Gast
#4394237
> #pragma interrupt_handler Timer_ISR
Da scheint mir doch mindestens der Vector zu fehlen.
Wäre sowas nicht besser:1 | |
2 | |
3 | |
Leider Nein, weil wenn ich das Programm einfach so durchlaufen lasse und die Werte mir über die UART ausgeben lassen --> ab der 2-3 Ausgabe sind alle Wert dauerhaft 0 und sobald ich die ISR wieder raus nehme --> funktioniert! und löst die ISR so langsam aus, dass sichergestellt wird, das die Madgwick() komplett druchgeführt werden kann z.B. mit 1Hz --> funktioniert ....
Gast
#4394293
Joh W. schrieb: > und sobald ich die ISR wieder raus nehme --> > funktioniert! Erstens, du bist nicht auf meinen Beitrag eingegangen. Schade... Und dieses hast du auch wohl noch nicht gelesen: https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Programmieren_mit_Interrupts Schade ... Und vielleicht, das interessiert mich jetzt auch nicht mehr, wirst du das SREG retten und wiederherstellen dürfen Und, was das in der ISR tun soll...
1 | |
2 | |
3 | |
4 | |
Ist das vielleicht ein Witz, oder so...? PS: Und sowas traue ich mich als Arduino Jünger zu sagen... Auch schade....
@Ulrich F. habe das aus dem Beispiel http://www.cypress.com/documentation/application-notes/an90833-psoc-1-interrupts
Gast
#4394305
Joh W. schrieb: > Sry, hab die main.c angehängt. Wahrscheinlich bin ich etwas zurückgeblieben :-\ welche CPU setzt Du denn ein? Wenn ich die float-Berechnungen + I2C + USART sehe ...
@Dieter F. CY8C29466-24PXI - ziemlich klein und ich weis --> ARM wäre besser, leider gibt es kein Kompromiss bei der Voraussetzung ......
Dieter F. schrieb: > Wahrscheinlich bin ich etwas zurückgeblieben :-\ welche CPU setzt Du > denn ein? Wenn ich die float-Berechnungen + I2C + USART sehe ... Und was mich so wundert, ist das die Funktion anscheinend nicht mehr die alten Werte sichern kann sobald die ISR auslöst ....
Gast
#4394318
Joh W. schrieb: > @Dieter F. > > CY8C29466-24PXI - Oha.... Dann nehme ich alles zurück! Und bitte untertänigst um Verzeihung.
Gast
#4394321
Joh W. schrieb: > CY8C29466-24PXI - ziemlich klein und ich weis --> ARM wäre besser Da könnte ich nur dumm schwafeln - ich überlasse das Feld den Experten ...
Ulrich F. schrieb: > Und, was das in der ISR tun soll...if (CpuTimeNow == 65534) > { > CpuTimeNow = 0; > } > Ist das vielleicht ein Witz, oder so...? würde ich die if Anweisung mit in die Main() nehmen, könntest du mir dann bei meiner Herausforderung einen kleinen Tipp geben?
Gast
#4394329
Joh W. schrieb: > Ulrich F. schrieb: >> Und, was das in der ISR tun soll...if (CpuTimeNow == 65534) >> { >> CpuTimeNow = 0; >> } >> Ist das vielleicht ein Witz, oder so...? > > > würde ich die if Anweisung mit in die Main() nehmen, könntest du mir > dann bei meiner Herausforderung einen kleinen Tipp geben? Die If Anweisung ist komplett über! 16 Bit Variablen machen den Wrap Around automatisch. Oder verfolgst du damit einen besonderen Zweck? Mit dem CY8C29466-24PXI und seinen Brüdern kenne ich mich leider nicht aus.
Ulrich F. schrieb: > 16 Bit Variablem machen den Wrap Around automatisch. war mir diesbezüglich unsicher, deshalb ist es mit eingeflossen ... Dank Dir
Ulrich F. schrieb: > Wäre sowas nicht besser:ISR (NAME_OF_INTERRUPT_vect) { > > } Habe dazu : #pragma interrupt_handler <func1> [ ,<func2> ]* For interrupt handlers written in C. Virtual registers are saved only if they are used, unless the handler calls another function. In that case, all Virtual registers are saved. This interrupt handler changes the ret to reti at the end of the function. The function can be used as an interrupt handler by adding a ljmp _name at the interrupt vector in boot.tpl. It cannot be used in regular C code because the reti expects the flags to be pushed on the stack. In the large memory model, the Page Pointer registers (CUR_PP, IDX_PP, MVW_PP, and MVR_PP) are saved and restored in addition to the Virtual registers for a #pragma interrupt_handler. gefunden
Joh W. schrieb: > CY8C29466-24PXI - ziemlich klein Bei nur 2K SRAM könnte Dir schlicht mit der ISR der Stack überlaufen.
Jim M. schrieb: > Joh W. schrieb: >> CY8C29466-24PXI - ziemlich klein > > Bei nur 2K SRAM könnte Dir schlicht mit der ISR der Stack überlaufen. Habe ich geprüft --> ist nicht der Fall ....