Looking for users with experience using RC5 remote control component

mnfisher
Valued Contributor
Posts: 399
http://meble-kuchenne.info.pl
Joined: Wed Dec 09, 2020 9:37 pm
Has thanked: 49 times
Been thanked: 227 times

Re: Looking for users with experience using RC5 remote control component

Post by mnfisher »

An NEC reader operating entirely in the pin change interrupt....

This is for AVR (Arduino) - will need Ben's code to alter pin change direction for PIC...

Seems to work reliably (ignores 'repeat' code for now)
pulse_timer.fcfx
(21.02 KiB) Downloaded 15 times
Martin

jan.didden
Posts: 59
Joined: Thu Dec 17, 2020 3:16 pm
Has thanked: 18 times
Been thanked: 12 times

Re: Looking for users with experience using RC5 remote control component

Post by jan.didden »

Why is that Martin? Why can I not expect a timer value of 250ms?
Doesn't the interrupt routine just chug on till the RETFI instruction?

Jan

mnfisher
Valued Contributor
Posts: 399
Joined: Wed Dec 09, 2020 9:37 pm
Has thanked: 49 times
Been thanked: 227 times

Re: Looking for users with experience using RC5 remote control component

Post by mnfisher »

Hi Jan,

The interrupt handler effectively blocks all other interrupts - the timer (component ) has another interrupt (occurring when a timer (register) overflows) - but this doesn't happen when the processor is already handling an interrupt. Thus the timer is effectively stopped whilst the MCU is handling the pin-change (or any other) interrupt. At the end of the 250ms delay the timer will still return 0.
This depends on the delay using MCU 'nop' instructions or similar in a loop - if it relies on an interrupt timer then the MCU may actually lock up - waiting for an interrupt that is blocked until the routine returns..

The print routines might also rely on an interrupt occurring (for example at the end of a byte) - and again these will be blocked until interrupts are re-enabled. This could lead to the MCU 'locking up'

Some MCUs do allow higher level interrupts to occur whilst the MCU is handling a 'lower-level' interrupts - but this tends to be more powerful processors .

The processors do this because - on interrupt - the IP etc is saved on the stack . Registers that are in use (or often all registers) are saved to stack - or swapped to an alternate register bank - so if interrupts were allowed to occur during an interrupt handler - then either the stack rapidly uses all available stack space or registers become corrupted.

It is possible (but difficult) - to re-enable the interrupts / re-organise / reload the registers to perform some 'tricks' (multi-tasking for instance) - but for the sake of sanity I don't recommend it...

Many MCUs also will 'chain' interrupts - so if an interrupt occurs whilst an interrupt handler is running then a flag (a bit) is set and it runs after the first returns(and interrupts are re-enabled) (this doesn't help for the timer example however - where just one 'tick' will occur after the macro returns). This stops, for example keystrokes / timers etc - being missed, however it still relies on a maximum of one such event occurring whilst the MCU is in an interrupt handler.

Martin

Did you try my code - above - it occurs to me that for PIC we just need to 'toggle' the direction bit on each interrupt.

jan.didden
Posts: 59
Joined: Thu Dec 17, 2020 3:16 pm
Has thanked: 18 times
Been thanked: 12 times

Re: Looking for users with experience using RC5 remote control component

Post by jan.didden »

Now that makes a lot of sense, thanks for taking the time for this.
I can follow your software, but I won't be able to test it for a couple of weeks.
I lost the prototype and am waiting for new PCBs to arrive.

I understand the issue with stack overflow with nested interrups; I should have kept the timer delay to below 30ms to avoid timer overrun/interrupt, if I have done my sums right (16 bits at 2MHz ticks).
I think I can get by, by just looking at the falling edge (the IR receiver has active low output) as the pulse widths for '1', '0', start, repeat etc are unambiguous.

I'll report back as soon as I got my new prototype h/w. In the mean time I can try to get it going on the sim, but I believe we already established that that may not work correctly. Don't know if the sim supports interrups in a script or something.
Have you tested your code in simulator? If so, how do you generate the int while the sim is running?

Thanks again,

Jan Didden

mnfisher
Valued Contributor
Posts: 399
Joined: Wed Dec 09, 2020 9:37 pm
Has thanked: 49 times
Been thanked: 227 times

Re: Looking for users with experience using RC5 remote control component

Post by mnfisher »

I haven't tried it in simulation - I think timing might be an issue but if would be easy to add a 'lookup table' of pulse times to be loaded at the start of the interrupt handler. I used fairly wide tolerances of pulse length - which probably need a bit of tuning.

On AVR the interrupt pins (d2 and d3) can generate an interrupt by changing them in software - so maybe a way to test various cases? I haven't tested to see if this works in sim.

The other 'fly in the ointment' is error handling (which i 'deliberately' avoided) what- happens if, for example, a signal stops half way through. I 'think' it should recover after 1 missed signal - which may or may not be adequate - if the user then 'holds down' a button because it 'didn't work' the receiver will just get a repeat signal?

Martin

mnfisher
Valued Contributor
Posts: 399
Joined: Wed Dec 09, 2020 9:37 pm
Has thanked: 49 times
Been thanked: 227 times

Re: Looking for users with experience using RC5 remote control component

Post by mnfisher »

A brief experiment - FC does do pin-change interrupts (view -> digital pins and then 'clicking' the <> (change) icon by the relevant pin)

Then use an IsSim decision to load pulse with a time from a lookup table (or calculate it using a 'send' value?) to check that the PinChange interrupt handler is working correctly...

I always feel that I've barely scratched the full potential of FC when I find features like this - I guess I go straight to hardware (or breadboard) too early...

Martin

chipfryer27
Valued Contributor
Posts: 102
Joined: Thu Dec 03, 2020 10:57 am
Has thanked: 84 times
Been thanked: 47 times

Re: Looking for users with experience using RC5 remote control component

Post by chipfryer27 »

Hi
mnfisher wrote:
Sun May 08, 2022 10:01 am
I always feel that I've barely scratched the full potential of FC when I find features like this - I guess I go straight to hardware (or breadboard) too early...
Until recently I predominantly used the PIC multiprogrammers, and with some home made SIL breakout boards plugged in giving me full access to the ports (I've since found screw terminal versions on the usual cheapo sites) it made it so very easy to test with (especially if I could get Ghost working too, but that's another story).

Your find will be quite helpful when not in front of hardware.

Thanks for the tip.

Regards

mnfisher
Valued Contributor
Posts: 399
Joined: Wed Dec 09, 2020 9:37 pm
Has thanked: 49 times
Been thanked: 227 times

Re: Looking for users with experience using RC5 remote control component

Post by mnfisher »

A version for simulation...

I modded the code to use a LCD display (looks better on the 2d panel) - and added a 'Send' function. This toggles pin d2 (in this case) firing off the pin change interrupt. When running in sim it sets a 'length' variable rather that using the timer (I didn't test with timer - but it might be adding delays in send works here ?)

The Send sim - could also be used as the basis of a 'real' send too..

One 'bug' I notice in my code - I don't check for the final 'end of data' pulse - so that needs adding?
NEC IR Sim.fcfx
(29.46 KiB) Downloaded 20 times


Martin

jan.didden
Posts: 59
Joined: Thu Dec 17, 2020 3:16 pm
Has thanked: 18 times
Been thanked: 12 times

Re: Looking for users with experience using RC5 remote control component

Post by jan.didden »

Martin, a quick reply: I intend to discard the msg when an error detected and go back to idle. Surely any remote key press must send off multiple messages.
The IsSim directive is new to me ...

Chipfryer27, thanks for chiming in.

Jan

mnfisher
Valued Contributor
Posts: 399
Joined: Wed Dec 09, 2020 9:37 pm
Has thanked: 49 times
Been thanked: 227 times

Re: Looking for users with experience using RC5 remote control component

Post by mnfisher »

Yes. - I agree that going to idle is the thing to do. The problem is how to detect the error state. One check is 2nd and 4th bytes should be inverse of 1st and third. Another would be a timeout after 62.5ms (total transmission time)

The controller puts out command followed by 'repeat' signals (9me pulse, 2.25ms gap 560us pulse) when button is held down - which is easy to check for. An error state also needs to clear previous cmd? - to avoid repeating a ( possibly) corrupt instruction. Setting volume to 255 might alarm the neighbours?

Martin

Post Reply