User avatar
LemmeFatale
Posts: 253
Joined: Fri Feb 01, 2013 8:47 pm
Location: UK

Re: RISC OS included in OS types reviewed in Linux Format

Fri Mar 22, 2013 10:04 am

thradtke wrote:
LemmeFatale wrote:I was referring to the small-scale hobbyist things I've read around here [...]
Have a look what I wrote:
thradtke wrote:I think everything works if you're just toying (or self-educating yourself ;-) ).
Understood. :) Thanks very much.
polas wrote:It would be very interesting to see the differences in cost between running a non trivial ROS and PC network
Now that, I'd love to see.

I've always felt that the narrowing of computing diversity in schools was always a very bad idea, and I'd be interested to know how much it's cost the taxpayer. :P
Classic - Raspberry Pi Model B (512MB) with Motorola Atrix Lapdock
Lemcon-One - Raspberry Pi Model B (256MB) PiMAME TV-Box

NigelJK
Posts: 65
Joined: Wed Sep 05, 2012 1:44 pm

Re: RISC OS included in OS types reviewed in Linux Format

Fri Mar 22, 2013 11:39 am

I have personal experience of the way this was achieved. We were 'given' a 5 station at-clone Ethernet network by Zenith. This was when PC's were new and the retail cost of this 'network' would have been close to £50K. I also understand that Microsoft 'sponsor' one of the Oxford University dept's and this was one of the ways that they persuaded the masses that their kit was of educational quality.

PeterT
Posts: 11
Joined: Wed Nov 07, 2012 4:47 pm
Location: Hampshire, U.K.
Contact: Website

Re: RISC OS included in OS types reviewed in Linux Format

Fri Mar 22, 2013 5:12 pm

thradtke wrote:A ranking is nonsense, imo. Both OS have their advantages and disadvantages, making one or the other suitable for a certain task. E.g., for building/home automation no one (hopefully) would use Linux (so zero out of n stars), while RISC OS might get n out of n stars ... as long as there isn't OS-9 on the Pi :D
I have been using linux to run my home automation for years - lights, tv, curtains, energy monitoring and temperature monitoring - all controllable using a web browser and e-mail. I can leave it running for years without problems, it runs on very low power (<5W) cheap (~£100) computers and doesn't need a desktop. It also runs the key software - heyu, rddtool, apache2, postfix - I use. It also interfaces easily with mobile phones so that I can also control the house using sms.
RPi running Rasbian, SheevaPlug and DreamPlug both running Debian Wheezy, 2 netbooks both running Debian Wheezy with Gnome 3.

User avatar
jojopi
Posts: 3079
Joined: Tue Oct 11, 2011 8:38 pm

Re: RISC OS included in OS types reviewed in Linux Format

Fri Mar 22, 2013 6:09 pm

thradtke wrote:You can ensure RISC OS isn't writing anything to the card AFAIK.
You can certainly ensure that Linux is not writing to flash. It is quite widely used in embedded applications, and not just by hobbyists. I have more consumer devices (that one might not realise are) running Linux in my house than computers. A more embedded configuration will address other issues like boot time as well.

Does home/building automation require accurate timing, such as latencies below 1ms? And if it does, is RISC OS actually much better?

I understand that RISC OS allows a process to take full control of the machine, and even disable interrupts, whereas a Linux process with real time scheduling priority can only avoid preemption for a limited period, and interrupts can only be disabled in a kernel module. But in practice how long can you disable interrupts (on either system) before USB and network stop working? And if you do not disable interrupts, how does the maximum interruption length compare?

PeterT
Posts: 11
Joined: Wed Nov 07, 2012 4:47 pm
Location: Hampshire, U.K.
Contact: Website

Re: RISC OS included in OS types reviewed in Linux Format

Sat Mar 23, 2013 1:04 pm

While at a certain level home automation needs good timing, this tends to be handled by PICs - akit to a modem. The linux computer is being used as a supervisor, it gets messages from the various sensors and switches and runs a set of rules to decide what to do about it. this can be logging in a database or changing the state of the light, curtain, tv etc. Messages arrive at non-determinate times so a multitasking OS is very useful. If I wanted to do low level control and there wasn't something I could buy that did it already I would use arduino - but still use linux to supervise.

Linux runs very happily headless. I don't need keyboard, mouse and screen connected. I manage the linux computer using ssh from my netbook.

Linux is highly resilient to power outages. When there is a power cut the system recovers when the power returns. The linux computers tend to boot faster then the network so boot time isn't an issue. In reality, I never shutdown a linux computer before removing power - I just turn it off. I have not found this to be a problem.

I back up my own software and data and keep another computer ready to go. Occasionally I have SD card problems (1 per 2 yrs) but these are usually resolved by running the checks.
RPi running Rasbian, SheevaPlug and DreamPlug both running Debian Wheezy, 2 netbooks both running Debian Wheezy with Gnome 3.

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: RISC OS included in OS types reviewed in Linux Format

Sat Mar 23, 2013 1:43 pm

jojopi wrote:I understand that RISC OS allows a process to take full control of the machine, and even disable interrupts, whereas a Linux process with real time scheduling priority can only avoid preemption for a limited period, and interrupts can only be disabled in a kernel module. But in practice how long can you disable interrupts (on either system) before USB and network stop working? And if you do not disable interrupts, how does the maximum interruption length compare?
As far as I recall it's around 100 microseconds, any longer than that and there could be issues. Bear in mind though you'll get a lot done in assembly code in 100 microseconds. If you need longer than that you'd probably set up a call back and re-enable interrupts.

By the way you don't have to disable interrupts if the code you're using is re-entrant and does not make any SWI (RISC OS system calls) that are flagged as non-re-entrant. While that is a bit of a limitation it does mean that you can (sometimes) get away without disabling the interrupts.

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: RISC OS included in OS types reviewed in Linux Format

Sat Mar 23, 2013 1:58 pm

jojopi wrote:Does home/building automation require accurate timing, such as latencies below 1ms? And if it does, is RISC OS actually much better?
Probably not, but some sensors your system may be attached to it might (referred to by PeterT). The Linux path would probably involve using a PIC for those portions (as he suggested) - with RISC OS you might be able to get away with GPIO from the Pi and RISC OS handling the device interrupts (in that case, however, you'll have to do more complex coding - so there is pain involved in both routes - it's then up to you as to which is more tolerable :) ).

The reality, I suspect, is that either OS is suitable - but each requires some compromises and which set of compromises are acceptable (and what OS is selected) is very much down to the developer.

The RISC OS one might allow you to use simpler hardware and fewer resources (at the expense of more complex programming), the Linux one would (probably) require additional hardware (depending on the exact sensor/use case) but would probably be an "easier" programming task (as the timing critical bits would be handled externally).

PeterT
Posts: 11
Joined: Wed Nov 07, 2012 4:47 pm
Location: Hampshire, U.K.
Contact: Website

Re: RISC OS included in OS types reviewed in Linux Format

Sun Mar 24, 2013 2:27 pm

I am struggling to think of any home automation that needs time accuracy down to 1ms.

In my experience, controls cause changes state that take less than 0.5 sec. The energy measurement sends a reading every 6 minutes, the odd several seconds do not matter. Temperature sensors send a reading when a change of 0.1 degree is detected - this is roughly every 10 minutes when the house is being heated. I also have watchdogs running that monitor the status of attached systems, again a few seconds do not matter.

I don't control the heating automatically but if I did then a few minutes wouldn't matter.

The biggest problem in home automation, in my experience, is setting up the rules so that it is natural for the occupants of the home. It is easy to set up something that turns them against it.

The other problem is over filling the networks, I use RF and Powerline, with messages.
RPi running Rasbian, SheevaPlug and DreamPlug both running Debian Wheezy, 2 netbooks both running Debian Wheezy with Gnome 3.

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: RISC OS included in OS types reviewed in Linux Format

Sun Mar 24, 2013 3:22 pm

PeterT wrote:While at a certain level home automation needs good timing, this tends to be handled by PICs
I am just wondering why?

If a reading every second (or so) is acceptable - why is it necessary to use PICs at all? Just attach the sensors via a simple interface to Pi (I2C or whatever) and use Linux to read the values. I've always been puzzled why, apparently, the first response (for Linux users) is to resort to PICs when dealing with external devices when (apart from signal level adjustment say) the Pi and a very simple interface is surely all that is required.

The PI is many times faster than a PIC surely - so why tag on unnecessary silicon like a PIC?

Arguably the more complex you make a system by adding unnecessary gubbins you both add to its cost and reduce its reliabily.

colin B
Posts: 119
Joined: Sun Mar 04, 2012 12:23 pm
Contact: Website

Re: RISC OS included in OS types reviewed in Linux Format

Sun Mar 24, 2013 11:58 pm

AMcS wrote:The PI is many times faster than a PIC surely - so why tag on unnecessary silicon like a PIC?
Actually this is somehting I am considering doing and I'm not a Linux user :)

I'm making a voltage and current logger for work, I think it would be easier to use the PIC to make an auto read six channel input, and, via either serial or SPI send to the Pi via possibly a 232/SPI -> USB dongle.

The advantage is that I don't have to worry about manipulating the Pi (using RISCOS) as far as the transport is concerned and the Pi can be used in areas that it is easier to manipulate than the PIC, such as fancy displays and disk/SD card access.

The PIC also acts as a buffer to some extent between the nasty power supplies that I test and the more delicate and expensive Pi (relatively speaking).
Last edited by colin B on Tue Mar 26, 2013 9:16 pm, edited 1 time in total.
On a clear disk one can seek forever

PeterT
Posts: 11
Joined: Wed Nov 07, 2012 4:47 pm
Location: Hampshire, U.K.
Contact: Website

Re: RISC OS included in OS types reviewed in Linux Format

Tue Mar 26, 2013 2:21 pm

I do have simple sensors connected directly to the linux computer. What I don't what to do is use the linux computer to decode or encode complex waveforms for data exchange over RF and Powerline networks. There are perfectly good modems available that do this; the ones I have all include PICs - very low power and interface to the computer using USB, or over one of the networks. I also have a mobile phone connected by USB to the computer.

I have temperature sensors in my living room, externally and in the loft. I have electricity and gas monitors in the garage. It would be difficult to wire that lot together (lots of wire and lots of holes) so I use the RF network. I use 1-wire sensors and connect them together using telephone cable when possible.
RPi running Rasbian, SheevaPlug and DreamPlug both running Debian Wheezy, 2 netbooks both running Debian Wheezy with Gnome 3.

Return to “RISCOS”