Archive

Posts Tagged ‘raspberry pi’

Raspbian for Raspberry Pi Boards Gets Upgraded to Debian Stretch

August 17th, 2017 9 comments

While Raspberry Pi boards support many different operating systems, Raspbian is by far the most popular option, and in the last two years the distribution was based on Jessie (Debian 8), the Raspberry Pi foundation has just announced it was now replaced by an update to Stretch (Debian 9).

The Jessie version is completely gone from Raspbian Download page, and you’ll only be offered to download “Raspbian Stretch with Desktop” or “Raspbian Stretch Lite”.

So what has changed compared to Jessie? Debian 9 changelog will list the main differences compared to Debian 8, but some modifications have also been made in Raspbian itself:

  • Version 3.0.1 of Sonic Pi “Live Coding Music Synth” app – See changelog
  • Chrome 60 stable with improved memory usage and more efficient code
  • Bluetooth audio is supported by the bluez-alsa package by default instead of PulseAudio
  • Better handling of “non-pi users”, as previously many applications assumed to be run by pi user.
  • SenseHAT extension added to Scratch 2
  • BroadPwn exploit fix to close a vulnerability in the firmware of the BCM43xx wireless chipset
  • Other minor bug fixes and UI improvements

If you already have Raspbian Jessie running in your board, and would like to upgrade to Raspbian Stretch, you can try to do so at your own risk by changing all occurrences of ‘jessie’ to ‘stretch’ in /etc/apt/sources.list and /etc/apt/sources.list.d/raspi.list, and running:

The Raspberry Pi foundation however recommends to back up your micro SD card first, as upgrading that way is not guaranteed to work in every circumstance.

Aspencore 2017 Embedded Markets Study – Programming Languages, Operating Systems, MCU Vendors, and More

August 15th, 2017 2 comments

Aspencore media group asked readers of their EE Times and Embedded.com websites to fill out an online survey about their embedded system projects. They got 1,234 respondents mostly from North America (56.3%), followed by Europe (25.2%), and Asia (10.6%). This resulted in a 102-page market study which you can download here. I’ve extracted a few slides to have a look at some of the trends.

My current embedded project is programmed mostly in:

C language is still the most used language in embedded systems, but other languages like C++, Python and even assembly language are gaining traction.

Please select ALL of the operating systems you are currently using.

Operating system is more spread with Linux being the most used via Embedded Linux distributions, Debian, and Ubuntu. FreeRTOS comes in second place, while Android registers fourth with 13%.

Which of the following Version Control software systems do you currently use?

Git has finally supplanted Subversion in 2017, with all other version control software losing ground.

Did you start your current embedded design with a development board?

Switching to some hardware slides, 44% used a development board to start their embedded design with ST Microelectronics, Texas Instruments and Xilinx at the top three.

Which form factor boards are you currently using, and considering using ?

Most used custom or proprietary form factors in their designs, and I’m actually surprised at the rather large number of designs using low cost boards form factors such as the ones used in Arduino, Raspberry Pi, or BeagleBone boards. The “considering using” for Raspberry Pi is particularly high. The question does not clearly states whether it’s for evaluation / prototyping only, or in the end product however.

Please select the processor vendors you are currently using.

The chart is a little confusion due to the recent M&A activity, but Texas Instruments, Freescale (now NXP) and Atmel (Now Microchip) take the top three spots. You cannot add Freescale (26%) and NXP (17%), or Atmel (26%) and Microchip (25%), since some respondents may have already selected both. Renesas is only at 9%, but it was only second to NXP (Freescale + NXP) in MCU market share in 2016, so maybe the apparent discrepancy is due to the sampling in the survey with the majority of respondents from the US & Canada, which may also explain why Greater China companies like Holtek, or CEC Huada Electronic Design do not register at all.

You’ll find many more interesting slides in the full study.

Fedora 26 Supports Single “Unified” OS Images for Multiple ARM Platforms

August 14th, 2017 29 comments

The decision to use device tree in Linux occurred several years ago, after Linus Torvalds complained that Linux on ARM was a mess, with the ultimate goal of providing a unified ARM kernel for all hardware. Most machine specific board files in arch/arm/mach-xxx/ are now gone from the Linux kernel, being replaced by device tree files, and in many case you simply need to replace the DTB (Device Tree Binary) file from an operating system to run on different hardware platforms. However, this is not always that easy as U-boot still often differ between boards / devices, so it’s quite frequent to distribute different firmware / OS images per board. Fedora has taken another approach, as the developers are instead distributing a single Fedora 26 OS ARMv7 image, together with an installation script.

Images for 64-bit ARM (Aarch64) are a little different since they are designed for SBSA compliant servers, so a single image will work on any server leveraging UEFI / ACPI implementation on the hardware. So what follows is specific to ARMv7 hard-float images as explained in the Wiki.

You’ll need to install Fedora Arm installer after downloading one of the Fedora 26 images. This requires an Fedora machine, and since I’m running Ubuntu 16.04, and don’t want to setup a Fedora virtual machine in Virtualbox, I used docker instead right inside Ubuntu as it’s much faster to do:

The last line requires some explanation. /media/hdd is the mount point of the storage device on the host where I download the Fedora image and that will be accessible through /mnt in docker, /dev/sdd is my micro SD card device, while /dev/sdd3 will be the rootfs partition.Note that it took me a while to get that right, and I’m not sure it works for all targets (other other /dev/sddx are also needed), so using an actual Fedora 26 installation would be easier. The rest of the instructions below are not specific to docker.

I could then install the Fedora ARM Installer and the required xz & file packages…

…and check the usage:

Let’s see how many boards are supported in /usr/share/doc/fedora-arm-installer/SUPPORTED-BOARDS file:

AllWinner Devices:
A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM
A20-OLinuXino-Lime A20-OLinuXino-Lime2 A20-OLinuXino_MICRO
A20-Olimex-SOM-EVB Ampe_A76 Auxtek-T003 Auxtek-T004 Bananapi Bananapro CHIP
CSQ_CS908 Chuwi_V7_CW0825 Colombus Cubieboard Cubieboard2 Cubietruck
Cubietruck_plus Hummingbird_A31 Hyundai_A7HD Itead_Ibox_A20 Lamobo_R1
Linksprite_pcDuino Linksprite_pcDuino3 Linksprite_pcDuino3_Nano MK808C
MSI_Primo73 MSI_Primo81 Marsboard_A10 Mele_A1000 Mele_A1000G_quad Mele_I7
Mele_M3 Mele_M5 Mele_M9 Mini-X Orangepi Orangepi_mini Sinlinx_SinA31s
UTOO_P66 Wexler_TAB7200 Wits_Pro_A20_DKT Yones_Toptech_BS1078_V2 ba10_tv_box
colorfly_e708_q1 difrnce_dit4350 dserve_dsrv9703c i12-tvbox iNet_86VS
icnova-a20-swac inet86dz jesurun_q5 mk802 mk802_a10s mk802ii orangepi_2
orangepi_lite orangepi_pc orangepi_plus polaroid_mid2809pxe04
pov_protab2_ips9 q8_a13_tablet q8_a23_tablet_800x480 q8_a33_tablet_1024x600
q8_a33_tablet_800x480 r7-tv-dongle sunxi_Gemei_G9

MX6 Devices:
cm_fx6 mx6cuboxi novena riotboard wandboard

OMAP Devices:
am335x_boneblack am57xx_evm kc1 omap3_beagle omap4_panda omap5_uevm

MVEBU Devices:
clearfog

ST Devices:
stih410-b2260

Other Devices:
jetson-tk1 rpi2 rpi3 trimslice

So we’ve got a list of device to choose from. For example, if you wanted to install Fedora 26 server in a micro SD card for Raspberry Pi 3, you’d run something like:

You’ll then be ask to confirm:

The full process will take several minutes, and at the end you’ll get “_/” rootfs partition, “_/boot ” partition, and a “30 MB volume” with u-boot, config,etc…


I did not try the micro SD card in Raspberry Pi 3 board myself, because Geek Till It Hertz has already done it successfully on both RPi 3 and Banana Pi boards as shown in the video below.

He also showed the boards run Linux 4.11.8 version, but that can be upgraded with dnf update to Linux 4.11.11, just as on his Fedora 26 installation on a x86-64  computer.

VoltaStream ZERO NXP i.MX6ULL Linux Audio Board Follows Raspberry Pi Zero Form Factor

August 10th, 2017 20 comments

Back in 2013. Philip came with the idea of designing a development board for audio application, and after various experiments with off-the shelf Raspberry Pi boards and audio DACs,  he founded PolyVection company, and started designing the board. Forwarding to today, he has completed his work and introduced VoltaStream ZERO to the world, a board based on NXP i.MX6ULL processor with 512MB or 1GB RAM, and a choice of Texas Instruments DAC. It also follows Raspberry Pi Zero form factor, like the upcoming Banana Pi BPI-M2 Zero board.

Click to Enlarge

VoltaStream ZERO specifications:

  • SoC – NXP i.MX6ULL ARM Cortex-A7 processor @ 996 MHz
  • System Memory – 512 MB or 1 GB DDR3
  • Storage – micro SD card slot
  • Audio
    • 1x I2S for integrated DAC, 1x I2S for GPIO access, 1x S/PDIF header / TOSLINK jack
    • Analog DAC – Texas Instruments PCM5121 (106 dB) or PCM5142 (112 dB)
  • USB – 1x micro USB slave port (USB gadget mode supported), 1x USB type A host port
  • Expansion Headers – 40-pin GPIO header with 5V, 3V3, GND, 2x UART, flexCAN, 2x I2C, SPI, I2S, 3x PWM, S/PDIF input
  • Misc – On/Off switch integrated button handler / accessible from header, RTC integrated into SoC
  • Power Supply – 5V via micro USB port or GPIO header;
  • Power consumption
    • 0.10 Watt – Linux suspend
    • 0.25 Watt – Linux idle
    • 1.10 Watt – USB WiFi busy
  • Dimensions – 65 mm x 30 mm (Raspberry Pi Zero form factor)

Note there’s no network connectivity, but that’s what the USB host port cam be used for by connecting a USB WiFi dongle or USB Ethernet dongle.

 

VoltaStream Zero with Case

The board has been designed with KiCAD 4.0.5, and the schematics and PCB layout files have been released in Github under the Creative Commons BY-NC-ND 3.0 license. The company has developed a Linux distribution called PolyOS, built with the Yocto Project, and that includes shairport-sync, librespot, DLNA renderer and a special atomic updater. A generic Debian distribution (PolyBian) is also available, and work is being done to support Volumio. Documentation with a getting started guide, and a system reference manual has also been published.

You’ll find all those resources on the product page, where you can also purchase the board starting at 41.93 Euros excluding VAT and shipping, for the 512 MB RAM / PCM5121 version.

Movidius Neural Compute Stick Shown to Boost Deep Learning Performance by about 3 Times on Raspberry Pi 3 Board

August 9th, 2017 14 comments

Intel recently launched Movidius Neural Compute Stick (MvNCS)for low power USB based deep learning applications such as object recognition, and after some initial confusions, we could confirm the Neural stick could also be used on ARM based platforms such as the Raspberry Pi 3. Kochi Nakamura, who wrote the code for GPU accelerated object recognition on the Raspberry Pi 3 board, got hold of one sample in order to compare the performance between GPU and MvNCS acceleration.

His first attempt was quite confusing as with GoogLeNet, Raspberry Pi 3 + MvNCS achieved an average inference time of about 560ms, against 320 ms while using VideoCore IV GPU in RPi3 board. But then it was discovered that the “stream_infer.py” demo would only use one core out of the 12 VLIW 128-bit vector SHAVE processors in Intel’s Movidius Myriad 2 VPU, and after enabling all those 12 cores instead of just one, performance increased to around 108 ms average time per inference. That’s almost 3 times faster compare to using the GPU in RPi3 for this specific demo, and it may vary for other demos / applications.

That’s the description in YouTube:

Comparison of deep learning inference acceleration by Movidius’ Neural Compute Stick (MvNCS) and by Idein’s software which uses Raspberry Pi’s GPU (VideoCore IV) without any extra computing resources.

Movidius’ demo runs GoogLeNet with 16-bit floating point precision.Average inference time is 108ms.
We used MvNC SDK 1.07.07 and their official demo script without any changes. (ncapi/py_examples/stream_infer/stream_infer.py)
It seems something is wrong with the inference results.
We recompiled graph file with -s12 option to use 12 SHAVE vector processor simultaneously.

Idein’s demo also runs GoogLeNet with 32-bit floating point precision. Average inference time is 320ms.

It’s interesting to note the GPU demo used 32-bit floating point precision, against 16-bit floating point precision on the Neural Compute Stick, although it’s unclear to me how that may affect performance of such algorithms. Intel recommends a USB 3.0 interface for MvNCS, and the Raspberry Pi 3 only comes with a USB 2.0 interface that shares the bandwidth for the USB webcam and the MvNCS, so it’s possible an ARM board with a USB 3.0 interface for the stick, and a separate USB interface for the webcam could perform better. Has anybody tested it? A USB 3.0 interface and hub would also allow to cascade several Neural Compute Sticks.

Work on VideoCore V GPU Drivers Could Pave the Way for Raspberry Pi 4 Board

August 8th, 2017 26 comments

I’ve come across an article on Phoronix this morning, about VideoCore IV GPU used in Broadcom BCM283x “Raspberry Pi” processors, but part of the post also mentioned work related to VC5 drivers for the next generation VideoCore V GPU, written by Eric Anholt, working for Broadcom, and in charge of the open source code related to VideoCore IV GPU for Raspberry Pi. This led me Eric’s blog “This Week in VC4/VC5” and articles such as “2017-07-10: vc5, raspbian performance“, where he explains he committed Mesa drivers for VC5.

I’ve just pushed a “vc5” branch to my Mesa tree (https://github.com/anholt/mesa/commits/vc5). This is the culmination of a couple of months of work on building a new driver for Broadcom’s V3D 3.3. V3D 3.3 is a GLES3.1 part, though I’m nowhere near conformance yet. This driver is for BCM7268, a set-top-box SOC that boots an upstream Linux kernel. I’m really excited to be working on a modern GLES implementation, and one that has its core platform support upstream already.

Raspberry Pi 3 is a nice little board, but competition is building with features not found in the RPi foundation board such as Gigabit Ethernet, USB 3.0, 4K video playback and so on. So even though, Eben Upton has clearly said he was in no rush in releasing Raspberry Pi 4, this will happen at some time, and in order to leverage part of existing software it would make sense to use an upgrade to VideoCore IV GPU like VideoCore V.

So I’ve tried to find more information about BCM7268 SoC, and information is quite limited. We know it’s designed for 4K Ultra HD set-top boxes, and features four cores delivering up to 14,000 DMIPS. Some speculated that the processor could be used in Raspberry Pi 4, but Jamesh – Raspberry Pi Engineer & Forum Moderator – poured cold water on the idea:

That’s a set top box chip, doesn’t cover the requirements for the next gen Pi.

So I tried to specifically find more details about the GPU, but again information is limited. The GPU supports OpenGL ES 3.1, and VideoCore V (V3D-530) is about 2.4 times faster than VideoCore IV (V3D-435) in T-Rex GFXBench benchmark on dual core development boards. We don’t know the GPU frequency however, so that’s just for reference.

Anyway, there’s still plenty of time to find out since the “official” timeline for Raspberry Pi 4 is sometimes in 2019.

RakWireless RAK831 LoRa Gateway Module is Based on Semtech SX1301 Base Band Processor

August 6th, 2017 7 comments

We’ve previously covered several products from RakWireless, with a Realtek WiFi IoT board, a WiFi camera board, and a Amazon Alexa compatible audio board. The company has now launched RAK831, a LoRaWAN gateway board powered by Semtech SX1301 base band processor, and working with their RAK811 LoRa node or other compatible nodes.

Click to Enlarge

RAK831 LoRA gateway board specifications:

  • Connectivity
    • Semtech SX1301 base band processor with LoRa concentrator IP
    • Frequency bands – 433, 470, 868, or 915 MHz
    • Sensitivity – Down to -142.5 dBm
    • Maximum link budget – 162 dB
    • Output power level – up to 23 dBm
    • Emulates 49 x LoRa demodulators
    • 12x parallel demodulation paths
    • 1x (G)FSK demodulator
    • 2x SX1257 Tx/Rx front-ends high frequencies
    • 2x SX1255 Tx/Rx front-ends low frequencies
    • Range  – Up to 15 km (Line of Sight); several kilometers in urban environment
  • GNSS – Optional GPS support
  • Host Interface – SPI
  • Expansion – 24-pin 2.54mm pitch “DB24” header with access to SPI, 5x GPIOs, radio related signals, and +5V / GND
  • Misc – Status LEDs
  • Power Supply – 5V
  • Dimensions – size 80.0 x 50.0 x 5.0mm

The board can be used for various applications such smart metering, wireless star networks, home/building/factory automation, wireless sensors, wireless alarm & security systems, and so on. The guide start guide found in the documentation page, explains you’ll need a USB to SPI adapter board, for example based on FT2232HL chip,connected to an Ubuntu computer, or instead a board with an SPI interface running Ubuntu, or other Linux distribution. Finally, you’ll need to install  the software found in RAK831_LoRaGateway Github repository.

The company has also sent beta samples to several testers, and one of them – Naresh Krish – wrote a guide to use RAK831 with Raspberry Pi 3 board, registering the WiFi <-> LoRa gateway with TheThingsNetwork, and connecting to a RAK811 node.

RAK831 gateway is for $120 and up on Aliexpress for 433 MHz, 868 MHz or 915 MHz frequencies, or $125 if you want to add the acrylic case shown above. You may find additional details on the product page.

Gumstix Pi Conduit Gateway Board Leverages Raspberry Pi Compute Module, Off-the-Shelf LoRa and Cellular Modules

August 4th, 2017 No comments

Gumstix has designed Pi Conduit Gateway baseboard for both the Raspberry Pi Compute Module and RisingRF RHF0M301 LoRa gateway module, in order to create a Linux based LoRa gateway that can optionally support LTE or other cellular connectivity via NimbeLink Skywire cellular modem.

Conduit Pi LoRa Gateway board specifications:

  • 200-pin SO-DIMM connector for Raspberry Pi Compute Module / Raspberry Pi 3 Compute Module (CM3 / CM3L)
  • Headers for RisingRF RHF0M301 LoRa Module
  • NimbeLink Skywire 2G/3G/4G cellular modem connector
  • Low profile 10/100M Ethernet jack (implemented via USB 2.0)
  • USB – 1x micro USB port for debugging via an FTDI USB to TTL chip
  • Misc – User (GPIO5) and reset buttons
  • Power Supply – 5V via power barrel

The board was designed using Geppetto, which means you should be able to customize it to your needs by modifying it the original design in a web browser, and order your brand new custom board from there.

Let’s have a closer look at the LoRa and LTE modules – pictured above – for the baseboard:

  • RisingRF RHF0M301 LoRa Gateway and Concentrator Module:
    • 10 channels (8 x Multi-SF + 1 x Standard LoRa + 1 x FSK) LoRa/LoRaWAN gateway or concentrator module.
    • RF input power – less than -13dBm
    • Frequency ranges (SKU dependent) – 430MHz ~ 437MHz; 470MHz ~ 490MHz; 779MHz ~ 787MHz; 859MHz ~ 870MHz; 900MHz ~ 930MHz
    • Host Interface – SPI
    • 24 pins DIP header
    • Operating voltage – <= 6V
    • Dimension – 40 x 63 mm
    • Temperature range – -40°C to +85°C
  • NimbeLink Skywire cellular modem modules:
    • 2x 10-pin headers
    • Several models for 2G CDMA, 2G GPRS, 3G EVDO, 3G HSPA+, LTE Cat 1/3/4, or LTE Cat M1
    • GPS supported on some models
    • Interfaces – XBee Standard, UART, and USB (on some models only)
    • Operating voltage – Depends on module (
    • Dimensions – 33 x 29 x 10.5 mm
    • Temperature range – -40°C to +85°C

Gumstix are known for their Overo modules based on Texas Instruments OMAP/Sitara processors, so they’ve also made an Overo Conduit Gateway using Overo modules instead of the Raspberry Pi SoMs, but only supporting RisingRF LoRa module, not the cellular ones. The video below gives an overview of the new Gumstix LoRa solutions and how to customize the board in Geppetto.

Pi Conduit Gateway board is sold for $84, but bear in mind that you need to add the price of the Raspberry Pi Compute Module, RisingRF module, and optionally NimbeLink Skywire cellular mode. The Overo baseboard is quite cheaper, and also customizable at $59. Visit Gumstix LoRaWAN family page for the full details.