I started with the default camera code from Kevin Watson a few weeks ago, and I have been making my modifications happily–that is, until yesterday. First, I added two of my own files, which did all the camera calls, consolidating them into a single Camera Update function. Then, I pulled the camera update function calls out of user_routines.c and put my camera update function call into Process local IO. I had something like this working last week, but it refuses to send any bytes out the serial port now.
Things I have tried:
-tested my serial link. It is good-I can send programs down + read them back with device reader. I also see IFI> when I reset the bot
-tested with another RC. Same problem.
-unplugged camera TTL converter. Same problem
-Added printfs everywhere in my code. None of them work unless I comment out the #include for serial_ports.h (this breaks the camera functionality of course) And none of the printfs produce any output
-Replaced all the files that should never have been modified (serial_ports.c/.h, terminal.c/.h, camera.c/.h are the ones I overwrote with the ones out of Kevin’s code). No effect.
I’m bashing my head on the wall right now…please help!
JBot
PS. I will post the code tonight if you need it. I am using a school machine right now and don’t have access to my code right now.
I am using the stdio.h version where it won’t compile unless I #include <stdio.h>.
It "Code error"ed out when I commented out the includes for Kevin Watson’s serial port code. It worked then for about 5 seconds but it gave me a red light of death afterwards, presumably because I was bombarding it with tons of printfs.
Sorry, we’ve been racing robots all night. They’re having a pushing contest now.
Probably need to attach or email your whole project to look at.
It’s hard to guess what serial port resource conflict you might have. There are too many answers.
Definitely zip up the project, there are a number of people out here on “the internets” who will take a look and give you a hand. Not being able to debug over the serial port leaves you with few options. The “Red Light of Doom” is typically caused by the same things that would cause a Windows-type program to either crash, or it went into an infinite/extremely long loop somewhere. The infinite/long loop would be the first thing I’d carefully check for in your code, it’s easier to do than you’d think.
If you are indeed the lone programmer for your team (poor guy :yikes: ) you might want to force some code versioning on yourself. Things like CVS or SVN (check out wikipedia or google it yourself) CAN AND WILL SAVE YOUR BACON! It’ll allow you to easily step back in time before you screwed something up, and will also provide an easier time of multiple people working on the project at once. This way you can try training an interested freshman without fear of him making changes you can’t get rid of when your team leader asks you “is autonomous mode done yet?” :ahh: It takes some work to understand, but I promise (and every other user of some code versioning system will promise) it will be worth the effort.
I had the same sort of occurrence myself this week as I was trying to program one of the 2005 units.
Since you haven’t mentioned which controller you’re using this may not work.
If you have a 2005 CPU it’s likely using a 8520 pic, which needs the following environment changes in mplab:
From the Configure >> Select Device... menu choose "PIC18F8520"
as the pic type
In your project use the "FRC_library.lib" for the 8520
(mine is named FRC_library_8520.lib) -To keep my sanity I
renamed it in the same
fashion as last years revised
libraries and linkers were.
Also In your project use the "18F8520.lkr" for the 8520
NOW the last ingredient for success in restoring printf’s (in my case anyway)
Load the FRC_MASTER_V12.BIN and reload your first compiled code
(before all of your changes)
If you’re using a pre 2006 CPU it’s probably not been loaded with a FRC_MASTER_V12.BIN but an older version.
I’m just guessing (since it’s now gone) but ours was probably using the V11 master code as distributed in April 2005.
Once the master code was updated my printf’s worked fine (no more IFI> terminal freeze ups)
I’m not sure this is sound advice, I looked on IFIs website, and the latest update I see for a 2005 controller is v11. The v12 update is included with the 2006 controller code. This to me implies the update is built for the 2006 controller, and I’m not sure if it shares a master processor with the 2005. If it does share a master processor, it should work fine, but if they’ve changed them, such an update could make the RC…not work.
Does anyone know if the 2005 and 2006 controllers share a master processor model? Also did you actually do the Master version update on your 2005 controller? It’s a little hard to understand as you speculate the controller in question was running v11.
Thanks so much for suggesting CVS/SVN! I now have SVN set up on my machine, and I like the looks of it. It’s really cool to look at the diff of two versions of one file. I can see how this would be great at robotics.
Oh, I like being the lone programmer! Nobody to fight with over how the code will work! I’m trying to train a freshman, but otherwise I’m it.
Thanks again. You learn something new every day. If only I learned something this cool every day…
Could you add the following to timer_handler.c in the InitializeTimer() function?
PIE1bits.TMR1IE = 0;
Since you don’t have an interrupt handler for that timer, but you start it, it is wise to make sure it’s set to not create an interrupt. It might start out that way by default, but this is much safer. An interrupt that is generated but not handled can do very bizarre things.
If i understand your original post correctly, it stopped working when you moved the function calls into your abstraction files?
I noticed you did not call “Initialize_Camera()” in your abstraction file (or anywhere in your project). Try adding that to user_routines.c in the User_Initialization() function.
I’ll be sure to let you know if these work. I won’t be able to check until we get back (on the 4th I think). It’s nice to know someone cares enough to pull down someone else’s code to look at it. I wouldn’t have been as generous before FIRST…
Thanks,
JBot
EDIT: I was under the impression that Camera_Handler() in camera.c was supposed to be calling Initialize_Camera(), and it is as far as I know. I can call it manually, but depending on the flags set in camera.c, it does get called if camera comms aren’t working. Correct me if I’m wrong…
The last step for success (in my eliminating the IFI> prompt freeze up while adding in printf’s for my chosen variables) WAS the loading of the MASTER_V12.BIN from the 2006 default code.
You are absolutely correct when you mention that there is no explicit documentation of whether it’s appropriate to try this.
But where is your sense of adventure.
The fact that IFI was doing FRC controller processor upgrades from ver 8520PICS to 8722PICS,
and Kevin Watson was releasing all kinds of code with instructions on how to load user programs written as enhancements for the 2006 base code onto 2005 processors.
Surely, if it were fatal to the processor somebody would have noticed by now that loading the MASTER_V12.BIN shouldnt be done on a 2005 controller.
Anyway it works, my 2005 controller is happily running MASTER_V12.BIN and both the FRC Default code and OUR 1114-1503-1680 Common base code that were teaching our programmers with.
Perhaps I should have actually read the IFI site for instructions on how to confirm which Master code we were running before I scrapped it, but I did save the bin file for posterity using device reader.
The only guessing going on was if it was v 10 or v11 not whether or not I fixed the freeze up at the IFI> stage.
Bruce
PS Jacob, I looked at your environment (8722PIC, lib & lkr) and you don’t have the same printf freeze issue I had.
Hmm. I’m glad someone else did this experimentation. It would be an interesting experience, to say the least, describing to our team leader exactly why the most expensive component of the robot has become a paperweight.
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.
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.
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.
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?
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.
Killing the RC my first year on 358 would have left a bad first impression 