Any reason why these topics are not being answered?

[crispin12]

Sorry to start a new thread but sort of surprised that there is no follow up? Seems to me that others have problems in this area not just myself. Also wondering how this got past in house and beta testing?
Subject : Timer2 interrupt no longer working in 18F43K22
Subject : v7.1.1.0 export graphic BMP JPG of panel not working

[Benj]

Hi Crispin,

Sorry to start a new thread but sort of surprised that there is no follow up?

One of the posts has already had several replies, the other I have replied to now.

Thanks for letting us know of the problems.

Also wondering how this got past in house and beta testing?

We do extensive testing before each and every launch but unfortunately we cannot test absolutely everything. For example there are literally thousands of microcontroller targets if we fully tested each one before each release then we likely wouldn't ever get anything else done. We are a small team and so we do rely quite heavily on our VCs and users to report problems as they find them. We then do our best to fix these problems in a timely manner if possible.

[crispin12]

Hello Ben

With all due respect all I am seeing on the issue of the Timer interrupts thread are notes at the bottom of the last post from yourself and LeighM thanking the poster for the information. I'm not sure that gives us a lot of feedback in the sense that the issue is being handled, investigated, recognised, worked upon or whatever. There is no actual response giving feedback that the problem is being replicated at your end. That is what I am saying. When I initially raised the problem you were prompt to inform me that it was a question of understanding the way the new interrupt system worked until Martin made a contribution that actually made you consider "oh perhaps there is a bug in the system". You then create an example of a port driven LED timer2 interrupt and point out it is working for you. What I and another subsequent poster has done has shown that on further investigation there is a problem in the interrupt system regardless of your working port driven LED interrupt example. I don't see any direct response from you or the support team that acknowledges the problem is recognised and being investigated? In terms of customer support I think you would find that a simple response along the lines of...yes... we can replicate what you're seeing and will be looking into it asap or whatever is more than adequate and would keep most customers like myself content.

I appreciate you are a small team doing your best but I could equally make the point that even though a small company with limited resources, when you start charging big ticket numbers (the cost for a full blown Flowcode license is now around £700) and then pulling the we're a small company with limited resources angle doesn't sit well with myself and others who have the paid up for the product but cannot use features because those features are not working correctly?

You may be overlooking the fact that for me to act as your unpaid beta tester means that I have to switch between installing v 7.1.1.0 (which works) and uninstalling then installing the latest version to test your fix. ...and the reality is that your port driven LED interrupt example does not represent a fix. The downtime for me with one computer to hand is close to 2 hours just to switch between the two versions of Flowcode from 7.1.1.0 to 7.2.x and then back to 7.1.1.0. To have to go through all that just to alert you to what appears to be a major problem and then not to get any direct forum feedback that Matrix recognises the problem and what fixing it might entail does not seem very fair to me sitting here waiting to get a tool that I feel I can have confidence in the way the interrupt system is working.

[QMESAR]

Hi

I understand your frustration with all respect to MATRIX and specially Ben that does his best to solve issues between his day to day tasks
I have also encountered a number of problems however when the simulation leave me in dought, I always check the code generated on real HW, after all simulation is exactly what it says simulation and in my opinion can never be trusted 100%,

Did you have a go with this Timer interrupt on real HW ?

[crispin12]

In my experience if a simulation product does NOT run under simulation then it will not run on hardware. If a simulation product does run under simulation then it may or may not run on the hardware. Simulation is a first step on the design process cycle. If the simulation runs you move on to the hardware and check the simulator didn't lie. However if the simulation is not working I have found there is usually little point going to hardware as the program is usually broken. This of course assume the simulator itself is capable and proven to give a consistent emulation of hardware like most spice based applications and applications like Proteus VSM.

I do not received the chips yet from Microchip that will allow me build this circuit. The Flowcode simulation is part of a confidence chain that should indicate whether the firmware design is stable enough to go to the cost of building real hardware.

If we extrapolate the argument based on the unreliability of simulation being an excuse for a problem with the UI to a simulator engine then surely we are in danger of devaluing the simulator as a CAE design tool. If you want to go down that road then Matrix might as well scrap the simulation from Flowcode and we end up with a basic IDE editor compiler assembler product. The modus operandi ought to be focused on getting the simulator fit for purpose and make it as reliable as you can and then you have a reasonably useful tool that increases your probability of having a working design before moving to hardware. In the case in point regarding the latest version of Flowcode, the simulator engine doesn't even start up until user interaction takes place on the simulator panel. During the 21 years I worked in the N. Cal Silicon Valley, Arizona and Texas Instruments in Tx. that is something we called a broken product. Ignoring that issue and arguing that we should only design in hardware is self defeating I would have thought.

[QMESAR]

If we extrapolate the argument based on the unreliability of simulation being an excuse for a problem with the UI to a simulator engine t

This is not what I said or implied

I clearly said when in doughts and after working the same as you first step building the product in mixed mode simulation(SPICE 3F5 )CAD/ VSM and many times also apply MATLAB automatic code generation, I have learned that even product as MATLAB that cost US$60K per year in license fees has some bugs and the same with PROTEUS VSM, which I work with for many years has instances when the simulation does not yield the expected results and in those rare cases if in dought do a a check in HW ,and in your case with an timer interrupt you do only need a simple demo board to verify the issue not building your complete design and wave the simulation .Stop doing virtual design and do not trust simulation is not what I said Please read my post carefully.
Back to MATRIX they never refused or did not pay attention to issue reported .

[crispin12]

and in your case with an timer interrupt you do only need a simple demo board to verify the issue not building your complete design and wave the simulation .Stop doing virtual design and do not trust simulation is not what I said Please read my post carefully.

That's a bit rich isn't it. Perhaps you should have read my post more carefully specifically the part where I answered your query; have I done a hardware test? I stated the specific ICs PIC18f have not arrived from the manufacturer so I am unable to do the tests in the real hardware (with or without a demo board). So continuing stressing this point about the value of these tests is a moot point?

[QMESAR]

I am unable to do the tests in the real hardware (with or without a demo board). So continuing stressing this point about the value of these tests is a moot point?

Yea well good luck until MATRIX fixed the issue , you just have to wait then .
Topic closed for me