Author Topic: Motion control, S-curves and other stuff >> controlling lift with DC motor  (Read 8752 times)

0 Members and 1 Guest are viewing this topic.

Offline jbb

  • Super Contributor
  • ***
  • Posts: 1265
  • Country: nz
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #25 on: October 10, 2019, 12:42:34 am »

... Delta pos method is better for low speeds, delta time for high speeds so basing on setpoint I use "crossover" speed to decide which measurement should be forwarded to speed variable ;) At the moment it works like a switching point but maybe I should use some kind of proportional change in wider range? I don't know ;)
...
I wonder if that planned current loop will help with such things. Current loop will be fast, much faster than speed loop, and current measurements are available each cycle so no need to wait for speed pulse to react. As fas as I understand that, between speed loops there will be a constant current setpoint and current loop will try to handle it. Constant current means constant torque... How it will react to changing friction or other disturbance? With constant torque additional friction will probably slow down the lift and it will have to wait for speed loop that will ask for more current/torque to keep speed setpoint...

Switching between sense modes does seeming something that makes a ‘bump.’ Maybe you can experiment? A ‘mixed’ region might be an option to improve matters if necessary. IE you could smoothly transition from delta pos mode to a mix of delta pod and delta time to full delta time.

A current / torque control loop would indeed keep the same current setting between updates of the speed controller. (Look up Zero Order Hold if you’re interested.) Any changes in the plant mechanics (eg friction or changing load) will cause a change in speed that the speed control loop needs to deal with.
 

Offline Kasper

  • Frequent Contributor
  • **
  • Posts: 793
  • Country: ca
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #26 on: October 10, 2019, 03:39:36 am »
Looks like you are well beyond my understanding of this subject but I'll share something simple that worked for me.

I had to make a test set move air like human lungs. Was given a couple 2L syringes and a linear actuator with controller with speed input and position output

I used speed = sine(position) and added extra variables for tuning. 

That worked well enough but when I later saw a professional version I was jealous of its simplicity.
It used disc and rod (like a train). They just needed steady motor speed and the disc smoothly changed the speed and direction of the rod.  It also had easy and accurate way to set travel distance: connect the rod to holes at different radius on the disc.
 

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #27 on: October 10, 2019, 04:59:18 am »
Switching between sense modes does seeming something that makes a ‘bump.’ Maybe you can experiment? A ‘mixed’ region might be an option to improve matters if necessary. IE you could smoothly transition from delta pos mode to a mix of delta pod and delta time to full delta time.

A current / torque control loop would indeed keep the same current setting between updates of the speed controller. (Look up Zero Order Hold if you’re interested.) Any changes in the plant mechanics (eg friction or changing load) will cause a change in speed that the speed control loop needs to deal with.
If I recall correctly it was way below that crossover speed but thank you for your suggestion, I will check that twice to be sure. I think it is caused by non-constant update rate in delta pos method and for very low speeds update period is probably longer than control loop period so it becomes a little bit nervous that no reaction can be observed for previous demand ;-) I will try to check it somehow.

And thanks for one more keyword. I will check what it stands for ;-)
 

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #28 on: October 10, 2019, 05:01:17 am »
Looks like you are well beyond my understanding of this subject but I'll share something simple that worked for me.

I had to make a test set move air like human lungs. Was given a couple 2L syringes and a linear actuator with controller with speed input and position output

I used speed = sine(position) and added extra variables for tuning. 

That worked well enough but when I later saw a professional version I was jealous of its simplicity.
It used disc and rod (like a train). They just needed steady motor speed and the disc smoothly changed the speed and direction of the rod.  It also had easy and accurate way to set travel distance: connect the rod to holes at different radius on the disc.
Thanks for example. I also prefer situations where physics does the hard job, not calculations ;-)
 

Offline IconicPCB

  • Super Contributor
  • ***
  • Posts: 1564
  • Country: au
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #29 on: October 10, 2019, 10:16:53 am »
For the adventurous spirits forget PID nonsense... go straight to take back a half algorithm for those dificult to control processes.
 

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #30 on: October 10, 2019, 10:52:11 am »
For the adventurous spirits forget PID nonsense... go straight to take back a half algorithm for those dificult to control processes.
What do you mean exactly? Any suggestions?
 

Offline IconicPCB

  • Super Contributor
  • ***
  • Posts: 1564
  • Country: au
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #31 on: October 10, 2019, 11:23:31 am »
Enjoy
 

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #32 on: October 10, 2019, 03:52:04 pm »
Are you one of the authors? ;)
 

Offline IconicPCB

  • Super Contributor
  • ***
  • Posts: 1564
  • Country: au
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #33 on: October 10, 2019, 07:14:34 pm »
No.

I have however been interested in applying this algorithm for a while.

So far I have had good success with PID with Feed forward in conjunction with incremental set point in a situation where conventional PID did not perform terribly well.

The point to recognise is the micro provides a lot of flexibility so that the control strategy is no longer limited to prior art.
 
The following users thanked this post: Siwastaja

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #34 on: October 11, 2019, 11:19:08 am »
How exacly is feed-forward implemented in such situations? Is it some kind of OUTPUT = FF_VAL_CALCULATED_FROM_WHATEVER + PID_OUTPUT? And PID checks SP versus PV with such side-channel under hood, so PID only reduces error in FF_VAL_CALCULATED_FROM_WHATEVER estimation of output, and not full range of OUTPUT?
 

Offline IconicPCB

  • Super Contributor
  • ***
  • Posts: 1564
  • Country: au
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #35 on: October 11, 2019, 06:58:05 pm »
With PID a control loop is implemented such that an error value is processed by the PID algorithm and the output of the algorithm then controls the process.

Feed forward is a very simple scaling of set point not error value followed by summation with PID algorithm output.

The scaling is selected by observation of process response with PID set to minimum value.

Set feed forward level to achieve best possible open loop performance and then close the loop via PID.
Adjust FF then  P, D and then I, if needed, in that order.
 

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #36 on: October 14, 2019, 07:10:37 pm »
Ok, thank you very much. I was close in my presumptions, I think, but you have made that even clearer :-)
 

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #37 on: October 16, 2019, 05:34:56 pm »
Ok, when I started thinking about implementation of S-curves linked earlier I have calculated shape of velocity and acceleration and... yeah, right.. it will be nice and smooth move from point A to point B but there is no constant velocity region which is most important for me :(
So I need different equation for calculating that. I am not good in profiles generation and I am not sure how to do it exactly. The best solution would be the 7-region approach with linear ramps on acceleration. There are also cubic ramps but it will be too complicated, I think.
It would be nice to specify max acceleration, max speed, start and landing points, total time of transition and maybe read/calculate from which time point velocity is linear and when it is not linear again at braking...
I have found this article
https://www.researchgate.net/publication/278969938_A_complete_S-shape_feed_rate_scheduling_approach_for_NURBS_interpolator
and there is a section about S-shape profile generation. There are even equations for each region so it could be quite easily adapted, I think, but I will have to think how it should be implemented, for example by providing desired speed in constant region or total time? There should also be some verification point to decide if desired profile can be achieved on physical object etc.
Any ideas? ;)
« Last Edit: October 16, 2019, 05:38:08 pm by krisRaba »
 

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #38 on: October 23, 2019, 07:29:17 am »
I have made a "proof of concept" with linear ramps on current changes and it shows that physics works ;)  :-/O
With linear current (= acceleration) there are S-shapes visible on velocity plots.

But I have some problems with current sensing, I think, or maybe it always is like that and only my lack of experience screams that current plot should be "cleaner". At the moment there is a lot of noise but it can be caused by long (but twisted ;) ) wires between ACS current sensor and MCU. Maybe it catches everything from air like antenna ;)
Maybe someone can confirm my setup:
1. bipolar ACS current sensor is in serie with motor windings
2. it has selectable bandwidth - 20kHz or 80kHz - I use 20kHz
3. long twisted wires from ACS to MCU - to be fixed in next PCB release
4. optional RC filter near MCU - currently bypassed because it introduces additional delay in feedback loop but maybe just ADC trigger should be delayed accordingly - simple 100R/100nF increases feedback delay from 2.4us to 8us, just to operate on real numbers
5. ADC is triggered synchronously with generated PWM - in the middle of "ON" state delayed by 2.4us to compensate propagation delay on feedback signal (mainly caused by ACS) - sampling rate is thus 21kHz so I should increase it above 40kHz (Nyquist) for example by adding sampling also in the middle of "OFF" state or limit the bandwidth below 10.5kHz... What would be best here?

On the DSO I can see the output from ACS and it is a rounded and skewed triangle plot. On my ADC readings it of course looks different because I try to sample once per period and I treat that measured value as an average. But real current fluctuates a little bit up and down between cycles so it is a thick line on DSO screen and of course my sampled "average" also changes between cycles so it is a "noisy" signal on data plot.

From that point there is a small step to problems in current control loop. If I set parameters of current PI regulator to react slowly it rejects that noise but general response is veeery slow. If I set it to be more "nervous" and instantly follow PV changes motor starts to be audible and feedback noise excitates everything...

What steps should I make to improve that closed current control loop?
 
 

Offline capt bullshot

  • Super Contributor
  • ***
  • Posts: 3033
  • Country: de
    • Mostly useless stuff, but nice to have: wunderkis.de
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #39 on: October 23, 2019, 08:04:13 am »
What steps should I make to improve that closed current control loop?

Interestingly, this is a common issue with motor phase current measurement in 3ph Servos too. More interstingly, the large servos can cope quite well with this noise and still act dynamically, I believe it's also a matter of physics because large motors have large inertia. It's all a matter of physics and control loop parameters. Typically, any servo drive must optimize it's parameters to the system.

Anyway, from a HW point of view:
- look for common mode noise coupled from the high du/dt motor voltage into the small signal current measurement. Twisted pair is a good approach in the first place. Sometimes you get noise injected into the sensors output within the sensor itself, you cannot do too much about it but taking care of a good (solid / massive) grounding the sensor to a quiet low impedance ground or choose a better CMRR sensor.
- look for non-current sensor related issues in the signal path - often one can see badly designed ADC input circuitry and decoupling with MCU integrated ADCs - good layout and clean supplies, proper low impedance decoupling GND plane etc. are as important for a clean signal as the design of the sensor itself.
Safety devices hinder evolution
 

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #40 on: October 23, 2019, 08:51:02 am »
Thanks for these suggestions. I have already extended my TODO list to improve ACS power supply filtering as well because AFAIK it produces ratiometric output so any noise on its VCC will be reflected in output signal, I think. "CMRR" doesn't exist in ACS722 datasheet so I am probably right about its rule of operation ;). At the moment there is some foil cap in THT for VCC decoupling because it was easier to install so in final design I will replace it with low ESR mlcc 100n+1u and maybe ferrite bead.
AVCC which is also AREF in this MCU is already quite well filtered, I think. 

My particular DC motor has rather low rotor inertia itself - 72.8gcm2 - and what is also important (I suppose) it has quite low windings inductance - 0.103 mH - so current will be less filtered than in high inertia, high inductance models and motor will react faster to any changes on input.
What it interesting, original motor controller that can be purchased with that motor uses 50kHz PWM, 25kHz current PI loop, 2.5kHz speed PI loop and 2.5kHz position PID loop. In some NXP article I have found a note:
Quote
This principle works only on the condition that the motor electrical time constant must be many times higher than the switching period. Therefore, the motor current waveform will be almost linear during the pulse of the PWM
and my DSO shows rounded and skewed triangle on ACS output, as mentioned earlier... Maybe they have increased PWM frequency to get more linear current transitions? I don't know. Or maybe it is only a matter of limited bandwidth? ;)
 

Offline jbb

  • Super Contributor
  • ***
  • Posts: 1265
  • Country: nz
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #41 on: October 23, 2019, 09:36:18 am »
Glad to hear it more or less works. It’d be nice to see some photos of the setup if you’d be so kind.

I suggest you try sampling the ADC at twice the sampling frequency. Then you can quite simply average the two samples and feed that into your current controller, which hen runs at 1x PWM frequency.

If you then want to try more, you could try a modified PI controller. Keep the integrator part as normal, and add a low pass filter to the proportional part to knock down the high frequency gain a little. (Rationale: the integrator has a 90 degree phase lag. If you simply low pass filter the current the you add filter phase lag to the integrator phase lag and could have trouble.)
 

Offline IconicPCB

  • Super Contributor
  • ***
  • Posts: 1564
  • Country: au
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #42 on: October 23, 2019, 10:33:32 am »
Place an  inductor  in series with the motor to achieve required electrical time constantwith motor
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 9333
  • Country: fi
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #43 on: October 23, 2019, 11:50:19 am »
If getting the correct & accurate average current is an issue due to large current ripple, or running in DCM (at low currents, in "diode emulation mode"), use an MCU with high enough sample rate ADC, and sample several times during the PWM cycle. For example, I have done 2 x 8 samples/cycle in a 140kHz dual converter no problem using STM32F334, averaging in software. With motor control frequencies (say < 50 kHz) and only one channel required, it should be trivial to go for, say, 32 samples/cycle. Some ADC peripherals offer oversampling in the peripheral itself (accumulating in the data register). This will reject switching noise as well, unless the spikes are truly massive.
« Last Edit: October 23, 2019, 11:54:47 am by Siwastaja »
 

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #44 on: October 23, 2019, 02:57:43 pm »
Glad to hear it more or less works. It’d be nice to see some photos of the setup if you’d be so kind.
Maybe with next release. Now it looks horrible :-DD
I suggest you try sampling the ADC at twice the sampling frequency. Then you can quite simply average the two samples and feed that into your current controller, which hen runs at 1x PWM frequency.
That is a good idea and easy to implement. I will try that.
If you then want to try more, you could try a modified PI controller. Keep the integrator part as normal, and add a low pass filter to the proportional part to knock down the high frequency gain a little. (Rationale: the integrator has a 90 degree phase lag. If you simply low pass filter the current the you add filter phase lag to the integrator phase lag and could have trouble.)
Yeah, some time ago I have noticed that too much lag causes strange bahavior which is quite obvious because reaction is made against something that is not true anymore in reality ;)

Place an  inductor  in series with the motor to achieve required electrical time constantwith motor
You are right, I have noticed today that original controller has specified built-in motor choke of about 9uH and I have found FAQ document with some formulas to check if additional external inductor is needed. And what even more interesting, they claim that for calculations only 30% of inductance from datasheet should be used because it is measured with 1kHz sine and effective inductance for higher freq square is 30-80% of that ;)
So I plan to add 4,7uH to each H-bridge output. I was looking for some info about type, whether it should be CM choke or DM (not coupled inductors) and I am still not sure ;) By intuition DM... But I have also found some standard solutions with 220uH CM and 82uH+RC to ground ;) The best way to check would be to play around and swap some components, maybe there will be some spare time to do that ;)

If getting the correct & accurate average current is an issue due to large current ripple, or running in DCM (at low currents, in "diode emulation mode"), use an MCU with high enough sample rate ADC, and sample several times during the PWM cycle. For example, I have done 2 x 8 samples/cycle in a 140kHz dual converter no problem using STM32F334, averaging in software. With motor control frequencies (say < 50 kHz) and only one channel required, it should be trivial to go for, say, 32 samples/cycle. Some ADC peripherals offer oversampling in the peripheral itself (accumulating in the data register). This will reject switching noise as well, unless the spikes are truly massive.
Yes, I think that my F303 could also handle that. I will check the results with simplier solutions and if it fails I will try more sophisticated ones.. :)


In the meantime I have switched to 50kHz PWM ;) It works (without current control loop at the moment) but I have to check some bad things on output signals. From very quick investigation I think that ringing on MOSFET gates causes cross-conduction for short moments so motor works but H-bridge becomes hot...
 

Offline capt bullshot

  • Super Contributor
  • ***
  • Posts: 3033
  • Country: de
    • Mostly useless stuff, but nice to have: wunderkis.de
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #45 on: October 23, 2019, 04:05:42 pm »
CM inductor is useful for EMI mitigating purposes, but it's magnetizing inductance isn't added to the motor inductance since the motor current cancels out. Only the stray inductance will add to the motor inductance.

I've seen designs adding a small value inductor (e.g. 4.7uH) to each H-Bridge output - it's purpose is to limit dI/dt to some value the short circuit protection can handle. Depends on the ruggedness of the MOSFETs and the speed of the short circuit protection (if applicable). Also helps with capacitive charging currents of longer motor cable runs.

If you want to use higher switching frequencies to lower the ripple, your current control loop still can run on a lower frequency (if computing power is the limit) - a faster loop would still run with the same bandwith required by the system, doing more computation than necessary. Oversampling and averaging or downsampling (filtering) is a good measure to reduce noise and increase resolution, as long as you can meet your bandwith requirements.

Driving a MOSFET H-Brigde requires tuning and low impedance layout for best performance ;) Cross-conduction is rather easy, just increase the dead band. Diode recovery and ringing can be way more nasty, try slowing down the switching by increasing the turn-on gate resistors, keep turn-off fast - or try to find a very narrow dead band configuration that avoids MOSFET body diode conductance and switches fast. The latter one is difficult to maintain over a wider range of DC-Link voltages and loads characteristics.
Safety devices hinder evolution
 
The following users thanked this post: Siwastaja

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #46 on: October 23, 2019, 06:39:56 pm »
First thing I have to check is raw MCU output. I was a little bit surprised about its shape. Maybe it was some kind of ringing but looked like short turn off during ON state :-| On 21kHz everything looked perfect, I think, so it is strange that it behaves so different.. but I have to double check as it was just quick test before turning everything off ;-)
 

Offline jbb

  • Super Contributor
  • ***
  • Posts: 1265
  • Country: nz
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #47 on: October 23, 2019, 07:30:37 pm »
In the meantime I have switched to 50kHz PWM ;) It works (without current control loop at the moment) but I have to check some bad things on output signals. From very quick investigation I think that ringing on MOSFET gates causes cross-conduction for short moments so motor works but H-bridge becomes hot...

I gotta say, cross-conduction (aka shoot-through) is bad at any switching frequency.  You should check for that; it might be fixable by adjusting the gate driver circuits.

Also, do you really need 50kHz PWM?  Assuming the same H Bridge, higher switching frequency will always lead to higher switching losses.  Also, laminate iron rotors will tend to show lower effective inductance (and higher iron losses) at higher switching frequencies.
 

Offline capt bullshot

  • Super Contributor
  • ***
  • Posts: 3033
  • Country: de
    • Mostly useless stuff, but nice to have: wunderkis.de
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #48 on: October 23, 2019, 07:36:22 pm »
Interesting - some kind of timer misbehaviour? Do you use the capture/compare shadow / buffer registers (don't remember real name in the datasheet and ATM I'm too lazy to look that up) so the PWM values get updated at the correct sampling point?
I've experienced some weird effects with STM timers, usually I could resolve them by checking and fixing my code ;)
From my experience, it's highly recommended to handle the bare metal timer, not to use ST HAL code. It's way more efficient and you've got to debug your own code only. Since I'm lazy, usually still leave the basic initialization to Cube/HAL, but no more HAL once it's up and running, especially within timing critical interrupts.
« Last Edit: October 23, 2019, 07:40:28 pm by capt bullshot »
Safety devices hinder evolution
 

Offline krisRabaTopic starter

  • Regular Contributor
  • *
  • Posts: 59
  • Country: pl
Re: Motion control, S-curves and other stuff >> controlling lift with DC motor
« Reply #49 on: October 23, 2019, 08:19:57 pm »
I gotta say, cross-conduction (aka shoot-through) is bad at any switching frequency.  You should check for that; it might be fixable by adjusting the gate driver circuits.
I have to investigate what is the real source of that problem. Power section is quite nice layed-out, I think. It is not my design but I would give a thumb up for that part of PCB to my colleague ;) And the problem was also observed on MCU side, before isolated gate drivers, so I presume it just follows junky drive signals. These lines are quite long and one of them is rewired near gate driver because I had to do some pin re-arrangements to free additional hardware connections. But it worked perfectly with 21kHz and 50kHz doesn't sound like astronomic change ;)

Also, do you really need 50kHz PWM?  Assuming the same H Bridge, higher switching frequency will always lead to higher switching losses.  Also, laminate iron rotors will tend to show lower effective inductance (and higher iron losses) at higher switching frequencies.
I don't know, just to be honest ;) Company that designed these motors and controllers doesn't hire idiots.. I hope ;) It's rather top brand. These motors and controlers are designed to work together and their controllers use 50kHz and other parameters that I have already mentioned. So I think there is important reason for that.
I have already mentioned effective inductance and it looks like they know about that problem ;) And this is why they suggest to use 30-80% of its value in calculations...
Generally I have to check if there is any significant improvement in current ripple. I couldn't hear any difference in motor sound when working at 21kHz and 50kHz, no resonances, buzzing etc. in both situations ;)
I usually use 21kHz just to go above audible range but their 50kHz tortures my brain ;)

Interesting - some kind of timer misbehaviour? Do you use the capture/compare shadow / buffer registers (don't remember real name in the datasheet and ATM I'm too lazy to look that up) so the PWM values get updated at the correct sampling point?
I've experienced some weird effects with STM timers, usually I could resolve them by checking and fixing my code ;)
From my experience, it's highly recommended to handle the bare metal timer, not to use ST HAL code. It's way more efficient and you've got to debug your own code only. Since I'm lazy, usually still leave the basic initialization to Cube/HAL, but no more HAL once it's up and running, especially within timing critical interrupts.
I use HAL only for GPIOs init because in CM4 it is designed so strange that it would be hard to write simple macro to set that and this is done only once at startup ;). Other things usually controlled in "bare metal" on registers. I use "preload" on all CCR registers so it's not that. And nothing was changed here between 21kHz and 50kHz.
Of course before blaming MCU vendor I always study datasheet, my code, datasheet, and so on.. ;)
But to still have good resolution after increasing output frequency I have switched clock source from PCLK2 to 2xPLL ;) So now this timer runs at 144MHz :D  8) But datasheet claims it can handle that ;) TBD in reality ;)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf