Well I've been using one of the three replacements I bought for a few days and haven't blown it up yet I'm going to blame it on the cheap Chinese breadboard power supply
solushun iz simple. give kat shrimpz an he wont chew wirez. no brainer.
-browz
If it was only that simple.
This cat has seemingly developed a plastic fetish.
Small cords seem delicious to her, however SP-1 or SP-2 extension cords and larger are not suitable to her palate.
As a precautionary measure EVERY cord that now enters our house, be it ours or belonging to a guest, gets coated with a liberal dose of Bitter Apple juice, as this seems to be the only deterrent to the chewing.
The destruction of last years Christmas tree lights, and the ensuing fireworks display only caused a momentary reprieve from the destruction.
LucyFURR has also determined that Zip Lock bags appear on the desert menu.
But being a cat she is a finicky eater, so the only portion of the bags she is interested in is the side with the zipper closure.
The solution to that problem seems to be Cat::~Cat()
Won't work, you will need something like:
#define CAT_LIVES 9
for (int i = 0; i < CAT_LIVES; i++)
{
c.Cat::~Cat();
}
Remeber to do that for all instance of Cat in you program, use delete on dynamally created Cats.
Of course those Cat instances may have spawned child Cat's that you won't be able to find so easily.
#define CAT_LIVES 9
for (int i = 0; i < CAT_LIVES; i++)
{
c.Cat::~Cat();
}
Remeber to do that for all instance of Cat in you program, use delete on dynamally created Cats.
Of course those Cat instances may have spawned child Cat's that you won't be able to find so easily.
Eight. Six Spin Stamps due to improper insertion into the BOE socket. One due to the catastrophic misapplication of 12V that also took out a PSC and LCD. One blew out all I/O pins (except to/from host) for some as-yet-to-be-explained cause. This prop executes fine, just no I/O except with the host. I named it "The Thinker".
No one has talked about a defective chips rate. As my project machines grow larger, for example with 150 chips, what can I expect in terms of chip failure per unit time? (specs not exceeded)
No one has talked about a defective chips rate. As my project machines grow larger, for example with 150 chips, what can I expect in terms of chip failure per unit time? (specs not exceeded)
I've never had a processor go bad. Once I burned a board from overclocking (a long slow cruel death, to be sure), once a regulator let the magic smoke out (Hey that board didn't have an LED there before!) but in both cases the board smoked and the processors were still good. In all other cases that boxes became obsolete and were removed from service before they could die. This is what I think you might expect from normal use, at least until presented with evidence to the contrary.
Comments
I own 3. One is used and will land on my car, 2 are for testing and learning. I give then a hard time
If it was only that simple.
This cat has seemingly developed a plastic fetish.
Small cords seem delicious to her, however SP-1 or SP-2 extension cords and larger are not suitable to her palate.
As a precautionary measure EVERY cord that now enters our house, be it ours or belonging to a guest, gets coated with a liberal dose of Bitter Apple juice, as this seems to be the only deterrent to the chewing.
The destruction of last years Christmas tree lights, and the ensuing fireworks display only caused a momentary reprieve from the destruction.
LucyFURR has also determined that Zip Lock bags appear on the desert menu.
But being a cat she is a finicky eater, so the only portion of the bags she is interested in is the side with the zipper closure.
Won't work, you will need something like:
#define CAT_LIVES 9 for (int i = 0; i < CAT_LIVES; i++) { c.Cat::~Cat(); }Remeber to do that for all instance of Cat in you program, use delete on dynamally created Cats.Of course those Cat instances may have spawned child Cat's that you won't be able to find so easily.
-browz
Ah yes, so we need some kind of recursive algorithm to remove them all:)
Ok, I laughed out loud.
There is a common thread in this thread. Most if not all chip failures have been caused by our abuse.
If you keep within the spec sheet limits one can expect actual failures to be vanishingly low. Just as low as any other micro.
If you need MTBF data you need to contact Parallax. They should have accelerated life test information.
Duane J
I've never had a processor go bad. Once I burned a board from overclocking (a long slow cruel death, to be sure), once a regulator let the magic smoke out (Hey that board didn't have an LED there before!) but in both cases the board smoked and the processors were still good. In all other cases that boxes became obsolete and were removed from service before they could die. This is what I think you might expect from normal use, at least until presented with evidence to the contrary.