Strange behaviour of interrupts

Recurrent H/W and software problems
User avatar
Electroguard
Posts: 836
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 268 times
Been thanked: 317 times

Re: Strange behaviour of interrupts

Post by Electroguard »

In the final version wlog will not be there anymore. What will be there is a bunch of commands to do the job. They will certainly be much slower than wlog

Interrupting INTERRUPTs can lead to all sorts of unwanted results, including malfunction from stack overflows.
So it might be useful for all interrupt handler routines to start by calling a subroutine that disables ALL interrupts.
Might be worth stopping any Timers as well.
Then after all interrupt handlers have done their thing, the last thing they do is call a subroutine to re-enable ALL interrupts and start Timers(s) again.
ulli
Posts: 47
Joined: Tue Feb 09, 2021 9:48 am
Location: Monschau, Germany
Has thanked: 8 times
Been thanked: 2 times

Re: Strange behaviour of interrupts

Post by ulli »

What I forgot to mention:

If the timer is not active, it works absolutely correct. The triggered input issues a single wlog channel number. The problem comes after the fourth, fifth or sixth input triggered. Then it suddenly stops working. The number of working contacts is random.
The light at the end of the tunnel has been switched off for energy saving reasons.
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: Strange behaviour of interrupts

Post by cicciocb »

The example I gave works perfectly.
Try it on the wokwi simulator
ulli
Posts: 47
Joined: Tue Feb 09, 2021 9:48 am
Location: Monschau, Germany
Has thanked: 8 times
Been thanked: 2 times

Re: Strange behaviour of interrupts

Post by ulli »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Wed Jun 07, 2023 4:57 pm
In the final version wlog will not be there anymore. What will be there is a bunch of commands to do the job. They will certainly be much slower than wlog

Interrupting INTERRUPTs can lead to all sorts of unwanted results, including malfunction from stack overflows.
So it might be useful for all interrupt handler routines to start by calling a subroutine that disables ALL interrupts.
Might be worth stopping any Timers as well.
Then after all interrupt handlers have done their thing, the last thing they do is call a subroutine to re-enable ALL interrupts and start Timers(s) again.
I can try this tomorrow, alas, with little hope. Currently I trigger a single input, look at the result and try another one. No interrupts during interrupt handling.

Can one of you guys eventually try my program on your hardware? Do you also see this effect?

I'm completely clueless, maybe even blind for the obvious.
The light at the end of the tunnel has been switched off for energy saving reasons.
ulli
Posts: 47
Joined: Tue Feb 09, 2021 9:48 am
Location: Monschau, Germany
Has thanked: 8 times
Been thanked: 2 times

Re: Strange behaviour of interrupts

Post by ulli »

Sorry for the delay. I was off site for a few days.

Now I replaced all wlogs by print commands and now it works perfectly. Thanks for all your help.

cicciocb: What's wrong with wlog? In principle it's a nice and very useful command as there is no need for a serial connection to acquire some status info. Can it be improved? Should I file this as a feature request?
The light at the end of the tunnel has been switched off for energy saving reasons.
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: Strange behaviour of interrupts

Post by cicciocb »

Nothing is wrong, it must not be used to a send many messages in a short period of time, how can be the case for the rebounds of the interrupt. Probably you can put back wlog if you are raising the interrupts with a clean signal
ulli
Posts: 47
Joined: Tue Feb 09, 2021 9:48 am
Location: Monschau, Germany
Has thanked: 8 times
Been thanked: 2 times

Re: Strange behaviour of interrupts

Post by ulli »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Sun Jun 11, 2023 1:54 pm Nothing is wrong, it must not be used to a send many messages in a short period of time, how can be the case for the rebounds of the interrupt. Probably you can put back wlog if you are raising the interrupts with a clean signal
Ok, I understand that. What I still don't understand is why this only worked a few times and then hung. As you can see from my code wlog was only used with an incoming low interrupt and then only after this interrupt was was disabled. It only printed the resp. interrupt number once, so it looked like it was working correctly.

The interrupts were (and currently still are) dirty bursts of high and low. I issued these interrupts at a slow pace, less than 1 / sec. Even with a 10-15 secs pause between interrupts, the results were still the same: 3 to 5 interrupts were handled well, then there was nor further reaction to anything.

print does not have this problem, it's working very well with my burst interrupts.

Problem is thus solved, but I'm curious. :?
The light at the end of the tunnel has been switched off for energy saving reasons.
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: Strange behaviour of interrupts

Post by cicciocb »

Try to put back the wlog ....
ulli
Posts: 47
Joined: Tue Feb 09, 2021 9:48 am
Location: Monschau, Germany
Has thanked: 8 times
Been thanked: 2 times

Re: Strange behaviour of interrupts

Post by ulli »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Sun Jun 11, 2023 4:37 pm Try to put back the wlog ....
And then?
The light at the end of the tunnel has been switched off for energy saving reasons.
User avatar
Electroguard
Posts: 836
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 268 times
Been thanked: 317 times

Re: Strange behaviour of interrupts

Post by Electroguard »

Unlike Print which is local serial, Wlog entries must be html encoded by Annex (along with any system log messages if "Stop log" is not 'checked' in the Editor page) then transmitted via buffered wifi from your device to your browser, where it must then be processed by your browsers javascript capabilities.

Big-brother tracking browsers like Chrome will not consider handling your local javascript more important than processing your personal tracking info.
In addition, your Annex devices must compete for wifi resources with other internet access devices, even if only regular burst traffic looking for updates.

To get the most out of Wlog I would minimise as much other network access as possible.
My many Annex devices interact with each other 24/7 without problems because I have them on a separate isolated subnet without internet access.
And although I use Firefox for internet access, I only use a small lightweight browser (Falkon) when connecting to my Annex devices.

Be aware that the 'Stop log' checkbox on the Editor page defaults to off (unchecked), so even though you 'check' it, it will be unchecked again when you next open the browser or refresh the page.
wlog2.jpg
You do not have the required permissions to view the files attached to this post.
Post Reply