Page 2 of 2

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

Posted: Fri Mar 22, 2013 10:04 am
by LemmeFatale
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

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

Posted: Fri Mar 22, 2013 11:39 am
by NigelJK
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.

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

Posted: Fri Mar 22, 2013 5:12 pm
by PeterT
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.

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

Posted: Fri Mar 22, 2013 6:09 pm
by jojopi
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?

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

Posted: Sat Mar 23, 2013 1:04 pm
by PeterT
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.

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

Posted: Sat Mar 23, 2013 1:43 pm
by AMcS
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.

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

Posted: Sat Mar 23, 2013 1:58 pm
by AMcS
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).

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

Posted: Sun Mar 24, 2013 2:27 pm
by PeterT
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.

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

Posted: Sun Mar 24, 2013 3:22 pm
by AMcS
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.

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

Posted: Sun Mar 24, 2013 11:58 pm
by colin B
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).

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

Posted: Tue Mar 26, 2013 2:21 pm
by PeterT
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.