C++ and other stuff on Raspberry Pi

Hi all,
Just joined as I have just come across this site.
I have had a project in mind for some months now to make myself an oscilloscope.
Not done anything with hardware yet except with arduino but considered the following:

First thought was use my desktop computer and arduino but only good enough for audio frequencies.

Then thought of using PC and parallel port via linux ( only used linux for 10+ years not MS WIndows ).
Found that being as it is linux, I would struggle to get good timings because of the multi-tasking element and so much going on in the background.

RISC OS looks ideal so I have taken the plunge, ordered an R.Pi and RISC OS on an SD card.

However I have a lot of questions which I hope you guys can answer for me please.
1/ How fast is Basic on RISC OS. Can i get really fast access to GPIO and processing results?
2/ How does it’s speed on RISC OS compare to say C++ on linux ( okay probably hard to answer but ballpark idea fine )?
3/ How does C++ work out on RISC OS? I obviously will need to display the waveform in at least near real time.
4/ Can I download C/C++, gcc or g++ for R.Pi or do I need a special package?

tia
Norman

BASIC is pretty quick on the Pi, as the entire interpreter fits inside the ARM’s cache. However, the quickest way to use it is via its in-line assembler. That way you’re effectively running bare-metal code and it can then be as quick as compiled C code.

All of this assumes you’re running in single-tasking mode (non-desktop). If you want to have a fancy looking trace that multi-tasks on the desktop then you can forget real-time sampling and a noise-free environment. And even in single-tasking mode, drawing anything to the screen (especially graphics) will slow things down considerbly and introduce all sorts of stutter into the sampling process.

Using assembler, it’s possible to toggle a single GPIO output line at about 20MHz – which is close to its theoretical maximum, whichever OS you’re using. Reading GPIOs, however, is much slower than that – probably only a quarter of that rate as there are simply more code cycles involved.

Thanks Neil,
As I am completely new to R.Pi and RISC OS I intend to do this as simple as possible first. I would do it in basic and I have an AD7822 ADC which is parallel output and has a maximum sample rate of 2Msps and runs at 3.3volts. I am thinking I could connect it directly to the R.Pi and read one of the 32 bit registers each time it has completed a conversion. Some bit manipulation should quickly give me the value from the ADC. Then a simple screen to output to. If I can do that well I will be very pleased. From there I can see what else is possible, maybe a faster adc – possibly a PICAXE chip – or a more fancy graphic interface.

It looks like you can do a bit better than 20MHz for certain purposes – http://www.icrobotics.co.uk/wiki/index.php/Turning_the_Raspberry_Pi_Into_an_FM_Transmitter
Quite probably not what Norman wants to do but way cool!

You could write much of your code in BASIC and the fast read loop in assembler. BBC BASIC is quite convenient for that sort of thing as long as you can bear writing in BASIC. It suits some people, horrifies others. You can get the gcc compiler suite for free (obviously) and use C or C++ (I’ll try not to get started on my c++ hatefest) or you can spend a little more money and get the nutPI package from this very website. That include the ‘proper’ Acorn development tools. I quite like them but then again I’ve used them since 1987 so that may be just habituation.

Thanks Tim,
I have had a look at nutPi and have ordered it.

Found that being as it is linux, I would struggle to get good timings because of the multi-tasking element and so much going on in the background.

Not to mention the increased effort involved in writing a system level driver for Linux…

RISC OS looks ideal so I have taken the plunge,

;-) RISC OS is a lot friendlier in this respect, yes.

1/ How fast is Basic on RISC OS.

BASIC is pretty fast, but in common with all purely interpreted languages, the interpreter will need to “interpret” each line of code as it comes across it, over and over again.

For as fast as BASIC is, a well written compiled program can wipe the floor with it each and every time – simply because the code is already there and known.

But don’t get dissuaded – BASIC is great for prototyping stuff. For some of the more complicated things, I’ve been known to write a “slow and clumsy” version in BASIC and then (if I can be bothered, sometimes the BASIC one is fast enough) rewrite it in C. And then from time to time I rewrite bits in assembler mainly ‘cos I can (99% of the time, there’s little point crying over a couple of hundred wasted cycles on a >500MHz processor!).

Can i get really fast access to GPIO and processing results?

Depends “how fast is really fast”. In pure BASIC, you can use Tank’s GPIO module via SWI calls. This will be slow (BASIC code, overheads of SWI dispatch, code in the module may not be optimised in a way beneficial for your particular case (compare OS_SpriteOp that tries to do everything)).

This will “get you going”.

If you are reading fast enough but the delay is in processing, you have probably surpassed what BASIC can offer. Time to move to C. Happily, SWI calls aren’t so hard in C, do you can pretty much do a 1:1 port of your code and it’ll be faster.

Still not happy? Well then there’s the time to look to separating the GPIO reading from the processing; you could have a small module that examines the GPIO directly (not via Tank’s module) and possibly under some form of interrupt, to write the data to a large circular buffer; and a front-end that picks up this data and processes it. You’ll need to implement a mechanism to determine if the buffer has overrun – this isn’t hard, a “head” pointer is written by the GPIO reader, and a “tail” pointer is written by the processing. Given the buffer is circular and will loop around, if head should equal tail, time to say “oh crap”. ;-)

Still not satisfied with the speed? This is where RISC OS provides for some fun. For short bursts of high speed sampling, you can disable interrupts and just read-read-read as fast as the hardware can manage. There are some caveats – there’s a ticker that runs at 100Hz that is rather important to the system’s concept of time, plus forgetting to turn interrupts back on while developing the code will mean an instant hang-up that only a hardware reset will get you out of. You probably know this stuff, I’m just re-iterating it because it is only a SWI call away. ;-)
Oh, and you don’t want to kill interrupts if your reading routine is interrupt driven. I state this because I made that mistake once. Facepalm!

How does it’s speed on RISC OS compare to say C++ on linux ( okay probably hard to answer but ballpark idea fine )?

What, BASIC or C? Assembled code on any platform ought to run about the same speed on the same hardware regardless of the OS. BASIC, as I said, will be slower due to the need to interpret.

3/ How does C++ work out on RISC OS? I obviously will need to display the waveform in at least near real time.

C++ or plain old C? When you say “near real time”, what did you have in mind exactly. I would have thought you could make a 2MHz scope fairly easily. Perhaps as far as 5-6MHz. Perhaps the most important thing will be periodicity of sampling (irregular timings are no good, so how will you determine when to sample?) Bear in mind that you may wish to sacrifice some potential speed to allow for enhanced functionality, such as a “trigger” mode or the ability to vary the sampling speeds. It depends on how fast the hardware can run relative to the processing required.

I would consider version 1 to be a singletasking program. Due to the RISC OS co-operative multitasking model, you can’t guarantee how and when you will be polled. Plus you’ll get a lot more processor cycles to yourself if you abandon multitasking.

4/ Can I download C/C++, gcc or g++ for R.Pi or do I need a special package?

I would recommend the official C suite, it is part of the NutPi package (and very hansomely priced it is too); however there is a version of GCC available for free. Try riscos.info – I can’t really help as I have no experience with GCC (I use the official DDE, albeit a slightly older version).

To put them in context: Official DDE – can build RISC OS. GCC – can build Firefox. As you can see, both are quite capable.

Neil added:

hat way you’re effectively running bare-metal code and it can then be as quick as compiled C code.

Just to point out, you will probably need to switch to supervisor mode (SWI OS_EnterOS) in your assembler, as you can’t access I/O stuff in plain old user mode. If, in the course of developing your program, you hit bizarre errors (data aborts and “the memory just isn’t there”), it is probably because you are still in user mode.

Back to Norman:

I would do it in basic and I have an AD7822 ADC which is parallel output and has a maximum sample rate of 2Msps and runs at 3.3volts. I am thinking I could connect it directly to the R.Pi and read one of the 32 bit registers each time it has completed a conversion.

How many physical I/O lines are involved here? What is the read protocol? If you are reading 4 bit nibbles, each sample would be eight or more parallel GPIO accesses; and if you shift the value in serially, you could be looking at 40-50 single accesses (if you need to set up which register to access first).

Thanks Rick,
That’s really encouraging. To comment on some of your answer.

I was wanting to get a feel as to how much faster on RISC OS basic is compared to Linux and is the ratio of basic to C different on RISC OS to what it is on Linux but obviously if I had engaged my brain when I type I would realize that unless it’s the same hardware anyway it cannot be compared.;-(

Are you saying that you need something equivalent to root to access to get the values of the registers?

From what I have read so far the GPIO pin states are stored in 2 32bit registers. Not all of them are available to the R.Pi as they are used for other things. The ADC I mentioned has parallel output of the conversion so the value is presented as an 8 bit byte on 8 pins. If I connect them to the right set of 8 GPIO pins on the R.Pi I should be able to read the correct register, AND the value to mask out all except the 8 I need then divide that as needed to end up with an 8 bit number which corresponds to the output of the ADC. Is that right?

I hear Charm is very quick too, no idea however if it would be capable of doing what you’re looking for.

Are you saying that you need something equivalent to root to access to get the values of the registers?

“Sort of” (very tenuously).
You can’t access hardware in “USR” mode on the processor. It needs to be in “SVC” mode.
To do this on RISC OS, issue the SWI “OS_EnterOS”. This will return to you with the processor in SVC mode. That’s about as close to root/non-root as you get on RISC OS. ;-)

Take a quick look at this: http://www.heyrick.co.uk/armwiki/Processor_modes

You can see this in action at the top of this page: http://www.heyrick.co.uk/assembler/podule.html in the part “Messing with the parallel port”.
However, DO NOT COPY THIS CODE because it is written for an older version of the ARM. The TEQP in there is to restore user mode by poking R15, but on modern ARMs the processor mode is not held in R15!
[this is why I’m deprecating /assembler in favour of ARMwiki; too much old stuff, too long to explain what/how/why it doesn’t work]

The ADC I mentioned has parallel output of the conversion so the value is presented as an 8 bit byte on 8 pins. If I connect them to the right set of 8 GPIO pins on the R.Pi I should be able to read the correct register, AND the value to mask out all except the 8 I need then divide that as needed to end up with an 8 bit number which corresponds to the output of the ADC. Is that right?

You may need more than eight pins – does it have address pins or something? I’m not familiar with the part. There are eight apparently unused GPIO pins on P1 (once SPI, IIC, etc is taken into account). Looks like it is all 3.3V. There are four more GPIOs on P5 (IIRC).

Take a look at http://elinux.org/Rpi_Low-level_peripherals

For you, not only do you have DB0-DB7 to interface, but there is also !RD to switch between “offline” and “read”. As it is the only device on the “bus”, you can hardwire !CS to always keep the chip selected. The 7822 is a single channel ADC, so you don’t need to worry about A0-A2. You need !CONVST which initiates a conversion. That leaves !EOC which signals to the host that a conversion has finished.

To use less I/O, you might want to wire !EOC into !CS & !RD so that !CONVST starts the conversion procedure, and it is automatically made available and signalled to the host with the !EOC signal. See p19 of the datasheet.

The least I can get it down to is ten I/O:
!CONVST – output, pulse low to start a conversion [device powers down if it stays low]
!EOC – input, goes low when conversion has finished; this can be polled initially, but you’d probably be best using this as an interrupt. That’s a different level of complexity.
DB0-DB7 – inputs, for reading the conversion data.

Looking diagrams, you have eight plain GPIOs available. Some places label these logically as GPIO0-GPIO7, others use a totally erratic numbering and say “this is Broadcom’s nomenclature”. Go figure.
In addition, as RISC OS (currently) does not use SPI, you may be able to repurpose the GPIO for the SPI for the remaining pins.

Things to note:

• The IIC bus is pulled up, it is intended specifically for IIC.
• It is possible that certain states on TX/RX at power up may affect the boot loader [the page http://elinux.org/Rpi_Low-level_peripherals notes this as “Boot to Alt 0 →”, whatever that actually means]
• Jeffrey recently posted a proposal for an SPI API. This doesn’t mean that RISC OS will support SPI tomorrow, but it is something to keep in mind. You may prefer to use to GPIO on P5 instead?

As for how fast the hardware can go, take a look at: http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/

Under RISC OS we might be able to eke out some more as we can kick the OS into the background, something you can’t really do with Linux. I do like the part where native C scored 14-22MHz while perl clocked in a sedate 35kHz. As for doing it in a shell script… Don’t ask. Really, don’t. ;-)

Are you saying that you need something equivalent to root to access to get the values of the registers?

No. Not even slightly.

“Root access” is a purely software concept, unique to Linux and its derivatives. Linux is a multi-user system in which every user can have individually restricted privileges to do certain things, and the user which can do everything is known as “root”. I know you know this, but the point is, the only thing stopping user “Norman” from doing things he shouldn’t be able to do without logging in as “root” is the OS. (And finding ways to circumvent the OS is big business in some countries…)

RISC OS is a single-user system, which is to say that, in Linux terms, every user has root privileges! This tends to alarm many newbies from Linuxland.

Processor modes are a feature of the physical ARM chip. Linux has them too, or at least it does when running on an ARM processor, but like most other things, it buries them under several layers of architecture-independent abstraction, whereas RISC OS enables you to get much closer to the hardware. (Hey, that’s why you’re using it, right?)

The mode in which most programs run is called USR mode, but there is another one called SVC mode, which can do more stuff like access the IO registers. To switch from USR mode into SVC mode, execute the instruction SWI OS_EnterOS – or, in BASIC parlance, SYS "OS_EnterOS". Hey presto – you are now in SVC mode. (Security? Puh-lease, this is the 1980s, cybercrime won’t be invented for another 20 years!)

If you’re going to get into this kind of bare-metal programming, then you will need to learn about the concept of processor modes! Brushing up on ARM assembler might be advisable too…

Norman, I posted some GPIO read/write BASIC code to the GPIO thread in the General forum a while back. You might find it useful as a starting point as its designed for flat-out speed of reading and writing. You’ll find it posted on 17th November towards the bottom of the first page. It also gives an example of mapping the Pi’s GPIO registers into the RISC OS memory map.

Alternatively, for simplicity of use, you may prefer to use Tank’s GPIO module. It makes it easy do almost anything with the GPIO lines, at the expense of a certain amount of speed.

Finally, there’s a very useful book just been published by Bruce Smith – A Hands On Guide to Assembly Language on the Raspberry Pi – which features RISC OS and BBC BASIC’s in-line assembler throughout the text. It’s a very handy RISC OS reference to have on hand – I have a copy and can recommend it (it uses 32-bit compatible code examples of course). More info is available on Bruce Smith’s website.

In fact, I think we’re a bit spoilt here in RISC OS land as this may be the only R-Pi specific book to have been published so far, apart from the Foundation’s own beginner’s guide. And as there are only occasional references to the Pi in the text, it could really be re-titled ‘RISC OS Assembly Language – A Beginner’s Hands On Guide’.

<In fact, I think we’re a bit spoilt here in RISC OS land as this may be the only R-Pi specific book to have been published so far, apart from the Foundation’s own beginner’s guide. And as there are only occasional references to the Pi in the text, it could really be re-titled ‘RISC OS Assembly Language – A Beginner’s Hands On Guide’.>

…Which was published 25 years ago in 1988 (I have a copy of both books too;-) Bruce Smith was then the publisher, who along with David Atherton formed the fledgling DABS company. Nice to see Bruce returning to his roots. Its amazing that ARM and RiscOS is still ‘on the go’ 25 years later ! If you set the clock back 25 years from 1988 the Beatles were becoming famous and English Electric were building KDF9s and KDF7s. Very little of the 1963 computer technology was still in use by 1988.

The RPi running RISCOS is really just a go-faster Acorn computer running on more modern hardware. Oh, and at a fraction of the price. Did I really pay GBP 1700 for my first RiscPC ?

Ralph

The RPi running RISCOS is really just a go-faster Acorn computer running on more modern hardware. Oh, and at a fraction of the price.

Hmmm. The thing on my desk at work is really just a go-faster DOS box with a bolt on GUI running on more modern hardware. :-)
Oh, and the price is much the same.
I think some people might be being ripped off.

@Patric
Thanks , I will have a look at this but see the rest of my post.

@DavidS
Probably surprises a lot of people including me. I think it could be well worth trying to do this in Basic first, even if it is only as proof of concept.
Had a quick look at Charm but at this stage it seems quite different so could be a steep learning curve, not that that has stopped me before :-)

@Rick
Thanks, I guess USR and SVC modes are similar in some ways to user and root mode or userland and kernel mode in Linux.
Yes I realised I would need more than 8 I/O pins and having looked at the spec for the AD7822 I figured 10 would be right.I will look at the links as well.

@Martin
Yes I have, for some things I have wanted to do, been able to create a group, add myself to it and change permissions to do what I wanted but obviously it depends on the nature of the problem.

@Neil
Great, I will study your code, no doubt it will save me some work. I have an O’Reilly safari bookshelf so, if it’s available, I will add the book and see if I can get my head around it. ( I’m 69 so things take longer to sink in these days! ). I find I feel more comfortable with some styles of writing. If it suits I will surely buy it as I find hard copy is easier than staring at the screen for hours.

@Ralph
Ahh reminiscing, My 1K Ram zx81 and my 12K Ram Acorn Atom with inline assembler in the Basic.

Thanks guys I haven’t got a lot of time just now as we will be away on holiday soon for a few weeks but it’s given me a lot to think about.

Probably surprises a lot of people including me. I think it could be well worth trying to do this in Basic first, even if it is only as proof of concept.

I think we’d all be interested to know how well BASIC performs.

Thanks, I guess USR and SVC modes are similar in some ways to user and root mode or userland and kernel mode in Linux.

In the sense of a change of privilege, yes. However as Martin pointed out – “root” and non-root is an operating system abstraction so it is best left as a “SVC mode is like root in that it opens up otherwise inaccessible areas”. Any further comparisons would be faulty.

Yes I realised I would need more than 8 I/O pins and having looked at the spec for the AD7822 I figured 10 would be right.

It sounds like an interesting project. What I would like to ask you before to go off on holiday (someplace warm I hope!) is that you want to make an oscilloscope, right? What sort of input ranges will you have – could you plug the mains into it to see if the electricity is “noisy”? The ADC has a very specific input range, so how do you plan to step x down to the 0-2V required by the ADC?

I’m 69 so

…so? I’ve met some “old people” (early 70s I’d guess, exact age unknown) who could wipe the floor with any number of generic teenagers when it came to maths, philosophy, maths, grammar, maths, geography, and maths.

I include maths many times as it is quite fascinating to see a(n old) person look at something, make a frame that fits first time without having measured it, and then watch a younger person have to take it apart to understand how a mitred joint works.

Just because you are 69 doesn’t mean the grey matter splutters and gives up. You’re probably smarter and more capable than a disturbing percentage of school leavers…

[after all, look at the project you have set yourself]

I find hard copy is easier than staring at the screen for hours.

Oh yes. PDFs are great for quick reference. I have a bunch of datasheets on my phone.

If I won the lottery and had a pile of disposable cash, the first thing I’d do (you know, after the heart attack etc) would be to get the lot printed. On actual pieces of paper. I guess my mother corrupted me when she introduced me to these “book” things. I find printed documentation a LOT easier to work with than stuff on a screen. I’d probably be a lot more knowledgable about the OMAP3 (and my pet DM320) if I had paperwork. For starters, I could lie in bed and read it to make a change from my Haruhi Suzumiya light novels ;-) – all I have done with the PDF versions has been to look up things. I, frankly, can’t stand reading PDFs. It might be better with eInk, but is there an afforable eInk device that can correctly render a PDF like it is supposed to look?

Reminiscence…

Hehe, that’s the thing about getting older. There’s more to reminisc about. I tend to go on nostalgia kicks with ‘80s music claiming that this modern stuff is just no good – despite the fact that synthesisers featured heavily in the 80s (Erasure, Pet Shop Boys, etc) while some of the stuff I listen to from this era has a lot of real instruments (Within-Temptation [ http://www.youtube.com/watch?v=s1OnQ104_Xc ], anything by Yuki Kajiura [ http://www.youtube.com/watch?v=zJ-CLKqFScg ]). You think the words to songs are rubbish these days? Let’s line Adele’s “Set Fire To The Rain” [ http://www.youtube.com/watch?v=xBcMKwbMEcQ ] alongside Culture Club’s “Karma Chameleon” [ http://www.youtube.com/watch?v=JmcA9LIIXWw ] and see which one makes sense. Alternatively we could look at Beacon Blue’s “Dignity” [ http://www.youtube.com/watch?v=-3ueYxrA-Zs ]and favourably compare any song ever written against Rebecca Black’s “Friday” [ http://www.youtube.com/watch?v=kfVsfOSbJY0 ] (and that is including certain anime themes where the subbers resort to a literal translation because they gave up trying to work out what it was supposed to mean).
Fact is, music through the ages has had highlights and rubbish. I could point to the obvious – Elvis, Dylan, the other Dylan, Edith Pfiaff, Manilow, The Boss [ http://www.youtube.com/watch?v=vtQqQxD021Y ; if you don’t like Springsteen, skip to +6m and chill out as the pianist owns this song over and over and over ], Sinatra, Westenra [ http://www.youtube.com/watch?v=jUYPdKzEMXM ], Beatles, Duran Duran, The Cure, R.E.M., Jefferson Airplane [ http://www.youtube.com/watch?v=VZc-kPWWQvc ], Depeche Mode, Tears for Fears, Gene Clark, Red Hot Chili Peppers, AKB48 [ http://www.youtube.com/watch?v=fgESmgZ4ld8 ]…

Okay, I’m trolling with that last one. ;) Point is, I think “stuff we remember from our childhood” is better and more fondly remembered than anything else. For example, I have fond memories of “Oh L’Amour” (Erasure) although I refuse to listen to it now because I know if I did I would hate it. On the other hand, their “The Two Ring Circus” was spookily prophetic [ http://www.youtube.com/watch?v=XPNjcLAplsY ], not to mention their “Phantom Bride”. Hehe, my favourite bit of nostalgia is kicking the future with the past. Also known as “we never learn”.

[and if nothing else, it ought to be a seriously eclectic playlist for you guys!]

That’s another thing I need to look into. many scope probes attenuate the signal by 10x or 100x but equally an op-amp front end can amplify tiny signals. Plus you could probably use a resistor chain.

As to the holiday – well just going down to England to our daughter’s. It will be our 50th wedding anniversary and, as most of the family live down there ….

And I have ordered the book. I always liked coding the assembler stuff on my Acorn Atom

How far you go with the project depends on how well you need the oscilloscope to perform. One of the problems you will face is that your application will be interrupted from time to time; or, if you disable interrupts so that your waveform captures aren’t interfered with, RISC OS will malfunction in some way.

I would always look to get some dedicated hardware (e.g. an FPGA, probably with some external RAM) to perform the sampling and storage, and make your application control the dedicated hardware. But that reflects my background in test equipment design and use, digital signal processing, and hardware design.

Yes from what I have read FPGA’s are what are used in high speed scopes. Unfortunately I have absolutely no experience with these so I would be lost. If the FPGA had no RAM how would it compare to using an external ADC?

Would it be practical to program ans ATMega328 – as in an Arduino – to control the ADC but just to get instructions from the R.Pi as to sampling rate?
I have a Uno and took the micro-controller out, dropped a zif socket in it’s place and put the micro-controller back in.
In the past I have bought a few with optiboot on them then I have developed some code then put the micro-controller on my final circuit board with just the components needed for it to work independently.
Got a quality board here: http://www.protostack.com/boards

The FPGA would be a controller for the ADC and in fact the whole sampling process. Some FPGAs contain enough RAM to hold a decent number of samples (again, it depends on what performance you want; I have an oscilloscope next to me right now that has 4 channels with simultaneous sampling at 100 megasamples per second with a trace depth of 50k samples per channel; this is wonderful for zooming in, post capture, with a factor of up to 1000 times!)

An external microcontroller dedicated to the sampling process could be a useful way to go. It can have a really simple job, which means it wouldn’t need interrupts, which translates to no disturbance to the sampling process. There are lots of ARM boards around, some of which are remarkably cheap (there’s an LPC1114 board for under GBP10, for example, which I’ve used successfully), as well as Arduino.

Would it be practical to program ans ATMega328 – as in an Arduino – to control the ADC but just to get instructions from the R.Pi as to sampling rate?

The first question is, obviously, how fast can the ATMega go? The most important thing is to know precisely what speed your sampling runs at in order to create useful results.
To put this in a real-world context, imagine a door entry control system that can tell you which people came and went through the door, but couldn’t say exactly when…

That said, microcontrollers have the benefits of:

• Being able to (mostly) dedicate itself entirely to the task in hand with no issues of being interrupted by the OS, only by the I/O to the host when it is needed.
• If programming in assembler, you ought to be able to time your program down to the exact clock tick, so you will know how long everything will take.
• As an alternative, if you have a really fast part, you might be able to hook up an I/O pin to an 8MHz crystal or somesuch and just take samples every time that interrupts?

I think for this you will need a reasonably capable part – preferably something with an ADC built in (simplifies/optimises accessing the data) and a largish-event wodge of RAM that you can use it as a buffer.

For the sampling, I would say if you are going to be sampling at 8MHz, the simplest option would be to do so always. Then for the 4MHz mode, simply write every other sample to RAM, for the 2MHz mode, write every fourth sample to RAM, for 1Hz every eighth, and so on. Alternatively, if the data transfer to the host is quick, it might work better to sample at the fastest option always and just let the software on the host figure it out.

You might find this interesting – http://code.google.com/p/dsonano/

The DSO Nano is basically a project to take bits of an MP3 player and repurpose it into a little hand-held ‘scope. While most people think the stock firmware is crappy (open source, so better options exist), it runs at 1MHz (IIRC!) displaying a single trace on a 320×240 screen. There’s USB and an SD slot. Jeez, sounds like my Zen media player.

There’s a more in-depth write-up here: http://www.justblair.co.uk/seeed-studio-dso-nano-pocket-digital-storage-oscilloscope-review.html

I would say that this device is too limited for anything other than a very basic hobbyist. Heck, you can’t even poke around inside a Beeb with the DSO. As a guess, perhaps a minimum of 4MHz and definitely dual-trace. Radio hams may well require something meatier. ;-)

At any rate, it might be worthwhile looking at how this thing has been put together. It is an ARM Cortex M3 running at 72MHz.

Whoo-hoo – scrub that – look at this thing: http://www.seeedstudio.com/wiki/DSO_Quad

Insides of it: http://www.seeedstudio.com/blog/wp-content/uploads/2010/09/100826110546e2814a133ba587.jpg

Somebody has had some fun with the Quad: http://essentialscrap.com/dsoquad/

Aaaaanyway; it isn’t often you can poke around inside a ’scope to see what makes it tick. Now you can. Might give you some pointers to ways to do things in your own project?

Whoa there boy!
I started off thinking I would be using an ADC ( 2Msps ) directly connected to a bog standard R.Pi and write basic or C then we crept up a bit to 4 – 5 Msps → to riscos and maybe basic or c → bare metal assembly.
All these are good ideas but whatever else happens I need a shed load of thinking and planning.
No seriously guys I really really appreciate all your suggestions and I will definitely follow up on the links.
Hardly any experience with C, ancient Basic ( done on an HP150 in the 80’s) to start with then Visual basic (3). Inline assembly on my Acorn Atom (6502) and you’re thinking I can match professional kit! phew there’s confidence for you.
Still succeed or fail I can see I will be having some fun with this and, no doubt, learning a lot,

Well the ATMega328p in the arduino is clocked at 16 MHz for compatibility with something ( not found out yet ) but the MCU itself can be clocked at 20 MHz and that’s in spec for the device so I guess I could pa
lay around with that as well.