Webbotlib pinChange event handling w/AXON... Mine blows up

[jaime]

Any one else using the webbot avr lib's pin change event handling mechanism?  Is it working for you?  

My SSCCE is below (http://sscce.org/)

On my Axon, this program turns on the status led and does nothing else.

Code: [Select]

// Specify which board is being used.
#include "sys/axon.h"
#include "uart.h"
#include "rprintf.h"
#include "core.h"
#include "timer.h"
#include "a2d.h"
#include "iopin.h"
#include "pinChange.h"

void
on_pinchange(const IOPin* io,boolean val, volatile void* data);

void
appInitHardware(void)
{
    pin_change_attach(C0, &on_pinchange, NULL);
}

TICK_COUNT
appInitSoftware(TICK_COUNT loop_start)
{
    return 0;
}

TICK_COUNT
appControl(LOOP_COUNT loop_count, TICK_COUNT loop_start)
{
    // NOP for 1 sec.
    return 1000000;
}

void
on_pinchange(const IOPin* io,boolean val, volatile void* data)
{
    statusLED_off();
}


[Webbot]

What are you using to change the level on C0 to fire the pin change?

[jaime]

What are you using to change the level on C0 to fire the pin change?

I have an RF (err remote control) card that sets the value low/high.  I've validated this with a multimeter.

But the thing is, it is not even getting that far.  It lights up the status led and stops.  I am not lighting the status led anywhere in my code.

I don't even have anything plugged into C0.

Thanks!
jaime

[Webbot]

The library itself turns on the status LED before calling your program.
Your program then doesn't do anything until C0 is changed.

[jaime]

In my "big" version of the program, I did have things wired up and ready to go.

Let me double check things this weekend.  I'll post an update tomorrow or Saturday.

Thanks,
jaime

[jaime]

Ok, so I'm a bit late...  Too much football, too little time...   

Below is my code example.  In order to test, I hook a wire directly to one of the 5v regulated pins on the Axon and plug the other end into C0.  I expected to see the LED come on.  Am I missing something obvious?

Code: [Select]

// Specify which board is being used.
#include "sys/axon.h"
#include "iopin.h"
#include "pinChange.h"

void
on_pinchange(const IOPin* io,boolean val, volatile void* data);

void
appInitHardware(void)
{
    pin_make_input(C0, 0);
    pin_change_attach(C0, &on_pinchange, NULL);
}

TICK_COUNT
appInitSoftware(TICK_COUNT loop_start)
{
    statusLED_off();
    return 0;
}

TICK_COUNT
appControl(LOOP_COUNT loop_count, TICK_COUNT loop_start)
{
    return 20000;
}

void
on_pinchange(const IOPin* io,boolean val, volatile void* data)
{
    statusLED_on();
}


[Webbot]

The ATMega640 only supports pin change interrupts on the following pins: PCINT0 - PCINT23 which correspond to IO pins:
B0, B1, B2, B3, B4, B5, B6, B7, E0, J0, J1, J2 ,J3, J4, J5, J6, K0, K1, K2, K3, K4, K5, K6, K7

You app uses 'C0' - which isn't in the list.

In fact what you should see is the status LED flashing out an error message to tell you that your call to 'pin_change_attach' is specifying an invalid IOPin.

[jaime]

The ATMega640 only supports pin change interrupts on the following pins: PCINT0 - PCINT23 which correspond to IO pins:
B0, B1, B2, B3, B4, B5, B6, B7, E0, J0, J1, J2 ,J3, J4, J5, J6, K0, K1, K2, K3, K4, K5, K6, K7

You app uses 'C0' - which isn't in the list.

In fact what you should see is the status LED flashing out an error message to tell you that your call to 'pin_change_attach' is specifying an invalid IOPin.

My status LED isn't flashing.  I'm not sure about those pin mappings you mention above, because the Axon doesn't have all of those.  The Axon has - E2-E7, H2-H6, A0-A7 and C0-C7.

FWIW, I did try a handful of other pins and could not get it to work on them either.  No, I don't recall what they were  .

I can just check for the pin to be high or low when I step through main, so this isn't a big deal.  If you need me to help you trouble shoot this further, don't hesitate to ask.

Thanks for your help!
jaime

[Webbot]

Hi jaime

I'm not sure about those pin mappings you mention above, because the Axon doesn't have all of those.  The Axon has - E2-E7, H2-H6, A0-A7 and C0-C7.

Thats why I said 'ATMega640' rather than 'Axon'. ie 'Axon' is a subset of ATMega640.
Note that the 'pin change' interrupts are NOT a 'feature' of my lib -they are dictated by the abilities of the hardware. So the port C pins will never work on an ATMega640/Axon.

At least one other SoR member has also used the quadrature encoder code, as have I, which relies totally on the pin change interrupt and we've both managed to make it work. So can you try changing your code so that it uses one of the pins that supports pin change interrupts: such as K0 to K7 on the Axon (which are the right most pins of the ADC channels).
 

[jaime]

Webbot, thanks so much for your help!!  That fixed it.

Wow, there is a lot to learn with this robot stuff...  It's what makes it interesting.

I appreciate your patience!

jaime

[Admin]

In fact what you should see is the status LED flashing out an error message to tell you that your call to 'pin_change_attach' is specifying an invalid IOPin.

Webbot, I'm sure you've already thought of this and ruled it out but . . . can you somehow generate a compile warning when mistakes like these happen? My Axons are typically far away from me, or buried inside a robot, as I program it. I never notice flashing LEDs . . .

And/or perhaps force the error to be outputted through serial, like the Axon USB port? There can always be a warnings(off) function if it causes people problems . . .

(apologies if I just thread-jacked, its kinda related!)

[Webbot]

In fact what you should see is the status LED flashing out an error message to tell you that your call to 'pin_change_attach' is specifying an invalid IOPin.

Webbot, I'm sure you've already thought of this and ruled it out but . . . can you somehow generate a compile warning when mistakes like these happen? My Axons are typically far away from me, or buried inside a robot, as I program it. I never notice flashing LEDs . . .

And/or perhaps force the error to be outputted through serial, like the Axon USB port? There can always be a warnings(off) function if it causes people problems . . .

(apologies if I just thread-jacked, its kinda related!)

Thought about it a while ago but its sooooo hard to do.

The library supports a number of different processors and for each of those there can be different configurations.  ie ATMega640 could be for, say, Axon or AxonII configurations. Taking the list of pins supporting pin change interrupts listed previously then they are the same for all ATMega640s but the Axon II provides headers for more of them than the Axon does. Whereas the Roboduino or ATMega328P are completely different. So trying to produce compiler errors is therefore horrendously complex ie given 'C0' you have to check if the processor has a 'C0', then check if the board provides a pin out for 'C0', then check if 'C0' supports pin change interrupts for the given cpu. It would be kinda simpler with C++ (except that AVRStudio simulator is useless with C++) using multiple inheritance or by achieving the same thing in C but that would inflate the memory requirements further.

The only path worth investigating is to change all of the current constructor macros from:
THING name = MAKE_THING(a,b,c);
to
MAKE_THING(name, a, b, c);

The first (and current) method doesn't allow you to do much in the way of processing at compile time, whilst the second method would allow you to do more. This change would effect all existing applications and so would be a bit of a bore for current users - but may be worth investigating.


Reporting errors over a UART at runtime would be easier and would trap all the 'other' errors. For example the lib gives a runtime error if you try to use the same PWM pin for more than one motor (which would be almost impossible to check at compile time).

[Admin]

I trust your decision. If you think the UART error reporting idea is easiest, lets go with that. Its definitely more user friendly to output semi-informative text errors versus counting LED flashes.

(but must also be Webbot-friendly in terms of programming it in)

The LED-flashing should still stay, as someone might not have UART hooked up to say hyperterminal.


And again apologies for the thread-jack. I figured as more people used WebbotLib, more questions like this will come up. Trying to solve it before it becomes a common problem.

[Webbot]

If you think the UART error reporting idea is easiest, lets go with that. Its definitely more user friendly to output semi-informative text errors versus counting LED flashes.

They wont be informative text messages; they will report the error number (as per the number of flashes) e.g. 'WebbotLib Error 10'. It would be nice to have long descriptive pieces of text but they would bloat the program unnecessarily - all that text would need to be stored somewhere! So you would need to refer to "errors.h" to find a description of what error 10 refers to.

[Admin]

If you think the UART error reporting idea is easiest, lets go with that. Its definitely more user friendly to output semi-informative text errors versus counting LED flashes.

They wont be informative text messages; they will report the error number (as per the number of flashes) e.g. 'WebbotLib Error 10'. It would be nice to have long descriptive pieces of text but they would bloat the program unnecessarily - all that text would need to be stored somewhere! So you would need to refer to "errors.h" to find a description of what error 10 refers to.

Yea, I figured something short and sweet. If the manual has an error quick ref section, thats good enough!