cycles timing question

[airman00]

23/.992*(time in milliseconds) = number of cycles

From where do we get the 23/.992 ?

Also, how would this formula change if the microcontroller was running at 16mHz

Btw I am writing a function for the Axon that is mS based instead of cycles , just to make it easier for me. I might write a function for angle also , once I have the mS done . Easier for me to go from mS to angle , then from cycles to angle . 

Thanks

[Admin]

From where do we get the 23/.992 ?

My oscilloscope.

Also, how would this formula change if the microcontroller was running at 16mHz

If you are going from 1 MHz to 16 MHz, it should be:
23/.992*(16MHz/1MHz)*(time in milliseconds) = number of cycles

AVRlib has these functions that will already work on the Axon:
delay_ms(1000);
delay_us(1000);

However, I remember that AVRlib had some bug that if you put a variable in it like this:
delay_us(variable);
that it won't work if the variable went above 255. So thats why I created the cycles method for servos. Plus, on the $50 Robot, timer interrupts are limited.

[airman00]

can AVRlib deal with fractions? ]

If I write a  macro for mS, can I do

Code: [Select]

servo(1.5)
Or can it not handle the 1.5?

[Admin]

If I write a  macro for mS, can I do

Code: [Select]

servo(1.5)Or can it not handle the 1.5?

I just tried both of these:

Code: [Select]

PORT_ON(PORTE, 6);
delay_ms(1.9);
PORT_OFF(PORTE, 6);
delay_ms(1);and

Code: [Select]

PORT_ON(PORTE, 6);
delay_ms(1);
PORT_OFF(PORTE, 6);
delay_ms(1);
and got a frequency of 471 Hz for both.

This also shows that the ATmega640 clock isn't perfect (5.8% error), as it should have been 500Hz. The $50 Robot clock will not be perfect either.

[airman00]

However, I remember that AVRlib had some bug that if you put a variable in it like this:
delay_us(variable);
that it won't work if the variable went above 255. So thats why I created the cycles method for servos. Plus, on the $50 Robot, timer interrupts are limited.

does that mean that this wont work? Or is the bug fixed already?

#define servo(port,number,position)   (PORT_ON(port,number), delay_us(position), PORT_OFF(port,number))

I made it time based instead of cycles based - its just easier for me .

[pomprocker]

just use 1500uS instead of 1.5mS

[airman00]

just use 1500uS instead of 1.5mS

yea that was what I was planning to use but admin said there was a bug for using variables above 255 in delay_us.  I wanted to know if the macro would work since its not really a variable , but rather passing numbers - i think.

[pomprocker]

also check out <util/delay.h>

http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html

[airman00]

will this work :

Code: [Select]

Set up code:
'set up servo macro
#define servo(port,number,position)   (PORT_ON(port,number), delay_us(position), PORT_OFF(port,number))
'hardware define:
#define servo1( position ) servo(PORTE,6,position)
Then when I want to control the servo :

Code: [Select]

servo1(1500)
The only reason I can see for it not to work is because of that bug Admin mentioned. But I was wondering if one of the more seasoned programmers can help me out.

[pomprocker]

instead of using software based pwm, why don't you use the pwm capabilities built into the avr?

[airman00]

instead of using software based pwm, why don't you use the pwm capabilities built into the avr?

Because there are only 9 PWM channels but I have a lot of servos

[Ro-Bot-X]

Arduino has a ServoTimeTimer1 that works like you described: Servo1(1500). Check it out here: http://www.arduino.cc/playground/ComponentLib/Servotimetimer1

[airman00]

thanks RobotX but I think the code is pin specific ,

Will that code I posted above work?

[JesseWelling]

I'm working on a configurable PWM C code that is somewhat object oriented and utilizes hardware timers but It's not quite working yet. Any one who wants to look at it can but to make it compile you'd have to take out a bunch of debug stuff. And if any one can find the bug before I can let me know. Once I get this working I need to make it a more general solution (For any F_CPU) and then Add support for more than one timer.

[airman00]

What I want to do is to be able to control the servos the same way that the SSC-32 controls it.
Its command to control the servos are :

Code: [Select]

'RA,                    RK,      RH,       LA,                LK,                 LH,        speed
#0 P1427      #1 P1292   #2 P1292  #16 P1573    #17 P1708    #18 P1708   T500
Where RA is right ankle,RK is Right Knee, RH is Right Hip, etc.
The pulse is in uS as you can see by the " P1427" which is a pulse for 1427 uS.

I want to control the servos from the Axon in a way similar to this . I want a macro that does servo1(1427) . Can anyone help me to write this macro? I still don't know if a bug exists for having a variable larger than 255 in a delay_us macro. 

And I'd rather not use UART from the Axon to control the SSC-32 , I want it all done on the Axon.

[pomprocker]

can you write your own function

Code: [Select]

void pulse(uint8_t microseconds) {

     while (microseconds > 0) {
          delay_us(1);
          microsecs--;
     }  // end while loop

} // end pulse function

[paulstreats]

The way I got around it in Pic18's running a 20mhz clock was like the sample below.

Basically you call the function and pass the degree that you want the servo to turn to as the parameter (0 = far right. 180 = far left on servo. 90= servo centered). so i would write move_servo(90) to center the servo.

The thing is that its a freak occurence that running a 20mhz clock produces the correct servo angle when the angle degree is multiplied by 4 (in the PIC because it delays according to instruction cycles). But maybe it can be modified to your needs...

Code: [Select]

void move_servo(unsigned int duty){

SERVO1 = 1;
Delay10TCYx(duty);
Delay10TCYx(duty);
Delay10TCYx(duty);
Delay10TCYx(duty);
SERVO1 = 0;
}

There is obviously a small loss in precision by having to call the delay 4 times but its not going to be huge.

Doing it this way means that nothing else can happen while the servo is being pulsed. If you are wanting to do that then you need some serious speed.

Try to find the common denominator between the delay functions and the servo angles and you will eventually come up with something that will work for you.

[Admin]

You could just write a quickie function that converts milliseconds to cycles . . .

[airman00]

You could just write a quickie function that converts milliseconds to cycles . . .

I'm confused

Didn't you say that the Axon cannot do 23/.992 since it will round up and will end up being 23/1

I want it accurate also.

[Admin]

23/.992*(time in milliseconds) = number of cycles

Lets say you want 1.5ms, then you get 34 cycles.

Or 1.1ms, 25. Or 2ms, 46.

This is already way more accurate than your servos will be, trust me

The Axon runs 16 times faster than the $50 Robot, so you'll get 16x higher accuracy on the cycles method.

[pomprocker]

I'm no expert but I was reading on AVRfreaks that servo delays are for n00bs, and that the proper thing to do would be to use timers. The higher resolution the timer the better.

[Admin]

Nope not for n00bs. It has a lot to do with your processing requirements, if you have other interrupts running, how many servos you plan to use, how many timers you have, etc.

For example, if you only have 4 servos, thats only a ~25ms delay per second. Hardly worth the frustration of implementing timer interrupts.

Now if you are making a 25 servo biped with tons of sensor processing, well thats another story . . .

[airman00]

I did what pomprocker suggested. Thanks!!!

Heres the macro:

Code: [Select]

void pulse(uint8_t microseconds) {

     while (microseconds > 0) {
          delay_us(1);
          microseconds--;
     }  // end while loop

} // end pulse function

and heres the modified servo define code:

Code: [Select]

//define the servo function macro
#define servo(port,number,position)   (PORT_ON(port,number), pulse(position), PORT_OFF(port,number))
To call the macro I just do :

Code: [Select]

servo_1(1500)  // where 1500 is the pulse in microseconds.

[Admin]

Looks exactly like my cycles code, but with a timer delay inside of it . . . I not sure which is more accurate, probably the only way to know is by comparing both with an oscope . . .

your code:

Code: [Select]

void pulse(uint8_t microseconds) {

     while (microseconds > 0) {
          delay_us(1);
          microseconds--;
     }  // end while loop

} // end pulse function
my cycles code (with your variables):

Code: [Select]

void pulse(uint8_t microseconds) {

     while (microseconds > 0) {
          microseconds--;
     }  // end while loop

} // end pulse function

[airman00]

one second

the servos are turning but no matter what I give them 1000 - 2000 they will always turn the most extreme 2000 point. This reminds me of my PULSOUT problems the PIC microcontroller where the oscillator speed caused issues. 

I'll get back to you guys once I try a solution.

[airman00]

found the issue :

Exactly the same problem with my PIC . Dividing the amount in microseconds by 16 solves the problem. I think delay_us might be faulty.

This works

Code: [Select]

void pulse(unsigned long int microseconds) {
     microseconds=microseconds/16;
     while (microseconds > 0) {
          delay_us(1);
          microseconds--;
     }  // end while loop

} // end pulse function
Btw I changed it to unsigned long int b/c its easier for me to understand the code at a glance

[dunk]

so i'm no C expert but you guys have me thinking about C data types...

Airman: when you first tried to use the "uint8_t" type to define "microseconds" you were limiting that variable to 1 bite = 8 bits = a maximum value of 255.
the type "unsigned long int" you use later is possibly a little excessive allowing 4 bites = max value of 4294967295. but hey, you have plenty of memory on the AVR right?

Admin: when you were talking about the bug with delay_us accepting  a max value of 255 near the start of this thread, delay_us in AVRlib is written to accept the type "unsigned short" which i  believe is the same as "unsigned short int" should be good for 2 bytes...
this strikes me as a compiler issue rather than a AVRlib issue.
what compiler do you use?
i'm guessing you could chance AVRlib's timer.c to make delay_us use type "int" instead of "short int" as a workaround.


dunk.

[pomprocker]

They are typdefs

http://www.mil.ufl.edu/~chrisarnold/components/microcontrollerBoard/AVR/avrlib/docs/html/avrlibtypes_8h-source.html

[Admin]

so i'm no C expert but . . . the type "unsigned long int" you use later is possibly a little excessive allowing 4 bites = max value of 4294967295.

Isn't it 65535? And isn't it spelled 'byte'? Don't you work for google?

Admin: when you were talking about the bug with delay_us accepting  a max value of 255 near the start of this thread, delay_us in AVRlib is written to accept the type "unsigned short" which i  believe is the same as "unsigned short int" should be good for 2 bytes...
this strikes me as a compiler issue rather than a AVRlib issue.
what compiler do you use?
i'm guessing you could chance AVRlib's timer.c to make delay_us use type "int" instead of "short int" as a workaround.

I should reclarify that I first read and I *think* even experienced this problem about 1.5-2 years ago. I don't really remember anymore, shoddy memory from the days I was an AVR noob . . . but yea I think if I change it to 'long int' it should work . . . Im using the gcc compiler. I'll try it out when I have time and add it to the next Axon software upgrade if it works.

[dunk]

Isn't it 65535

65535 would be 2 bytes.
4 bytes = max value of 0xFFFFFFFF = 4294967295.

And isn't it spelled 'byte'?

bahh. fix your website's spilling chacker.


dunk.