Demo runs rather better if exported as a Flowcode app....
Martin
Implementing a non blocking delay
-
mnfisher
- Valued Contributor
- Posts: 1826
- http://meble-kuchenne.info.pl
- Joined: Wed Dec 09, 2020 9:37 pm
- Has thanked: 153 times
- Been thanked: 865 times
-
chipfryer27
- Valued Contributor
- Posts: 1886
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 411 times
- Been thanked: 635 times
Re: Implementing a non blocking delay
Hi
Further to all above, I used DSP to delay so unless you are using v10 / v11 or have a DSP license you won't be able to run. Good time to upgrade to v11 then....
This seems to simulate OK and the output reflects input after x-seconds. So if the delay was three seconds and the button was pressed for one-second, after the delay the output would be on for one-second. Similarly if it was on for 300mS then after the delay it would be on for 300mS.
Not quite got the hang of Delay Array but that is probably due to me not having enough practise with it, so here, there are three seperate in / delay / out components, one for each channel.
Didn't use much memory either.
I would need to test in hardware to check the delay is three seconds, and I have just assigned whatever as inputs / outputs.
I think perhaps something like this or the counter comparison approach documented in posts above might be the way. Thoughts?
Regards
Further to all above, I used DSP to delay so unless you are using v10 / v11 or have a DSP license you won't be able to run. Good time to upgrade to v11 then....
This seems to simulate OK and the output reflects input after x-seconds. So if the delay was three seconds and the button was pressed for one-second, after the delay the output would be on for one-second. Similarly if it was on for 300mS then after the delay it would be on for 300mS.
Not quite got the hang of Delay Array but that is probably due to me not having enough practise with it, so here, there are three seperate in / delay / out components, one for each channel.
Didn't use much memory either.
I would need to test in hardware to check the delay is three seconds, and I have just assigned whatever as inputs / outputs.
I think perhaps something like this or the counter comparison approach documented in posts above might be the way. Thoughts?
Regards
- Attachments
-
- Delay_byte_3.fcfx
- (32.83 KiB) Downloaded 18 times
-
chipfryer27
- Valued Contributor
- Posts: 1886
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 411 times
- Been thanked: 635 times
Re: Implementing a non blocking delay
Hi
Having done some tests, what you want to do won't run on a 88' if using DSP as it does not have enough RAM. You could use a 1847 and I have attached an example. Well I hope I've attached the correct one <s>
You need to use an 8MHz Oscillator and I used the internal one, and then set appropriate timer delays etc. I don't have a 1847 but the code fits inside. I ported to a different PIC for testing with these results:-
In the screenshots below, Ch0 is input-1 with Ch1 output-1. You can see the delay between input and output in the train of pulses
This shows output accurately reflecting input.
This last shot shows all three inputs (0/1, 2/3, 4/5)
As I have things out I'll try and give an example with an 88' using a counter.
Regards
Having done some tests, what you want to do won't run on a 88' if using DSP as it does not have enough RAM. You could use a 1847 and I have attached an example. Well I hope I've attached the correct one <s>
You need to use an 8MHz Oscillator and I used the internal one, and then set appropriate timer delays etc. I don't have a 1847 but the code fits inside. I ported to a different PIC for testing with these results:-
In the screenshots below, Ch0 is input-1 with Ch1 output-1. You can see the delay between input and output in the train of pulses
This shows output accurately reflecting input.
This last shot shows all three inputs (0/1, 2/3, 4/5)
As I have things out I'll try and give an example with an 88' using a counter.
Regards
- Attachments
-
- Delay_1847_Interrupt.fcfx
- (35.99 KiB) Downloaded 12 times
-
chipfryer27
- Valued Contributor
- Posts: 1886
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 411 times
- Been thanked: 635 times
Re: Implementing a non blocking delay
Hi
The potential issue in using the DSP is that the output will mimic the input in terms of duration. If you need a fixed output length then you need to involve more code or use a counter comparison.
The screenshot below is using a counter to increment a "tick". When triggered the tick value at that point is obtained and three seconds of "ticks" are added and stored in a CB (on buffer). Another CB (off buffer) is also populated with the same value plus duration.
The chart looks for the On value in the On buffer and compares to current Tick value and if present removes and sets the output.
The chart also does the same for the Off buffer.
As you can see in this example, irrespective of duration of trigger pulse, all Output pulses are delayed by approximately three seconds for a duration of a third of a second.
Regards
The potential issue in using the DSP is that the output will mimic the input in terms of duration. If you need a fixed output length then you need to involve more code or use a counter comparison.
The screenshot below is using a counter to increment a "tick". When triggered the tick value at that point is obtained and three seconds of "ticks" are added and stored in a CB (on buffer). Another CB (off buffer) is also populated with the same value plus duration.
The chart looks for the On value in the On buffer and compares to current Tick value and if present removes and sets the output.
The chart also does the same for the Off buffer.
As you can see in this example, irrespective of duration of trigger pulse, all Output pulses are delayed by approximately three seconds for a duration of a third of a second.
Regards
-
chipfryer27
- Valued Contributor
- Posts: 1886
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 411 times
- Been thanked: 635 times
Re: Implementing a non blocking delay
Hi
Forgot to attach chart.
As mentioned previously these are just examples illustrating concept and how it could be done. Steve and both the Martin's examples will no doubt be more efficient and generally "better"
You can see from the analyser traces that both count and DSP do similar in terms of delay.
Pay attention the the size of your circular buffers. Default is 128 bytes which will rapidly eat up your RAM. Set size to cover expected trigger events in a single delay period. For example if the maxium triggers that can occur within the delay period is five, then you need five bytes not one hundred and twenty eight.
In the example the 88 runs at 19.xxMHz and interrupt frequency is 75Hz which gives a "Tick" of 75 counts each second. Modify to suit your settings. A third of a second would therefore equal 75/3 = 25 counts.
This as it stands probably won't simulate too well as documented previously and you could use Medelec35's example if you do want to simulate. However it should be fine on Hardware as per traces.
Regards
Forgot to attach chart.
As mentioned previously these are just examples illustrating concept and how it could be done. Steve and both the Martin's examples will no doubt be more efficient and generally "better"
Pay attention the the size of your circular buffers. Default is 128 bytes which will rapidly eat up your RAM. Set size to cover expected trigger events in a single delay period. For example if the maxium triggers that can occur within the delay period is five, then you need five bytes not one hundred and twenty eight.
In the example the 88 runs at 19.xxMHz and interrupt frequency is 75Hz which gives a "Tick" of 75 counts each second. Modify to suit your settings. A third of a second would therefore equal 75/3 = 25 counts.
This as it stands probably won't simulate too well as documented previously and you could use Medelec35's example if you do want to simulate. However it should be fine on Hardware as per traces.
Regards
- Attachments
-
- Delay_count_88.fcfx
- (35.42 KiB) Downloaded 10 times