connecting R Pi to a usb port on a monitor or projector?

Hello Doug, i'm not much of an expert, but multiple unclean shutdowns sound like a way to end up with a corrupt OS.

How often will the device be powered up and down I think is the key here?

Steve

Given that these would be connected to classroom projectors they would be shut down anywhere from 6 to 20 times a day.  We're need to see if we can monitor the projector/monitor serial port and shutdown the system properly.

Doug, hopefully one of the ones more versed in Electrical Engineering  and Linux will be along soon to tell me I'm talking rubbish, but doing a cold shutdown like that up to 20 times a day sounds like a sure fire way to end up with a corrupt file system fairly quickly. As for damage, I don't think it may do it harm in the short term, but could possibly shorten the life expectancy. Heating an cooling repeatedly will tend to shorten the life of anything like that, a constant temperature is more gentle.

I think I have more questions than answers:

1. What is the purpose of connecting the RPi to the projector/monitor? Is it to transfer data or is it just for power?
2. If this is going to be part of an emergency notification system that should always be ON, how is it that you are worried about exessive power cycling?

Thanks, Salvador

Classroom projectors/displays are never left on when there is no class in the room.  Faculty are instructed to turn off the projectors/displays after every class. We're planning to connect the video output of the Pi to a spare input on the displays and use the room control system to trigger either switching the video source or turning on the display then switching.  Initially we'll have the Pi put out a static message alerting viewers that there is an emergency.  Ultimately we hope to write a script that would capture the text from our emergency alert system and display that info on the display. 

Thanks Doug. I see now. The USB is mostly for power and the video is to display the message. There are devices out there now that have Linux and are safe to turn ON and OFF at any time. One such device that I can think of is the Insignia Infocast 3.5". You can Google the phrase embedded linux for more specifics on this.

Also, making note of the list of OSes that have been ported to the RPI I have no doubt that you'll be able to configure any one of them in such a way as to avoid the possible pitfall of data corruption due to turning the device OFF at an un expected time. Perhaps one design decision will to selectthe most appropriate OS/distribution for this project. Hopefully some one with this knowledge will chime in. Regards, Salvador

Hello Doug,

Have you tried to make the root partition read-only and mount /var to a seperate partition that get rewriten/extracted at each boot?

What i know of Linux is that the programs does not tend to write in their directory unless there is a configuration change and all the volatile data that keep on changing goes in /proc and /var.

/proc is a directory that get mounted on each boot and it is a virtual link to the internal processes.

/var contains directories mostly that many programs expect to find to store runtime data like spools.

Even though ext4 is a really robust journalled filestore, just turning off a *nix system at the power switch rather than with a proper shutdown is asking for trouble.  When the system is quiescent then most of the time ext4 recovers cleanly on next boot, but one day it won't.  You should really avoid doing so.

If such use is unavoidable, I suggest that you plan for it by appropriate system design.  This is actually a fairly common situation, and various solutions are available and well known.  Typically:

1) Protect your /boot partition by keeping it normally unmounted in /etc/fstab:

/dev/mmcblk0p1        /boot        vfat        noauto,noatime      0 0

2) Make your root (/) filestore read-only.  See http://wiki.debian.org/ReadonlyRoot

3) Use network storage for everything that must be continually writeable, for example using NFS.

Given these 3 changes, turning off the power arbitrarily shouldn't matter as far as software is concerned.

Of course hardware issues are a completely different kettle of fish.  Even in the absence of power spikes or unexpected power sequencing as things are turned on or off, the lifetime of hardware is almost always reduced by daily power cycling, and if it's done after every class then I strongly suspect that your equipment will last a shorter time than it otherwise might.  I think you'll have to consider the pros and cons here carefully.

Morgaine.