A/D component - V3 to v5 changes

[echase]

I opened an old v3 project in v5 and it has messed up the A/D performance. I think it is because it has defaulted to a sample time of 1 and speed of Fosc/2. What defaults are normally set and has it changed globally because I used Fosc/2 on another project? The former is OK as I am only using one channel, but the latter is way too fast. I need it as fast as possible but accurate. I could experiment till it works but would rather have a formula that works out Fosc/x. Is it x>= Fosc * TADmin? For my 16F690 it is 20,000,000 x 1.6 /1,000,000= 32? So Fosc/32 is OK.

I think it would be useful if your Help files said. “To select the parameter Fosc see the ADC CLOCK PERIOD table in the Microchip datasheet for your PIC”

What units are used for your 0-40 acquisition time? Is it usec as a 690 recommends 11.5 usec.

As reported here http://www.matrixmultimedia.com/mmforum ... f=5&t=8622 in v3 I was tweaking the 16F690 file to speed up the A/D, e.g. by changing the line:

adcon1 = 0x20; //Conversion Speed

Can I assume that in v5 the adjustment of the Fosc parameter does the same thing so I do not need to resort to adjusting the v5 16F690 file?

I like the fact you have added the ability to change the reference voltage because on another project I was having to change the file for this too.

[Benj]

Hello,

I think it would be useful if your Help files said. “To select the parameter Fosc see the ADC CLOCK PERIOD table in the Microchip datasheet for your PIC”

Good idea, we are already working hard on the documentation for v6 so I will pass on this comment.

Can I assume that in v5 the adjustment of the Fosc parameter does the same thing so I do not need to resort to adjusting the v5 16F690 file?

Yes this should control the same bits in the adcon1 register and you should have full control via the component properties.

[echase]

What units are used for your 0-40 acquisition time? Is it usec as a 690 recommends 11.5 usec?

[Benj]

Hello,

The units are in micro seconds and it's only able to deal with whole microseconds so you would have to use 12 to meet the criteria, though in practise you may get away with 11 as there are other instructions that need to be processed.

[echase]

Unfortunately adjusting the Fosc setting has not stopped my A/D returning erratic results some of the time. Could it have anything to do with the error message below and what should I do about it to reduce the stack usage? Don’t understand stacks.

The stack message disappears if I remove a block of LCD write commands that are executed every 1 second from main loop, even though I turn off the interrupts whilst these LCD commands are running as previously I found my TMR0 interrupt, which triggers the A/D, could cause corrupt LCD characters. Only use TMR0.

There are other LCD writes upon startup outside the main loop and they do not cause a stack error message.



Building CASM file
Serious Warning: Call stack usage exceeds:8!

Call Stack Usage Report
=======================
main and Task(s): hw used:5, exceeded by:0
interrupt: hw used:4, exceeded by:0

Memory Usage Report
===================
RAM available:256 bytes, used:218 bytes (85.2%), free:38 bytes (14.8%),
Heap size:38 bytes, Heap max single alloc:37 bytes
ROM available:4096 words, used:3487 words (85.2%), free:609 words (14.8%)

[Enamul]

Hi
If you call any component macro inside the interrupt it will cause stack corruption..Please avoid to use delay and LCD macro which uses delay in any interrupt.

[echase]

Hi
If you call any component macro inside the interrupt it will cause stack corruption..Please avoid to use delay and LCD macro which uses delay in any interrupt.

Did you mean a delay in an interrupt or delays that happened whist interrupts are in background? I do the latter but not the former.

I call the A/D component in the interrupt but no other component. The LCD is called during a normal loop and I stop the interrupt whilst the LCD commands are executed.

I have had a heavily amended version of the software (originally written in v3) running fine with v5 for months but the slightly amended or supposedly not amended versions won’t work. It’s not just A/D problems but the LEDs, which are not interrupt driven, also don’t respond properly.

This had all been working for 2 year. It’s either the change to v5 that has caused these problem or some minor tweak to the software I have made. I am going to go back though my saved files, find an old v3 version that has never seen v5 and see if that will work. Worst case scenario is that I have permanently corrupted all the old files by opening them with v5 and so do not have a working copy anywhere. Can a v5 file be opened with v3 because that might be one way to restore it to working again?

Is there any reason why v5 Pro would cause a different hex file than from the same fcf in v3 Pro, apart from the fact that the A/D function is slightly differently implemented? E.g. is the Boost C compiler the same for both?

Getting very anxious about all this as don’t seem to be getting anywhere despite having spent hours and hours on it.

[Enamul]

Did you mean a delay in an interrupt or delays that happened whist interrupts are in background? I do the latter but not the former.

I have talked about former one.

Can a v5 file be opened with v3 because that might be one way to restore it to working again?

No, but you can make your own code in V3 if you really feel that important to do in V3 and also if not too big.

Is there any reason why v5 Pro would cause a different hex file than from the same fcf in v3 Pro, apart from the fact that the A/D function is slightly differently implemented? E.g. is the Boost C compiler the same for both?

There are quite a lot of difference in v3 to v5 in different aspects and obviously Boostc is not same.

Getting very anxious about all this as don’t seem to be getting anywhere despite having spent hours and hours on it.

Please post anything if you feel you are getting problem not in whole code rather small part is not working properly in V5. we believe that can be sorted

[echase]

Can a v5 file be opened with v3 because that might be one way to restore it to working again?

No, but you can make your own code in V3 if you really feel that important to do in V3 and also if not too big. [/quote]

If I have simply opened the file in v5, compiled it to hex without making any change to the flowchart, can I open it now in v3 and get back to exactly the v3 version I had?

Getting very anxious about all this as don’t seem to be getting anywhere despite having spent hours and hours on it.

Please post anything if you feel you are getting problem not in whole code rather small part is not working properly in V5. we believe that can be sorted[/quote]

Difficult to post a part as no idea what the cause of this problem is. How does one post a part of the fcf? It would help is you could explain stack corruption to me and that may help me to pinpoint the general area of the problem. I am not completly sure though it only fails to work when the stack corruption message appears.

I fear that the only safe way out of this is go back to v3 for every change to this old project and only use v5 for new projects.

I know that my use of TMR0 to drive the A/D is a critical part of the code in terms of timing, so it’s possible v5 just can't cope with it, although the aforementioned v5 heavily modified version was using this interrupt running even faster and worked fine. But it means all the recent updates I have done need to be redone in a clean but 2 year old v3 file.

Previously I have found that the easiest way to do this is the use the MS Word merge and compare function to compare the C files of the old and new versions to see what I have updated and then revise the flowchart until the C files match, or at least match for all things apart from ones where v5 would have changed them because it’s v5. Is there an easier way?

[dazz]

If I have simply opened the file in v5, compiled it to hex without making any change to the flowchart, can I open it now in v3 and get back to exactly the v3 version I had?

Hi Echase
No as when you compile the flowchart it saves it as a V5 file. if you have the001 file which is a copy of the fcf and its showing the old date then rename it to fcf and it should work, what I do with V4 files is to rename it ie myflowchart4.fcf then make a copy in a different folder and rename the copy(remove the 4) , that way I have the V4 original, and if I open it in V5 from the other folder i still have the original(if thast makes sense

Regards
Dazz

[echase]

If I have simply opened the file in v5, compiled it to hex without making any change to the flowchart, can I open it now in v3 and get back to exactly the v3 version I had?

Hi Echase
No as when you compile the flowchart it saves it as a V5 file. if you have the001 file which is a copy of the fcf and its showing the old date then rename it to fcf and it should work, what I do with V4 files is to rename it ie myflowchart4.fcf then make a copy in a different folder and rename the copy(remove the 4) , that way I have the V4 original, and if I open it in V5 from the other folder i still have the original(if thast makes sense

Regards
Dazz

Always wondered what the 001 file was. So if I have opened and compiled the file once in v5 the 001 should be the old v3 file. But If I have opened it more than once the v3 file will have been overwritten. Is that right?

[dazz]

hi
not sure but if you look at the file date that will tell you if its backed up lately

Regards
Dazz

[JonnyW]

Hello.

If the file is upgraded from an older version, it should also save the file with a '.vXXX' extension, where XXX is the older copies file version. All subsequent saves will first update the .001 file before saving.

Cheers,

Jonny

[echase]

Found some files with v20 endings that probably date back to my v3. Never had v2 so why is v20 used and not v30?

[JonnyW]

Hi. In v5 and below each file has a 'schema number'. This tells Flowcode what version of file it is from. Each time the file format was amended the schema number was increased, to avoid compatibility issues.

File versions 32->42 are for v5, 21->31 are from v4. Below 21 is undocumented as to the Flowcode version, though its a safe bet v20 is from the last release of Flowcode v3.

Jonny

[echase]

Great, that means I do have a clean copy of the v3 file now, named with v20.

Just have to reinstall v3, make all the needed tweaks to components and use it for all updates to this project. Is it safe to cut and paste sections of the flowchart, where I have made updates, from v5 back to v3?

In long term much rather use v5 so can anyone explain the stack issue to me?

[kersing]

The stack issue CAN be caused by changes in one of the components. One possibility is a component using an additional level of the stack as the result of the introduction of the CAL layer. It can be caused by this, I'm not saying it is as it all depends on the components used and the code.

As I've got both V3 and V5 installed (and V4 as well) I could look into it if you PM the flowcode files.

[echase]

Is the stack problem dependent on the processor type? I wonder if the fact that my aforementioned heavily modified code does work properly in v5 and does not compile with a stack error message is because it’s using the more capable/modern but pin compatible 18F14K22 PIC, instead of the 16F690 for the basic code.

The datasheet for 690 says 8-Level Deep Hardware Stack and the 14K22 says 31-Level, Software Accessible Hardware Stack

Thus if the problem I am getting is purely due to stack usage is the answer that I can use v5 as long as I change the processor type?

The number of stack levels is not a parameter that Microchip headlines in their selection tables or summary details of a PIC, which is maybe because most people are not interested in it. It is a distinguishing feature between basic, mid and enhanced ranges if you look closely.

Having read up about stacks in Wikipedia I wonder if another solution is to remove some of the subroutines/macros and put them into the main loop? From my limited understanding of stacks it seems that calling subroutines fills up the stack levels. Although this solution would use up more memory, which is available, it uses less stacks. Am I right?

[echase]

kersing very kindly looked at my code and says :

“In Flowcode 3 the code generated for the interrupt is:
Code:
Generic Interrupt code, calls (level 1)
Increment_time, calls (level 2)
ADC1_SampleADC (level 3)

For Flowcode 5:
Code:
Generic Interrupt code, calls (level 1)
Increment_time, calls (level 2)
ADC1_ReadAsInt, calls (level 3)
CAL_Enable_ADC, calls (level 4)
delay_us (level 5)

As you can see the CAL layer added one level (CAL_Enable_ADC) of stack usage and the redesign of the component another (delay_us).”

So changing to v5 has added 2 stack layers to my code which is why it is now over the limit of 8. Anyone got any ideas on how to remove one or two of these layers? E.g. maybe:

1) Put some subroutines into main code as mentioned above

2) Modify the A/D component to remove a level or two. As I only use one channel of the A/D it can be simplified but not sure if that could involve stack call reduction. For instance I do not need to enable the A/D every interupt as it can be left permanently enabled.

[kersing]

Is the stack problem dependent on the processor type? I wonder if the fact that my aforementioned heavily modified code does work properly in v5 and does not compile with a stack error message is because it’s using the more capable/modern but pin compatible 18F14K22 PIC, instead of the 16F690 for the basic code.

The datasheet for 690 says 8-Level Deep Hardware Stack and the 14K22 says 31-Level, Software Accessible Hardware Stack

Thus if the problem I am getting is purely due to stack usage is the answer that I can use v5 as long as I change the processor type?

Yes, by switching to a processor with a larger stack that problem can be eliminated.

Having read up about stacks in Wikipedia I wonder if another solution is to remove some of the subroutines/macros and put them into the main loop? From my limited understanding of stacks it seems that calling subroutines fills up the stack levels. Although this solution would use up more memory, which is available, it uses less stacks. Am I right?

You are right.
Each macro (subroutine) call adds one level. So does an interrupt. Returning from the macro (subroutine) or interrupt decreases the level.
By reducing the number of layered macro (subroutine) calls the stack use decreases. Reducing the number of sequential macro calls does nothing.

Changing : Main calls Macro 1, Macro 1 calls LCD component
To: Main calls LCD component
Result: Reduces stack usage with 1 level.

Changing: Main calls Macro 1, Main calls LCD component
To: Main (includes Macro 1 code) calls LCD component
Result: No change in stack usage

[echase]

Each macro (subroutine) call adds one level. So does an interrupt. Returning from the macro (subroutine) or interrupt decreases the level.
By reducing the number of layered macro (subroutine) calls the stack use decreases. Reducing the number of sequential macro calls does nothing.

Changing : Main calls Macro 1, Macro 1 calls LCD component
To: Main calls LCD component
Result: Reduces stack usage with 1 level.

Changing: Main calls Macro 1, Main calls LCD component
To: Main (includes Macro 1 code) calls LCD component
Result: No change in stack usage

Just moving the regularily called LCD routine into the main loop solves the stack error problem. Whether it totally cures the real life performance problem caused by v5 remains to be seen but initial tests look OK. Very happy if this is all it takes to restore v5 to be able to be used for this code.

Was there a warning in v5 documentation that it might increase the stack levels? Had there been one, or had I read it, a huge amount of man-hours would have been saved by me over the last 6 months as this does seem to be the reason I have been having enormous trouble. Can you add such a warning or make it more prominent?

One reason it has appeared to be working some of the time may be that I use a PCB jumper to switch out some of the code in some applications. Is it the case that if the jumper causes the code that triggers the stack overflow to be skipped then it won’t overflow, despite the compiler error message? The compiler does not know that that bit of code will be skipped. Obviously the full code is sitting in the PIC programme memory to be used when jumper removed.

In the following error message is it saying that 5 stack levels are used for main and tasks (whatever tasks are) and 4 for interrupt? And stack usage is exceeded as 5+4>8? Thus I only need to remove one stack call to get it down to 8.

Building CASM file
Serious Warning: Call stack usage exceeds:8!

Call Stack Usage Report
=======================
main and Task(s): hw used:5, exceeded by:0
interrupt: hw used:4, exceeded by:0

[echase]

Have now reloaded v3. When I compare the C Code of it done in v3 and v5 there are hundreds of differences altough mostly a few types of changes repeated a lot. Most quite trivial but one of two of them must be stopping the code working properly on real hardware. And/or the different complier is doing it. It’s too difficult for me with my limited knowledge of C to understand where the problem is but I’d suspect the A/D routine or LCD component as the 2 are quite different in v5.

Is there anywhere a published list of likely suspects to look for when upgrading?

I looked at going back to using v3 only for this project but support has been withdrawn for v3 which could be a big problem because it did not compile when I tried it in v3.