Timer - 5 min on, 2 sec off

[maiksebben]

About the code, i had 2 different programmers look at the code, and they were not able to find anything wrong. But even if I fix the code let’s say, I would still keep this circuit, it’s a great feature that can act alone if there’s anything wrong with the RPI itself, or the SD Card, or the power supply... it’s not just the code. Obviously this circuit cannot fix a fried SD Card for an example, but many times a simple restart can resolve an issue.

I brought up the PIC subject because it was mentioned on this thread, and that member said, “it would be so much easier”, so I decided to ask.

I have a programmer for PICs, not sure if that’s what I need. If it really is easier, I wouldn’t mind doing the project all over, will be a good learning experience for me as well. Thanks.

 

[Pommie]

There's a thing called a Watch Dog Timer that does exactly this and is built into most (all?) Processors. Not used the Pi but would imagine using the WDT to fix randon crashes would be the way to go.

Mike.

 

[maiksebben]

10F322 <- link to a eval board.

Very interesting

 

[gophert]

Do you run into problems if the pi resets periodically. Why use an external circuit to do this?
You can simply put the line in ".profile" file under user pi..

at now + 10 days reboot

The "at" command creates a list of commands that are executed at various times in the future. You can also add right in the command to make any time you want. If you want it to happen at midnight, ten days from startup, use...
at midnight + 10 days reboot

It will start 10 days after the next midnight.

The one problem is, you need to check the "at queue" atq , to make sure a reboot command is not in the queue before adding another reboot. If so, you could get an "explosion" of reboots. The at command create the queue as a file saved to disk so even on restart, at commands are still present so a restart and execution of a .profile script will create a second reboot in the queue.

If this is an adequate path to a solution, you can also look at the other "execute in the future commands in Linux (Unix). Batch and Cron are some of them.

 

[maiksebben]

Do you run into problems if the pi resets periodically. Why use an external circuit to do this?
You can simply put the line in ".profile" file under user pi..

at now + 10 days reboot

The "at" command creates a list of commands that are executed at various times in the future. You can also add right in the command to make any time you want. If you want it to happen at midnight, ten days from startup, use...
at midnight + 10 days reboot

It will start 10 days after the next midnight.

The one problem is, you need to check the "at queue" atq , to make sure a reboot command is not in the queue before adding another reboot. If so, you could get an "explosion" of reboots. The at command create the queue as a file saved to disk so even on restart, at commands are still present so a restart and execution of a .profile script will create a second reboot in the queue.

If this is an adequate path to a solution, you can also look at the other "execute in the future commands in Linux (Unix). Batch and Cron are some of them.

Since the RPI freezes and will do nothing at that stage, I use this outside circuit to do a power restart, in order to put the RPI back in the air. I already tried many things, one was scheduling restarts, it doesn't help it, still freezes. When I say it freezes, I mean the RPI stops completely, like if the CPU halts and it does absolutely nothing anymore, until a power restart... adding commands for that purpose were unsuccessful. Weird thing is that, sometimes when the crash happens, it's idling, the machine is doing nothing at that moment. And at other times it's doing normal tasks. It freezes without making much sense, nobody yet has been able to explain why.
But since this circuit was born, it pretty much resolved the issue. I thought I could make it better by simply programming a single chip and eliminating most components on the PCB.