Posted by Chris Anderson on February 16, 2009 at 10:34am
Here's a Sparkfun engineering report on those last few boards that got out with incorrect fuse settings. Short form: the glitches from a few weeks ago should now all be gone:
"A small number of boards that did not have the correct fuse setting got mixed into the batch that are correctly programmed.
Currently, production is programming the correct fuses on all new builds. I am getting someone to go through our storefront stock right now to make sure the correct fuse settings are programmed.
So, all boards from now on will have the correct fuse setting and boards sent out after 2/5 that do not have the correct fuse setting should be minimal anyway.
Sorry for the confusion and we are sending new boards (hopefully with correct fuse settings now) to customers that have issues and do not have AVR programmers."
Hi Chris and Jordi,
First of all, congrats on this little gem you guys developed, it's got so much potential I want to learn code again just to see how far we can push this little board!
Ouuccchhhh! Just ordered mine yesterday! I hope I get a clean one without the fuse issues. I would hate to have to send it back. Crossing my fingers. I only ordered the board, breakaway connectors and USB FTDI.
The plan : Fit this little beauty in a 12 foot wingspan motorized sailplane and navigate a couple of waypoints with an HD camera filming and taking snapshots, controled via FPV goggles on a separated cam and laptop ground station. Once again, you guys rock for having put together something this small with such a huge potential. Kudos.
Olivier.
Do you know how it crashed, or what may go wrong? Division by zero, hang in a loop, or bad algorithm? Or even complete hang of chip (don't know if it's possible).
I'm thinking about alternatives - using AT168's watchdog timer, self-reset, or so.
You're a better programmer than we are! Our code crashed dozens of times in the air during development. We would have lost the plane each time if it hadn't been for the MUX. As far as I'm concerned, an autopilot development board (ie, one where you're supposed to mess with the code) without a failsafe is not just a bad idea, it's irresponsible and unsafe.
Personally I don't care, because I program both my ArtuPilots solely through AT168, including MUX control. Both of my boards seem to suffer by AT45 problems, but it's quite easy to make workaround in software.
I think that AP would be better without AT45 - smaller, less complex, cheaper. AT45 just makes one useful thing - setting multiplexer state. If I can do the same by main CPU, I don't need another CPU.
Ok, AT45 can also reset main CPU if it gets hung, but how often is it going to be used...
Comments
First of all, congrats on this little gem you guys developed, it's got so much potential I want to learn code again just to see how far we can push this little board!
Ouuccchhhh! Just ordered mine yesterday! I hope I get a clean one without the fuse issues. I would hate to have to send it back. Crossing my fingers. I only ordered the board, breakaway connectors and USB FTDI.
The plan : Fit this little beauty in a 12 foot wingspan motorized sailplane and navigate a couple of waypoints with an HD camera filming and taking snapshots, controled via FPV goggles on a separated cam and laptop ground station. Once again, you guys rock for having put together something this small with such a huge potential. Kudos.
Olivier.
I'm thinking about alternatives - using AT168's watchdog timer, self-reset, or so.
I think that AP would be better without AT45 - smaller, less complex, cheaper. AT45 just makes one useful thing - setting multiplexer state. If I can do the same by main CPU, I don't need another CPU.
Ok, AT45 can also reset main CPU if it gets hung, but how often is it going to be used...