Clock will not start

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 5.
To post in this forum you must have a registered copy of Flowcode 5 or higher.

Moderator: Benj

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: Clock will not start

Post by medelec35 »

18F14K22 intosc 64MHz LCD not OK pre delay change.png
(72.05 KiB) Downloaded 2241 times
Hi Ben thanks for suggestion.
Unfortunately did not work for me.
If this helps here are some screen shots that may assist to finding a solution.
18F14K22 intosc 16MHz LCD OK.png
(78.33 KiB) Downloaded 2241 times


It looks like the delay change altered the width of enable signal

It look like the issue is caused by initialising routine. several lots of 3 should be sent, then some 2's. It is with internal osc set to 16MHz.
however at 64MHz 2 is no longer sent as bit0 stays high.

Martin
Martin

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Clock will not start

Post by echase »

Benj wrote:

Code: Select all

	#ifdef _BOOSTC
	  #define %a_DELAY   delay_10us(20)
	#endif
This should hopefully be enough to get the display working.

Let me know how you get on.
As I posted on Sunday I already tried that (unless there is some subtle difference between this code and that posted in viewtopic.php?f=29&t=10258&p=32636)and it does not work.

Martin's plots look like they show the problem.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Clock will not start

Post by Benj »

Hello,

I may have spotted the problem.

We are writing to the port register with the LCD component using set_bit and clear_bit functions.

Because the micro is running so fast the port variable is not updated quick enough which means that some of the output state changes may not make it through to the output as the read/modify/write process is resetting them back to the previous state.

In the code customisation edit the defines section and find the following section of code.

Code: Select all

	#define %a_PORT0    port%b
	#define %a_PORT1    port%c
	#define %a_PORT2    port%d
	#define %a_PORT3    port%e
	#define %a_PORT4    port%f
	#define %a_PORT5    port%g
Edit so that it looks like this.

Code: Select all

	#define %a_PORT0    lat%b
	#define %a_PORT1    lat%c
	#define %a_PORT2    lat%d
	#define %a_PORT3    lat%e
	#define %a_PORT4    lat%f
	#define %a_PORT5    lat%g
You should also be able to set the delays back to 100us.

I will investigate if we can make this change permanent or if there are implications for AVR, ARM, dsPIC etc.

Let me know how you get on.

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: Clock will not start

Post by medelec35 »

Hi Ben,
Fix works for me thank you.
here is waveform of working LCD What about devices that don't have latch command?
Martin

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Clock will not start

Post by Benj »

Great, thanks for testing it for me :)
What about devices that don't have latch command?
I'm hoping that devices that don't have the latch command will be running a lot slower and so this hopefully won't be a problem.

If it is then I think the only option is to start introducing delays after each of the set_bit and clear_bit functions on output pins. In fact it could be that we insert a tiny delay into these functions themselves to bottom the problem without modifying all the component code.

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: Clock will not start

Post by medelec35 »

Hi Ben,
No problem at all.
If I can help out I will.

You came up with a quick solution after my post showing you the screen shot of port logic levels over time.
Did that post help you?
Or did you already discover the cause and was working on a solution prior to my post?
Just need to know for posting future screen shots of waveforms or not?

Martin
Martin

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: Clock will not start

Post by medelec35 »

Hi Ben,
I have a very simple solution based on your fix.

If osc is set >=32MHz then defines are set as lat.
otherwise set as port:

Code: Select all

/component connections
#if MX_CLK_SPEED >= 32000000                        
	#define %a_PORT0    lat%b
   #define %a_PORT1    lat%c
   #define %a_PORT2    lat%d
   #define %a_PORT3    lat%e
   #define %a_PORT4    lat%f
   #define %a_PORT5    lat%g
	#else
	#define %a_PORT0    port%b
	#define %a_PORT1    port%c
	#define %a_PORT2    port%d
	#define %a_PORT3    port%e
	#define %a_PORT4    port%f
	#define %a_PORT5    port%g	
	#endif

	#define %a_TRIS0    tris%b
	#define %a_TRIS1    tris%c
	#define %a_TRIS2    tris%d
	#define %a_TRIS3    tris%e
	#define %a_TRIS4    tris%f
	#define %a_TRIS5    tris%g
	#define %a_BIT0    	%h
	#define %a_BIT1    	%i
	#define %a_BIT2    	%j
	#define %a_BIT3    	%k
	#define %a_RS      	%l
	#define %a_E       	%m
	#define %a_ROWCNT	%n
	#define %a_COLCNT	%o
My logic for this is If device has osc < 32MHz then may not have latch registers so set defines as port.

I have tried this in the components folder and it works after resetting custom macro back to default value.
The delay idea would probably be a better solution.

Martin
Attachments
FC5_PIC_LCDDisplay.c
(11.92 KiB) Downloaded 271 times
Martin

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Clock will not start

Post by echase »

Please don't slow it down too much. It is already too slow to me (when working)!

Do you have a view as to what the effect of an interrupt is on the new code? As reported elsewhere I have a TMR0 interrupt that might fire 100 times during one LCD clear or write routine. I previously found that this causes character corruption so had to pause the interrupts. Any chance that your revised code would fix this issue too? I would not need to care so much about the slow LCD speed if I could keep the interrupts going during all LCD operations.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Clock will not start

Post by Benj »

Hello,

Mine and Martins latest mods should not slow down the display at all from the standard non modded component. Instead the mods simply ensure that data destined for an output pin makes it even at high speeds when read -> modify -> write operations are taking place.

Regarding the interrupts problem what is your interrupt code currently doing? Is it doing anything with I/O or calling any large sections of code e.g. a component macro?

Also I had an idea about the problem but your screen shots confirmed this for me.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Clock will not start

Post by echase »

Excellent news, both your LCD fixes work at 64MHz. So hopefully this is the end of my clock problems.

On the interrupt, in my simple test routine, if I enable the interrupts with the usual macro it calls, the LCD works OK with no corruption, but the LED flash speed has slowed down by a factor of 5. This post http://www.matrixmultimedia.com/mmforum ... 46&t=10706 explains what the interrupt does. As it is quite a heavy interrupt with an A/D sample I wonder if it’s taking so long doing it that it’s slowing down LCD write so much that it slows down the whole loop and hence LED flash rate.

With the full code rather than test code the LCD also behaves well but can’t yet say what delays are happening whilst it writes.

My goal would be to write a single LCD command, like clear or print number, in less than one mains cycle (20ms), preferably less as ideally need to get the whole screen written with several variables all in 20ms. Next task is to time the LCD writes with ‘scope and see if the delays in your LCD component can be shortened.

Thanks

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Clock will not start

Post by Benj »

Hello,

I wonder.... The ADC channel you are sampling in your interrupt. Are you regularly sampling any other channels in your program. If you are then not sure I can help much but if your not then I might be able to help speed up the ADC routines for you by removing the setup, pre-charge and cleanup time.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Clock will not start

Post by echase »

Benj wrote:Hello,

I wonder.... The ADC channel you are sampling in your interrupt. Are you regularly sampling any other channels in your program. If you are then not sure I can help much but if your not then I might be able to help speed up the ADC routines for you by removing the setup, pre-charge and cleanup time.
Yes only measuring one channel, AN4 or AN 5 I think. Measuring a sine wave so there is little sample to sample change usually, thus charging up the sampling capacitor for a long time is not essential.

There is a vague plan to extend this to 2 channels but the second one’s sampling rate is much slower like >1 second. But I guess it might be hard to have 2 different A/D routines, one without setup, pre-charge and cleanup time and one with, unless I just insert the second one as a C block containing your standard A/D code. Does not matter if it then switches back to sampling the first channel and has the wrong capacitor voltage, as I can cope with one erroneous sample on channel 1, as I sum lots of readings and one somewhat wrong is swamped in the overall sum. But channel 2 has to be correct as only one sample taken per > 1 second and not summed.

For moment please ignore second channel.

One thing I have noticed about Microchip is that they are hyperfocused on low power so their PICs are arranged so everything gets turned off when not used. In my case I’d be quite happy to leave the A/D on all the time if it saves time. Not worried about saving the odd mA.

On the LCD code there is some quite complex pin mapping going on in your C code to map the PIC pins to the LCD data/EN/RS lines. I wondered if this can be done once rather than every time a LCD write occurs to save time? But maybe I misunderstand the way it works.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Clock will not start

Post by Benj »

Hello,

In v5 there are some new ADC component macros.

What about if you call the following at the start of your program to get the ADC setup and precharge out of the way.

ADC0 -> ADC_RAW_Configure_Channel

Then call one of the following functions inside the interrupt routine depending on what resolution you require.

ADC0 -> ADC_RAW_Sample_Channel_Byte
ADC0 -> ADC_RAW_Sample_Channel_Int

Then if you ever need to briefly sample another ADC channel then you would do the following.

ADC0 -> ADC_RAW_Disable_Channel
ADC1 -> Read_As_Byte
ADC0 -> ADC_RAW_Configure_Channel

Hopefully this should considerably speed up your interrupt service routine.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Clock will not start

Post by echase »

Benj wrote: ADC0 -> ADC_RAW_Configure_Channel

Then call one of the following functions inside the interrupt routine depending on what resolution you require.
ADC0 -> ADC_RAW_Sample_Channel_Int
With your raw sample option it cuts my nominal 3 sec test loop from 17 real sec to 4.5. Using the options in the A/D setup screen, cutting the charging time to zero makes no further improvement, presumably because using the raw configure command has already made this improvement.

The other option to change A/D clock speed from default OSC/8 to OSC/2 cuts it to 3.5 sec. So that is a tremendous improvement overall. But as calculated below OSC/2 seems too short.

This PIC’s datasheet says:

TAD A/D Clock Period 0.7us min 25.0us max if VREF >= 3.0V and -40°C to +85°C

I assume TAD A/D Clock Period means a full square wave cycle of a 1 and a 0 and not half a cycle. So I should set your OSC/xx to match no shorter than 0.7us as my OSC is 64MHz. So if I set it to OSC/64 it is 1us (Or is my OSC 16 MHz because the internal clock is always main clock/4 and thus I need to set it to OSC/16?).

There are other options for speed settings other than OCS/xx and I am not clear from the help file what they mean. When the help file says it gets less accurate if too fast do you mean it's less accurate near 0.7us, say at 1us, or only if it's shorter than 0.7us? Can't find a datasheet/application note on the relationship betwen speed and accuracy.

Only occasional LCD corruption noted but that might be due to a loose LCD connection I have failed to locate. I will try your suggestion from another post “Otherwise you could maybe disable interrupts just while the LCD data enable signal is active. I think this is only ever high for a couple of microseconds at a time.”

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Clock will not start

Post by Benj »

Hello,

Glad you have some speed improvement using the new functions. The pre-charge time delay is only part of the init function so this will not effect the sample function at all.

I find that when the datasheet is not being clear the best way is to experiment and find out for yourself what you can get away with.

One good way would be to use a potentiometer and a multimeter then play around with the timings and see how fast you can run the ADC before your readings start going a bit screwy or inaccurate.

Also at the moment the sample function starts the sample, waits for the sample to end and then collects the sample. You could take this further by starting the sample and then collecting the completed sample next time around the loop before triggering the next sample. This should allow you to use a slower conversion speed without adding extra delays into your program.

Let me know how you get on.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Clock will not start

Post by echase »

Benj wrote: I find that when the datasheet is not being clear the best way is to experiment and find out for yourself what you can get away with.
see how fast you can run the ADC before your readings start going a bit screwy or inaccurate.
Very wise. I tried this and got the following results for every one of the speed options in the A/D properties screen.

Option, Sample time, Accuracy, Same result got from another option
FRC, 6us, No reading, 1MHz
OSC/2, 6us, Poor, 2MHz
OSC/4, 9us, Good, 3MHz
OSC/8, 28us, Excellent, 4 and 8MHz
OSC/16, 5us, Poor, 5MHz
OSC/32, 6.5us, Good, 6MHz
OSC/64, 14us, Excellent, 7MHz
OSC/128, 28us, Excellent, 8 and 4MHz

(Sorry that was a nicely tab aligned table till posted)

Those times include the time to turn an output on and off to drive a 'scope but I am assuming that that only takes <<1us.

Several things are weird about these results:

1) The sample time for RAW_sample_integer increases as expected from OSC/2 to OSC/8 but then drops dramatically again at OSC/16 and rises again to OSC/128 with 32-128 being a near repeat of 2-8. Why the non linear response? Has some Flowcode value rolled over at OSC/16 because my 64MHz clock speed is high?

2) Despite 1), slowing the OSC clock generally increases sample time as expected. But for MHz the opposite is true as faster clocks give slower sample times.

3) From OSC/32 to OSC/128 there is doubling of time for each division of clock by 2, as expected. But for the MHz settings changing slightly from 6 to 8 MHz causes a 4 times increase in time.

4) FRC is a default time but just produces a zero reading. One would assume that a default would be a safe value that would always work.

From 2) and 3) I’d interpret that the selected “MHz” is not really the MHz speed of the A/D clock, especially as this one isn’t supposed to operate at speeds higher than 1.3MHz, so how is it apparently giving accurate results at 7 and 8 MHz? Is it really: A/D clock = 2 x OSC/2^n where n is the “MHz”?

It is clear that accuracy drops off at times less than 10us and it’s consistent despite the anomalies above. "Good" above means within 3 and "poor" within 50 of the correct reading (out of 1023). For me OSC/64 gives a fast and accurate option, which matches the theoretical maximum of 11 A/D clock cycles at 0.7us per cycle = 7.7us = 1.3MHz. OSC/64 =1MHz if OSC=64MHz so OSC seems to be the PIC clock value after PLL.

I might push it to OSC/4 which only degrades 1 off the result for DC signals. Are AC ones likely to be less accurate due to the time taken to adjust the sampling capacitor between samples? But, as it's a 50Hz signal, there is not normally much change between sampes at my 100us sampling rate.

At higher A/D speeds is it reasonable to assume that what is happening is that the last few bits of the 10 bit sample are not being processed, so the answer for the first few bits is accurate but it’s miscalculating up to 1, 2, 4, 8, etc. as the speed increases? In results so far it is always reads low if overclocked, never high. If true my error of 50 is because it’s dropping the last 7bits which at most is an error of 64. I want to be sure it is never going to drop any of the first few bits instead, as the answer would then be up to 512 in error, but have not yet experienced that.

I can cope with up to 4 in error, so read as byte is an option, but in practice it makes little difference as I believe that the full 10 bit sample is still done but the last 2 bits then discarded. So it does not save sampling time.
Last edited by echase on Thu Jun 07, 2012 10:23 am, edited 1 time in total.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Clock will not start

Post by Benj »

Hello,

From your observations it looks like the Flowcode ADC property settings are not lining up exactly with the settings in the control register.

I will have a look into this and see if there is anything we can do about it. Might have to be a new section in the FCD to detail how this ADC setting is populated.

You've probably already said but which device are you using and I will have an investigation.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Clock will not start

Post by echase »

Benj wrote:Hello,

You've probably already said but which device are you using and I will have an investigation.
18F14K22 but might also use the 18K13K22.

For my current purposes OSC/4 or 64 seem to work so I possibly don’t need a fix. But I have a niggling doubt that as there is an apparent bug here that it might affect the A/D in other ways that would adversely affect my programme or the conversion accuracy/speed.

Shutting down the processing during A/D conversion improves the accuracy. One suggested method is to put the processor to SLEEP, and use the FRC clock for the A/D conversion. Datasheet says “When the device frequency is greater than 1 MHz, the FRC clock source is only recommended if the conversion will be performed during Sleep.” This might explain the non working FRC setting above. Also the datasheet, unlike your Help file, does not call it a default setting so I think your use of the word “default” is a bit misleading.

“The FRC source has a typical TAD time of 1.7 us.” Bit slow for me so in fact I’d probably use the RC_RUN_IDLE mode instead of SLEEP as can still run the A/D at less than 0.7us if going down this route (unlikely). This all might be possible, but I guess I’d have to insert a SLEEP/IDLE command into the A/D FDC.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Clock will not start

Post by echase »

Benj wrote:

I will have a look into this and see if there is anything we can do about it. Might have to be a new section in the FCD to detail how this ADC setting is populated.

I know I said I didn’t have to have a fix but are you likely to release one?

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Clock will not start

Post by Benj »

I am trying to get something into the FCDs to fix this issue so the fix is coming.

However this is a fairly huge amount of work to get it right and there is a lot on here at the moment so the official fix will probably not be for a while.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Clock will not start

Post by echase »

Don't worry too much. I can wait for a couple of months as long as am sure now that all parts of the A/D function other than this speed setting function are working fine.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Clock will not start

Post by echase »

Benj wrote:I am trying to get something into the FCDs to fix this issue so the fix is coming.

However this is a fairly huge amount of work to get it right and there is a lot on here at the moment so the official fix will probably not be for a while.
Did you ever get this fixed? What release is it in? I am OK at the moment but next time I change the A/D or clock speed I will have to remember to experiment with the values to get one that works.

Post Reply