B+ RISC OS problems

The B+ uses some of the GPIO pins to make some of it work - which the A/B doesn't do - so these need to be initialised by either the bootloader + GPU firmware or the running kernel (I don't know if the bootloader/firmware does it)

Without these additions, the USB hub + Ethernet won't work.

(And the ACT LED might not work either as it's been moved to a different GPIO pin)

The B+ can also sense low voltage input and control the USB current limiter (600mA by default)

The upshot is that if you use a Linux image that works fine on a B, but hasn't been updated in the past 3 months, it won't work too well on a B+ A current B+ Linux image will work fine on an older A/B Pi.

I presume the folks producing RISC OS got these updates too, but I don't use it, so don't know.

(And it sounds like they have, as the USB really wouldn't work without being enabled via the system)

Are there new users of RISC OS?

Gordon

[snip]

I did have some of those issues you reported with an early release of ROOL's RISC OS Pi. Another of the oddities was the R-Pi didn't boot-up except on re-inserting the card (I thought it was a bad 'card present' switch). I've upgraded to a 32GB SDHC card using Piccolo's !SystemDisc to build the OS and can't recall seeing any more of these problems.

This sounds like the wireless keyboard/mouse problems mentioned a number of times on ROOL. Is that what you are using? If so try wired versions and see if the problem disappears. I believe this is being worked on but there are other priorities these guys need to concentrate on.

[snip]

Since upgrading SDHC/OSI I haven't had reliability problems that you have experienced on my model B. I have had odd software errors which I have reported to the respective programmers only for them to disappear on running another day - rather embarrassing to say the least. My R-Pi is in a plastic case next to an ADSL modem router - I wonder if the radio signal is causing interference ? I'm monitoring its performance having moved it away.

Using RISC OS 5.21

Can't comment.

I have an Iyonix which has been an excellent workhorse and generally highly reliable (except when I've messed things up). RISC OS on the R-Pi, model B is certainly as reliable as my Iyonix. Don't write it off.

Richard

Ha! Aww. I tried but it was too weird for me. The direct Basic prompt of Risc OS Pico is fun, though. I wish there was a "Raspbian Pico" + Python version of that. (Lack of integrated graphics and sound probably preventing it. Ah, for the days of just 10 screen 2; 20 line(0,0,100,100).)

We had all sorts of model of Pi (A,B,B+) running all day at the RISC OS London Show on Saturday with no trouble, so there must be something odd with your setup.

Possible things to look at:

- What power supply are you using?

- Have you tried a different PSU?

- What make of keyboard and mouse? MS and Apple ones are prone to issues.

- Are they wired or wireless?

- Are they connected directly or via a hub?

- If you have a hub connected, is it powered?

- Anything else connected?

Bryan.

--
RISC OS User Group Of London  -  http://www.rougol.jellybaby.net/ 
RISC OS London Show           -  http://www.riscoslondonshow.co.uk/

As a (rather long) lifetime user of RISC OS and its precursor, I found the use of all its incarnations intuitive and instinctive; but Raspbian on the RPi remains utterly beyond me even to get started. Each to their own, you might say...

--
Mark J 
From RISC OS on a BeagleBoard-xM and Raspberry Pi 
- and Linux on a PandaBoard ES

RISC OS open Ltd, who maintain the open source version of RISC OS, claimed during their talk on the RO show on Saturday, that hits on their website, including downloads, are increasing steadily.

This implies more users or, at least, a lot more people trying it out.

--
Stuart Winsor 

Tools With A Mission 
sending tools across the world 
http://www.twam.co.uk/

If you'd like to get up to speed in Raspbian, take a look at the "Linux in a Nutshell" book. Since you understand computers and at least one OS, the conciseness of this book shouldn't phase you. However, it does restrict itself to the user view of Linux (not much/anything about sysadmin facilities and tasks).

You might also find "Linux for Dummies" useful - just don't be put off by the title.

The "RaspberryPi User Guide" has the basics of RPI sysadmin tasks. Others may have better ideas about guidance on being your own sysadmin.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

Good news.

For absolute novices...there is a simple welcome guide to the RISC OS desktop available from the RISC OS Open site at...

Locating RISC OS software can be daunting for new users. As an introduction register with PlingStore where you can download many utilities for free.

Richard

[...]

Registering via the website is only necessary for those wishing to *supply* software via the !Store application.

It isn't necessary for downloading software - this is done via the application itself, which can be found on the RISC OS disc image for the Raspberry Pi (and, indeed, the RISC OS disc images for other new platforms).

Ah, those days, when on-screen graphics were easy.

I notice that Raspbian has python-pygame installed by default, which doesn't seem *too* bad in that you only have to double the program size with object-oriented mumbo-jumbo.

I've converted an old DOS Qbasic program of mine to Python here. It's that illustration of Chaos Theory, the Bifurcation Diagram. It's drawn in about 1 minute on the Pi, and about 1 second on my main computer.

#!/usr/bin/env python import pygame, numpy w = 600; h = 400 pygame.display.init() screen = pygame.display.set_mode((w, h)) screen.fill(pygame.color.Color("white")) rnd = 0; n = 0.655 for x in range(0,w): for j in numpy.arange(0, 1, 0.005): r= (x + j)/w * 1.1 + 2.89 rnd = (rnd + 757) % 997 n = (n * r) * (1.0 - n) + rnd * 5.0e-8 y = int(n * h) screen.set_at((x, y),pygame.color.Color("black")) pygame.display.flip() while pygame.event.wait().type != pygame.QUIT: pass pygame.display.quit()

You can run an interactive (ish) Python with idle

They still are:

In RTB: (One line per statement I'm afraid)

w = gwidth h = gheight colour = white cls random = 0 n = 0.655 start = time for x = 0 to w - 1 cycle for j = 0 to 1 step 0.005 cycle r = (x + j) / w * 1.1 + 2.89 random = (random + 757) mod 997 n = (n * r) * (1 - n) + random * 5.0e-8 y = int (n * h) plot (x, y) repeat repeat done = time print "Time taken: "; done - start; "ms" end

I run it in a 640x480 screen size and got this:

which looks about right to me. (neat!)

1.833 seconds in RTB on a Pi, however I'm not updating the display until the very end - try moving the

pygame.display.flip()

back 2 spaces...

It takes 78mS on my desktop Linux PC.

And of-course there's BASIC V under RISC OS too...

-Gordon

That's very fast for an interpreter running on a lightweight machine like the Pi. I've just downloaded RTB and tried this example. Impressive.

There's not much that can be done for Python's speed, unfortunately. Most of the time is taken by the loop. Usually it doesn't matter much on a fast computer, though. Where speed is needed, I use C.

Don't forget that the B+ should have a decent 5v 2amp PSU so that it can power all of its 4 USB sockets.

Bernard

--
Contact Me - http://www.bapfish.org.uk/contactme/

I'm somewhat surprised Python is slow here. Moving the "flip" instruction outside the loop will speed it up - but when I tried it, it still took the best part of a minute. The few crude benchmarks I've done on RTB vs Python have shown that Python mostly has the edge. It might well be the pygame itnerface though - really hard to tell.

RTB is written in C

-Gordon

As is the standard Linux distro Python, of course. I've managed to cut it down to about 1/4 minute from the window opening to completion on the Pi, with a few tweaks, but I think that's as good as it gets. A few tests on my desktop machine suggests that Pygame is about 30% of that and the rest is mostly the time taken to parse the bytecode.

#!/usr/bin/env python import pygame, numpy, random w = 600; h = 400 pygame.display.init() screen = pygame.display.set_mode((w, h)) screen.fill((255,255,255)) rnd = 0; n = 0.655 for x in xrange(0,w): for j in xrange(0, 200): r = (x + j / 200.0) / w * 1.1 + 2.89 n = (n * r) * (1.0 - n) + random.random() * 2.0e-4 y = int(n * h) screen.set_at((x,y),(0,0,0)) pygame.display.flip() while pygame.event.wait().type != pygame.QUIT: pass pygame.display.quit()

^^^

I still think that flip line ought to be

BBC BASIC doesn't do that: the internal ops (DRAW, PLOT, CIRCLE FILL, etc) call the RISC OS graphics routines that plot those things on the display device. Things with hardware acceleration (eg ATI/NVIDIA cards) intercept those and do GPU side ops. The Pi doesn't do that (no OpenVG drivers), so the OS uses its own rendering calls into video memory. Once it's in video memory the GPU then displays that (rescaled as necessary).

You can get the address of the framebuffer and plot stuff directly (you don't need to map it, you already have write access), but this is frowned upon. It doesn't play nicely with PCI cards where the video memory is on the wrong side of the PCI bus, so is slower than writing to DRAM and then using the GPU to DMA out the framebuffer at Vsync time. It's possible to cache DRAM but more awkward to cache PCI space. It's also awkward if the GPU pixel format doesn't match the OS pixel format (which can do 32, 16, 8,

4, 2 and 1 bit per pixel modes).

Theo

It saves another 30%, but having the display develop like that is the point, really.

(For anybody that's not familiar with it, the Bifurcation Diagram illustrates a principle in chaos theory. If there's a colony of rabbits say, with a population density n, and breed annually with fecundity r, then next year's population would be n^r, except that there's a limited food supply so that if they eat too much then starvation will cut next year's population, so represent that with (1-n) to give next year's population as (1-n)*n^r. Now imagine that they evolve over time to increase their fecundity, and their population grows, but after a while something surprising happens; their population starts jumping between two densities on alternate years, then later between 4 levels, then 8 and so on. Eventually the population density becomes truly chaotic, until with a fecundity of 4 they eat all the available food one year and are extinct the next.)

And I forgot that pygame's y-origin is at the top of the screen so I got it upside-down. y should be y = int((1 - n) * h)

Yes. And SDL is supposed to be one of the more lightweight and fast abstraction layers by modern standards. If I've got time this evening, I'll see how fast it runs with python/tk or python/pil.

But Gordon updated the screen only at the very end; here you still update for every column, 600 times. Does that make a big difference? (I imagine Gordon already tried it, though.)