Super twang, I honestly think you're over thinking the situation. It's good to try and cover all possibilities, but you're asking questions of people that have not answered specific questions that were answered by others already. There are several smart people on this group. Of which I'd like to count myself among them, but in my own case I know I do not think of everything. Which is why my buddy and I have talked at length on this subject trying to work everything out.
. . .And you know what, we missed something that thanks to Graham I'm thinking of now. A stale Ethernet connection is every bit as bad as a hung system. @Graham, What I propose is that you do not need an Ethernet Micro connected to the BBB. Instead, you have the BBB ping the outside world once every set time frame, and it a ping comes back unreachable after say 5-10 minutes. You just stop "kicking the dog". Which does present a potential problem that Your internet connection may just be down. But a remote system that reboots once every 5-10 minutes because the internet connection is down is not something I'd personally see as a bad thing. After all you're unable to connect to the system anyway. On Tue, May 17, 2016 at 12:12 PM, Graham <[email protected]> wrote: > Twang: > > You could look at the PIC32MX5xx/6xx/7xx series or PIC32MZ series. > The low end starts below $5, quantity one. They will need an external > Ethernet phi chip. > 32 bit MIPS core, program in C, full Ethernet stack available. > > If you want to experiment, get a PIC32MX starter card. > > Ti may have something equivalent on an ARM core. I just happen to be more > familiar with the PICs. > > --- Graham > > == > > On Tuesday, May 17, 2016 at 10:34:10 AM UTC-5, Super Twang wrote: >> >> @Graham >> I’ll have to experiment with this. Thanks for the suggestion! It is >> definitely a higher level approach that could be easier to piece together >> with low-cost OTS components. >> >> Do you have a specific PIC in mind? If not, I can dig around for a good >> one. Last time I used a PIC it was all assembly language, with no USB ICSP >> and a PC-only dev environment. Has that changed? (I’m developing from a >> Mac) >> >> Initially my thought was that it wouldn’t work for me because my device >> is designed to work while disconnected from a larger network (It is >> connected to a router broadcasting a private access point). But, there is >> nothing preventing me from connecting a switch to the router, and then the >> device and an auto-ping power control to the switch. My own little >> auto-ping network… Hmmm! >> >> ST >> >> >> On May 16, 2016, at 9:05 PM, Graham <[email protected]> wrote: >> >> Twang: >> >> Well, that is what the "Auto-Ping" is all about. >> >> If I don't get a ping from you in the last two minutes, then you get >> power-cycled/rebooted. >> >> There are IoT PICs that are ~$5 that can speak Ethernet and could be >> programmed to reset, or press the power button if 5V was present, and they >> had not heard from the BBB lately. >> >> More appropriate monitoring for a server, than watching some GPIO wiggle. >> >> --- Graham >> >> >> On Monday, May 16, 2016 at 8:08:01 PM UTC-5, Super Twang wrote: >>> >>> @Graham >>> Wow! I hadn’t yet thought of Ethernet as a point of failure. Apart >>> from the (“It doesn’t always soft-reset" issue — see outline I.B.1.b) I’d >>> guess you could solve this with the onboard watchdog timer. Run some kind >>> of daemon that periodically “Checks for good ethernet” (a bit vague, I >>> know), if found, it tickles the watchdog, if not, it provokes a reboot. >>> But yes, the problem remains that the reboot doesn’t always complete. >>> >>> Of course if your ethernet got fried, that’d turn into a reboot cycle >>> without some logic to notify you of the problem, and stop after a number of >>> cycles. >>> >>> >>> >>> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "BeagleBoard" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/beagleboard/RaFm9AT7-2c/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/20debbaf-a5a3-48e3-95a1-2984b714daf4%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/20debbaf-a5a3-48e3-95a1-2984b714daf4%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/73c0f3ff-43b7-433c-8a9a-783162c7fef8%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/73c0f3ff-43b7-433c-8a9a-783162c7fef8%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqPvrtMLD-QTgpKRoUyb0-QHjTwVVdeFFKNLJ%3DS2TGOwA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
