Comment by William Premerlani on July 24, 2009 at 4:55am

Roy,

Implementing a few extra PWM output channels would require a minor h/w mod to the board. It would also require special servo connections, because you need ground, power, and signal for each servo.

The way that I would do it would be to take a servo extension cable for each additional PWM output and cut the signal wire on the end that would normally plug into the radio, and solder it directly into a spare digital I/O pin of the board. Then, I would plug the connector with the remaining two power and ground wires right into the radio to pick up power and ground.

I would not use the power and ground in the spare pin port of the board to power a servo. The only traces on the board that are meant to carry servo power are the ones that create a power bus tieing the PWM input/output channels together.

Best regards,
Bill

Comment by Ben Levitt on July 24, 2009 at 8:35am

Hi Bill,

Do you think it would also be practical to add another radio channel input? (Am I right thinking that adding another input is actually much easier than adding an output that doesn't use the dedicated PWM hardware?)

I'm imagining a setup similar to what you describe where I take a servo extension cable and cut the signal wire in the middle, and connect the end coming from the receiver to one digital I/O pin as an extra RC channel input, and the end going to the servo to another digital I/O pin as a new servo output. The remaining two wires would power the servo.

Thanks all!
Ben

Comment by William Premerlani on July 24, 2009 at 11:05am

Ben,

Actually, its easier to add servo outputs to the UAV DevBoard than it is to add radio channel inputs.

The ideal way to do a PWM input with the dsPIC30F4011 is with the "capture" channels, which basically do pulse width calculations in hardware. They are really great. Problem is, there are only 4 of them on the dsPIC30F4011, and I have used all four of them. The spare digital I/O pins do not generate interrupts, so it would be very difficult to implement more PWM inputs. I have not been able to figure out how to do it without continuously polling the digital pins and without interference from the all of the interrupt service routines that are running. If anyone can figure out how to do it, please let me know.

On the other hand, PWM outputs are rather easy to do, you set up a timer to generate an internal interrupt, which you use to toggle the output pin.

The obvious thing for me to do is to come out with a more advanced board using the dsPIC30F6015, which has more dedicated PWM I/O channels. I briefly considered introducing another board for this flying season, but I was not sure what GPS and other sensors such as airspeed and magnetometer, altimeter, to use, and I am presently rather busy just supporting the board I have. So, what I will probably do is design the next generation board over the winter and introduce it in the spring.

Best regards,
Bill

Comment by Roy Brewer on July 24, 2009 at 3:47pm

Bill,

I'm still a little new to the DSPIC family. Can you explain why you'd go with the dsPIC30F6015 versus, say, a dsPIC33?

My friend Brij is building quadrotor board based on the ATMEGA644p, which has certain limitations of its own, of course. We were also considering using an ARM, perhaps this one: http://www.luminarymicro.com/products/lm3s1968_evaluation_kits.html

Thanks. Sorry for all the off-topic posts.

Roy

Comment by William Premerlani on July 24, 2009 at 4:34pm

Roy,
The reason I was considering the dsPIC30F6015 was because its in the same family as the dsPIC30F4011, so the learning curve would not be so steep for me or for UAV DevBoard users, and it has all the resources we would need. I will revisit the question if and when I think about my next board design, I would certainly take a look at the dsPIC33 at that point.
Bill

Comment by Ben Levitt on July 29, 2009 at 1:50am

Hi Bill,

I've been digging through dsPIC30F4011 info. It seems like a really cool chip!

This might be a newbie question, but do you think it would be possible to use the spare FLTA/INT0/RE8 pin as another RC input? Unfortunately it looks like INT0 only detects either low-to-high transitions or high-to-low transitions, but I was thinking it might be possible to wait for a low-to-high, and then save the time and reconfigure the pin to listen for high-to-low, etc. by switching the INT0EP bit back and forth in each INT0 interrupt.

Does this sound like a reasonable thing for me to try, or am I talkin' crazy? :)

Ben

Comment by William Premerlani on July 29, 2009 at 3:50am

Hi Ben,

Your suggestion for using FLTA/INT0/RE8 as a 5th PWM input channel just might work. The idea never occurred to me to change the polarity of the detection on the fly.

The idea might work, it might not, but it is certainly worth trying out. I encourage you to give it a try. If will too, when I have some time.

I read the documentation, it did not give me any clues about it. Whether the idea will work or not is going to hinge on what happens when you change the polarity of the interrupt. In the worst case, it might generate a spurious interrupt, or it might skip one. Hopefully, that will not happen, in which the idea should work.

Here is what I think you should do each time you get an interrupt on INT0:

1. Record the time first thing in the interrupt, and do whatever pulse measurement math you need to do. Double check the polarity of the pin so that you will know which direction you are going.

2. Turn off the interrupt.

3. Clear the interrupt.

4. Change the polarity.

5. Turn the interrupt back on.

Regarding the priority of the interrupt, you can set it once and for all.

Thank you, and best regards,
Bill Premerlani

Comment by Ben Levitt on July 29, 2009 at 9:04am

Hi Bill,

Thanks for the suggestions! I have it mostly coded up, but my dev board doesn't arrive at my home for a couple more days. And worse, I myself don't arrive at my home for about a week! :P So I won't be able to test until then. But I certainly will as soon as I can!

And I guess that last one wasn't a newbie question after all, but this one probably is: Where should I grab the time from during the INT0 interrupts? The other rc inputs grab from the IC[1278]BUF. Does the INT0 interrupt write the time somewhere analogous? Or should I grab from TMR1? Or is there a simple system clock value somewhere that I missed? For whatever location you suggest, will that value have the same scale as the IC1BUF time values, or will I have to shift it to account for any timer prescaler or anything else?

Thanks very much,
Ben

Comment by William Premerlani on July 29, 2009 at 1:34pm

Hi Ben,

The best thing to do in response to the INT0 interrupts is to grab TMR2. That is the timer that I've set IC[1278] to use, so if you use TMR2, you will not have to do any shifting, you will be on the same time basis as the other 4 PWM input channels.

The input capture (pulse width measurement) hardware snapshots either timer 2 or 3, depending on how you set it up. I set it up to use timer 2.

The only difference between what you plan to do with INT0 and what input capture does, is that input capture automatically snapshots the selected timer to a buffer using hardware at the very instant of the interrupt event, so any latency in processing the interrupt is irrelevant.

In your case, there will be a small amount of latency (not enough to matter) between the time the interrupt event occurs and when you get to read the time. The first thing you should do in the interrupt service routine is to record the value of TMR2.

Best regards,
Bill

Comment by William Premerlani on July 29, 2009 at 1:45pm

Hi Ben,

A couple of more things I forgot to mention.

Set the priority of the interrupt service routine for INT0 to 7. That is the highest priority. You need to do that, because actually that routine will be the only time critical routine in the system. All of the other interrupts in the system do not need to be serviced immediately, because the time critical steps were already performed by the hardware.
Since your code will be pre-empting everything else, make sure you don't hang the CPU! Just do the time measurement, deal with the interrupt related flags, and get out.

Regarding the wiring for INT0, all you need is signal and ground, do not connect anything to the spare VCC pin. The best thing to do is to connect at least one other PWM input channel to your radio, that will establish power and ground on the board, so all you need to do is tie the signal for the spare PWM input channel from the radio to RE8. I suggest that you solder a single header pin to RE8, and run a jumper wire from RE8 to the signal pin on your radio.

Good luck! If what you are planning to do works, then the UAV DevBoard will be able to handle 5 PWM input channels, and drive 6 PWM servos!

Best regards,
Bill

Comment

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page