A/D returns strange results

[echase]

What happens if a PIC is in the middle of an A/D read and an interrupt such as TMR0 or PORT B change is triggered? Does it wait till end of A/D read before actioning the interrupt? Or is the A/D conversion paused and then restarted once the interrupt finishes, with no glitch in the A/D result?

I ask because I am sometimes getting strange/inaccurate integer values returned, like negative values (which should be impossible), by Read_as_int from some (but not all) of the A/Ds. Simulation is OK.

More likely though in my case is a hardware problem.

[Benj]

Hello

Yes you are right negative values should not be being received.

It does sound like an interrupt problem though it could be display related rather then ADC related. Are you writing to the display in your main program and your interrupt routine? If so then this could be causing the errors. Try only writing to the display outside of the interrupt routine.

[echase]

I don't call an LCD write from within an interrupt.

You previously gave me a mod to the LCD file to turn off the interrupt. Think it was

{
/*Macro_Γ‰crit_ChaΓ®ne_Start*/
/*Macro_ImprimirCadena_Start*/

clear_bit(intcon, GIE);
.....
function code
.....
set_bit(intcon, GIE);

/*Macro_Γ‰crit_ChaΓ®ne_End*/
/*Macro_ImprimirCadena_End*/
}
But I found I did not need to use it once I had slimmed down my TMR0 interrupt.

Can I use something similar in the 2520 PIC file to turn off TMR0 (and possibly PORTB change) interrupts whilst an A/D conversion is happening? Needs to be a very short turn off or else it could affect my clock timings a lot.

[Benj]

Hello

Yes you can use the GIE bit to temporarily disable the interrupts and see if this helps with your strange results.

In the device FCD file is a line of code called starting "ADCCapture"

Find this line and then scroll along until you see this. Note the piece of code may assign 0x02 to adcon0 instead of 0x04.

"adcon0 = adcon0 | 0x04;\nwhile (adcon0 & 0x04);\n"

place the following before and after the chunk of code shown above and interrupts will then be disabled for a short period while the conversion is taking place.

clear_bit(intcon, GIE);\n ****** chunk of code ******* set_bit(intcon, GIE);\n

so you should end up with something like this.

"clear_bit(intcon, GIE);\nadcon0 = adcon0 | 0x04;\nwhile (adcon0 & 0x04);\nset_bit(intcon, GIE);\n"

or

"clear_bit(intcon, GIE);\nadcon0 = adcon0 | 0x02;\nwhile (adcon0 & 0x02);\nset_bit(intcon, GIE);\n"

Let me know if this solves the problem you are having. If not then you can simply cut the pieces of code back out or overwrite the FCD file with a saved copy to resume normal operation.

[echase]

Do you think that upgrading to the latest Flowcode 3.6 might help as I use 3.4? Better the devil you know has been my philosophy. Far as I can tell from the History file they is nothing new that should affect me.

But what about:-

Minor fixes to LCD, EEPROM,

or
KNOWN ISSUES
* Flowcode.exe
- multiple enables of the same interrupt can have different macros (ok in simulation; in PIC, only the first macro is used)

I only enable the TMR0 and PORT B change interrupts once upon booting so does this known issue affect me?

[Benj]

Hello

I think the LCD fixes resolve a startup issue and a problem with referencing larger 4x16 or 4x20 character displays.

The EEPROM fix was minor and just adding compatibility for newer devices.

The Interrupt issue shouldn't effect you. It only comes into effect when you enable an interrupt, disable it and then re-enable it somewhere else but specifying a different service macro. In practise the first service macro specified is the one that is always called.

[echase]

Not great news. Adding the clear_bit(intcon, GIE) etc. lines to the LCD component has no adverse effect; not been able to check if it improves things because of next issue.

But adding these lines to the PIC fcd seriously messes things up. Firstly the LCD is now blank so can’t do anything, although the relays are clicking so the programme may running normally behind the blank display. No extra compiling errors are shown. Simulation is OK.

Very worryingly though reverting to any original fcd without this mod does not recover the LCD again. So I now have several versions of the software that are unusable as every one I have tried with the modified fcf can not be reverted to where it was. Tried closing and opening Flowcode and rebooted the PC but makes no difference.

Looks as if the change to the fcd has permanently changed something else like the FCF file, but not everything, as any fcf that I have not yet compiled with a modified fcd still shows the LCD OK.

How can I recover all these failed fcfs as they represent my most recent changes? Although I can recover most of my recent changes by merging several older working fcfs.

Why would this change affect an fcf?

Also can’t understand why it caused a blank LCD as the boot order is

Initialise LCD
Display some stuff
Later read the A/D and start the interrupts

So why would a line that inhibits interrupts when A/D read affect code that comes in advance of it?

Did I get the fcf syntax correct? I found that it did not seem to matter if I wrote \n adcon0 or \nadcon0. My new lines in fcf are

\n//begin conversion and wait until it has finished\n clear_bit(intcon,GIE);\nadcon0 = adcon0 | 0x02;\nwhile (adcon0 & 0x02);\n set_bit(intcon,GIE);\n \n//restore old tris value, and reset adc registers\n

[Benj]

Hello

Ok it sounds like there may be somthing in your program stopping the LCD from working. Maybe that the component connections for the LCD have somehow changed. Clock speed is another important factor when driving the LCD. Also If you have modifed your LCD component code file then this could be causing the problems. Do you have a backup of the component file you can try?

Your FCD mods to the analogue sample routine look correct and should work correctly.

Restarting Flowcode after a FCD or component code mod is always recommended. Maybe this is the cause of the problem.

If you cant get this working then please send me your FCF and C code file for your project and I will compare the C file with the file that my Flowcode generates.

[echase]

Ok it sounds like there may be something in your program stopping the LCD from working. Maybe that the component connections for the LCD have somehow changed. Clock speed is another important factor when driving the LCD.

Not changed the connections or the clock speed.

Also If you have modified your LCD component code file then this could be causing the problems. Do you have a backup of the component file you can try?

Can’t exactly remember now but I think the problem occurs whether the original LCD file or the one with the above GIE lines added are used. I tried an old backup and it’s AOK.

Restarting Flowcode after a FCD or component code mod is always recommended. Maybe this is the cause of the problem.

I always do that.

If you cant get this working then please send me your FCF and C code file for your project and I will compare the C file with the file that my Flowcode generates.

Many thanks. Sent.

[Benj]

Hello

Ok I have found something that may be causing the problems here in your code.

At the start and end of your LCD functions is the following code.

trisb = trisb & 0x0F; //Sets the high nibble to an output
trisb = trisb | 0xF0; //Sets the high nibble to an input

What this is doing is allowing the LCD E line to potentially go high when the LCD is not in use. This may corrupt the display or stop it from working alltogether depending on the external signals coming in on the E and RS lines. If you need some of the I/O on port B then I suggest you use the low nibble as this should not effect the LCD operation.

Another thing regarding your email. The "FCV_TOTAL_KWHR_LAST_WEEK" variable is of type BYTE which means it can only hold 255 as a maximum. Try changing this to an INT variable and you should now be able to do the larger calculation without any problems.

[echase]

The 4 switches are on RB4-7. That is the upper nibble I assume. It isn’t possible to change this now as PCB made. The switches are connected via resistors so if the PIC senses data whilst a switch is pressed the PIC can drive enough current so that the switch is not seen as closed by the LCD.

The E and R/S lines are not shared with anything else so don’t think there can be spurious signals on these. Even if there is corrupt the LCD is cleared every 5 secs so any corruption should get cleared.

It does look as if the A/D conversion may be correct although difficult to say; it’s maybe only not always correctly displayed on the LCD.

I tried adding the GIE line to other parts of the LCD file such as the Print number and Clear LCD parts. Is this allowed as it’s the print number routine that is most often corrupt on LCD?

Made it worse and had the same disturbing behaviour as above; when reverting to the original LCD component it does not revert it to normal behaviour despite restarting Flowcode after every LCD edit. But when an older fcf was tried it does revert. Any idea why these things are not reverting?

Does this GIE mod stop all interupts including PORT B change?

[Benj]

Hello

Ok if you are using resistors on the switch inputs then you should be alright.

Yes the GIE flag is the Global Interrupt control. Clearing this bit disables all interrupts.

[echase]

I made a slight change to the code for test purposes. Instead of

Read all A/Ds
Display first converted reading, wait 5 secs
Display second converted reading, wait 5 secs
……
Display sixth converted reading, wait 5 secs
Repeat from read A/D

It is now

Read all A/Ds
Display first converted reading, wait 5 secs
Display fourth reading, wait 5 secs
Display fourth reading, wait 5 secs
Display fourth reading, wait 5 secs
Display fourth reading, wait 5 secs
Display sixth converted reading, wait 5 secs
Repeat from read all A/Ds

As the fourth reading tends to be the most inaccurately reported.

The real display is now

21Celcius (which is correct and nearly always is)
2030
2029
1876
2030
5volts (which is correct and often is)

This exactly repeats every time, i.e. the third result is always 2029

All this is with a LCD file that had had the GIE mod on the print sting and print number sections, but I am reasonably sure it would still give the same result without these mods.

There are several odd things about this

1) The max value for the fourth reading should be 1023 as it is a read of a 10bit A/D
2) The actual value should be about 900 based on the steady voltage I am feeding it
3) All the values should be the same as the code is not changing the variable between A/D reads

It seems unlikely that the variable itself is taking on these unusual values so the error is presumably in the way the LCD code is interpreting the variable. Is it significant that the variable is an integer and not a byte as there is some evidence that the errors are greatest when it has to display integers?

You said the LCD is sensitive to clock speed. I have tried 125, 250 and 500 kHz, although not with the exact above test code, and it makes no difference to LCD corruption.

[echase]

I need to understand how Flowcode compiles.

Option 1

The FCF flowchart and the component and PIC files are all read on compiling and the compiled C, ASM, HEX files result. The original FCF flowchart and the component and PIC files are not altered by this.

Option 2

The FCF flowchart file incorporates some of the code from the component and PIC files when saved or compiled. Thus original FCF flowchart is altered if a component or PIC file changes.

Which is it? Option 2 would explain why I can’t revert my FCF files back to original after making a change to a component or PIC file, as some remnants of the change may be left after the reversion. The LCD component seems a bit different in style from the other components so maybe it is used in a different way to the others.

[echase]

trisb = trisb & 0x0F; //Sets the high nibble to an output
trisb = trisb | 0xF0; //Sets the high nibble to an input

Did I add those lines or are they standard in your LCD component? I seem to remember we did once discuss adding something like that to ensure that the port reliably switched back to an input so my switches on same port could be read. But I think the standard non modified file also has these lines.

Would adding a short delay after each

trisb = trisb & 0x0F; //Sets the high nibble to an output

enable the LCD or PIC to stabalise before sending the data to the LCD, in case my error is due to the LCD or PIC not quite being ready to do the transaction of data?

This post does not supeceed the above 2-3 ones so grateful of a response to all, thanks.

[Benj]

Hello

The normal LCD driver files do not have these lines of code. I seem to remember that they were put in to allow for better action with your switches.

Try adding the following line of code to the start of the functions. This will ensure that the E line does not get pulsed until the driver is ready.

Code: Select all

portb = portb & 0xF0;  //Clears the high nibble of the port ensuring the E is not high when the outputs are enabled
trisb = trisb & 0x0F;     //Sets the high nibble to an output

You could also try adding a small delay after these lines of code if you wish.

Eg.

Code: Select all

delay_10us(1);    //Waits for 10us

[Benj]

FCD and Component files are read into Flowcode when starting the software.

Flowcode updates the component macro code when it compiles but will not update the macro definitions or initialisation code etc if these are changed.

FCD files are also read in when changing target. However for the most reliable option it is best to restart after a FCD file modification.

[echase]

Flowcode updates the component macro code when it compiles but will not update the macro definitions or initialisation code etc if these are changed.

Don’t quite understand this. Does not seem to be my option 2 so does not explain why I having trouble reverting FCDs.

If I:-
Take FCF no. 1.
Change the component or target file
Save FCF as no. 2
Compile
Find the software got worse
So change the component or target files back to original
Restart Flowcode with no 2 FCF
Save and compile again

I should be back to where I was at beginning with no. 1 and 2 FCF exactly the same, but this is not what I find based on the way no. 1 and no. 2 now run on the hardware. I have not however actually done a line by line check of the 2 C files.

What is the easiest way to do such a check? I have been posting them into Word and doing a Merge and Compare.

[echase]

Things much better now. Sprinkling

clear_bit(intcon, GIE);
set_bit(intcon, GIE);

around my code and in the LCD file has solved most or maybe all of the LCD corruption. Clearly the LCD does not like interrupts disturbing its routines although it's never been a problem on my 16F886 version, which used essentially the same routines.

Also added it to my A/D read macro so that it is not disturbed by interrupts either, that seems to have improved the A/D read accuracy/consistency, again not a problem found on 886.