PIC24 Timer2 Interrupts Count

[canary_wharfe]

Can someone please look at the attached Timer2 Interrupt test routine and tell me what is going on? The LCD count is indicating the interrupt Fq is around 39Hz but this is nothing like the figure indicated in the Timer2 properties window. With build setting used and an 8MHz ext clock is the actual Interrupt Fq 39Hz or not. I don't unfortunately have this chip to test the hardware but I would have expected the LCD in simulation to show more or less the correct number of interrupts per sec. What is even more alarming is if I select different clock frequencies in the build settings it seems to make no difference to what is shown on the LCD.

[WingNut]

I'm not sure all interrupts simulate. If its any more help I get 12 or 13 when I run this simulation

[kersing]

Simulation, including interrupts are no where like on device performance. Clock settings for the target device have no bearing in simulation speed. You PC speed wil determine simulation speed.

[canary_wharfe]

Hang on a mo! There's two different things here. One is simulation speed and the other is an absolute clock count quantity / number obtained during executing an interrupt sub routine. I totally understand that the speed of simulation will be equivalent to the system performance the simulator is running on. But if you have set in the simulation a clock generator controlling an interrupt and then have a subroutine that is supposed to count so many pulses, the total number of pulses counted within the simulation should emulate the maths setting regardless of how quick or slow the simulation is running. Its about quantity of the result not how fast or slow the result is obtained. The point is the quantity should be accurate so the simulation can be considered valid. What I pointed out in the original post is that it doesn't seem to matter what clock settings are used in the sim, the interrupt count quantity doesn't change. To my way of thinking that just can't be right for the simulator to serve any useful value whatsoever.
There's is another post back in June where a Flowcode user had a similar problem on a PUIC16 device and the response from Steve at Matrix basically indicated the error to that problem cannot be fixed until Flowcode 10. I'm just not sure what the real message here is. Regardless of whether the simulation works or not, does flowcode compile so that the interrupt subroutine performs in hardware to match the flowcode interrupt frequency shown in the property page of the timer interrupt?

[Steve-Matrix]

There's is another post back in June where a Flowcode user had a similar problem on a PUIC16 device and the response from Steve at Matrix basically indicated the error to that problem cannot be fixed until Flowcode 10.

I believe the post you are referring to is this one?
viewtopic.php?f=5&t=1231

This is an issue with how Flowcode calculates the value shown. So in some circumstances you need to be aware that the interrupt frequency shown in the Interrupt Properties is incorrect and does not reflect the actual interrupt frequency when downloaded to a target device.

I believe this problem is limited to some interrupt settings for 8bit PICmicros. It is where the "clkdiv" entry for a specific setting differs from the "master_divider" entry in the FCDX file for that device. The "clkdiv" entry is the correct clock divider when calculating the frequency, but this is ignored and the "master_divide" is used instead. If you have 2 interrupt settings such as "Internal clock (Fosc)" and "Internal clock (Fosc/4)" on the same device, you will see these calculate the same value for the interrupt. The "Fosc/4" calculation should be correct, but the other one will in fact be 4 times faster.

If you are in doubt, you can open the FCDX in a text editor to check, or make a quick test to check the frequency using a simple project to toggle an output, or ask on this forum if your chip and interrupt setting is affected by this issue.

I hope this helps explain the issue better.

[canary_wharfe]

Thanks for the update Steve. You are correct that was the issue. The explanation has clarified the problem. However, what I don't understand (and I may be missing something so apologies in advance), is why the fix can only be applied to Flowcode 10 and not the current 9? It feels like Matrix is implying that this bug can only be fixed if we spend £500 and upgrade. Flowcode is not a low cost development tool and having been a supporter and purchaser of several versions I am starting to consider the fact that there are many issues and bugs left with older versions and users aren't benefitting from the fixes unless they continually shell out more money.

I'm sorry if this sounds blunt and if I have got the wrong end of the stick then please put me right but I for one would be totally happy not to see another version and instead see Matrix make an all out effort to get every single recorded discrepancy on the current version sorted and fixed. I suspect that would break the business model of getting revenue from new versions but as things stand it always seems like Flowcode is continually chasing its tale with new versions, more revenue, then chasing the new bugs. Meanwhile some of the older bugs in earlier versions get left behind.

As an example, a few weeks ago, I raised an issue concerning an interrupt and sent in sample code demonstrating the problem. Other than getting acknowledgment that there is a problem, users are not getting any confirmation that the issue is being fixed?

However, in a few months we are going to be given the opportunity to upgrade at a significant cost to a new version which will doubtless have a new set of bugs we have to contend with. Why can't we just get the current product as good as it possibly can be?

[Steve-Matrix]

It takes a significant effort when putting a new release of Flowcode together and so issuing an update for issues like the one you have identified is difficult to justify. We tend to release only when there is a significant collection of improvements available, or if there is a fix to a significant issue which has no workaround.

This does not affect fixes and improvements to certain parts of Flowcode such as the components or chip definitions as we have the facility to offer these piecemeal. But changes to Flowcode's main executable require a lot more care and consideration before being made public.

Hopefully the information and suggestions in my previous post provides enough insight into this specific problem that allows you to work around the particular issue you are facing.

Unfortunately, the staff at Matrix won't work for free and so there does need to be a way of generating income to pay them.