Looking for users with experience using RC5 remote control component

[jan.didden]

Yes, found it. I edited my msg above, seems to work in h/w.
Thanks for all your encouragement!

Jan

[jan.didden]

Hmm. It seems an interrupt service routine can only be called from either a falling edge or a rising edge on a pin.
For this setup, I need to service both a falling and a rising interrupt.
The h/w of the PIC16F15355 can be set to interrupt on both a rising and a falling edge on a particular pin.
Is there a workaround that anybody knows of?
Maybe I could define two input pins as sources of an int, one on a rising edge, one on a falling edge, both calling the same service routine, but that seems a bit convoluted.

Jan

[jan.didden]

Quick update. The selection of interrupt pins for this device (PIC16F15355) is limited to portA and portB, although the other ports (C, D) also have this capability. Can live with that.
I set up B2 as interrupt on falling edge, but for some reason that pin then gets configured as a low output. If I connect the IR receiver output to pin B2, it is clamped to ground. So there seems to be an issue with configuring B2 within the interrupt setup.
Any ideas?

Edit: updated attachment

Jan

[jan.didden]

If I look into the C file, I see:

// Name: Interrupt, Type: Interrupt: Enable INT0
cr_bit(INTCON,INTEDG);
INTPPS = 0x0A;
st_bit(INTCON,GIE);
st_bit(PIE0, INTE);

This must be the section enabling the int and setting the edge direction.
I can not find any definition of which port pin this INT0 is assinged to (should be B2).
But,for some reason, in the component macro, you can set the int pin (any port A or port B pin), but for simulation, only A0 can be used.
Maybe there's a hitch there?
I'm not smart enough to dig deeper ...

Edit -edit - scratch the above. I made a connection error to B2.
Corrected it, and now the edge is correctly detected, and the int service routine is called.
So now I can continue to build the data decoder.

Jan

[jan.didden]

Next hurdle. For some reason, the timer returns zero elapsed time, even with a deliberately inserted 4ms delay.
Looking at the timer properties there is a 2MHz coount rate specified with no option to change it.
Does FC, knowing the osc freq, insert a prescaler to get to 2MHz?
My processor runs at 32MHz.
Could that give a conflict?

Jan Didden

[mnfisher]

Hi Jan,

It's a mistake to try and do so much in the interrupt handler - the LCD handling needs to be moved into the main code.
The interrupt handler needs to be as quick as possible (and not rely on any code that uses interrupts for timing (SPI/i2c/UART etc) or to have a delay...

MArtin

[mnfisher]

I did a simple example....

Its for AVR (Arduino) - so you'll need to change the C code (EICRA -= ) to the code given by Ben....

It uses UART to display the output (there is too much data for a small LCD)

pulse_timer.fcfx

(16.46 KiB) Downloaded 750 times

It just records 'pulses' to a circular buffer (and I have the IR sensor attached to Pin2)

Martin

[mnfisher]

Thinking about it on the way in to work - it might be easier to reset the timer after recording each pulse (removes the need to save last time and do current - last)
It's a pity that the get_time routines (except raw?) use floating point maths - which means the interrupt handler is a little bit slower (the golden rule is keep it fast here)

It should be fairly easy to combine this with the state machine from before and read the IR code entirely in the interrupt handler (and set a 'flag' on received)

Martin

[jan.didden]

Martin, I understand the need to keep the ISR short and fast, but I was just trying to read the timer, not to get any accuracy.
And yes, I intend to reset the timer after each detected pulse.
So far it just returns zero when I read it. If I solve that I can move on.
Appreciate your input.

Jan

[mnfisher]

The interrupt handler has print statements and a 250ms delay - this is very unlikely to give the results you want / work at all...

Martin