Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PIC32 Pinguino Change Notification fails
15-01-2016, 07:18 PM,
#1
PIC32 Pinguino Change Notification fails
PIC32 Pinguino, Windows 7{64), IDE Version 11. I simply cannot get the IDE to compile to make a change notification interrupt, let alone actually achieving an interrupt! I have tried innumerable examples from this forum, Olimex's forum and the web. The latest and best was recommended by Regis himself in this forum under Frequently Asked Questions when he suggested we look at Henk van Beek's ddf77.c for a pretty good example for setting up interrupts. Here are the important lines of code and what happened:

Everybody, including Henk, seems to agree this line is required:
IntConfigureSystem(INT_SYSTEM_CONFIG_MULT_VECTOR); // Used in interrupt.c and interrupt.h
The user's manual says that while setup() and loop() are mandatory, interrupt() is optional. I would have guessed that, because the PIC32MX440H256 comes out of RESET in single vector mode, interrupt() would be where interrupts are vectored to by default in the IDE. That would imply that I wouldn't have to do ANYthing else to get a properly set-up Change Notice interrupt to vector to interrupt(). Not so, assuming my CN setup is okay. And I could never find an example where interrupt() is actually used. In fact, even SINGLE_VECTOR is never used once (and only referred to once in interrupt.c) in all the libraries that came with the IDE. So I have to dive into the multiple vector code, starting with the above line, even with my very simple interrupt service routine. I put the above line in setup(). In the spirit of Arduino ready-to-use, shouldn't ISRs vector to interrupt() by default with little or no user comprehension?
Anyway, I had added interrupt() for SINGLE_VECTOR attempts and wrote my desired ISR routine. When I went to MULT_VECTOR, I commented interrupt() out and compiled with just the call to IntConfigureSystem(INT_SYSTEM_CONFIG_MULT_VECTOR). I got this error:

In file included from C:\pinguino-11\user\source\main32.c:57:0:
C:\pinguino-11\user\source\user.c: In function 'setup':
C:\pinguino-11\user\source\user.c:1374:24: error: 'INT_SYSTEM_CONFIG_MULT_VECTOR' undeclared (first use in this function)
IntConfigureSystem(INT_SYSTEM_CONFIG_MULT_VECTOR);
^
C:\pinguino-11\user\source\user.c:1374:24: note: each undeclared identifier is reported only once for each function it appears in
make: *** [compile] Error 1

When I uncommented my ISR and overwrote the name to be UserInput() -- never explicitly telling the IDE it was to be an ISR (so it must have known the former interrupt() was an ISR)-- the sketch compiled without error. In other words, with an ISR function, the call to IntConfigureSystem() works, without the ISR function, it fails. Hereafter I left my ISR uncommented. So-- onward and downward.

Henk's code:
// Put the ISR_wrapper in the good place
void ISR_wrapper_vector_4(void) __attribute__ ((section (".vector_4")));
My modification for PIC32 Pinguino, having, I understand, 26 for the Change Notice vector.
// Put the ISR_wrapper in the good place
void ISR_wrapper_vector_26(void) __attribute__ ((section (".vector_26")));
This line compiled without error.

Henk's code (for TIMER1, but according to Regis' general recommendation, useful for other kinds of interrupts):
// ISR_wrapper will call the DCF77_timer1Interrupt()
void ISR_wrapper_vector_4(void) { Timer1Interrupt(); }
My modification for PIC32 Pinguino
// ISR_wrapper will call the ISR
void ISR_wrapper_vector_26(void) {UserInput(); }

This resulted in two warnings, and finally a failure:

In file included from C:\pinguino-11\user\source\main32.c:57:0:
C:\pinguino-11\user\source\user.c:1572:6: warning: conflicting types for 'UserInput'
void UserInput() {
^
C:\pinguino-11\user\source\user.c:146:35: note: previous implicit declaration of 'UserInput' was here
void ISR_wrapper_vector_26(void) {UserInput(); }

collect2.exe: error: ld returned 1 exit status
make: *** [compile] Error 1

How there could be conflicting types for UserInput when there's only one reference to it so far, I don't understand. So I tried adding my version of Henk's next line, a declaration of the function with an attached attribute that it is an interrupt service routine.

Henk's code:
// Tmr1Interrupt is declared as an interrupt routine
void Timer1Interrupt(void) __attribute__ ((interrupt));
My equivalent:
// The ISR is declared as an interrupt routine
void UserInput(void) __attribute__ ((interrupt));
The resulting errors:

In file included from C:\pinguino-11\user\source\main32.c:57:0:
C:\pinguino-11\user\source\user.c:148:6: warning: conflicting types for 'UserInput'
void UserInput(void) __attribute__ ((interrupt));
^
C:\pinguino-11\user\source\user.c:146:35: note: previous implicit declaration of 'UserInput' was here
void ISR_wrapper_vector_26(void) {UserInput(); }
^
C:\pinguino-11\user\source\user.c: In function 'UserInput':
C:\pinguino-11\user\source\user.c:1609:1: error: interrupt handlers cannot be MIPS16 functions
}
^
and repeated 30 times:
C:\pinguino-11\user\source\user.c:1609:1: error: interrupt handlers cannot be MIPS16 functions
and finally:
make: *** [compile] Error 1

So I learned about void __attribute__ ((nomips16)) and got rid of the scolding about mips16 by backing up to this:

// Put the ISR_wrapper in the good place
void ISR_wrapper_vector_26(void) __attribute__ ((section (".vector_26")));
// Assign ISR handlers to interrupt vector
void __attribute__ ((nomips16)) ISR_wrapper_vector_26(void) {UserInput();}

I'm not scolded about mips16, but I still have an error about it, and also about conflicting types for UserInput:

In file included from C:\pinguino-11\user\source\main32.c:57:0:
C:\pinguino-11\user\source\user.c:152:1: error: 'ISR_wrapper_vector_26' redeclared with conflicting 'nomips16' attributes
void __attribute__ ((nomips16)) ISR_wrapper_vector_26(void) {UserInput();}
^
C:\pinguino-11\user\source\user.c:1572:6: warning: conflicting types for 'UserInput'
void UserInput() {
^
C:\pinguino-11\user\source\user.c:152:63: note: previous implicit declaration of 'UserInput' was here
void __attribute__ ((nomips16)) ISR_wrapper_vector_26(void) {UserInput();}
^
make: *** [compile] Error 1

Same reasoning-- maybe I have to re-add the declaration of UserInput() (I learned that void __attribute__ ((nomips16)) is very much unwanted for the void UserInput() declaration):

Henk's code, in full:
// Put the ISR_wrapper in the good place
void ISR_wrapper_vector_4(void) __attribute__ ((section (".vector_4")));
// ISR_wrapper will call the DCF77_timer1Interrupt()
void ISR_wrapper_vector_4(void) { Timer1Interrupt(); }
// Tmr1Interrupt is declared as an interrupt routine
void Timer1Interrupt(void) __attribute__ ((interrupt));
My chastened and repentant code, in full:
// Put the ISR_wrapper in the good place
void ISR_wrapper_vector_26(void) __attribute__ ((section (".vector_26")));
// Assign ISR handlers to interrupt vector
void __attribute__ ((nomips16)) ISR_wrapper_vector_26(void) {UserInput();}
// Declare interrupt handler
void UserInput(void) __attribute__ ((interrupt));
The incomprehensible error:

In file included from C:\pinguino-11\user\source\main32.c:57:0:
C:\pinguino-11\user\source\user.c:152:1: error: 'ISR_wrapper_vector_26' redeclared with conflicting 'nomips16' attributes
void __attribute__ ((nomips16)) ISR_wrapper_vector_26(void) {UserInput();}
^
C:\pinguino-11\user\source\user.c:154:6: warning: conflicting types for 'UserInput'
void UserInput(void) __attribute__ ((interrupt));
^
C:\pinguino-11\user\source\user.c:152:63: note: previous implicit declaration of 'UserInput' was here
void __attribute__ ((nomips16)) ISR_wrapper_vector_26(void) {UserInput();}
^
make: *** [compile] Error 1

How can this be SO WRONG?!? I've only got one dim star after my name. Can some of you folks with large clusters of stars after your names please tell me what is wrong? I'll fix whatever you say, and then will see if my interrupt service routine is actually configured right. But so far I am not even started!

Thanks, Loren
Reply
16-01-2016, 12:28 AM, (This post was last modified: 16-01-2016, 01:01 AM by pingotg.)
#2
RE: PIC32 Pinguino Change Notification fails
I think you mean dcf77.c

I'm not sure why he did it that way or quite why it works. Does dcf77.c compile and work? Just curious...

I'm especially surprised he in effect uses Timer1Interrupt before defining (or declaring) it.

I think the idea of Pinguino was to add things to ISRwrapper.S and then you can code the way rtcc.c and spi.c do.

Very possibly ISRwrapper.S should define all vectors and there could be weak externals or such like so the linker doesn't moan.

I recall there's been some work to use mips16, perhaps by default?, so you'd have to not use that for your ISR - which might explain one/some of the errors.

edit: I think there may be weak linker things already but ran out of time to hunt around

John
Reply
16-01-2016, 10:23 PM,
#3
RE: PIC32 Pinguino Change Notification fails
Thank you, John. I follow your many posts with interest. I don't really understand the pertinence of your reply to my post, but that only means more reading and thinking on my part is required.

The bottom line is, how does one ACTUALLY set up a change notice interrupt in a PIC32 Pinguino or OTG? If you are able to see the peculiar order of Henk's code (and it never occurred to me to see if it compiles, since Regis recommended it), and judging by your many astute posts, you probably have an excellent idea of what it takes to set up a change notice interrupt. So let me ask you directly, on behalf of all the battery-powered users of the Pinguino/OTG where SLEEP is important at every opportunity and Change Notification and/or Watchdog interrupts are therefore mandatory-- how would YOU do a CN interrupt on a Pinguino/OTG?

Thanks so much,

Loren
Reply
17-01-2016, 06:11 PM, (This post was last modified: 17-01-2016, 06:12 PM by pingotg.)
#4
RE: PIC32 Pinguino Change Notification fails
It's not my code - I was just hunting around for ideas that might help you. Ideally whoever decided how interrupts are handled now would know the plan and might even have written it up or at least be able to tell you!

I don't have any battery-operated PIC32s, either. I'm somewhat interested but not in the next few months I suspect.

For a CN interrupt if you can't contact whoever (Regis?) set up the interrupt scheme... I'd change the ISR code I mentioned and see if the interrupt is triggered. Flash a LED or some such.

John
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)