Shop OBEX P1 Docs P2 Docs Learn Events
WiiCamera Object Causes Resets? — Parallax Forums

WiiCamera Object Causes Resets?

edited 2011-02-24 15:39 in Propeller 1
I am using a Wii Camera via i2c and the wiicamera.spin object. I am quite happy with my results and the numbers coming from the camera. I am almost able to "dock" my robot solely off the camera, without the need for any of his sonar sensors.

The issue I have it seems, are spontaneous resets when the wiicamera object is "running". If I start and "init" the object, the whole darn chip will reset itself every minute. Almost exactly a minute, actually. It resets, and gets right back to working like nothing happened.

Back info:
I stripped the code to bare bones for "testing" of this problem.
I have 3-4 cogs running with a ton of head-room in terms of stack:

*main routine
*TV
*One robot-related cog that had to be left in to get the main routine to compile
*The wiicamera opens its own cog

The robot-related cog includes a poor-man's timer that keeps an eye on the cnt and increases a variable called "seconds" --not accurate but I use it to time different modes and "personalities" of the robot. The TV object is the ORE_TV_TEXT_009 object. I am using the Prop Board USB from Gadget Gangster. I think that's it. Any thoughts?

Comments

  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-02-24 11:33
    I'm trying to get a generic Wii camera to work right now. It's different than the original.

    Could you post your code? I'll take a look at it.

    If it's reseting after one minute is seems like it has to do with the system counter rolling over and causing a problem.

    Duane
  • RaymanRayman Posts: 14,886
    edited 2011-02-24 11:38
    Just 'cause it's been on my mind... You're not running "fullduplexserial" for debugging with the USB cable disconnected are you?
    I think that's been known to power up the FTDI USB chip and cause a spontaneous reset...
  • edited 2011-02-24 13:49
    No FullDuplexSerial. I am running a couple simple serials but that's it. At any rate, here is the whole code. Please ignore my mess --this particular chunk of code has not gotten to the "tidy up" stage for a while. Hmm... New to the forum here... How do I do that nifty little box that you put your code into? Hmmm. Sorry guys, I guess it is an attachment for now. Ignore it's name --it is an unrelated issue that has since been fixed. Navigation 15 fixing ez-1s.spin
  • RaymanRayman Posts: 14,886
    edited 2011-02-24 14:26
    I took a quick look and my first suspect would be the stack sizes... Looks like you've been experimenting with them. But, I'd try a 100 long stack size for all your cognews and see if that changes anything...
  • edited 2011-02-24 14:30
    Will do. I am a picaxe/ arduino convert so calculating stack space is not quite second hand yet. I thought I had done my math right, with quite a bit of room to spare. And yes, I have experimented with them in the past. Trimming each cog's stack until it fails, then adding 10 or 15 longs back on. I will give it a shot.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-02-24 14:47
    Chris The Carpenter,

    An attachment is better than having your code in a code block. [CODE ]code you want in the block [ \CODE] but without the spaces is how to have your code display correctly. It's best to use code blocks for small bits of code. It's a lot easy to download an attachment than to try to cut and paste code from the blocks.

    The Propeller Tool has an archive feature File\Archive\Project. By archiving your project, we don't have to track down all the objects you are using. I might be nice enough to take a look at someone else's code, but I'm not so nice as to hunt down all the objects it uses.

    When I've had trouble with some code, I've tried to pare it down to just the code causing the trouble. The act of simplifying the code has lead me to find the problem myself without ever having to post it. You don't have to do this, I'm just letting you know what I've done.

    This looks like a really cool project. I hope you share some pictures and/or video of it.

    By the way, welcome to the forum.

    Duane The Chemist
  • edited 2011-02-24 15:03
    Couldn't be that simple... I uncommented everything, let all 7 cogs run including the wiicamera, with each cog's stack space increased to 100 longs. Seems solid as a rock now. Don't get me wrong, I am quite happy that Walter the Robot is back up and running, this just seems too easy --and something I should have caught/tried/figured out. Alas, can't look a gift horse in the mouth, I guess. I appreciate your time, guys. It does seem my sonar lock-up is back however, but I am not going to put too much stock into this one --It has been problematic in the past, I thought I had it fixed, I guess not. --Just put it on the "to fix" list, I guess. Still surprised my little time-out is not kicking in. (It's in ticks2) --It should be a "get outta here" after 100ms... Gotta do some testing...

    Oh, I tried an after-market wii camera with much frustration and no results. I tried different pin-outs, different frequencies for the clock feed, different levels of pull-ups on i2c and reset, etc. No go. --It was a Nyko "Wand" from Radio Shack and I tried it via Prop and Arduino, BTW.

    Oh, and Walter is here. And I just started building a "Little Buddy" for him as well. The whole "wiicamera" thing is partially so Walter and his "Little Buddy" can play a little follow-the-leader and hide-and-seek.

    Thanks again, folks.
  • RaymanRayman Posts: 14,886
    edited 2011-02-24 15:39
    Wow, am I 2 for 2 today?

    Stack size problems are very common...
    With complex code, it's very hard to know how much you need.
    100 longs seems enough for most things though.
Sign In or Register to comment.