Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
On Saturday 16 January 2016 15:07:26 Ralph Corderoy wrote: > Paraphrasing your description, I get > > 00:00 Start sun lamp PWM from 10% to 90%. > 00:30 Switch off house lights; it's dawn. > 04:30 Start sun lamp PWM from 90% to 10%. > 05:00 Switch on house lights; it's dusk. > 09:00 Goto 00:00. > > Is that right? It seems regimental. You might want the house lights, > which are only simple on and off, to be controlled in several batches, > perhaps even independently. If there's not enough GPIO to do that, then > a few shift registers would do since you've ample time to shift out the > current state again, with only one light changing, and latch that. > Also, house lights, unlike street lights, don't stay on all night, etc. > You could have a bit of randomness used too. And when dawn breaks, it's > not linearly between 10% and 90% duty cycle, I think, but slow to start > with? At present, we only have three 'wire-ends' to control; Houses LEDs, Bulbs and the Daylight floods. We can therefore do that with three GPIO pins and suitable interfacing electronics; relays for the Houses and Bulbs and a MOSFET driver for the Daylight floods. If we decide to control more individual lights and add more variability, we would simply update the program to add support for more GPIO pins. > The Zero has hardware PWM, two of them IIRC, though I think one maps to > a pin used for audio, but you're not needing that. So if you were to > use those then you'd be spared the software overhead. > > It also has hardware DMA where you give it a wave table, in effect, how > long each run of 0 or 1 should last, and it does the timing and > transitions, so you could use that maybe on other GPIO pins. I think it > can also be used to drive the PWM! IOW, the DMA writes to the PWM's > control bytes to change the settings on schedule. Lots of > possibilities. Or just stick to software bit-banging of GPIO. I've been playing around with software PWM in Python, using RPi.GPIO and there is a another library called RPIO, which does a kind of hybrid hardware/software PWM using something like the DMA you mention to reduce the CPU overhead, but I haven't tried it yet. (RPIO is written as C Library, so that may be the way to go). I haven't found any examples or documentation that supports the hardware PWM capability built in to the Broadcom device yet. I'd like to, because that seems the obvious route, especially since we only really need one PWM channel. Making certain assumptions about how this works (and what I would do if I was designing it), I would expect to be able to program the pin to provide a certain value of PWM and then do something else while the pin got on with it; exactly what we want. > As for multithreading, beware Python's Global Interpreter Lock. :-) And > do you really need it? Let's say you've really only got two outputs; > the sun lamp, and the house bulb. The former needs PWM, the later is > binary. Your code could just run through a data table telling it what > to do to these two outputs. > > label sun house ticks > 0 01 9 # 10% duty cycle for sun. > 1 11 1 > 2 repeat 10 times: goto 0 > 3 01 8 # Now 20% duty cycle. > 4 11 2 > 5 repeat 9 times: goto 3 > ... > 24 01 1 # Finally, 90% duty cycle. > 25 11 9 > 26 repeat 3 times: goto 24 > 27 10 420# Daytime. > ... Wouldn't that vastly increase the CPU overhead? If I've understood your idea correctly, each line would have to represent the state of each pin in 10 ms steps to generate a 100 Hz PWM. I can see how you would interleave the right values for the Houses and Bulbs channels during the generation of that 100 Hz square wave to negate the need for multithreading, but at what cost? Or have a misunderstood the way that RPi.GPIO does it; maybe the library is generating code to do pretty much what you've described (without the opportunity for interleaving). At the moment, I'm finding it difficult to see how the house lamps could be left running (at some intermediate PWM value) while the other lights are switched on / off, other than your table, multithreading or my hypothetical PWM pin capability. > > So if I wanted to use Python, then I would have to ensure that those > > files are available in the running system? > > Well, yes, though a Tiny Core installation of Python would have done > that for you. The main reason that I picked on Tiny Core is because I've never created any kind of Distro other than that. We did a project at work which involved creating a distro that would boot at switch on and use hwinfo to read all the physical data about the machine into a file. It took me a while to work out what to do, so I rather thought it would be sensible to do the same sort of thing. --
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
On Sunday 17 January 2016 09:25:58 Terry Coles wrote: > I've been playing around with software PWM in Python, using RPi.GPIO and > there is a another library called RPIO, which does a kind of hybrid > hardware/software PWM using something like the DMA you mention to reduce > the CPU overhead, but I haven't tried it yet. (RPIO is written as C > Library, so that may be the way to go). The good news is that I now have the lights sequence working perfectly in Python. It turns out that PWM switching doesn't stop when the Houses and Bulbs lights are being switched, so no multi-threading is needed. So. All I need to do between now and when the hardware arrives is work out the best way to prevent SD corruption from all the suggestions, I've received. I think that it probably comes down to a minimal Tiny Core distro with the Python code launched at boot-up, but I have plenty of time to change my mind :-) -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
Hi Terry, > I haven't found any examples or documentation that supports the > hardware PWM capability built in to the Broadcom device yet. Try Google with "Raspberry Pi Hardware PWM". It turns up things like http://www.hertaville.com/rpipwm.html for me. Basically, you map the addresses containing the memory-mapped PWM registers into your process's address space using /dev/mem, and then POKE them. > I would expect to be able to program the pin to provide a certain > value of PWM and then do something else while the pin got on with it; > exactly what we want. The Broadcom datasheets for the SoC will give that detail if the libraries you're using don't. > > Your code could just run through a data table telling it what to do > > to these two outputs. > > > > label sun house ticks > > 0 01 9 # 10% duty cycle for sun. > > 1 11 1 > > 2 repeat 10 times: goto 0 > > 3 01 8 # Now 20% duty cycle. > > 4 11 2 > > 5 repeat 9 times: goto 3 > > ... > > 24 01 1 # Finally, 90% duty cycle. > > 25 11 9 > > 26 repeat 3 times: goto 24 > > 27 10 420# Daytime. > > ... > > Wouldn't that vastly increase the CPU overhead? Compared to hardware PWM, yes, but you started off talking of software PWM and waggling GPIO lines IIRC, e.g. RPi.GPIO. :-) And a lot of the time would be a sleep for the remainder of the tick. > I can see how you would interleave the right values for the Houses and > Bulbs channels during the generation of that 100 Hz square wave to > negate the need for multithreading, but at what cost? I was thinking the sun's PWM becomes 0 or 100% for the bulk of the day, but considered the alternative when I said If you've house lamps changing during sun PWM, then two tables that you walk through in parallel could define each separately to avoid one interfering with the definition of the other. >From the later emails, you wrote: > > I've been playing around with software PWM in Python, using RPi.GPIO > > and there is a another library called RPIO ... > It turns out that PWM switching doesn't stop when the Houses and Bulbs > lights are being switched, so no multi-threading is needed. If you look at the code for RPi.GPIO https://sourceforge.net/p/raspberry-gpio-python/code/ci/default/tree/source/soft_pwm.c you'll see it uses POSIX Threads, AKA pthreads, one per soft PWM that's running, and toggles GPIOs and sleeps, much like running through the compile-time table above. So multi-threading is being used, though the Zero has only one core, of course. A bit of a closer look suggests the code, whilst probably "good enough" has some odd corners. full_sleep() needlessly uses recursion to cope with nanosleep(2) being interrupted. None of the contents of the struct pwm are locked for mutual exclusion, or marked volatile, e.g. the thread running a PWM keeps checking p->running to know when to stop, and another thread sets it false in pwm_stop(). Similarly, changing the duty cycle, etc., all twiddle with multiple numbers in the struct whilst they're being used by the PWM thread. Glad to hear you've got it going. :-) Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
On Sunday 17 January 2016 14:08:16 Ralph Corderoy wrote: > Hi Terry, > > > I haven't found any examples or documentation that supports the > > hardware PWM capability built in to the Broadcom device yet. > > Try Google with "Raspberry Pi Hardware PWM". It turns up things like > http://www.hertaville.com/rpipwm.html for me. Basically, you map the > addresses containing the memory-mapped PWM registers into your process's > address space using /dev/mem, and then POKE them. :-) Whilst I've no doubt that it is lighter on the processor it definitely doesn't seem KISS to me. As mentioned earlier, one of the Requirements that we've laid on ourselves is that the system be maintainable by someone who is not really a software developer (remember I wasn't a software engineer; I was a systems engineer and before that an applications engineer). Suitable candidates might be a hobbyist (or maker as they're called now) or someone who has completed the latest ITC curriculum, which includes enough to program in Python. That's one reason why I was keen to use Python. > From the later emails, you wrote: > > > I've been playing around with software PWM in Python, using RPi.GPIO > > > and there is a another library called RPIO > > ... > > > It turns out that PWM switching doesn't stop when the Houses and Bulbs > > lights are being switched, so no multi-threading is needed. > > If you look at the code for RPi.GPIO > https://sourceforge.net/p/raspberry-gpio-python/code/ci/default/tree/source/ > soft_pwm.c you'll see it uses POSIX Threads, AKA pthreads, one per soft PWM > that's running, and toggles GPIOs and sleeps, much like running through the > compile-time table above. So multi-threading is being used, though the > Zero has only one core, of course. Yes. I'm running it on the RPi 2 at the moment, because my Zero has no header connector on the GPIO pins yet. When I try this with a Zero the story may change, in which case we could upgrade to the Pi 2. Anyway, I had the sequence running for much of this morning while I was monitoring the processor temperature every 30 s. There was not a noticeable rise in temperature, until I ran apt-get update and update, when it rose by one degree. > A bit of a closer look suggests the code, whilst probably "good enough" > has some odd corners. full_sleep() needlessly uses recursion to cope > with nanosleep(2) being interrupted. None of the contents of the struct > pwm are locked for mutual exclusion, or marked volatile, e.g. the > thread running a PWM keeps checking p->running to know when to stop, and > another thread sets it false in pwm_stop(). Similarly, changing the > duty cycle, etc., all twiddle with multiple numbers in the struct whilst > they're being used by the PWM thread. I suspect we can live with that. > Glad to hear you've got it going. :-) So am I. The bug was obvious once I spotted it but it took a while :-) -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
On Saturday 16 January 2016 08:12:37 Terry Coles wrote: I see that the mailer munged my sequence and made it a bit incomprehensible. Here it is again with each step separated out: Code will be written in Python or C and will implement the following functions in the sequence: 1 Brightening of the 'Daylight' Lamps to simulate dawn. This will use a PWM function with a range of nominally 10 % to 90 % of full brilliance. The nominal time between 'Night' and 'Day' will be 30s. It will be possible to set the timing and the range during development and subsequent upgrades. 2. At 'Dawn' switching off of the 'House' and 'Bulb' Lamps. 3. A 3 to 5 minute delay. It will be possible to set the delay during development and upgrades. 4. Dimming of the 'Daylight' Lamps to simulate dusk. This will use a PWM function with a range of nominally 90 % to 10 % of full brilliance. The nominal time between 'Day' and 'Night' will be 30 s. It will be possible to set the timing and the range during development and subsequent upgrades. 5. At 'Dusk' switching on of the 'House' and 'Bulb' Lamps. 6. A 3 to 5 minute delay. It will be possible to set the delay during development and upgrades. The above functions will loop continuously until a break is detected or the power is removed. Re-iterating my point from the original message, I think that I will need to use multi-threading to keep the PWM going while the delays time out and the House and Bulb lamps are switched. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
Is there one Pi Zero doing all the lights, or will there be several, coordinating? Paraphrasing your description, I get 00:00 Start sun lamp PWM from 10% to 90%. 00:30 Switch off house lights; it's dawn. 04:30 Start sun lamp PWM from 90% to 10%. 05:00 Switch on house lights; it's dusk. 09:00 Goto 00:00. Is that right? It seems regimental. You might want the house lights, which are only simple on and off, to be controlled in several batches, perhaps even independently. If there's not enough GPIO to do that, then a few shift registers would do since you've ample time to shift out the current state again, with only one light changing, and latch that. Also, house lights, unlike street lights, don't stay on all night, etc. You could have a bit of randomness used too. And when dawn breaks, it's not linearly between 10% and 90% duty cycle, I think, but slow to start with? I was wondering about the complexity of it, and the ability to use a random generator to switch the house lights randomly during dusk, and also to control house lights seperately from other street lights which might stay on all night. This strays from Terry's KISS, but could be thought of as a second generation project? Peter -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
Hi Terry On 16/01/16 08:12, Terry Coles wrote: So you are saying that the above sequence would simply be a script at the end of init? I'm not sure if that could be done in bash, because I'm thinking that to keep the PWM going while the other lights are being processed, I'll need to use multithreading, hence the use of a reasonably capable device (eg Pi instead of Arduino) and a reasonably capable language such as Python or C. I'd suggest avoiding Linux at all as it's just an inconvenient complication for this application. There's a gcc project specifically for Arm embedded: https://launchpad.net/gcc-arm-embedded Here's some more info: http://www.valvers.com/open-software/raspberry-pi/step01-bare-metal-programming-in-cpt1/ As to processor power, hardware PWM is pretty much a given on any embedded application processor over the last 30 years and even if you have to do it in software, a 5kHz interrupt rate will give 2% resolution at 50Hz. For any processor running at more than a few MHz that's no problem if there isn't much else to be done. You certainly don't need don't need multitasking here but but if you did then again that's readily available for a wide range of processors from very modest 8-bitters upwards (FreeRTOS, Atomthreads etc). Cheers Tim -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
Hi Terry, > > I was thinking your program would need *no* required code to support > > execution, i.e. a statically linked executable, and no programs to > > have run before hand to set anything up, e.g. networking, the date, > > hostname, logging, etc., and thus could be init, and never kick off > > any other programs. > > So you are saying that the above sequence would simply be a script at > the end of init? init is the program run by the kernel when it's finished initialising. It gets PID 1. Here's it's /sbin/init. There's a kernel parameter called `init' that can be set on the boot command line, e.g. from grub's menu, so one can do `init=/bin/sh' to be presented with sh's prompt instead with none of the normal user-space stuff initialised, e.g. networking, and without being prompted for a password, since that's not the kernel's job, but login(1)'s. Since the kernel creates whatever's init's process as user root, it's all powerful, and is useful to repair loss of root's password, for example. If an executable file starts with `#!' then the kernel takes the rest of the line as the program to run that file, thus an /sbin/init starting `#! /usr/bin/python' should result in `/usr/bin/python /sbin/init' being run. (I haven't tried it. :-) > > Is there one Pi Zero doing all the lights, or will there be several, > > coordinating? > > I don't think it had occurred to us that we might need more than one. > Do you believe that there is a benefit in having two or more? Or that > we might need several? I assumed it would more depend on what electronics you need to drive, including position and wire lengths, and how that fits with the Zero's interfaces. More than one introduces the synchronisation problem I mentioned. :-) Paraphrasing your description, I get 00:00 Start sun lamp PWM from 10% to 90%. 00:30 Switch off house lights; it's dawn. 04:30 Start sun lamp PWM from 90% to 10%. 05:00 Switch on house lights; it's dusk. 09:00 Goto 00:00. Is that right? It seems regimental. You might want the house lights, which are only simple on and off, to be controlled in several batches, perhaps even independently. If there's not enough GPIO to do that, then a few shift registers would do since you've ample time to shift out the current state again, with only one light changing, and latch that. Also, house lights, unlike street lights, don't stay on all night, etc. You could have a bit of randomness used too. And when dawn breaks, it's not linearly between 10% and 90% duty cycle, I think, but slow to start with? > I'm not sure if that could be done in bash, because I'm thinking that > to keep the PWM going while the other lights are being processed, I'll > need to use multithreading, hence the use of a reasonably capable > device (eg Pi instead of Arduino) and a reasonably capable language > such as Python or C. The Zero has hardware PWM, two of them IIRC, though I think one maps to a pin used for audio, but you're not needing that. So if you were to use those then you'd be spared the software overhead. It also has hardware DMA where you give it a wave table, in effect, how long each run of 0 or 1 should last, and it does the timing and transitions, so you could use that maybe on other GPIO pins. I think it can also be used to drive the PWM! IOW, the DMA writes to the PWM's control bytes to change the settings on schedule. Lots of possibilities. Or just stick to software bit-banging of GPIO. As for multithreading, beware Python's Global Interpreter Lock. :-) And do you really need it? Let's say you've really only got two outputs; the sun lamp, and the house bulb. The former needs PWM, the later is binary. Your code could just run through a data table telling it what to do to these two outputs. label sun house ticks 0 01 9 # 10% duty cycle for sun. 1 11 1 2 repeat 10 times: goto 0 3 01 8 # Now 20% duty cycle. 4 11 2 5 repeat 9 times: goto 3 ... 24 01 1 # Finally, 90% duty cycle. 25 11 9 26 repeat 3 times: goto 24 27 10 420# Daytime. ... When the end of table is reached, start again at the beginning. The table definition could be in the source code, edited by hand, but it might be easier to have it produced by another program. That way you could have a simple C program on the Zero running through the table, doing simple GPIO changes, and a Python program slowly producing the table on your desktop with whatever bells and whistles of logic you want. Its text output could be #include'd by the C. Once the table is mechanically produced, then you could produce one four times the length with variation between the four to avoid the repitition being spotted; there's surely room in the Zero. If you've house lamps changing during sun PWM, then two tables that you walk through in parallel
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
Hi Terry, > 'Dusk' and 'dawn' are fixed values around 3 to 5 minutes apart so that > the visitors can see the layout operating at 'night' as well as during > the 'day'. There is no need to know the real time. Is there one Pi Zero doing all the lights, or will there be several, coordinating? > So if a truly cut-down solution was required, I'm sure that the Python > code could be converted to C and compiled to run-standalone. Yes, or Go, which is what that Bytemark blog link was using. > I'm intrigued at the idea of making the program 'init'. Are you > saying that we would have a custom init that launches only the minimum > code required to support execution and then finally our program? I > had wondered about doing something like that, eg boot into a shell and > then launch the code, but that seems even more extreme. I was thinking your program would need *no* required code to support execution, i.e. a statically linked executable, and no programs to have run before hand to set anything up, e.g. networking, the date, hostname, logging, etc., and thus could be init, and never kick off any other programs. (If you run ldd(1) on an executable, e.g. /usr/bin/python, you'll see the shared libraries that ld.so(8) has to load in and then resolve references. If you do python -c 'import time; time.sleep(42)' & sleep 1; lsof -p $! then you'll see the files python has open once it's up and running, ld.so having finished.) No particular reason for making it init except that you can't get much simpler if nothing else is required, and there's nothing that would want to be writing to disk, though the ram disk solves that another way. Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
I have just done a very quick test booting a RPi with the filesystems mounted read-only. Basically it just worked. There were some 'failure' messages at startup where it was trying to save things to disk, but they aren't things which would matter. If the filesystems are all mounted read-only then there's no problem just turning power off. There's nothing waiting in RAM to be written to the disk if it's read-only! I assume that "dawn" and "dusk" will be time intervals like "every few minutes", rather than actually following clock-time? I'm sure you are aware that the RPi doesn't have a real-time clock, so every time you turn it on its clock will start from the same time. However for around £10 you can get a GPS receiver module which can be connected to the RPi's 3.3v serial pins, which would provide an accurate time if it were needed. If it doesn't know the real time and gets restarted every day then the RPi might actually keep running past year 2038! If the filesystems are mounted read-write then you shouldn't power off by just removing the power. If you do then any data in RAM which hasn't been written to the disk will be lost, and the filesystem will still be marked as dirty, so even if there's no un-written data it might take longer to start the next time. If you do end up using a UPS, perhaps a large capacitor would be better than a battery as it shouldn't require replacement. The "interface kit" required to connect a computer to an Arduino is a USB cable. -- Andrew. -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
Hi Terry, Andrew wrote: > However for around £10 you can get a GPS receiver module which can be > connected to the RPi's 3.3v serial pins, which would provide an > accurate time if it were needed. If you need all the Zeroes to be in sync, but find they drift apart after all being turned on at the same moment, then you could wire them all up to a single very-slow "clock" signal that just marks "midnight" of their "day" and brings them regularly back in step. This would also help if individual ones lose power during the day because of maintenance of their section of track. Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
Hi Tim, > Two or three years back I designed a UPS to work with a Pi for a > backup server, communicating over IIC, only to discover that the Pi > IIC didn't implement pulse stretching. That's interesting. I found http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html detailing the І²C problem. Not good news! And no sign Broadcom are interested in fixing it in later versions. :-( Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
Hi Terry, > we would like to use a Pi Zero to turn lights inside houses on and off > at intervals and also to dim and brighten the main lights at 'dusk' > and 'dawn'. Do dusk and dawn occur repeatedly through the day, or is there any need to tie in with wall clock time, only there's no real-time clock on the Pi Zero. > We have a physical solution and the code is fairly trivial, but my > main concern is the fact that once implemented, the Pi would have to > run unattended for most of the time and also withstand having the > power removed without a formal shutdown every evening (or if there is > a power cut). Clearly, this would put the integrity of the data on > the SD Card at risk. Yes, the Pi can just have its power cut, as Peter, said, but the integrity of the filesystem data depends on the filesystem being unmounted first so its data is flushed out. > I think we have a solution, but before we rush off to do it, I'd > appreciate your comments. The plan is to create a Live Tiny Core ( > http://tinycorelinux.net/ports.html[2] ) distro containing the > packages needed and the code to be run. We would install this on the > SD Card and then make it Read-only. How does the "read only" bit happen? I was thinking of having Raspberian boot as normal and then re-mount its SD-card filesystems read only along with starting your light show. `sudo mount -o remount,ro,noload /dev/...' does the re-mount. ro means read-only. ext3 and others also need noload to avoid reading their journal and making repairs; IOW, without that, they do *write* to the media. See mount(8) for your filesystem type to see if it's needed. But the downside of this is what bits Raspberian has set running take a dislike to finding nothing's writable, and whether that affects system stability over the longer term. Your idea of a cut-down installation with the minimum is better. Taking that further, you could make your program be `init'. Any idea what language you're planning to use yet? If it's not a statically-linked executable then its run-time dependencies will need to be present. This post might be useful. https://blog.bytemark.co.uk/2016/01/04/setting-up-a-raspberry-pi-perfectly-on-the-first-boot Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
Hi Terry >Clive has recruited me to help him at the Wimborne Model Town Railway ( http://www.wimborne-modeltown.com/the-model-town/model-railway/ 1] ). His responsibility is controlling the lighting and >we would like to use a Pi Zero to turn lights inside houses on and off at intervals and also to dim and >brighten the main lights at 'dusk' and 'dawn'. > >We have a physical solution and the code is fairly trivial, but my main concern is the fact that once >implemented, the Pi would have to run unattended for most of the time and also withstand having the >power removed without a formal shutdown every evening (or if there is a power cut). Clearly, this would >put the integrity of the data on the SD Card at risk. > >I think we have a solution, but before we rush off to do it, I'd appreciate your comments. The plan is to >create a Live Tiny Core ( http://tinycorelinux.net/ports.html2] ) distro containing the packages needed >and the code to be run. We would install this on the SD Card and then make it Read-only. Each morning, >the manager would then be able to power up the railway, which would bring up the Pi and start the >program running. At the end of the day, the manager would then be able to turn off the supply without >any risk to the SD Card. > >Can anyone see any problems with this approach or suggest a better way? One of these links could provide a solution https://www.raspberrypi.org/forums/viewtopic.php?f=37=39059 or http://mausberry-circuits.myshopify.com/collections/frontpage.The Mausberry Circuits solution may be a bit more expensive but I have the car power supply which works great powering down the Pi when the ignition is switched off. Regards Archie -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
On Tue, Jan 12, 2016 at 02:09:37PM +, Andrew wrote:
>I have just done a very quick test booting a RPi with the filesystems mounted
>read-only. Basically it just worked. There were some 'failure' messages at
>startup where it was trying to save things to disk, but they aren't things
>which would matter. If the filesystems are all mounted read-only then there's
>no problem just turning power off. There's nothing waiting in RAM to be
>written to the disk if it's read-only!
Hello, Dorset LUG.
This is perhaps a touch pedantic for a first post, but ...
There may still be some situations where you might corrupt the flash card if
you yank the power, even when the host processor does not attempt to write to
the flash. I expect this is very very rare, and possibly avoidable with the
right SD card. Good luck getting the SD card vendor to confirm if it behaves
correctly or not.
Your SD card almost certainly contains a microcontroller, most likely an ARM
or an 8051 with 32-bit extensions, running on the order of 100MHz. This
manages the flash and implements a flash translation layer (FTL) which
presents the block storage abstraction we know and love. The FTL handles
block mapping, concealing bad blocks, wear levelling, all that fun stuff.
The floating gates in modern flash memories are so small and densely packed
that they hold only a few hundred electrons. Some of these can leak away over
time. Worse, multiple reads of one memory block can over time cause changes
in nearby memory blocks -- this is known as "read disturb". These problems
are made more severe with 2 or 3 bit per cell designs (MLC/TLC) where the
thresholds between different values are very close. For example the Samsung
840 Evo SSDs were affected by this issue and required several firmware fixes
to fully address the problems.
The FTL may therefore track the age and number of reads to each block and
will copy blocks around, even if there is no write activity. This copying
also requires updating the block mapping so next time the controller knows
where in flash the block is located. It's hard to know for sure if the
controller in the SD card manipulates the on-flash data structures in such a
way that is robust against the power being yanked at any point in the
process.
For more insight on what's going on inside your SD card (including how to run
your own programs on the internal microcontroller!) I recommend this blog
post and 30C3 presentation from Bunnie Huang:
http://www.bunniestudios.com/blog/?p=3554
Also interesting and includes die-shots of a number of microSD cards:
http://www.bunniestudios.com/blog/?page_id=1022
The solution seems obvious - just give them a compressed image of the final
SD card. They can later uncompress and write this to a second SD card to make
a duplicate should the first ever become corrupted.
Will
_
William R Sowerbutts w...@sowerbutts.com
"Carpe post meridiem" http://sowerbutts.com
main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
(m=-1;m<7;putchar(m++/6%3/2?10:s[c]-31&1<
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
On Tuesday 12 January 2016 14:15:30 Ralph Corderoy wrote: > Do dusk and dawn occur repeatedly through the day, or is there any need > to tie in with wall clock time, only there's no real-time clock on the > Pi Zero. 'Dusk' and 'dawn' are fixed values around 3 to 5 minutes apart so that the visitors can see the layout operating at 'night' as well as during the 'day'. There is no need to know the real time. > How does the "read only" bit happen? I was thinking of having > Raspberian boot as normal and then re-mount its SD-card filesystems read > only along with starting your light show. `sudo mount -o > remount,ro,noload /dev/...' does the re-mount. ro means read-only. > ext3 and others also need noload to avoid reading their journal and > making repairs; IOW, without that, they do *write* to the media. See > mount(8) for your filesystem type to see if it's needed. But the > downside of this is what bits Raspberian has set running take a dislike > to finding nothing's writable, and whether that affects system stability > over the longer term. Your idea of a cut-down installation with the > minimum is better. Yes. That is what I had in mind. > Taking that further, you could make your program be `init'. Any idea > what language you're planning to use yet? If it's not a > statically-linked executable then its run-time dependencies will need to > be present. This post might be useful. > https://blog.bytemark.co.uk/2016/01/04/setting-up-a-raspberry-pi-perfectly-o > n-the-first-boot The plan at the moment is to write the program using Python, because of all the libraries for GPIO support and the huge number of prior examples (remember I was a systems engineer with a maintenance background who ended up doing some basic coding in C and ATLAS). So if a truly cut-down solution was required, I'm sure that the Python code could be converted to C and compiled to run-standalone. I'm intrigued at the idea of making the program 'init'. Are you saying that we would have a custom init that launches only the minimum code required to support execution and then finally our program? I had wondered about doing something like that, eg boot into a shell and then launch the code, but that seems even more extreme. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Using a Raspberry Pi 'Headless' and Unattended
On Tuesday 12 January 2016 15:49:06 Andrew Montgomery-Hurrell wrote: > Could you not just have the sdcard boot up system to run from a ramdisk? > Then the ramdisk can unmount the sdcard if necessary and you can have a, > albeit limited, writeable system. That's effectively what a live Tiny Core instance would do. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2016-02-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
