power on/off question

57 views
Skip to first unread message

Scott Smallwood

unread,
Nov 26, 2011, 1:03:21 PM11/26/11
to Satellite CCRMA
Hey all,

So, I finally got my beagleboard project mostly up an running. It's
basically an audio game via PD, an arduino nano, some LEDs, and a
small amp/speakers.

I'm getting ready to stuff everything into a box. I'm not planning to
use any kind of display - I'm trying to keep things very simple.
However, I'm wondering about powering down. I was planning on just
using a simple on/off switch for the project. However, I realize that
this means I'm not properly shutting down the beagleboard via a "sudo
halt" command.

My question: Is this ok? If not, what kinds of approaches have been
used to deal with power on/off for embedded projects like mine?

Ideas/strategies welcome!

Philip Galanter

unread,
Nov 26, 2011, 1:23:12 PM11/26/11
to satelli...@googlegroups.com, Philip Galanter
One thing I've thought about (mostly hand waving here...not sure about the details) is having the arduino create a serial port terminal session into the beagleboard. A shutdown switch on the arduino would cause it to send the halt command to the beagleboard and then after some time interval turn off the power to both units.

If anyone gets such a thing to work, please share!

Phil

Scott Smallwood

unread,
Nov 26, 2011, 1:33:49 PM11/26/11
to satelli...@googlegroups.com, satelli...@googlegroups.com, Philip Galanter
Yeah, this is sort of what I was planning on doing... Except I think you could do the terminal commands from PD, and just have the arduino trigger it via a button push.

But what I'm wondering is: will a simple power off really hurt anything on the board? I'm not reading or writing any files, although I realize that linnux sure is...


--ss

Scott Smallwood

unread,
Nov 26, 2011, 1:38:56 PM11/26/11
to satelli...@googlegroups.com, satelli...@googlegroups.com, Philip Galanter
Oh this reminds me: is root on the CCRMA image using the same passwd as the CCRMA account default passwd? I imagine this will be easiest to do as root...


--ss

On 2011-11-26, at 11:23 AM, Philip Galanter <li...@philipgalanter.com> wrote:

Edgar

unread,
Nov 29, 2011, 12:01:33 AM11/29/11
to Satellite CCRMA, Philip Galanter
Yes it is the same!

BTW to switch to the root account (after logging in), you can now run
the command "sudo su" from the terminal.

Best,
Edgar

On Nov 26, 10:38 am, Scott Smallwood <ssmal...@ualberta.ca> wrote:
> Oh this reminds me:  is root on the CCRMA image using the same passwd as the CCRMA account default passwd?  I imagine this will be easiest to do as root...
>
> --ss
>

Edgar

unread,
Nov 29, 2011, 3:31:44 AM11/29/11
to Satellite CCRMA, Philip Galanter
Dear all,

I'm rewriting this message because it seems like it didn't go through
the first time.

I haven't ever observed any data loss from simply powering off the kit
without halting it first properly. However, theoretically it could
happen. There is a "disk" cache to optimize performance if the user is
constantly making small changes to files. When user software writes a
block to a file, it first gets written to the cache, which eventually
later gets cleared and written back to the micro SDHC card. So, if you
simply power off the kit, any blocks in the cache that haven't been
written back to the SDHC card could get lost. However, if you save
your pd patch, quit pd, and reload it and open the patch again and let
it run for a while, it seems to me that it could be well likely that
the pd patch has been written completely through to the SDHC card and
can't get lost with a simple power-off. In addition, other files on
the SDHC card could theoretically be affected, although I think that
the linux developers have improved linux to make it and its
filesystems more robust to simple-power offs. If you are concerned,
you can run the "sync" command in linux to flush the "disk" cache (see
"man sync").

If you want to be really, really safe:
Keep a backup of your important files on your laptop, and you can even
make your pd patch halt the kit cleanly (which you could trigger via a
switch using the Arduino<->pd connection as we do in the music 250a
class) if you follow these steps:
• Run "sudo chmod u+s /sbin/shutdown" to give all users access to run
the shutdown command on the Beagle.
• Use the "shell" object in pd to call "shutdown -h now" from pd at an
appropriate time. See the attached example pd patch for more details.

Best,
Edgar

#N canvas 753 121 386 296 10;
#X obj 102 81 shell;
#X obj 102 127 print STDOUT;
#X obj 129 104 print DONE;
#X msg 63 57 ls;
#X msg 102 57 shutdown -h now;
#X text 16 192 Either run pd as root \, or first run the command;
#X text 16 204 sudo chmod u+s /sbin/shutdown;
#X text 16 215 to give non-root users permission to run shutdown.;
#X text 11 11 How to halt the kit directly from pd...;
#X text 296 256 Edgar Berdahl;
#X text 296 270 11/28/11;
#X connect 0 0 1 0;
#X connect 0 1 2 0;
#X connect 3 0 0 0;
#X connect 4 0 0 0;

Scott Smallwood

unread,
Nov 29, 2011, 5:57:03 PM11/29/11
to satelli...@googlegroups.com, Philip Galanter
Elgar, et al,

Thanks for this - totally makes sense and works great. I basically just added a button and code that initiates shutdown if the button is held for more than 1 second. Easy as pie.

Thanks so much! I think this thing is done and working well now! I just need to find some more CPU cycles here and there to get rid of the last of the gliches (my code can probably be cleaned up a bit too). Are there any daemons running that I could disable without making it impossible to ssh back in? What are things ya'll generally turn off once a project has reached completion stage?

One other question: I've got two more boards and I'm going to continue working on some related projects, but I'm thinking of switching to SC instead of PD, as it seems likely that I can get more efficient code this way. Any thoughts on which language has been best to work with? I would use ChucK but it still can't talk to the serial port (easily) so...

Thanks again for all the help - I hope to integrate some of this into my class next term, and ya'll (CCRMA) have made things super easy with this build!

--ss

[ - ] - [ - ] - [ - ] - [ - ] - [ - ] - [ - ] - [ - ] - [ - ] - [ - ]

S c o t t S m a l l w o o d

composer, sound artist
faculty of arts, u of alberta

scott.s...@ualberta.ca
http://www.scott-smallwood.com
http://www.ecnedive.com

Edgar

unread,
Dec 2, 2011, 3:54:20 PM12/2/11
to Satellite CCRMA
On Nov 29, 2:57 pm, Scott Smallwood <scott.smallw...@ualberta.ca>
wrote:

> Thanks so much!  I think this thing is done and working well now!  I just need to find some more CPU cycles here and there to get rid of the last of the gliches (my code can probably be cleaned up a bit too).  Are there any daemons running that I could disable without making it impossible to ssh back in?  What are things ya'll generally turn off once a project has reached completion stage?
To save CPU cycles for now, I recommend switching to 22kHz audio
computations, or just making sure that you're writing patches
efficiently. One good tip is to develop them on the kit rather than
developing them on a laptop and then transferring them to the kit.

> One other question:  I've got two more boards and I'm going to continue working on some related projects, but I'm thinking of switching to SC instead of PD, as it seems likely that I can get more efficient code this way.  Any thoughts on which language has been best to work with?  I would use ChucK but it still can't talk to the serial port (easily) so...

AFAIK, languages will work best if they do vector signal processing
rather than sample by sample. This reduces the overhead of function
calls. I've been told that SC works quite well on the kit, but I'm
not an SC programmer myself, so I can't really attest to it.

One thing I've discovered is also that using the compile switches -O3 -
march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp speeds up
some patches in pd vanilla by 50%. I will recomile pd extended using
these switches in the next release of the image.

Finally, if you make Neon vector computation calls in C++ using
intrinsics, I've been told that this can speed up audio computations
by even 10x.

Best,
Edgar

Reply all
Reply to author
Forward
0 new messages