6 ms·

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

by Aeolos 11y ago

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.

asandweech 11y ago
This might be of interest: http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-...
- Aeolos 11y ago
  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...)
  - timow1337 11y ago
    The new raspberry pi zero can be run as a device, so you could use that.
    - Aeolos 11y ago
      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 11y ago
        They haven't committed to making more, or if they do, to the $5 price point.
        ju-st 11y ago
        Really?? Then the zero was a really shitty marketing move...
        Narishma 11y ago
        They are making more, but they sell them faster than they can make them.
  - brobinson 11y ago
    >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 11y ago
    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 http://skpang.co.uk/blog/archives/323
jcoffland 11y ago
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.
- IshKebab 11y ago
  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).
  - niccl 11y ago
    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 11y ago
      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)
  - mrob 11y ago
    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 11y ago
    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.
tdicola 11y ago
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 11y ago
  > 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 11y ago
    On the other hand, the BBB has two dedicated on-chip MCU's for driving the GPIO's.
    - bsder 11y ago
      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.
niccl 11y ago
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
rdtsc 11y ago
Here is an example of a project driving a realtime camera with Beaglebone black. http://www.erlang-factory.com/static/upload/media/1394631509395316frankhunleth.pdf 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_GYN3iDpG_uMmADPzJQ 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://beagleboard.org/pru http://elinux.org/Ti_AM33XX_PRUSSv2 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.

by Aeolos 11y ago

asandweech 11y ago

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

Aeolos 11y ago
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...)
- timow1337 11y ago
  The new raspberry pi zero can be run as a device, so you could use that.
  - Aeolos 11y ago
    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 11y ago
      They haven't committed to making more, or if they do, to the $5 price point.
      - ju-st 11y ago
        Really?? Then the zero was a really shitty marketing move...
      - Narishma 11y ago
        They are making more, but they sell them faster than they can make them.
- brobinson 11y ago
  >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 11y ago
  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 http://skpang.co.uk/blog/archives/323

jcoffland 11y ago

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.

IshKebab 11y ago
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).
- niccl 11y ago
  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 11y ago
    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)
- mrob 11y ago
  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 11y ago
  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.

tdicola 11y ago

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 11y ago
> 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 11y ago
  On the other hand, the BBB has two dedicated on-chip MCU's for driving the GPIO's.
  - bsder 11y ago
    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.

niccl 11y ago

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

rdtsc 11y ago

Here is an example of a project driving a realtime camera with Beaglebone black. http://www.erlang-factory.com/static/upload/media/1394631509395316frankhunleth.pdf 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_GYN3iDpG_uMmADPzJQ 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://beagleboard.org/pru http://elinux.org/Ti_AM33XX_PRUSSv2 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.