Cam works but RC won't

[LightWaves1636]

I'm using "Bells and Whistles". the pwm outputs 13-16 aren't sending out any kind of signal and thus the speed controllers aren't amking the motors run. I uncommented Generate_pwm and now I'm stuck at a deadend. any ideas?

[d.courtney]

I had the same problem... it was the fact that Default_Routine wasn't called from main... hope that helps.

[Alan Anderson]

Pwm outputs 13-16 are special. They're generated by the user processor and can be updated more often than the 26.2 ms communication burst. But you need to call the Generate_PWMs() function in order for them to work. The line with that function call is present in Kevin's camera code, but it has been commented out.

They also have a reputation of being prone to "twitchiness" if you have lots of interrupts going, or if you call the Generate_PWMs() function repeatedly with too short a delay.

[LightWaves1636]

okay , it works now, thanks for all the help yay we finally can drive

[Eldarion]

Originally Posted by Alan Anderson

Pwm outputs 13-16 are special. They're generated by the user processor and can be updated more often than the 26.2 ms communication burst. But you need to call the Generate_PWMs() function in order for them to work. The line with that function call is present in Kevin's camera code, but it has been commented out.

They also have a reputation of being prone to "twitchiness" if you have lots of interrupts going, or if you call the Generate_PWMs() function repeatedly with too short a delay.

I've had a few quesions on this and Putdata, maybe you can clear them up

How long does Generate_PWMs() take to return? Can I call it from within a timer ISR?

If I call Putdata more than once every 26.6ms, will it update the PWMs faster?
How long does it take to return?

And finally, the master processor seems to allow the user processor more than 26.6ms?!??
This makes no sense, but our code is definitely taking longer than 26.6ms (because of serial communications bogging us down) and yet I do not get the BRLOD?!??

Thanks for any light you can shed on this!

[Alan Anderson]

Sorry, Eldarion, I don't know the answers to most of those questions. I would avoid calling any nontrivial functions from within an interrupt service routine.

Are you sure your serial communication is slowing down your code? The IFI Loader's terminal window is slow to display; maybe that's what you're seeing.

[Eldarion]

Originally Posted by Alan Anderson

Are you sure your serial communication is slowing down your code? The IFI Loader's terminal window is slow to display; maybe that's what you're seeing.

I am monitoring the routines' speed through how many times a Parallax PING))) sensor is triggered. Every time it triggers, a green LED flashes. When the camera is not hooked up (therefore preventing any serial communication), the light is almost steadily on. As soon as I hook up the camera and serial communication is established, the light slows down quite noticeably.

Also, I tried putting limit switches on a moving part of our robot, but they took much longer than 1/40 of a second (26.6ms) to respond. The response time was more on the order of 1/4 of a second! This ate several limit switches, unfortunately.

All the code I have mentioned was placed within the main "26.6ms" loop. I am basing my code off of last year's camera code; were there improvements made for this year? I was under the impression that last year's default code used buffered serial communications; however I am at a loss to explain this behavior.

Can anyone help me on this? Maybe someone from IFI (hint hint)?

Thanks,

Eldarion

[X-Istence]

well, the easiest way to test if the new code is better, is by running the new code.

Grab the new code from Kevin's site, then proceed to modify anything that needs to be modified, and test it.

[Alan Anderson]

Originally Posted by Eldarion

I am basing my code off of last year's camera code; were there improvements made for this year?

It's quite different this year. Whether or not you would consider it to be an "improvement" probably depends on how clever you are with programming your own camera communication routines.

If your limit switches are taking that long to respond, I suspect you have significant delays built in to your code. Even with buffered and interrupt-driven serial communication, you will slow things down a lot if you're sending commands and waiting for an ACK to come back before continuing.

[Eldarion]

Originally Posted by Alan Anderson

It's quite different this year. Whether or not you would consider it to be an "improvement" probably depends on how clever you are with programming your own camera communication routines.

If your limit switches are taking that long to respond, I suspect you have significant delays built in to your code. Even with buffered and interrupt-driven serial communication, you will slow things down a lot if you're sending commands and waiting for an ACK to come back before continuing.

That's the exact problem!

A few hours after I posted my plea for help, I remembered last year I had to deal with a certain wait_for_data() IFI put into the camera routine. It was blocking execution for quite a while, and probably explains the slowdown. I'm not sure why they tried to make the camera communication appear synchronous, but it should work just fine in asynchronous mode (I hope!).

I am still curious why this didn't trip the supposed 26.6ms code execution limit. In my testing, that limit seemed more on the order of a full half second. (I had added a timer without adding the ISR, causing it to crash almost immediately, but the BRLOD didn't show up for about a second).

Anyway, thanks for your help.