[Aeolos]

I have the perfect project for this! Generate a signal using the GPIO ports to drive a mirror and camera in a synchronized fashion.

Does anyone know if the RPi GPIOs can be driven at around 80KHz? I've seen reports that this is possible, but that the USB or video driver tends to lock the CPU for long times, messing with timings - but hopefully running on bare metal would take care of that.

[niccl]

And then if you want to get seriously weird, you could try the PRU on a Beaglebone Black. Two internal processors (almost) entirely separate from the main processor. They have a 200 MHz clock speed and can generate extremely accurate and deterministic time critical signals

[tdicola]

Yeah 80khz should be no problem. Even in Linux if you access the Pi's GPIO registers directly you can toggle pins in a tight loop at around 1-2mhz. As others mentioned though you might look at a small microcontroller though since the Pi is kind of overkill for generating a simple signal.

[bsder]

> Even in Linux if you access the Pi's GPIO registers directly you can toggle pins in a tight loop at around 1-2mhz.

Careful, this is strongly dependent upon the hardware, not Linux.

I seem to recall that people doing SWD programming can barely get the GPIO's to move faster than a couple of KHz.

I can tell you that, at least on the BeagleBone Black, you have to do some Linux driver voodoo to get better than a couple of KHz.

Edit: I stand corrected. Apparently the Broadcom chip in the RPi does much better than the TI one in the BeagleBone Black when driving baseline GPIO's.

[fpgaminer]

On the other hand, the BBB has two dedicated on-chip MCU's for driving the GPIO's.

[bsder]

True, but those are really annoying to program and are mostly meant for hard real-time rather than maximum speed.

The speed on the BBB for GPIO's is okay (I can get to about 12.5MHz with some care). It's more annoying that you actually have to be in supervisor mode to change the I/O direction of a GPIO pin.

[rdtsc]

Here is an example of a project driving a realtime camera with Beaglebone black.

http://www.erlang-factory.com/static/upload/media/1394631509...

There is a video for the presentation as well.

https://www.youtube.com/watch?v=OBGqVmzuDQg&list=UUKrD_GYN3i...

The trick is Bealgebone black has 2 co-processors PRUs and they can be used for realtime work:

http://beagleboard.org/pru

http://elinux.org/Ti_AM33XX_PRUSSv2

It is a programmable 200-MHz, 32-bit processor with single-cycle I/O so it can be used to toggling GPIO pins.

[asandweech]

This might be of interest: http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-...

[Aeolos]

Excellent, thanks!

So GPIO performance won't be a problem, but they note that OS multitasking can cause issues:

"What is not evident from the snapshots, however, is that due to multitasking nature of Linux, the GPIO manipulation is constantly interrupted for short periods when the CPU is doing something else, such as receiving or sending data over network, writing log files, etc"

Running on bare metal should take care of that, so the only remaining problem is how to synchronize the signal generation on the RPi with the recording of data on the host computer. (Sigh, if only RPi had a USB3 port...)

[brobinson]

>due to multitasking nature of Linux, the GPIO manipulation is constantly interrupted for short periods when the CPU is doing something else, such as receiving or sending data over network, writing log files, etc.

With a few simple tweaks (isolcpus + irqbalance + setting cpu affinity), you can get rid of the overwhelming majority of interruptions a specific userland program running on a Linux machine could encounter.

If this quote is talking about kernel context switches, choice of I/O scheduler and tick rate in the kernel could be tweaked for better performance.

[roywiggins]

You could probably use an Arduino for this, they connect to a computer using serial-over-USB.

You can do GPIO bit-twiddling pretty fast: http://skpang.co.uk/blog/archives/323

[timow1337]

The new raspberry pi zero can be run as a device, so you could use that.

[Aeolos]

O.o this $5 puppy could essentially replace the 1.5K National Instruments DAQ I'm using right now. Even better, I won't have to deal with their horrendous API documentation anymore.

Of course that would require a Linux kernel, so not bare metal anymore, but there might be a way to make this work!

Now I just need to get my hands on one, it's out of stock everywhere within a radius of 300km...

[ajb]

They haven't committed to making more, or if they do, to the $5 price point.

[Narishma]

They are making more, but they sell them faster than they can make them.

[ju-st]

Really?? Then the zero was a really shitty marketing move...

[jcoffland]

You could do this with much less than an RPi. I would recommend using an AVR or better yet a 555 timer if all you need is an 80KHz signal. Let me know if you want help with this I'm looking for projects like this or something much more complicated.

[Aeolos]

That's true, the reason I mentioned the RPi was because I happen to have one lying around. (Actually, I seem to remember there are a couple of AVR development boards lying around in the lab, so these might be worth a look.)

My project involves generating two analogue signals to drive a mirror (a sin wave on the x-axis and a staircase pattern on the y-axis), and a synchronized digital trigger signal for the camera. There are a number of configuration options that make this slightly more interesting than it looks at first (frequency, number of sin periods per staircase step, duty cycle and number of triggers per sin).

An implementation of this on a NI DAQ took the better part of a day and an implementation on a FPGA took roughly two weeks (mostly spent on familiarizing with the tools and communicating settings from the host.) I actually think an implementation on the RPi would be simpler than either, including wiring up simple DAQ.

[jcoffland]

I think you will run into real-time performance problems on the RPi.

[IshKebab]

I wouldn't recommend an AVR. That is outdated technology. Even Atmel mostly makes ARM microcontrollers now (and they are much nicer than their AVR ones).

[mrob]

AVRs are simple and reliable. You can read the whole datasheet and understand everything with much less effort than modern ARM MCUs. They've been around long enough that I have a lot of confidence in them. They're electrically more robust than most modern chips so they're hard to accidentally damage. There's a lot of community support available because of the popularity of Arduinos. Many tasks don't need anything more powerful. I think it would be foolish to discard AVRs as obsolete just because they're old.

[jcoffland]

AVRs are far from outdated. The AtXmega series is very powerful. It includes modern features such as DMA transfers. AVR chips are much easier to work with than ARM for certain applications. They are also lower power and cheaper. The OPs application would be significantly easier to implement on an AVR. On the RPi you would have to write a Linux kernel driver and deal with real-time issues. In the AVR you would create a few interrupt handlers and be done.

[niccl]

horses for courses. If you want a small microcontroller that has a very simple IO model then avr is great, and if you use something like an attiny they're cheap as ... chips.

[zokier]

At small scale the price difference is pretty meaningless or even non-existent. For example right now the cheapest AVR at quantity of 10 costs $0.837, while cheapest ARM is $0.714.

(prices checked from digikey)

[cmrdporcupine]

Or a Parallax Propeller