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!
If anyone gets such a thing to work, please share!
Phil
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
--ss
On 2011-11-26, at 11:23 AM, Philip Galanter <li...@philipgalanter.com> wrote:
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
>
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;
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
> 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