As open as the Raspberry Pi Foundation has been about their beloved products, they would be the first to admit there’s always more work to be done: Getting a Pi up and running still requires many closed proprietary components. But the foundation works to chip away at it bit by bit, and one of the latest steps is the release of a camera stack built on libcamera.
Most Linux applications interact with the camera via V4L2 or a similar API. These established interfaces were designed back when camera control was limited and consisted of a few simple hardware settings. Today we have far more sophisticated computational techniques for digital photography and video. Algorithms have outgrown dedicated hardware, transforming into software modules that take advantage of CPU and/or GPU processing. In practice, this trend meant bigger and bigger opaque monolithic pieces of proprietary code. Every one a mix of “secret sauce” algorithms commingling with common overhead code wastefully duplicated for each new blob.
We expect camera makers will continue to devise proprietary specialties as they seek a competitive advantage. Fortunately, some of them see benefit in an open-source framework to help break up those monoliths into more manageable pieces, letting them focus on just their own specialized parts. Leveraging something like libcamera for the remainder can reduce their software development workload, leading to faster time to market, lower support cost, and associated benefits to the bottom line that motivates adoption by corporations.
But like every new interface design borne of a grandiose vision, there’s a chicken-and-egg problem. Application developers won’t consume it if there’s no hardware, and hardware manufacturers won’t implement it if no applications use it. For the consumer side, libcamera has modules to interop with V4L2 and other popular interfaces. For the hardware side, it would be useful to have a company with wide reach who believes it is useful to open what they can and isolate the pieces they can’t. This is where the Raspberry Pi foundation found a fit.
The initial release doesn’t support their new High-Quality Camera Module though that is promised soon. In the short term, there is still a lot of work to be done, but we are excited about the long term possibilities. If libcamera can indeed lower the barrier to entry, it would encourage innovation and expanding the set of cameras beyond the officially supported list. We certainly have no shortage of offbeat camera sensor ideas around here, from a 1-kilopixel camera sensor to a decapped DRAM chip.
Transmitting video signals over long distances can be tricky. Cheap co-ax cables won’t do the job. You either need amplifiers along the path, or need to use expensive, high quality shielded co-ax cables – both of which can end up costing a lot. [Maurizio] built a low cost solution to transmit video over long distances using twisted pair cables.
The system is cheap and uses readily available parts. The idea is to convert the video signal into a differential output using a pair of op amps and transmit them over a pair of twisted pair wires, then extract the signal at the receiving end using another amplifier.
A differential amplifier usually requires a dual-polarity power supply, which may not be available when adding this upgrade to an existing system. To over come this limitation, [Maurizio] uses a bias voltage equal to half of the power supply value. This bias voltage is added to the non-inverting amplifier signal, and subtracted from the inverting amplifier signal. The resultant differential signal is then fed into the twisted pair cable through impedance matching resistors. At the receiving end, a single amplifier receives the differential signals and outputs a signal that corresponds to the original video signal.
This symmetrical configuration renders the system immune to external noise. The design was tested for transmitting video on inexpensive CAT-3 twisted pair wire. According to him, when transmitting on 300m of wire, good quality color video was displayed on a monitor with an NTSC input. He used LMH6643 op-amps for this experiment, but other devices with similar characteristics can be used. Here’s a useful PDF document that discusses signals, cables and connections.
If you want to check out more of [Maurizio]’s work, see how he figured out how to send serial data from Excel.
A few months ago, the Intel Edison launched with the promise of putting a complete x86 system on a board the size of an SD card. This inevitably led to comparisons of other, ARM-based single board computers and the fact that the Edison doesn’t have a video output, Ethernet, or GPIO pins on a 0.100″ grid. Ethernet and easy breakout is another matter entirely but [Lutz] did manage to give the Edison a proper display, allowing him to run Doom at about the same speed as a 486 did back in the day.
The hardware used for the build is an Edison, an Arduino breakout board, Adafruit display, speaker, and PS4 controller. By far the hardest part of this build was writing a display driver for the Edison. The starting point for this was Adafruit’s guide for the display, but the pin mapping of the Edison proved troublesome. Ideally, the display should be sent 16 bits at a time, but only eight bits are exposed on the breakout board. Not that it mattered; the Edison doesn’t have 16 pins in a single 32-bit memory register anyway. The solution of writing eight bits at a time to the display means Doom runs at about 15 frames per second. Not great, but more than enough to be playable.
For sound, [Lutz] used PWM running at 100kHz. It works, and with a tiny speaker it’s good enough. Control is through Bluetooth with a PS4 controller, and the setup worked as it should. The end result is more of a proof of concept, but it’s fairly easy to see how the Edison can be used as a complete system with video, sound, and wireless networking. It’s not great, but if you want high performance, you probably won’t be picking a board the size of an SD card.
Video demo below.
Continue reading “Running Doom On The Intel Edison”
For the Raspberry Pi’s second birthday, the Raspi foundation gave us all a very cool gift. Broadcom released the full documentation for the graphics on one of their cellphone chips and offered up a $10k prize to the first person to port that code over to the graphics processor on the Pi and run Quake III. The prize has been claimed, forming the foundation for anyone wanting a completely documented video core on the Pi.
The person to claim this prize is one [Simon Hall], author of the DMA module that’s in the current Raspbian release. Even though Quake III already runs on the Pi, it does so with a closed source driver. [Simon]’s work opens up the VideoCore in the Pi to everyone, especially useful for anyone banging their heads against the limitations of the Pi platform.
You can get your hands on the new video drivers right now, simply by downloading and compiling all the sources. Be warned, though: recompiling everything takes around 12 hours. We’re expecting a Raspbian update soon.