just use the bbb battery connector. it works fine then use a small micro for the watchdog/power monitoring my hardware does this and then after a power down cuts the battery with proper timing the bbb can stay up for ever
On 5/3/2016 4:54 AM, Yiannis Papelis wrote: > Fair enough. > > I think what I am leaning on doing is providing 5V directly to the > VDD_5V connector with a diode fused battery+external power through a > controllable regulator, and then using a tiny micro (most likely a > PIC) to monitor power loss and then trigger an interrupt on a pin to > cause the shutdown, then wait for the shutdown and then turn off > power. If power comes up during this process, the front end can halt > powering the BBB until it is fully down. > > I'll get a couple BBBs to experiment and if this works, I'll post what > I came up with. > > > On Tuesday, May 3, 2016 at 2:29:23 AM UTC-4, William Hermans wrote: > > /Everyone keeps using the same sentence "you're asking for > trouble" but without any more details on why that is the > case. I get the file system corruption issue, just wanting to > make sure there isn't anything else./ > > > I think Gerald already stated this, but I think it's worth > repeating. You can burn out the processor if pins are in certain > states and then removing power. I've been lucky myself and have > done this with no harm to the two beaglebones I have physical > access too. But several people here, on the groups have been > "bitten" by this. > > /I have used quite a few 'small micros', SBCs, DSPs with > anything from bare metal, VxWorks, Linux and all kids of > things, including a hardened laptop pretending to be a > stand-alone SBC. But that's not the point, most devices > targeting embedded computing aren't as fragile, or if they > are, they include embedded circuitry to ensure orderly > shutdown in case power is yanked, which is how you turn off a > stand-alone system. In my lab, we have several robots using > the Edison and logging process writing to SD card with no > external power management electronics other than a switch. > Over a couple of years of heavy use, there has been no issue./ > > > You can not compare the beaglebone to anything else out there. > It's that simple. Most things simply can not compare in cost, but > if they do; these systems can not compare in shear volume of > peripherals, or GPIO externally exposed. This is where most other > similar SBC's in the wild fail to compare. However, there are a > few, even in the same price range that do surpass this board as > well. They have other issues though . . . such as limited or poor > community software support, or other problems related to drivers, > or other such problems. Lastly, nothing in this price range have > anything like a PRU. > / > / > > /I have no problem handling this with external electronics > (although it tilts the cost-reward curve a bit), I am just > making sure that it is indeed necessary./ > > If you need bullet proof certainty. Then yes, it is necessary. On > both sides of power loss. Going, and coming. > > > > On Mon, May 2, 2016 at 3:55 PM, William Hermans <yyr...@gmail.com > <javascript:>> wrote: > > /As someone already posted, this is a bit more complicated > than that, but I get the idea./ > > > I did not see anyone other than you, I, and Gerald post on > your discussion here. But I do not get every post to this group.. > > But, sure . . . it is not as simple as that because while the > board is still being powered, a shutdown now -h will keep one > from being able to reset the board remotely. This applies to > being powered by battery too. > > In this case, where the board is being powered by a battery, > super cap, or whatever. You need an external "device" to break > VIN to the board. Or this would be a perfect example of why > having a hard reset tied to a test point, or header pin would > be beneficial. But we do not have this feature, so externally > is a must. > > As for the software. Everything is already in place except for > one small piece. A userspace app that monitors the systems > interrupts, particularly for the PMIC. Something similar to > acpid( a daemon ), or whatever you prefer. > > william@beaglebone:~$ cat /proc/interrupts > CPU0 > 16: 2671562 INTC 68 Level gp_timer > > . . . > > 179: 20 INTC 7 Level tps65217 > Err: 0 > > william@beaglebone:~$ cat /proc/irq/179/spurious > count 0 > unhandled 0 > last_unhandled 0 ms > > > Is pretty straight forward, and obvious. Things get a bit more > complex, and interesting where the external solution is > concerned. It is solvable though, we have solved it. > > On Mon, May 2, 2016 at 11:55 AM, Yiannis Papelis > <ypap...@gmail.com <javascript:>> wrote: > > As someone already posted, this is a bit more complicated > than that, but I get the idea. > > On Monday, May 2, 2016 at 2:09:44 PM UTC-4, William > Hermans wrote: > > /Use a super capacitor./ > > > Ok, a little abstract . . . > > Use a super capacitor, and if using a console image . > . . sudo apt-get install acpid > > Then the board will automatically shutdown when 5V > input goes missing. I'd make sure you pick a super cap > that can sustain the beaglebone for ~30 seconds, even > if not needed. Just in case. Typically though, here, > we see that the board shuts down within 5 seconds or > so. Maybe slightly longer. > > On Mon, May 2, 2016 at 10:47 AM, William Hermans > <yyr...@gmail.com> wrote: > > /I have been building embedded systems for a > while now and I am considering using the > beaglebone (BBB) for an upcoming project, but > I am confused by everything I read regarding > the shutdown requirements. As an embedded > system the only way to turn it off is to > simply shutdown the power with a switch, yet > my preliminary research indicates that this is > a no-no as it may damage the BBB and/or > corrupt the file system. I also read a lot of > comments regarding voltage on the pins after a > shutdown; in my case, very likely there will > be a CAT5 cable with live activity connected > even after power down; assume the magnetics > should protect the BBB, but just checking./ > > > This is true of any system running an OS that is > not red only. If you unceremoniously yank the > power, you're asking for trouble. > > /I have used quite a few micro controllers and > various self-standing systems, but am fairly > new to the BBB - still mostly reading about > it. Am I missing something? How can a device > meant to be used in embedded systems not be > tolerant of power loss and be so finicky about > power?/ > > > It sounds like you're missing a lot. It sounds > like you've had a lot of experience with small > micros, that run bare metal, but have have no, or > limited experience with using an embedded OS. > > Then if you stop and think of the cost of this > board, and what the goal of beagleboard.org > <http://beagleboard.org> was when the board was > created. Perhaps then it become clear as to how / > why we're where we are in this context. You can > fix all of this yourself, using external hardware, > and custom software. > > / > / > /By the way, I can see there is a battery > backup circuit but I do not want to use a > lithium battery for safety/temperature/cost > reasons. Using a large capacitor also seems > tricky as the shutdown may take a few seconds > so I don't see how that will work./ > / > / > > /Any suggestions would be greatly appreciated./ > > > Use a super capacitor. > > > > On Mon, May 2, 2016 at 8:39 AM, Gerald Coley > <ger...@beagleboard.org> wrote: > > > > On Mon, May 2, 2016 at 10:36 AM, Yiannis > Papelis <ypap...@gmail.com> wrote: > > I have been building embedded systems for > a while now and I am considering using the > beaglebone (BBB) for an upcoming project, > but I am confused by everything I read > regarding the shutdown requirements. As an > embedded system the only way to turn it > off is to simply shutdown the power with a > switch, yet my preliminary research > indicates that this is a no-no as it may > damage the BBB and/or corrupt the file > system. I also read a lot of comments > regarding voltage on the pins after a > shutdown; in my case, very likely there > will be a CAT5 cable with live activity > connected even after power down; assume > the magnetics should protect the BBB, but > just checking. > > I have used quite a few micro controllers > and various self-standing systems, but am > fairly new to the BBB - still mostly > reading about it. Am I missing > something? How can a device meant to be > used in embedded systems not be tolerant > of power loss and be so finicky about power? > > By the way, I can see there is a battery > backup circuit but I do not want to use a > lithium battery for > safety/temperature/cost reasons. Using a > large capacitor also seems tricky as the > shutdown may take a few seconds so I don't > see how that will work. > > Any suggestions would be greatly appreciated. > -- > 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 > beagleboard...@googlegroups.com. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/beagleboard/4b2dc307-631d-405d-88d6-7537adb3ac29%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/4b2dc307-631d-405d-88d6-7537adb3ac29%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit > https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > > Main reason for the shutdown process is the > corruption of the Linux file system. > > If you have power on any signal when the > processor is shutdown, then you are asking for > trouble. > > > http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Pin_Usage > > <http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Pin_Usage> > > > Gerald > > ger...@beagleboard.org > http://beagleboard.org/ > gco...@emprodesign.com > > -- > 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 > beagleboard...@googlegroups.com. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BergZ8%2BPd5zBdxsHqJDzQphgPXKXF0oayzjV1PVHPY8kw%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BergZ8%2BPd5zBdxsHqJDzQphgPXKXF0oayzjV1PVHPY8kw%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > > For more options, visit > https://groups.google.com/d/optout > <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 beagleboard...@googlegroups.com > <javascript:>. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/beagleboard/20708452-03c7-4c66-9e22-bd0cdd009806%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/20708452-03c7-4c66-9e22-bd0cdd009806%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > For more options, visit https://groups.google.com/d/optout > <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 beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/716c3ab5-5ea6-40c8-96d2-2c60b5077a2a%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/716c3ab5-5ea6-40c8-96d2-2c60b5077a2a%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/394d5095-aeff-6487-e271-8b148766656d%40gmail.com. For more options, visit https://groups.google.com/d/optout.