 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Playing with CLOCKTRIM
| Author | Message | ||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
I have been doing some investigation into the accuracy of the internal oscilator in the MX170 chip. Microchip data sheets mention the drift figures but don't bother supplying any charts to help visualise the stability. My test equipment consists of an old 12V car cooler/warmer. It can cover the temperature range of zero to 48 degrees C. There is a micromite in the cooler with a DS18B20 recording the temperature. I set a PWM of 10kHz and vary the temperature for various CLOCKTRIM settings. There is a maximite outside the cooler and it measures the frequency of the PWM. I also have a standard frequency meter in line and so far the maximite and frequency meter have agreed. It takes about 2 -3 hours to do a full temperature run for each CLOCKTRIM setting. The frequency of the oscillator depends on the internal temperature of the MX170 so it will depend on ambient temperature as well as the internal heating due to workload. I tried with a PWM frequency of 100kHz and the frequency was lower than the expected 10 times the 10kHz freq. for that ambient temperature. Higher internal temperature gives slower speed. When I have finished this set of readings, I will try with different CPU speed settings. I expect a CPU speed of 5Mhz will result in higher PWM frequency. This chart is the results this morning. 
All the readings are well within the quoted accuracy but if you want an accurate clock, you will need to use and external RTC. I would also like to set up a system for covering a wider range of temperatures but that will have to go in the shed. Jim VK7JH MMedit  MMBasic Help |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
I have finished playing around with CLOCKTRIM. 2014-11-02_012501_Frequency_stability_of_the_MX170.pdf 
The first chart shows the stability of a PWM output set at a nominal 10kHz over the range of zero to 48 °C The test was run for a number of OPTION CLOCKTRIM settings Below about 20 °C the frequency was very stable. Above 30 °C, the frequency changes considerably with temperature. 
At the higher CLOCKTRIM settings, the CPU speed does have a slight effect. A change to the CLOCKTRIM setting of one results in a change in frequency of 4Hz Conclusion. For ambient temperatures from zero to +20 °C, a CLOCKTRIM setting of -3 or -4 will improve accuracy considerably. At higher temperatures, the change due to temperature variations would make finding a suitable CLOCKTRIM setting difficult. Over the full range tested, the frequency change was sill less than 0.3% for any CLOCKTRIM setting. The frequency stability is more than adequate for most uses but a true RTC is needed for accurate time control. Jim VK7JH MMedit  MMBasic Help |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
Jim: have you tried doing some trials in conjunction with a DC18B20? having an tick routine fired off every second that samples the temperature and adjusts the clock trim value accordingly (in fact you'd want to start each reading at the end of the routine and read the result at the start of the next call). geoff: this would be a good application for using the on-die temperature sensor. indeed, the whole mechanism for correction could be built into MMbasic itself, though calibration would then be an issue. cheers, rob :-) |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
As far as I know, CLOCKTRIM values are saved in non volatile flash memory. If you were to save too often, the flash memory will eventually fail. If you were to chase too much precision, you would also need a finer trim value. I think that a trim change of one for a temperature change of 5 to 10 degrees should be doable without wearing out the flash. We probably use a CFUNCTION to get the die temperature and keep the precision within 0.1% Jim VK7JH MMedit  MMBasic Help |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
a valid point - one would need a mechanism for changing the clocktrim value directly, perhaps making direct access to the register available through something like MM.CLOCKTRIM. this may, of course, already be available using PEEK and POKE. in general, the granularity is not such a big issue if the value can be changed frequently. an example: many many years ago i needed to implement an exact 1mS timer tick interrupt under MSDOS, as part of some scientific experiments at uni. to do this on a PC requires setting a non-integer hardware clock divisor that is between 1192 and 1193 - clearly not possible. my solution was to use a variation of Bresenham's Line Algorithm to select between the two possible divisor values, such that the average clock tick rate came out at exactly 1mS. on every interrupt the algorithm selected the required divisior (1192 or 1193), which i then loaded into the PC's CTC. for those who remember, the default divisor on a PC was 65536, which gave a timer tick interrupt approximately 18.2 times per second. in the case of the micromite, going to this extreme would be a tad overboard given that we are dealing with just van RC oscillator. simply selecting from set of table values would almost certainly suffice. and then, only in the case of certain applications that would benefit from the improved timekeeping. cheers, rob :-) |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
This was something that I debated with myself when I implemented OPTION CLOCKTRIM. It could easily be changed to not store the trim value in flash but this would require the command to be in every program. I figured that most people would just want to trim the frequency once and therefore storing the new value in flash was appropriate. But if you need to continuously adjust the trim to match temperature you do not want this. I suppose that it depends on how many people would want to go to the trouble that TassyJim has gone to. Does anyone have an opinion on this one... save in flash or not? Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
simplest answer: will the required value be different for each individual MX170 processor? if yes, then it would probably be best stored in the lines of basic code. addendum: looking at the above graphs again, my opinion is swayed towards it always being set in program code so as to maintain visibility. also, it is something that is best set dynamically, depending on ambient/die temperature. rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Not really. If it is different for each processor you would want to store it in flash. That way you would only trim the clock once for each chip and then any program would run accurately without being concerned about CLOCKTRIM. That was my thinking when I originally implemented CLOCKTRIM. But, I think that it would only be a few programs that would require the clock to be trimmed and requiring them to place the command at the start of the program would not be a great impost. And they could always save the trim value using SAVE VAR If you want to correct for temperature then you do not want to store the value in flash because of the danger that Jim mentioned. I am leaning towards not saving the trim value in flash. Now call we need is a CFunction to get the chip's temperature... Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
given that the code behind the call is (i presume) so close to that of x = pin(0), would it not be of minimal cost to implement it within the interpreter using die_temp = pin(-1)? i'd actually suggest making both reading die temperature and reading the bandgap reference use negative pin numbers, so they both stand out clearly as 'special cases' within one's basic code. rob :-) |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
I would prefer it to NOT save in flash. That way users can go as silly as they like trying to keep the frequency stable. It would then be easier to recover if you went too far with the settings and lost communications. I was going to try to do some tests at a greater range of temperatures but the BOSS wouldn't let me take over the kitchen. If the CLOCKTRIM was easily adjusted without the worry of flash failure, I could sneak into the kitchen and do some quick tests. Instead of setting the trim and changing temperature over time as I did for the current tests, I could set the temperature and quickly run through the trim values for that temperature. I would still have to be very nice to the BOSS.... Jim VK7JH MMedit  MMBasic Help |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
Having access to the die-temperature would be very useful for monitoring when the device is squeezed into a sealed box sitting in the middle of nowhere. Looking out my window, I can see the snow on the hills so not a problem today but it does get hot here (sometimes). I usually put a temperature sensor of some variety in the box but internal would be better (and fewer parts). Jim VK7JH MMedit  MMBasic Help |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
OK, I will look at it. But the on chip sensor is not very accurate, it is just a forward biased diode. Geoff Geoff Graham - http://geoffg.net |
||||
| hitsware Guru Joined: 23/11/2012 Location: United StatesPosts: 535 |
> it is just a forward biased diode. That can be quite accurate . |
||||
 Print this page |
