I have a simple program attached that I desperately need some help troubleshooting. The intent of the program is to use a push button to start and stop a Timer module then print out the time passed between the start and stop. The Timer needs to be reset each time I start a new sequence. I am attempting to do this with the StartCounter(1) macro. This command is supposed to reset the timer, then start it. However, it is not reseting, so my timer just keeps incrementally increasing. Could someone PLEASE run this simple program and tell me what I am doing wrong? I really need this to work.
Thanks in advance for your help!
-Mike
Desperate for Help!
-
- Posts: 10
- http://meble-kuchenne.info.pl
- Joined: Fri Sep 13, 2024 9:07 pm
- Has thanked: 2 times
-
- Valued Contributor
- Posts: 1453
- Joined: Wed Dec 09, 2020 9:37 pm
- Has thanked: 135 times
- Been thanked: 707 times
Re: Desperate for Help!
Hi,
I don't have this hardware to test on - but there a few issues with your code.
You use an interrupt to start / stop timing - in theory this is okay, but 'switch bounce' may mean that the results aren't as expected. I would try using one of the Flowcode switch components and testing for a 'press' to start and stop timing. Bounce means that the interrupt may get called multiple times for each press - the switch components handle this for you (debounce can be handled in software or hardware (see for example https://www.circuitbasics.com/switch-debouncing/ )
You attempt to print the time to the display in the interrupt handler - this is generally not a good idea - and if the display code uses interrupts will possibly cause your program to lock up.
As mentioned - I don't have the particular hardware, but the timer component is pretty good in my experience (there has been another thread about it not clearing?) - I would test using the timer, and if it doesn't clear correctly record the start time at the first press, the end time at the second press and then subtract start from end time.
A simple example - can you test this. I just used a random display and Arduino - so you will need to tweak target and display and the pins (actually I used b1 for the button and the display - not sensible but changing it doesn't affect the following issues)
A couple of bugs - this will work in simulation - BUT resetting the timer doesn't work (!) Also the number is displayed twice on the display (in the 2d panel) - so 4300ms is displayed as 43004300. Both issues with simulation - didn't test on hardware.
On reloading the program - the display changed from a pale background (with pale blue characters) to a dark blue background - which was much more readable. Not sure why it didn't get correct colour on adding to project though.
Martin
I don't have this hardware to test on - but there a few issues with your code.
You use an interrupt to start / stop timing - in theory this is okay, but 'switch bounce' may mean that the results aren't as expected. I would try using one of the Flowcode switch components and testing for a 'press' to start and stop timing. Bounce means that the interrupt may get called multiple times for each press - the switch components handle this for you (debounce can be handled in software or hardware (see for example https://www.circuitbasics.com/switch-debouncing/ )
You attempt to print the time to the display in the interrupt handler - this is generally not a good idea - and if the display code uses interrupts will possibly cause your program to lock up.
As mentioned - I don't have the particular hardware, but the timer component is pretty good in my experience (there has been another thread about it not clearing?) - I would test using the timer, and if it doesn't clear correctly record the start time at the first press, the end time at the second press and then subtract start from end time.
A simple example - can you test this. I just used a random display and Arduino - so you will need to tweak target and display and the pins (actually I used b1 for the button and the display - not sensible but changing it doesn't affect the following issues)
A couple of bugs - this will work in simulation - BUT resetting the timer doesn't work (!) Also the number is displayed twice on the display (in the 2d panel) - so 4300ms is displayed as 43004300. Both issues with simulation - didn't test on hardware.
On reloading the program - the display changed from a pale background (with pale blue characters) to a dark blue background - which was much more readable. Not sure why it didn't get correct colour on adding to project though.
Martin
- Attachments
-
- timer.fcfx
- (15.84 KiB) Downloaded 186 times
Re: Desperate for Help!
Martin,
Thank You for your reply! I will use your input for sure. Especially regarding the switch bounce. I DID find a similar post from someone that could not get the Timer component to reset. One of the Matrix staff offered him a "fixed" version of the Timer component. I downloaded that same version and replaced my Timer component in the released library. Now my Timer component resets! Yay for me!
Regards,
-Mike
Thank You for your reply! I will use your input for sure. Especially regarding the switch bounce. I DID find a similar post from someone that could not get the Timer component to reset. One of the Matrix staff offered him a "fixed" version of the Timer component. I downloaded that same version and replaced my Timer component in the released library. Now my Timer component resets! Yay for me!
Regards,
-Mike
-
- Matrix Staff
- Posts: 1465
- Joined: Sat Dec 05, 2020 10:32 am
- Has thanked: 204 times
- Been thanked: 347 times
Re: Desperate for Help!
Glad you got it working, Mike.
I just want to expand on something Martin has said as I think this is really important and a major source of problems.
My general rule of thumb when using interrupts is to avoid delays, loops and calls to other macros (either user or component). Instead, just use them to set a 'flag' (e.g. a global variable) to indicate that the interrupt has occurred and then deal with it accordingly inside your main program loop (resetting the flag once it has been actioned).
This requires that your main program is getting frequent and regular opportunity to react to these 'flags', and often this means having an infinite loop in your main program that is repeating every few milliseconds or so. So in this main loop you should avoid lengthy delays and other lengthy processing.
This is only advice and there will be situations where a different approach is required.
I just want to expand on something Martin has said as I think this is really important and a major source of problems.
Keeping interrupt routines as short and snappy as possible is important because it will allow your 'main' program to perform well. It's also a good idea to avoid calling component macros as this could cause unpredictable program behaviour if those components are also used elsewhere in your project.
My general rule of thumb when using interrupts is to avoid delays, loops and calls to other macros (either user or component). Instead, just use them to set a 'flag' (e.g. a global variable) to indicate that the interrupt has occurred and then deal with it accordingly inside your main program loop (resetting the flag once it has been actioned).
This requires that your main program is getting frequent and regular opportunity to react to these 'flags', and often this means having an infinite loop in your main program that is repeating every few milliseconds or so. So in this main loop you should avoid lengthy delays and other lengthy processing.
This is only advice and there will be situations where a different approach is required.
Re: Desperate for Help!
Hi Steve,
Thank you for your suggestions and guidance. I appreciate it! I understand what you are saying and will arrange my program as you suggest. I will likely be moving from the LCD display to the UART and get that routine outside of the interrupt handler.
Regards,
-Mike
Thank you for your suggestions and guidance. I appreciate it! I understand what you are saying and will arrange my program as you suggest. I will likely be moving from the LCD display to the UART and get that routine outside of the interrupt handler.
Regards,
-Mike

Re: Desperate for Help!
Hi Steve.
Say, I have the Nano Timer1 custom interrupt with freq. 20kHz. The interrupt time period will be 1/20kHz = 0.00005 seconds.
As I understood correctly it will be a good idea to flag/stop the main loop and after 0.00005 seconds set the flag off and let the main
loop work again? Is it correct?
Say, I have the Nano Timer1 custom interrupt with freq. 20kHz. The interrupt time period will be 1/20kHz = 0.00005 seconds.
As I understood correctly it will be a good idea to flag/stop the main loop and after 0.00005 seconds set the flag off and let the main
loop work again? Is it correct?
-
- Matrix Staff
- Posts: 1465
- Joined: Sat Dec 05, 2020 10:32 am
- Has thanked: 204 times
- Been thanked: 347 times
Re: Desperate for Help!
My point is you should not have a lot of lengthy code being processed within the macro that is responding directly to the interrupt. The main loop of the program is where any lengthy operations should occur.viktor_au wrote: ↑Sat Oct 19, 2024 11:46 pmSay, I have the Nano Timer1 custom interrupt with freq. 20kHz. The interrupt time period will be 1/20kHz = 0.00005 seconds.
As I understood correctly it will be a good idea to flag/stop the main loop and after 0.00005 seconds set the flag off and let the main
loop work again? Is it correct?
Re: Desperate for Help!
Understood Steve.
I have no choice. I have to have a big interrupt macro as it constantly work on a half of sine wave construction.
As my interrupt macro is the 'main' macro in the program, should I pause the main loop during my interrupt macro work?
Say, I have to check on the current flow in the h-bridge, but this is not so important, as the sine-wave work.
Should I flag the main loop during the interrupt?
I have no choice. I have to have a big interrupt macro as it constantly work on a half of sine wave construction.
As my interrupt macro is the 'main' macro in the program, should I pause the main loop during my interrupt macro work?
Say, I have to check on the current flow in the h-bridge, but this is not so important, as the sine-wave work.
Should I flag the main loop during the interrupt?
-
- Matrix Staff
- Posts: 1465
- Joined: Sat Dec 05, 2020 10:32 am
- Has thanked: 204 times
- Been thanked: 347 times
Re: Desperate for Help!
Without me understanding your program in detail, I can't give specifics.
When the interrupt macro is running, your main loop will be paused anyway. That's what happens when an interrupt is being serviced.
But generally your program should be doing almost all of it's work in the main loop. If most of the work is in creating the sine wave, then that should probably being done in the main loop.
But if your project is working reliably then perhaps there is no need to make big changes.
When the interrupt macro is running, your main loop will be paused anyway. That's what happens when an interrupt is being serviced.
But generally your program should be doing almost all of it's work in the main loop. If most of the work is in creating the sine wave, then that should probably being done in the main loop.
But if your project is working reliably then perhaps there is no need to make big changes.