Re: Printf has just entirely failed to do anything
 

I missed that as well in camera.c :eek: so good call.

Aside from your efforts to start from the default code, I can send you a basic environment that has a working camera without too much of our robot-specific code in it just so you can verify its not the source you're building from.

Another possibility-what version of the IFI loader are you using? If you use the old version with code sizes> 32k (or whatever the max was for 2005's RC), you can get wicked crazy problems. That might explain why things stopped working as you added more functions/files.

-Eric

Re: Printf has just entirely failed to do anything
 

Good news & bad news...

I dropped your code as-is into one of our controllers and a printf I added to user_routines.c worked fine.
Master code v12
IFI_Loader v 1.1
I ran without the camera as a first test then connected the camera.

Which printf in what routine in particular were you having trouble with?

P.S. In the version you posted none of the camera code is ever called from anywhere, so there won't be any "uncalled for" printf's from any of that code.
I added a call to CAL_Update(); in Process_Data_From_Master_uP and uncommented the #include "camera_abstraction.h"
and I'm seeing the printf's from the camera code.

Re: Printf has just entirely failed to do anything
 

I'm using IFI Loader 1.1.0. I see no printfs anywhere, at all when I put this code into my rc. I've verified it's not my terminal program, serial port, or the rc itself as I loaded old code and it showed all the printfs fine. I can't test anything until somewhere around the 4th because I can't get into the shop until then. I had added printfs directly into main() because nothing else was working, and even that wasn't working. I suppose I should update the master code because I am pretty sure nobody bothered to do so last year--I think we're running v11 still.

Thanks again
JBot

EDIT: Is that what the new master code was released for--a fix in printf? I knew there was new code out there but I don't remember ever updating. I even have the binary on my machine right now, I just need to upload it.

Re: Printf has just entirely failed to do anything
 

No such luck.
The master code revisions usually are just to match changes in the field control software. v11 was released to fix a random twitch in the pwm outputs for Victors, but nothing that affects the behavior of our User code. The Master version won't affect your printf.
I dumped v11 into my test controller just to eliminate that as a potential cause, and your code still works fine.

Your code is small enough to fit and run on the older PIC-based controllers, so the IFI_Loader version isn't a likely issue. But if you get a Vex kit as a present you'll be able to test your code at home!

I'd start with a close look at the simple solutions.

When you get back to the robot after the holidays double check that you're downloading the .hex file you think you are. I notice you're putting the .hex file in a different directory than the source code (C:\old_'07_Code), so check the date on the file IFI_Loader is pointing to and verify it's new.

Double check your C18 version (2.4). I'm sure you have the current version, but verify there aren't older versions or the Vex version conflicting.

What's the history of the PC you're using? Has it been used for several years? Has MPLAB/C18/etc. been reinstalled around the time your troubles began?

Re: Printf has just entirely failed to do anything
 

Ugh. Here we go.

Not likely, but it would be nice. I think I'm going to ask the team leader if I can bring home the old controller, OI, some power source, and all the necessary testing hardware so I can get something done.
<scratches head> I looked at the project options again after you mentioned this, but I see the output directory is c:\old_'07_code, right where the source is. I verified that MPLAB is opening the right files. I have deleted the .hex file, recompiled, and yes, it shows up right where I expected it would, and I verified it was this .hex I downloaded.

I installed this from the '06 disc in the KOP which only had 2.4 on it. I only bought this PC in July or August of this year, so it doesn't have an old version conflict. Also, I have never done Vex ever, so that's not a possibility. I never reinstalled MPLAB, but I'm thinking that's my next step.

It might work right now. I have no idea. I'll have to test it when we get back.

JBot

Re: Printf has just entirely failed to do anything
 

I understand how you setup your project now. I unzipped your files to a folder on my computer that wasn't c:\old_'07_code. Removing the hardcoded paths for Output directory, Intermediates Directory, and Linker-Script Path let them default to whatever the current directory happens to be.

The MPLAB version won't matter much either. It's just an editing/organizing tool.

Don't sweat it until you're in a position to test again. It'll only drive you nuts. Right now what you've got looks good to me. I'll post the working hex file I compiled and you can use it to eliminate your PC/MPLAB/C18 as any kind of a suspect.

Here's the hex file and the camera initialization output printfs I'm seeing. (ignore the "MLM" that's my test printf from user_routines.c)

Re: Printf has just entirely failed to do anything
 

Alright, thanks. Got the file, will try it when we get back.

Some of the characters in the output are interesting, but I won't worry about it right now.

Thanks

You deserve a candy bar...

Here you go:
http://www.nadf.com/images/3musketeers_c.gif

hehe...I'm going nuts already. Think of what the season is going to do...:yikes:

JBot

Re: Printf has just entirely failed to do anything
 

JBotAlan,

I think your problem is both obvious and simple to fix, luckily. Rearranging the Camera_Handler function etc, had nothing to do with it. Had you left the original code intact, you still would have broken the program by moving Camera_Handler() (or CAL_Update() in your program) from user_routines.c to Process_Data_From_Local_IO(). Move Camera_Handler() back where it belongs and everything will work wonderfully again.

Here's my reasoning. Process_Data_From_Local_IO(), as you know, runs stupidly fast, as it runs every loop in the user PIC. As opposed to every 26.2ms for Process_Data_From_Master_uP(). Camera_Handler() is a very complicated little function, and does tons of fun stuff like disabling serial interrupts briefly and using the inherent timing of the slow loop to get the timing of its initialization correct. Basically, with Camera_Handler() in your Process_Data_From_Local_IO(), things are happening waaay too fast and piling up and generally causing the horrible broken execution and code error lights that you're seeing.

To put it even more briefly, in the camera_readme.txt, Kevin Watson says you should call Camera_Handler() from Process_Data_From_Master_uP(). You really ought to listen to him unless you've initmately acquainted yourself with the operation of said function.

Re: Printf has just entirely failed to do anything
 

Oh.

Maybe I should've read that readme.

I figured that it shouldn't be in the slow loop because by default that doesn't even execute during auton, where we need the camera the most. I will definitely read through that function and the camera readme and see if moving the function call back to process_data_from_up helps. That would make sense if it was disabling and re-enabling serial interrupts very quickly...

I never would've caught that.

Thanks
JBot

EDIT: Just glancing through camera.c, I don't happen to see where serial interrupts are disabled/enabled, but I haven't looked at all of the function calls either. I do notice a loop_count variable; that alone warrants moving it back into the slow loop. Like I said, I need it to execute in auton. I may well modify this function so that it can safely execute in the fast loop. I don't know; I don't have time today to deal with this but thanks for the help.

Re: Printf has just entirely failed to do anything
 

Kevin has a good point.
Although calling CAL_Update() from the fast loop (via Process_Data_From_Local_IO) would only prevent the camera from working properly.
It wouldn't lockup the controller or disable printfs. The camera code doesn't take very long to execute.

P.S.
Your autonomous code should also execute in a slow loop. It doesn't help to execute faster than you can deliver instructions to the pwms. If you check the IFI default code you'll see the autonomous section in user_routines_fast.c is really a slow loop by virtue of the line:
You just need to add your camera calls within that slow loop.
I'd advise you to pull all your autonomous code out of the user_routines_fast.c file anyway. The name of that file only confuses the issue and your freshmen programmers, since it's not true for the autonomous code.

Re: Printf has just entirely failed to do anything
 

At first, I thought that auton WAS a fast loop, but I looked at main() and now see otherwise. This brings up a few questions in my mind. Why is auton a slow loop? I had heard (but not tested) that the values we get from the OI are invalid during auton and to disregard them entirely. Is it that the master processor will only let me getdata and putdata every 26.2ms? Do PWMs update faster if I getdata and putdata every loop instead of only when NEW_SPI_DATA is 1? What will getdata do if there is no new data to get? Also, suppose I have a PID loop. It needs to execute fast (or so the whitepaper says). So I put it in local IO. It changes PWM values in between 26.2ms loops. Are the victors actually getting the updated values in between loops, or are they updated every 26.2ms? And are my sensor reads actually updating in between 26.2ms loops, or are they the same every loop? Sorry about all the questions...I don't really understand the architecture of the rc.

Wow, my basic assumption (based on the comments in the code...) was wrong.
So that comment is downright wrong? Sure looks like it by the looks of main()...I might shoot off an email to IFI just to let them know.

JBot

Re: Printf has just entirely failed to do anything
 

Mark,

You're right about the camera code executing quickly, but I think that might be where the problem lies. The initialization process fires off atleast a few packets to the camera. If Debug is on, it will also fire several long strings to the terminal. If all of this is in the fast loop... Well I just think the most likely culprit is all of these serial writes stacking up and possibly overflowing queues and generally making a mess of things.

Re: Printf has just entirely failed to do anything
 

We're pretty much limited to updating the pwm outputs at the slow loop speed whether regular driver mode or autonomous. While there is the potential to update a few special pwm outputs at a faster rate, the devices attached to the pwm outputs, such as Victors, aren't designed to receive the updates very much faster than the current slow loop speed.

The Master processor enforces the playing field control overrides and filters our OI inputs as well as our pwm outputs, a la
When it has us disabled the Master "neutalizes" our pwm outputs, when it has us in autonomous mode the Master "neutralizes" the OI inputs it passes to us.

I conjecture that calling getdata() extra times will just return a copy of the last packet the Master prepared and I don't believe the Master does anything with extraneous putdata's until after NEW_SPI_DATA is reset to 1. You'd have to test that theory to be sure. In any case the response of the downstream systems such as the Victors, motors, and drivetrain will lag and swallow the milliseconds we might save.

To work properly PID feedback control depends on regular feedback not just speed and to make correct decisions needs previous decisions to be acted upon. It'll quickly lose track of things if the outside world is ignoring 99% of it's requests for motor changes and only acting on a random 1%.

Typically, use the fast loop of Process_Data_From_Local_IO to sample sensors, especially polled sensors, and collect data for use in making decisions later in the slow loop.
Your decision logic based on OI inputs or resulting in pwm outputs don't need to be made any faster than we can tell the Master processor via getdata/putdata.

The default code slow loop in main() is just used to kickoff the separate autonomous slow loop. The way the autonomous slow loop is coded doesn't allow anything else, including the main.c loop, to run again until the Master signals the end of autonomous mode. We eliminate the separate autonomous loop and only allow the main loop.

That's a valid theory and can easily be tested, but that would also mean printfs would not work anywhere in the fast loop for the same reasons. We still complain when we see people printf-ing from interrupts, but they get printouts.

Re: Printf has just entirely failed to do anything
 

Those "special outputs" are 13-16, right? The ones our code has to generate the PWM signal for?

OK. That makes sense, as setting an output to max for only 26.2ms outputs a pulse that barely tensions the chain, let alone moving the drivetrain. I just thought that polling the gyro really fast was a good idea, but I didn't realize how short 26.2ms is.

I knew this would be damaging to the algorithm if the victors weren't getting the updated signal, but I didn't think that they were only updated every slow loop. Now that I know this, I have a little more info on why our PID loop was so broken last year (it oscillated beyond control in about 3 seconds. I know how to tweak it now; I didn't then).

So you mean poll the sensors if I want an average over that 26.2ms instead of an instantaneous reading during the slow loop?

Oh, I forgot it was a separate loop. I ripped that out of last year's code, but in hindsight I could've left it just like it was. About the part that's bolded above: what do you mean? Do you mean that your team has ripped out the separate loop and let main() loop like normal?

Thanks
JBot

Re: Printf has just entirely failed to do anything
 

Yep. Be wary and stay away from them though. They don't work correctly as they are used in the default code. There is some extra work required for those. If you're interested a CD search will point you in the right direction.

Using the fast loop to poll the gyro is a really good idea, because you have to average the data to get a meaningful result.
Polling a pot on an arm usually isn't necessary, because it returns absolute position anyway.

Sounds like we had similar solutions. We didn't like a software design that took control away from the main loop.
One of the advantages of ripping the loop out of User_Autonomous_Code is that Process_Data_From_Master_uP and Process_Data_From_Local_IO continue to get called normally from main() without any extra work or duplication of effort. We add a few other improvements to main() such as initial delays to allow the systems and sensors to stabilize on powerup and automatically resetting autonomous on disable. It's nice that these changes apply to every mode and don't have to be implemented again for that autonomous loop.