Archive

Posts Tagged ‘sdk’

Design Amazon Alexa Gateways, Robots and Smart Speakers with WisCore Modular Development Kit

June 17th, 2017 3 comments

RAK Wireless has launched a new development board powered by Mediatek MT7628A processor running OpenWrt with built-in WiFi and Ethernet connectivity, and audio codec and microphone to support Amazon Alexa voice service. Bluetooth, Zigbee, and Z-wave will also be supported via UART modules.

Wiscore Specifications:

  • Processor – Mediatek MT7628A MIPS24KEc CPU @ up to  580MHz
  • System Memory –  128MB DDR2 (64 MB optional)
  • Storage – 16 MB flash + micro SD card

    Block Diagram – Click to Enlarge

  • Audio
    • MicroSemi ZL38062 for audio in and out
    • MicroSemi ZL38067 to handle “Alexa” keyword
    • single or dual digital microphone up to 5 meter range
    • Far field voice wake up
    • Support for echo cancellation
  • Connectivity
    • 802.11 b/g/n WiFi 2×2 MIMO up to 300 Mbps
    • 2x 10/100M Ethernet (LAN and WAN)
    • Optional UART modules for Bluetooth, ZigBeem Z-Wave
  • USB – 1x USB 2.0 host port
  • Expansion – Arduino headers with UART, I2C, SPI and GPIOs
  • Power Supply – 5V via power barrel or mini USB port

As you can see from the photo below, the main components are on separate boards (for some reasons) with a “mother board”, MT7628 module, and an audio sub-board.

As mentioned in the introduction, the MT7628 module runs an OS based on OpenWrt with RAK iGate middleware, and the company provides an SDK allowing you to develop solutions based on Amazon Alexa thanks to one codec that will detect “Alexa” keyword and wake up to the board, and another codec handling audio capture and output. The software architecture is shown below, Wiscore app for Android and iOS is provided to pair the EVK with Alexa, and more documentation and software can be found in the Wiki on Github.

WisCore Software Architecture

The solution can be used to build voice controlled home automation gateways or appliances, smart speakers, and robots. RAK Wireless sells a development kit with the three boards, an Ethernet cable, a speaker, a USB cable, two antennas, some Dupont wires, some jumpers, and a Quick Start Guide for $49 plus shipping. Visit the product page for a few more details.

Olimex ESP32-EVB Board with Ethernet, CAN Bus, and Relays up for Sale for 26 Euros

May 30th, 2017 3 comments

One of the new feature of Espressif ESP32 SoC over ESP8266 is the inclusion of an Ethernet MAC interface, but so far few boards come with an RJ45 jacks. ESP32 Monster board is an option, also including an OLED Display and CAN Bus, and sold on Tindie for $35, but Olimex has now stocked their ESP32-EVB board with Ethernet, CAN Bus, and two relays, and you can purchase it for 26 Euros per unit, and less in larger quantities.

Olimex ESP32-EVB Rev. B specifications:

  • Wireless Module – ESP32-WROOM32 module with 802.11 b/g/n WiFi and Bluetooth LE
  • Wired Connectivity – 10/100M Ethernet with RJ45 jack (via LAN8710A)
  • External Storage – micro SD slot
  • Relays – 2x 10A/250VAC relays with LED status
  • Expansion
    • 40-pin GPIO female header (2.54mm pitch)
    • UEXT connector for sensors and modules
    • CAN Bus
  • USB – 1x micro USB port for debugging (CH340T) and power
  • Misc – Reset and user buttons, IR receiver and transmitter with up to 5 meter range
  • Power Supply
    • 5V via power jack or micro USB port
    • LiPo charger and step up converter allowing ESP32-EVB to run from LiPo battery
  • Dimensions – 75 x 75 mm

The specifications are a little different compared to the Rev. A prototype shown in February, as they added IR transmitter and receiver, a CAN bus, and a micro USB port for debugging, which increases the size of the PCB, and also explains why the price went up from an expected 22 Euros to 26 Euros for the final board.

The board is open source hardware, and you’ll find hardware design files on Github. The software directory is empty for now, but the Tindie page about ESP32 Monster board indicates that “Ether and CAN programming requires ESP-IDF environment and still not by Arduino IDE”, so if you want to use the latter you may have wait a little longer. Olimex is also planning for a color 2.8″ LCD 320×240 pixel display board connected through UEXT header.

Banana Pi BPI-M2 Berry Allwinner V40 Development Board, Allwinner Business Units & SDK/Software Management

May 29th, 2017 34 comments

SinoVoIP has unveiled yet another new board with Banana Pi BPI-M2 Berry this week-end. It’s actually quite similar to Banana Pi BPI-M2 Ultra board, by they replaced Allwinner R40 with Allwinner V40 processor, removed some features, and use Raspberry Pi 3 form factor. If we look at Allwinner V40 product brief we can see the specifications look almost identical, with V40 potentially exposing an extra CAN bus. The company’s announcement was very confusing since they show Banana Pi BPI-M2 Berry board with Allwinner R40 instead of Allwinner V40.

Banana Pi BPI-M2 Berry specifications:

  • SoC – Allwinner V40 quad Core ARM Cortex A7 processor with ARM Mali-400MP2 GPU
  • System Memory – 1G DDR3 SDRAM
  • Storage – micro SD slot, SATA interface
  • Connectivity – 1x Gigabit Ethernet port, 802.11 b/g/n WiFi and Bluetooth 4.0 (AP6212 module)
  • Video Output – HDMI 1.4 port up to 1080p60, 4-lane MIPI DSI display connector
  • Audio I/O – HDMI, 3.5mm headphone jack, built-in microphone
  • USB – 4x USB 2.0 host ports, 1x micro USB OTG port
  • Camera – CSI camera connector
  • Expansion – 40-pin Raspberry Pi compatible header with GPIOs, I2C, SPI, UART, ID EEPROM, 5V, 3.3V, GND signals.
  • Debugging – 3-pin UART for serial console
  • Misc – Reset, power, and u-boot buttons
  • Power Supply – 5V via micro USB port; AXP221s PMIC
  • Dimensions – 85mm x 56mm

The Wiki is also shared for BPI-M 2 Ultra/Berry boards. The company also showed a picture of BPI-M2 Ultra with Allwinner V40 confirming both processors are  pin-to-pin-compatible.

BPI-M2 Ultra Board with Allwinner V40 Processor

So why bother doing different processors since they are so similar? Last time, we were told Allwinner A64 and R18 had different SDKs, so it should be the same for R40 and V40. Allwinner has different family of processors dedicated to different market segments: A-series are application processors, H-series are for home entertainment, R-series for the IoT, and V-Series for video camera applications. In some ways, it makes sense to have different business units that specialize in specific market segments. If you customer wants to make an action camera redirect him to the V-series guys, a TV box that’s for H-series, and so on.

There’s been a long-ish discussion about Allwinner business units on CNX Software. What has apparently been happening is that some processors can be used across market segments, so they have duplicates (or close to it) with for example Allwinner A64/R18 that’s just the same chip but assigned to a different business unit. Each business unit work and release their own SDK, and based on different Linux and Android version for different SDK, there does not seem common work across business units, and they appear to have separate software teams.  The processors are differentiated by “CHIP ID”, and by default you can’t run firmware generated by R18 SDK on A64, and vice-versa, since the bootloader will detect the ID and prevent the software to run.  That also looks like a bad idea, since for example a software bug fixed on Allwinner R18 SDK, may go unnoticed on Allwinner A64 for years etc… So ideally all business units should get their software from a single team taking care of low level software (bootloader/kernel/drivers), middleware (Android/rootfs), while software developers’ part of a given business unit may work on the market specific software.

Jon had more insights on this business organization:

The R group is releasing a different SDK for the R18. They are not using the A64 one. That strongly suggests to me two sets of software people. A single software group would have simply added the R18 extras into the A64 SDK.

You want a centralized Linux and Android group. Then inside that group you develop specialists. For example the DMA person, the UART person, the Ethernet person, etc. That person is responsible for driver support over all of the CPUs Allwinner makes. They become experts on this piece of the SOC. The output of this group is a single SDK that supports all Allwinner processors. Like what mainline Linux is doing for Allwinner SOC currently. Not the single CPU kernels that AW keeps releasing.

Then you can give this central software group two instructions:
1) Add a new SOC to the existing base. Each specialist will extend their existing driver to add support for the new SOC. Not cut and paste then edit to make a new driver! That happens with separate groups.
2) Add support for a new kernel or Android release. Everyone in the group works together to bring all of the SOC support up to this new release. This is not that hard now since each expert in their niche will know exactly what the issues are.

The central group allows these vertical specialists to exist. Having the chip groups do it results in a lot of copy/paste/edit (which we see in spades) and many bugs because the work is having to be done by generalist assigned to the group. When the programmers belong to the hardware groups Allwinner is creating “port and forget” specialists.

and also mentioned it’s been tried before, and failed:

This awful management style was practiced by most of the US semiconductor industry in the 1990’s. Most have discovered that it was a really bad way to do things and have reorganized.

This management style occurs when chip people end up in top management at these SOC companies. They treat everything like a chip and software is definitely not a chip. But these “chip heads” don’t know much about software so they can’t see how bad this organization design is for long term support. You can’t blame the “chip heads” for acting this way, it is the only area they have worked in. What they are doing is the correct model for making chips.

Now I don’t have detailed internal org charts for Allwinner. But I used to work for US companies that had this exact management structure before realizing how messed up it was. Only after a couple of very expensive failed launches of new chips because the software supporting them didn’t work did management change.

Another not-directly related complain is that Allwinner will also release the source code as tarballs, and they don’t have a git (or other revision control system) repository accessible to customers, for example like Amlogic or Rockchip already do. Instead they release those large tarballs, and then linux-sunxi community may import the u-boot/Linux kernel part to github, and work on them, although those days, they may prefer to focus on mainline rather than on Allwinner SDK releases.

HiSilicon Hi3796M V200 UHD DVB + H.265 STB SoC Showcased at Broadcast Asia 2017

May 25th, 2017 6 comments

Broadcast Asia international digital multimedia & entertaiment technology exhibition & conference is taking place in Singapore on May 23 – 25, and I’ve been informed that Hisilicon showcased their latest Hi3796M V200 Set-top box SoC with support for 4K DVB, H.265, and high dynamic range technology such as HDR10, HLG and Dolby Vision.

Hiliscon Hi3796M V200 Board and DVB Tuner – Click to Enlarge

Key features and specifications of Hi3796M V200 processor:

  • CPU – Quad core ARM Cortex A53
  • GPU – ARM Mali-450MP
  • Memory – DDR3, DDR3L, DDR4
  • Video Output – 1x HDMI 2.0a Tx with HDCP 2.2
  • Video format – HEVC, H.264, MPEG2, MPEG4, VC1, VP9, AVS 2.0
  • HDR – HDR10, HLG, Dolby Vision, HDR and SDR conversion
  • HiVXE 2.0 VPU – Decoder – 4K60 10-bit; Encoder – HEVC/H.264 1080p30 or 2x 720p30
  • Ethernet – 1x Gigabit Ethernet, 1x Fast Ethernet
  • USB 2.0 – 2x USB 2.0 ports
  • SATA & PCIe & USB 3.0 – USB 3.0, SATA 3.0, PCIe 2.0 host interface (optional); cnxsoft’s note: all ports are likely multiplexed, so only one is usable.
  • Transport Stream I/F – 2x TS In + 2x TS In or Out + 1x Cable IF in
  • SDIO – 2x SDIO 3.0
  • Security – Advanced DRM, and CAS (NOCS3.X), and hardware video watermark. TrustZone

The company can provide Android 7.0 and Linux SDKs with middleware and RDK for the processor and development board. HiVXE 2.0 is also said to support PiP and video transcoding. Hardware video watermark ability allows the processor to meet MovieLabs UHD premium service delivery requirements.

Click to Enlarge

It appears the company will also offer a user-friendly way to watch VR videos / 360° videos on the TV by using a mobile app or remote control to navigate in all directions while the video is playing.

I could not find any information at all on the web about Hi3796M V200 processor, so thanks to Ovi for sending pictures directly from the Broadcast Asia exhibition, and allowing us to discover this new multimedia processor.

Android Things Developer Preview 4 Released with Google Assistant SDK Support

May 18th, 2017 2 comments

Earlier this month, Google released a preview of the Google Assistant SDK that works on boards running Debian like the Raspberry Pi 3, and even launched AIY Project Voice Kit for the later. You can now play with Google Assistant on Android Things as the company has just released Android Things Developer Preview 4 with support for Google Assistant SDK.

The operating systems works on any Android Things certified devices, but the example instructions  for Google Assistant API on Android Things also include steps to use Raspberry Pi 3 board together with AIY Projects Voice kit.

The developer preview 4 also adds I2S to the peripheral I/O API and is demonstrated in the aforementioned example, and new hardware support with NXP i.MX7D based Pico Board equipped WiFi & Bluetooth, Ethernet, USB ports, an audio jack, and an I/O expansion port.

Pico Board with NXP i.MX7D SoM

Android Things DP4 also brings the ability for developers to enable/disable Bluetooth profiles at run time. Finally, Google mentioned the open source hardware Edison Candle to show an example of Android Things hardware, which we shortly covered previously. Separately, Rockchip published a press release about a Rockchip RK3229 solution supporting the Google Assistant SDK and Android Things. Sadly, few details are provided in the PR, and RK3229 devkit is not listed in Android Things Hardware page.

You can download Android Things DP4 in the developer preview page.

Banana Pi BPI-M64 Board Gets Allwinner R18 Processor with Google Cloud IoT Core Support

May 18th, 2017 29 comments

Banana Pi BPI-M64 board was launched with Allwinner A64 processor, but a few days ago, I noticed the board got an option for Allwinner R18. Both processors are likely very similar since they are pin-to-pin compatible, and Pine64 was first seen with Allwinner R18, so I did not really feel it was newsworthy. But today, Google announced Google Cloud IoT Core cloud service working with a few app partners such as Helium and Losant, as well as several device partners including ARM, Marvell, Microchip, Mongoose OS, NXP… and Allwinner, having just announced the release of an Allwinner R18 SDK with libraries supporting Google Cloud IoT Core.

Let’s go through the board specifications first which are exactly the same as for the original BPI-M64 board, except for the processor:

  • SoC – Allwinner R18 quad core ARM Cortex A53 processor with Mali-400MP2 GPU
  • System Memory – 2GB DDR3
  • Storage – 8GB eMMC flash (16, 32 and 64GB options), micro SD slot up to 256 GB
  • Video Output / Display interface – HDMI 1.4 up to 4K resolution @ 30 Hz, MIPI DSI interface
  • Audio – HDMI, 3.5 mm headphone jack, built-in microphone
  • Connectivity – Gigabit Ethernet + 802.11 b/g/n WiFi & Bluetooth 4.0 (AP6212)
  • USB – 2x USB 2.0 host ports, 1x micro USB OTG port
  • Camera – MIPI CSI interface (which I guess you support parallel cameras via some kind of bridge)
  • Security – Hardware security enables ARM TrustZone, Digital Rights Management (DRM), information encryption/decryption, secure boot, secure JTAG and secure efuse
  • Expansion – 40-pin Raspberry Pi 2 somewhat-compatible header
  • Debugging – 3-pin UART header
  • Misc – IR receiver; U-boot, reset and power buttons;
  • Power – 5V via power barrel; 3.7V Lithium battery header; AXP803 PMIC

So from hardware perspective, there’s no advantage of getting the board with the new R18 processor. But the SDKs are somehow different, and based on Allwinner’s press release, only R18 processor gets Google Cloud IoT Core support.

Cloud IoT Core Overview

Some of the key benefits of Cloud IoT Core include:

  • End-to-end security – Enable end-to-end security using certificate-based authentication and TLS; devices running Android Things or ones supporting the Cloud IoT Core security requirements can deliver full stack security.
  • Out-of-box data Insights – Use downstream analytic systems by integrating with Google Big Data Analytics and ML services.
  • Serverless infrastructure: Scale instantly without limits using horizontal scaling on Google’s serverless platform.
  • Role-level data control – Apply IAM roles to devices to control access to devices and data.
  • Automatic device deployment – Use REST APIs to automatically manage the registration, deployment and operation of devices at scale.

Both Foxconn/SinoVoIP and Pine64 can offer Allwinner R18 platforms compatible with Google Cloud IoT Core via their Banana Pi BPI-M64 and Pine A64+ boards respectively.

Realtek RTL8710BN ARM Cortex M4 WiFi MCU, MJIOT-AMB-03 Module & Board, and Ameba 4.0a SDK

May 14th, 2017 5 comments

We’ve already covered Realtek Ameba ARM Cortex M3 WiSoC several times with their RTL8710AF, RTL8711AM and RT8195AM solutions, but the company has now a new “Ameba Z series” relying on an ARM Cortex M4 core starting with RTL8711BN MCU.

RTL8710BN specifications as listed on Realtek website:

  • CPU – ARM Cortex-M4(F) up to 125MHz with FPU (TBC)
  • Memory – 256KB embedded SRAM
  • Storage – 512KB embedded ROM, external flash interface; XIP (eXecut In Place) support
  • Wi-Fi
    • 2.4GHz 1T1R 802.11b/g/n up to 150Mbps; 20MHz and 40MHz
    • WEP, WPA, WPA2, WPS support
  • Security engine – MD5, SHA-1, SHA2-256, DES, 3DES, AES
  • Peripheral Interfaces
    • SDIO Slave
    • 2x UART
    • SPI interface (Master/Slave)
    • 2x I2C interface
    • ADC for voltage management
    • 5x PWM
    • Up to 17x GPIOs
  • Package – QFN-32; 5 x 5 mm

AFAIK, other Ameba MCUs do not support XIP, but RTL8710BN and this lowers memory requirements since code can be executed from storage.

RTL8710BN Board (MJIOT-AMB-03-DEBUG)

MJIOT-AMB-03 module – pictured at the top of this post – is the first module based on RTL8710BN, supports up to 128 MB external flash, and includes a PCB antenna, and an u.FL connector. Power consumption is said to be 2.5 mA during operation, and 70 uA during sleep (@ 3.3V?). The module can be made to interface with cloud services such as Ailink, Joylink, QQlink, Hilink, Gagent, and Weichat. You can find a longer list of hardware parameters here.

The module can also be found on MJIOT-AMB-03-DEBUG, a breadboard-friendly board with a micro USB port, two buttons, and a JTAG/SWD header. The module used to be sold for $1.98 and the board for $5 on eBay, but the listings have expired. However, some RTL8710BN items are still for sale on Taobao with a 5 CNY ($0.725) adapter board for MJIOT-AMB-03 module, 13.30 CNY ($1.93) for the module itself, and 30 CNY ($4.35) for the development board. Shipping (to China) adds 8 CNY ($1.15).

However, you can’t do much with an SDK, and kisste, who has been deeply involved in Ameba solutions (see VGA on RTL8710), found out that this module requires a newer Ameba SDK, and that Ameba SDK 4.0A without NDA had just been released with support for RTL8710BN / Ameba Z series MCU and mbedTLS.

RTL8710BN Module (MJIOT-AMB-03 Pinout Diagram

Google Assistant SDK Turns Your Raspberry Pi 3 into Google Home

May 3rd, 2017 7 comments

Google Home allows you to select music, control your home automation system and more with voice commands, but now you can do the same with a Raspberry Pi 3 as Google released a developer preview (alpha v1) of the Google Assistant API that works on Raspberry Pi 3, and other development boards running Debian or Ubuntu.
Functionalities are limited right now, with RPC API and Python sample code, but it only works with English language, and features such as timers & alarm, playing music, news, or podcasts, and precise location are not supported. Location is determined using your IP address only, and if you’re using some third party services / products such as Uber or Hue, you’ll need an actual Google Home device for initial setup.

Google has provided instructions to use Google Assistant SDK with Raspberry Pi 3 board. First you’ll need a USB microphone ($5.99 on Amazon), and speakers connected via USB or the 3.5 mm audio jack. After installing Raspbian on the board, you’ll need to configure a developer project and account settings, configure and test audio (with arecord/aplay), and finally install Python and the Assistant API sample:

Once this is done, authorize and run the sample:

Press Enter, ask something, and your Raspberry Pi 3 board should answer.

Since you just need audio and network working on the hardware, this should also work on other development boards, and Google has indeed provided instructions for other platforms too. Basically the same steps, but less detailed, except for the authorization part which seems a little more complicated.

Thanks to Harley for the tip.