Posts Tagged ‘ubuntu’

PINE64 Introduces SOPINE A64 Allwinner A64 SoM and SOPINE “Model A” Baseboard

January 17th, 2017 26 comments

Following yesterday’s Raspberry Pi Compute Module 3 launch, we have a new development board turned into system-on-module (SoM) today with PINE64 launching SOPINE A64 SO-DIMM module based on Allwinner A64 processor with 2GB RAM together with SOPINE “Model A” baseboard.

SOPINE A64 CPU module specifications:

  • SoC – Allwinner A64 quad core Cortex A53 processor @ 1.2 GHz with Mali-400MP2 GPU
  • System Memory – 2GB LPDDR3
  • Storage – 128 Mbit SPI flash, micro SD slot (on the back)
  • I/Os via 204-pin SO-DIMM edge connector
    • Video Output / Display – HDMI + CEC, MIPI DSI
    • Audio – I2S, HP, headphone, microphone
    • 2x USB
    • 1x Gigabit Ethernet (RGMII)
    • UART, I2C, PWM, GPIOs, etc…
  • Power Supply – AXP803 PMIC
  • Dimensions – 67.9 x 31.0 mm (DDR3 SO-DIMM form factor)

SOPINE A64 will basically run the same firmware as used for PINE A64+ development board, except for some modifications for LPDDR3 RAM support. Support operating systems should include Android, Ubuntu, and other Linux distributions. In order to get started while you design your own baseboard for the module or if you simply want to evaluate the solution, the company also released SOPINE “Model A” baseboard.

The baseboard has the same layout as PINE A64/A64+ boards and roughly exposed the same ports for some extra like an eMMC slot:

  • SoM Connector – 204-pin SO-DIMM slot
  • External Storage – Optional eMMC module
  • Video Output / Display I/F – HDMI, MIPI DSI + Touch Panel connector
  • Audio – HDMI, 3.5mm headphone jack
  • Camera – 1x MIPI CSI connector
  • Connectivity – Gigabit Ethernet, header for WiFi & Bluetooth module
  • USB – 2x USB 2.0 ports
  • Expansion – Pi-2-Bus, Euler bus, and EXP 10 headers
  • Misc – RTC header
  • Power Supply – 5V via power barrel, or 3-pin battery header

SOPINE A64 module and baseboard will be available next month after Chinese New Year, and sell for $29, while SOPINE Model A baseboard will go for $14.99, and a complete kit with the SOM and baseboard for just $34.99.

You’ll find more details on SOPINE A64 product page including schematics, and some development tools.

Self-hosted OpenGL ES Development on Ubuntu Touch

January 15th, 2017 4 comments

Blu wrote BQ Aquaris M10 Ubuntu Edition review – from a developer’s perspective – last year, and now is back with a new post explaining how to develop and deploy OpenGL ES applications directly on the Ubuntu Touch tablet.

Ever since I started using a BQ M10 for console apps development on the go I’ve been wanting to get something, well, flashier going on that tablet. Since I’m a graphics developer by trade and by heart, GLES was the next step on the Ubuntu Touch for me. This article is about writing, building and deploying GLES code on Ubuntu Touch itself, sans a desktop PC. Keep that in mind if some procedure seems unrefined or straight primitive to you – for one, I’m a primitive person, but some tools available on the desktop are, in my opinion, impractical on the Touch itself. That means no QtCreator today, nor Qt, for that matter.

The display of any contemporary Ubuntu Touch device is powered by Mir – a modern compositor/surface manager taking care of all (rectangular-ish) things eventually appearing on screen. We won’t be delving much into Mir beyond obtaining an EGL context (EGL being the binding layer between GLES and the native windowing system). But enough ado – let’s get to work.

Preparations for doing GLES on a Ubuntu Touch box:

The above, as of the time of this writing, should provide you with gcc/g++-4.9, make and gdb-7.9, among other things. The last package and its dependencies provide you with up-to-date Mir headers. Git comes out of the box, IIRC, but if it’s missing just apt-get it.

We need a primer to step on, so here’s my adaptation of Don Bright’s Mir/GLES adaptation of Joe Groff’s OpenGL tutorials, using Daniel van Vugt’s Mir/EGL examples (yes, that’s a quite a chain-work):

I’ve taken the liberty to expand on the work of those gentlemen by bringing the Mir integration up to date, handling Touch’s novelty Desktop Mode and throwing in my own dusty GLES sample code, for good measure.

To build and install the primer, just do:

That will provide you with an original police-car flashing-lights primer. An alternative primer featuring tangential-space bump-mapping can be built by passing arg ‘guest’ to the build script:

Both versions of the primer use a fundamentally identical interface — a resource-initialization procedure and a frame-drawing procedure, so it’s not much of an effort to use the respective routines from either primers in the framework of the host app hello.cpp, and thus get a running render loop.

A few words about the peculiarities of the GLES development for Ubuntu Touch. It took me some time to show anything on screen, despite the fact I had a valid draw context and a render loop soon after the primer was building successfully. The reason is Unity8 on the Touch will not simply let you run a window-painting app from the terminal – you would get your Mir and EGL contexts alright, but the target surface will never be composited to the screen of the device upon eglSwapBuffers() unless you take certain actions. You have two alternatives here:

  • Produce a valid Click package from your app and subsequently install that to the Apps pane (what our build script does), where you can launch from an icon, or…
  • Use a launcher app to start your window app (info courtesy of Daniel van Vugt):

Unfortunately the second (much quicker and convenient) approach is not currently usable due to a bug, so we’ll stick with the first. Any command-line args we’d want to pass to the app will need to be written to the app’s .desktop file, which can be found at the official app location after installation:

In that file, set the desired args on the ‘Exec’ line, like this:

Another peculiarity was that in Desktop Mode the app window does a classical ‘zoom to full size’ animation at start. Nothing extraordinary in that, if not for the fact that the Mir surface itself resizes along with the window. Now, a default viewport in a GLES context spans the geometry of the target surface at the time of its creation, which, in our case, is the start of the window-zoom animation, with its tiny surface geometry. One needs to wait for the zoom animation to finish, and then set the viewport geometry to the final geometry of the Mir surface, or live with a post-stamp-sized output in the lower left corner of the window, if the viewport is left unchanged.

Once we get past those teething hurdles we actually get quite a nicely behaving full-screen app on our hands – it composites smoothly with all other Ubuntu Touch desktop elements like the Launcher tab at the desktop’s left edge and the pull-down Indicator pane on right (see screenshot). Our app even does live output to the Scopes selector screen (i.e. the task-switching screen) — behold the miracles of modern-day screen compositors! ; )

Click for Original Size (1920×1080)

But hey, don’t just take my word for it – try out GLES coding on a Ubuntu Touch device – you have the basics covered:

  • App’s rendering loop and the entirety of the flashing-screen primer are in hello.cpp
  • Mir context creation and subsequent EGL context binding are in eglapp.cpp
  • Bump-mapping primer is entirely in app_sphere.cpp
  • Various helpers are spread across util_* TUs and hello.cpp
  • All files necessary for the generation of the Click package are in resource folder.

In conclusion, self-sustained development on the Ubuntu Touch is a perfectly viable scenario (take that, iOS!). Moreover, the GPU in the BQ M10 turned out to have a very nice modern GLES3 (3.1) stack – see excerpts from the app logs below. Actually, this is my first portable device with a GLES 3.1 stack, so I haven’t started using it properly yet — the GLES2 primer above doesn’t make use of the new functionality.

If I have to complain about something from the development of this primer, it’d be that I couldn’t use my arm64 code on the primer, since there are only armhf (32-bit) EGL/GLES libraries available for the Touch. So 64-bit code on the Ubuntu Touch remains in console land for now.

Excerpts from the primer logs:

egl version, vendor, extensions:

1.4 Android META-EGL
EGL_KHR_get_all_proc_addresses EGL_ANDROID_presentation_time EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_fence_sync EGL_KHR_create_context EGL_ANDROID_image_native_buffer EGL_KHR_wait_sync EGL_ANDROID_recordable EGL_HYBRIS_native_buffer2 EGL_HYBRIS_WL_acquire_native_buffer EGL_WL_bind_wayland_display

gl version, vendor, renderer, glsl version, extensions:

OpenGL ES 2.0 (OpenGL ES 3.1)
OpenGL ES GLSL ES 3.10
GL_EXT_debug_marker GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth24 GL_OES_depth_texture GL_OES_depth_texture_cube_map GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_EXT_read_format_bgra GL_OES_compressed_paletted_texture GL_OES_compressed_ETC1_RGB8_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_texture_npot GL_OES_vertex_half_float GL_OES_required_internalformat GL_OES_vertex_array_object GL_OES_mapbuffer GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_type_2_10_10_10_REV GL_OES_fbo_render_mipmap GL_OES_element_index_uint GL_EXT_shadow_samplers GL_OES_texture_compression_astc GL_KHR_texture_compression_astc_ldr GL_KHR_texture_compression_astc_hdr GL_KHR_debug GL_EXT_occlusion_query_boolean GL_EXT_disjoint_timer_query GL_EXT_blend_minmax GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_OES_texture_3D GL_EXT_texture_storage GL_EXT_multisampled_render_to_texture GL_OES_surfaceless_context GL_OES_texture_stencil8 GL_EXT_shader_pixel_local_storage GL_ARM_shader_framebuffer_fetch GL_ARM_shader_framebuffer_fetch_depth_stencil GL_ARM_mali_program_binary GL_EXT_sRGB GL_EXT_sRGB_write_control GL_EXT_texture_sRGB_decode GL_KHR_blend_equation_advanced GL_OES_texture_storage_multisample_2d_array GL_OES_shader_image_atomic


Lichee Pi One Allwinner A13 ARM Linux Board is Equipped with LCD Display and Camera Interfaces

December 26th, 2016 21 comments

Allwinner A13 – repackaged as Allwinner R8 – single core Cortex A8 processor is used in $9 C.H.I.P board with 512MB, 4GB storage, WiFi and Bluetooth, and I/Os. Now a Chinese company has created a new Allwinner A13 board called Lichee Pi that appears especially suited to drive LCD displays thanks to its 40-pin LCD RGB connector, but it also comes with WiFi & Bluetooth, a micro SD slot, and some I/Os.

Click to Enlarge

Click to Enlarge

Lichee Pi One board (preliminary/tentative) specifications:

  • SoC – Allwinner A13 ARM Cortex A8 processor @ 1.0 GHz with Mali-400 GPU
  • System Memory – 512MB DDR3 RAM
  • Storage – 2x micro SD slot
  • Display Interface – 40-pin RGB LCD connector, with 8080 interface, VGA and LVDS supported via add-on board
  • Camera – 24-pin CSI interface
  • Audio – 3.5mm audio jack
  • Connectivity – Optional 802.11 b/g/n WiFi and Bluetooth via RTL8723BU module (Multiplexed with USB 2.0 host port)
  • USB – 1x USB 2.0 host port, 1x micro USB OTG port, 1x micro USB port for power only
  • Expansion – Two 20-pin headers with 9x GPIO, 3x I2C, 3x UART, 3x SPI, etc…
  • Misc – RGB LED
  • Power Supply – 5V via micro USB port or 2-pin header, LiPo battery via miniJST connector
  • Dimensions – Est. 75 x 55 mm

The board can run Android or Linux distributions like Debian or Ubuntu, and you’ll find some information such as schematics and some documentation on Github.
You’ll find soon info in English on Linux-Sunxi website, as well as with more info, but in Chinese only. The price of the board was  as low as 39 CNY ($5.6) in Elecfans crowdfunding (most components not soldered), and a complete kit with a 4.3″ display (800×480) a 3MP camera went for 168 CNY (~$24). Shipping costs were not included. It’s not available for sale right now. The company has also registered, but the site is not accessible for now as it’s waiting for an ICP license.

$25 NanoPi A64 is a Compact Yet Features Packed Allwinner A64 Development Board

December 23rd, 2016 20 comments

FriendlyARM has had a very busy year with their NanoPi boards, and they are completing the year by launching NanoPi A64 development board based on Allwinner A64 quad core Cortex A53 processor with 1GB RAM, Gigabit Ethernet, HDMI, USB ports and more.

nanopi-a64NanoPi A64 board specifications:

  • SoC – Allwinner A64 quad-core Cortex-A53 @ 648MHz to 1.152GHz with an ARM Mali400 MP2 GPU
  • System Memory – 1GB DDR3 RAM
  • Storage – 1x micro SD slot
  • Video Output / Display IF – HDMI 1.4 port,  30-pin MIPI DSI connector
  • Audio – HDMI, 3.5mm audio jack
  • Connectivity – 1x Gigabit Ethernet port (RTL8211E), 802.11 b/g/n WiFi
  • USB – 2x USB 2.0 ports, 1x micro USB port for power only
  • Camera – 24-pin DVP camera interface
  • Debugging – 4-pin debug UART header
  • Expansion
    • 40-pin mostly Raspberry Pi compatible header with UART, SPI, I2C, PWM, GPIOs, etc…
    • 7-pin I2S header
  • Misc – IR Receiver, 1x power button, power and system LEDs,
  • Power – 5V/2A via micro USB port; AXP803 PMIC; supports software power-off
  • Dimension: 64 x 60mm (6-layer PCB)


FriendlyARM will provide Ubuntu-core with Qt Embedded and Ubuntu MATE images, but community ports such as ARMbian may be released in the future. You’ll find some documentation in the Wiki (Note: the Chinese version has more info right now).

NanoPi A64 development board is now sold with a micro USB to USB cable for $25 plus shipping on FriendlyARM website

Thanks to Thomas for the tip.

How to Use Sonoff POW ESP8266 WiFi Power Switch with MQTT and ThingSpeak

December 11th, 2016 10 comments

ITEAD Studio’s Sonoff is a family of cheap home automation products based on ESP8266 WiSoC, and I’ve already tested Sonoff TH16 wireless switch with a humidity and temperature sensor using the stock firmware and eWelink app for Android or iOS. It works, but up to recently it required a registration to a cloud service (the company will now allow use from the local network), and the source code is closed. So for the second device under review, namely Sonoff POW wireless switch with a power consumption monitor, I decided to install ESPurna firmware working on ESP8266 Sonoff devices and NodeMCU, as it’s open source, supports Sonoff POW natively, includes a web interface to control the device from the LAN, and includes an MQTT client.

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol used to control IoT sensors and devices, and it’s a popular method to gather data from client to a MQTT broker to push the data to the cloud or a local database.


So typically, you’d have a bunch of sensor nodes (like Sonoff devices) communicating over MQTT to an MQTT Broker in your local network, which could be an OpenWrt router or a Linux development board like a Raspberry Pi, which in turns gets the data the the cloud to services like AWS IoT, Xively, or ThingSpeak. It’s also possible to use Cloud services to control MQTT devices remotely through the MQTT broker.

I eventually plan to use NanoPi NEO board to run both MQTT and ThingSpeak locally (not connected to the cloud) in order to monitor the power consumption of my small office, but since I’m all new to this, I’ve started experimenting by connecting a 30W light to Sonoff POW, and use a desktop computer running Ubuntu 16.04 for MQTT and ThingSpeak.


Click to Enlarge

Click to Enlarge

Since I’ve already installed ESPurna firmware to the device, I disconnected the USB to serial board (important since Sonoff POW board has a hot ground), and connected it to the mains (220V in my location). That means we already have an MQTT client which first I had to configure.

Click to Enlarge

Click to Enlarge

Since it was the first time I connected a load to the device, I went to ESPurna’s status menu to check power usage was reported, and my 30 Watts light bulb was drawing 27 Watts. Close enough. I changed the hostname to sonoff-office, and setup two SSID in order to connect Sonoff POW to my local network in client mode, instead of using it in Access Point mode by default. You’ll need to tap on Update each time you modify the settings. Since the SSID must be entered manually, please note that SSID are case sensitive, e.g. CNX-SOFTWARE is different from cnx-software.

Click to Enlarge

Click to Enlarge

I wanted to calibrate the power using the 30W light bulb, so I entered 30W in AC RMS Active Power field, and tapped on Update, but the web interface reported “no changes”. I’m not sure how to use that part. Finally the most important part for this tutorial is to set the MQTT settings with MQTT IP address, and leaving other fields unchanged. However, you can change MQTT Topic field for example replacing /test/switch/{identifier} by /myiotstuff/{identifier}.

Now that our MQTT client is configured, I need to install mosquitto MQTT broker in Ubuntu:

mosquitto-clients is not really needed, but I’ll use it to test the MQTT broker a little later. Once you installed it, the MQTT Broker should already run automatically.

The last line of the log above shows a client connection from Sonoff POW. Now, we need to check the topic, and since ESPurna documentation is still work in progress, you could either check out the source code, or IMHO more fun, capture MQTT packet with tcpdump or Wireshark as I’ve done below.

Wireshark MQTT Capture - Click to Enlarge

Wireshark MQTT Capture – Click to Enlarge

Here we can see that Sonoff POW will send a Publich Message with the power level using the topic “/test/switch/sonoff-office/power29”.  “/test/switch” is the string we’ve defined in the web interface, “sonoff-office” the hostname we’ve given to Sonoff Pow, and “power29” indicates 29 Watts of power is currently used.

We can also start a client in Ubuntu 16.04 terminal window to check more MQTT topics with # wildcard for sonoff-office host:

We can use MQTT to get the IP address, firmware and file system version, hearbeat message, power use, and relay status (on or off).

It’s all good, but now we need to do something to draw the data, and possibly analyze it. I selected ThingSpeak for this purpose since it can be installed in the local network, or through their service in the cloud. By the end of my testing, I’ve noticed ThingSpeak has a new MQTT API, meaning it should be possible to connect your MQTT broker directly to it, but for this guide I use mqspeak instead as a bridge between MQTT and ThingSpeak. It may still be useful, as the open source version of ThingSpeak is not updated anymore, and lacks the MQTT API.

You’ll need Python 3 and pip3 to install mqspeak:

Once it’s done, we’ll need to create a config files as explained on mqspeak’s github repo, and I created /etc/mqspeak.conf with the following content:

Brokers are used to configure MQTT broker IP address and port, as well as the topic(s) to subscribe to, while Channels take care of ThingSpeak configuration with the channel’s Id and write API key, update rate in seconds (15s minimum), update type (see github for details), and fields defined in your ThingSpeak’s channel(s), which will create later on. I wrote one broker for the power consumption topic, and other for the relay status. However, I eventually ignored the relay status, as it’s not updated often enough and cause ThingSpeak’s channel to only be updated when the relay changes status, even if there are power updates in the meantime. A workaround is to use two different channels for ThingSpeak.

mqspeak connects directly to, so if you are using ThingSpeak cloud services, the next step is to register an account and setup one or more channels.

Extra Instructions for a local installation of ThingSpeak

However, if you’ve installed ThingSpeak in Ubuntu 16.04 or other Linux operating systems locally or on your own server, you’ll need to change the server in the source code, and reinstall mqspeak.

  1. Get the source code:
  2. Modify mqspeak/ to replace using HTTPS with localhost (or other IP address/URL where you’ve installed ThingSpeak) with HTTP:
  3. Install mqspeak

An improvement would be to install a signed SSL certificate, like the one offered by LetsEncrypt and configure the rails server to use https instead. I have not setup ThingSpeak server to start automatically yet, so I have to start it manually for now:

End of instructions specific to local installation.

The instructions specific for the local installation of ThingSpeak are now done, and all instructions below are valid for both the local installation and cloud service. Now open a web browser, go ThingSpeak (cloud or local), and click on “Get Started Now” in order to register an account.

Click to Enlarge

Click to Enlarge

Once it is done, login and click on “New Channel”.

Click to Enlarge

Click to Enlarge

Give it a name, a description, create fields as needed, for example power-consumption and power-status, and click on Save Channel.  Update /etc/mqspeak.conf accordingly with the fields’ name, and channel Id.

thingspeak-api-keyNow select API Keys tab to copy and paste the write API key into mqspeak.conf.

Now we can start mqspeak:

ESPurna firmware will send a power update every 60 seconds (this can be changed in code/src/pow.ino), so you’ll need a new message pop-up every 60 seconds with your channels Id and write API key. I’ve let it run for about one hour, and got the follow chart in ThingSpeak after turning on and off the lights from time to time.
thingspeak-power-consumptionThat’s pretty cool, so it only shows the current power in watt, and we’d probably want to get power consumption in kW/h per day, week and month at some time, and I have yet to study how to do that, Exporting the data to excel would be a workaround if this can not be handled in ThingSpeak. (but not the open source version) offers some Matlab processing of the data, so that’d be another options.

The next steps would be to install MQTT and ThingSpeak in NanoPi NEO board, enable HTTPS in ThingSpeak, autostart rails server and mqspeak at boot time, make ESPurna firmware publish the “Power” topic more often than every 6 second, and find some way to generate useful kW/h consumption charts from the data stored in ThingSpeak within ThingSpeak, or but exporting the data.

How to Install ThingSpeak in Ubuntu 16.04

December 7th, 2016 11 comments

Last week-end I installed ESPurna open source firmware with MQTT server on Sonoff POW WiFi switch, and the next step is find a way to draw power consumption charts in some web based interface. We could do this in the IoT cloud with services like Xively or ThingSpeak, but since one of the goals of replacing the default firmware was not to rely on a proprietary cloud based solution, I decided to find a way to draw those chart in a local server, and it so happens that ThingSpeak is also open source with the code available on Github. Hardware platforms like NanoPi NEO / NEO Air, or Orange Pi Zero boards appear to be particularly well suited for the task of running an MQTT broker and Thingspeak, but at first I wanted to install ThingSpeak in my own Ubuntu 16.04 computer to have a try.

Click to Enlarge

Click to Enlarge

As you can see from the screenshot above I manage to do it, but it requires a bit more efforts than expected, as the project has not been updated since 2015, and does not work out of the box with the latest operating system.

I used various resources on the web including the instructions on Github, as well as this ThingSpeak script for Ubuntu 14.04, and a few other resources.

First we have to make sure Ubuntu 16.04 is fully upgraded:

Ubuntu 16.04 comes with Ruby 2.3, but we need the older Ruby 2.1.0 version for ThingSpeak, so let’s uninstall ruby to avoid conflicts:

Now we can install dependencies, Ruby 2.1.0, and Bundle:

Once this is done, we can get ThingSpeak source code and install it:

This looked successful so I moved on to database configuration:

It’s recommended to change the username and password in config/database.yml for test, development and production databases with your own for security purpose. Once it’s done, let’s try to create the databases:

Sadly it starts with an error:

So I checked mysql2 version and upgraded it to see if it would fix the issue:

The previous error is gone, but only to be replaced by a new one…

Finally, I found out (can’t find where anymore) that I had to edit Gemfile in ThingSpeak directory, and add an older version to mysql2:

Let’s update mysql2, and try to create the databases again:

Damn a permission error. I could not find a proper fix, so at this point the title of the post should possibly become “How NOT to install Thingspeak in Ubuntu 16.04”, as although it will work, the steps below makes the installation insecure since I simply give full databases’ access to thing user. But that will do since I’ll only use it in my LAN, and maybe somebody will point to a secure solution to the issue.

[Update: Thanks to Arthur, I’ve got a more secure solution . I’ve left both insecure and secure workaround for reference, but obviously you should use the secure one, especially it’s not hard]

Insecure (don’t use it, I just left it to show what you should not do):

Secure way (strongly recommended):

This time I can create the databases for Thingspeak:

So now we can go to the next step to load the database with some data required by Thingspeak to work:

Great! Yet another error:

After spending a while for a solution I eventually found it in Rails Github with the reason being that MySQL 5.7 used in Ubuntu 16.04 does ot allows for NULL key.

We’ll need to create config/initializers/abstract_mysql2_adapter.rb file with:

Then we need add the following line at the end of config/environment.db

and run the command again:

Success! Finally…

The final step is to start the server:

Now start your web browser and you can access your local Thingspeak installation @ http://localhost:3000.
I’ll now have to study a little more about Thingspeak, install MQTT, as well as one of the MQTT to Thingspeak bridges available on the web, and see if I can plot power consumption data there.

Firefly-RK3399 Rockchip RK3399 Development Board Launched on Kickstarter for $139 and Up

December 5th, 2016 27 comments

Firefly-RK3399 is the first, and for now the only one, development board equipped with the latest Rockchip RK3399 hexa-core Cortex A72 & A53 processor. It’s just not available yet, but the board has now been launched on Kickstarter where it is offered for $139 to $199 depending on options.


Firefly-RK3399 board specifications:

  • SoC – Rockchip RK3399 hexa-core big.LITTLE processor with dual core ARM Cortex A72 up to 2.0 GHz and quad core Cortex A53 processor with ARM Mali-T860 MP4 GPU with OpenGL 1.1 to 3.1 support, OpenVG1.1, OpenCL and DX 11 support
  • System Memory
    • Standard – 2 GB DDR3
    • Plus devkit – 4 GB DDR3
  • Storage
    • Standard – 16 GB eMMC flash, micro SD card, M.2 socket
    • Plus devkit – 32 GB eMMC flash, micro SD card, M.2 socket
  • Video Output & Display Interfaces
    • 1x HDMI 2.0 up to 4K @ 60 Hz
    • 1x DisplayPort (DP) 1.2 interface up to 4K @ 60Hz (via USB type C connector)
    • 1x eDP 1.3 (4-lanes @ 10.8 Gbps)
    • 1x MIPI DSI interface up to 2560×1600 @ 60 Hz
  • Video Decode – 4K VP9 and 10-bit H.265 video codec support up to 60 fps
  • Audio
    • Via HDMI or DisplayPort
    • 3.5mm headphone jack with stereo audio output and mic input
    • optical S/PDIF
    • 1x LINE Out and 1x speaker via GPIO header; Speaker: 1.5W or 2.5 W per channel for respectively 8Ω or 4Ω speakers
    • Built-in microphone
    • I2S output and input interface up to 8 channels
  • Connectivity – Gigabit Ethernet (RJ45) port using RTL8211E transceiver, WiFi 802.11ac 2×2 MIMO and Bluetooth 4.1 (AP6354 module)
  • USB – 2x USB 2.0 host ports, 1x USB 3.0 port, 1x USB 3.0 type C port
  • Camera
    • 2x MIPI CSI interfaces up to 13MP or 2x 8MP
    • 1x DVP camera interface up to 5MP
  • Debugging – 3-pin serial header
  • Expansion
    • 42-pin GPIO female header with access to 1x I2S, 2x ADC, 2x I2C, 1x SPI, 2x GPIO, 1x LINEOUT, 1x SPEAKER
    • 1x mini PCIe for LTE, 1x PCIe 2.1 M.2 slot B-key (2x PCIe, SATA, USB 2.0, USB 3.0, HSIC, SSIC, Audio, UIM, I2C)
    • SIM card slot
  • Misc – RTC battery header; power & user LEDs; power, reset and recovery buttons; IR receiver
  • Power Supply – 12V/2A DC (5.5×2.1mm barrel connector)
  • Dimensions – 12.4 x 9.3 mm (8-layer PCB)
  • Weight – Board: 89 grams; board + cooling fan and heatsink: 120 grams

The company will provide Android 6.0.1 and Ubuntu 16.04 firmware images for the board, including a dual boot image. There are also work-in-progress documentation and placeholder links to Android SDK and schematics in the product page which will hopefully soon link to the actual documents and files, as well as a work-in-progress Wiki. It may also be worth monitoring the company’s  Github account.

firefly-rk3399-boardThe company aims to raise $50,000 from the crowdfunding campaign, and you’d have to pledge $139 to get “Firefly-RK3399 Development Kit” with 2GB RAM, and 16GB flash together with a 12V/2A power adapter, a USB Type C adapter, a USB to UART serial board, a USB cable, and a a cooling fan (I assume with an heatsink). After the 50 first pieces, the price goes up to $159, and if you want the “Plus development kit” with 4GB RAM and 32GB flash, you’d need to pledge $199 instead. Shipping adds $5 to $30 depending on the destination country, and delivery is planned for March 2017.

Getting Started with Pine64 PADI IoT Stamp – Part 2: Serial Console, GCC SDK, Flashing & Debugging Code

November 28th, 2016 5 comments

PADI IoT Stamp module powered by Realtek RTL8710AF ARM Cortex M3 WiFi SoC is a potential competitor to Espressif ESP8266 modules.  Pine64, the manufacturer of the module, sent me their kit with a $2 IoT stamp, a breakout board, a USB to TTL debug board and a J-Link debug board. In the first part of the review I’ve shown the hardware and how to assemble PADI IoT stamp kit. In the second part I’m going to write a tutorial / getting start guide showing how to control the board with AT commands, build the firmware with GCC SDK, and finally demonstrate how to flash and debug the firmware with the J-Link debugger.

The Quick Start Guide indicates you need to connect the USB to TTL debug board to UART2 instead of UART1 as I did on the very similar B&T RTL-00 RTL8710AF module, and set connection settings to 38400 8N1. This did not work for me, and I had indeed to connect the USB to TTL board to UART0 instead (GB0 & GB1 pins).

Click to Enlarge

Click to Enlarge

I’ll be using a Ubuntu 16.04 (Linux) computer for this quick start guide, but you can work with Windows and Mac OS X too, as tools as available for all three operating systems. So in my case I configure minicom to 38400 8N1 using /dev/ttyUSB0 device, and the boot log is almost the same as B&T RTL-00 with the same ROM version and toolchain:

There are however some changes, and for example the firmware used on PADI IoT Stamp has slightly more heap available. The guide also mentions ATS? should show all command available, but it’s not working for me:

Typing “help” as I did with RTL-00 module does not work either, and that does not look since documentation appears to be wrong again, but that’s not a big deal since we have all AT commands listed in that document. I could configure it as “IoTSTAMP” access point:

and enable the HTTP server with ATSW AT command:

It rebooted the IoT stamp with the same WiFi setting, and I could connect to its demo web page for configuration.

Click to Enlarge

Click to Enlarge

Since everything is so similar to B&T RTL-00 I’ll just point out to the post “Getting Started with B&T RTL-00 RTL8710 Module – Serial Console, AT Commands, and ESP8266 Pin-to-Pin Compatibility” for more tests with different AT commands. I still tried to turn on and off the a GPIO pin using the ATSG command since it’s something I did not do with RTL-00:

The first line pull GC0 pin to high level (3.3V), while the second command brings it down to low level (0V). Details about ATSG command:

I did not connect an LED, but instead measured the value with multimeter and could confirm the voltage level was right in both cases.

B&T provided an SDK which required a an unlicensed / pirated version of IAR ARM Workbench, but Pine64/Realtek have released a GCC SDK that do you require you to use pirated software. You can download sdk-ameba-rtl8710af-v3.5a_without_NDA_GCC_V1.0.0 (198 MB) directly from Pine64 website. After unzipped the SDK you can enter sdk-ameba-rtl8710af-v3.5a_without_NDA_GCC_V1.0.0 directory, and open readme.txt to have a look at RTL8710 GCC SDK structure:

Since I only aim to write a getting started guide I won’t go through all of it, but we can see the low level source code & binary, some documentation, an example project, and some tools include Android and iOS apps, OTA download server and more.

Nevertheless the readme.txt tells us to first read “UM0096 Realtek Ameba-1 build environment setup – gcc.pdf” in order to setup our development environment. The instructions are available with Windows and Linux, but again I’m only test them using Ubuntu 16.04. They’ll be very similar since you’ll rely on cygwin in Windows, and if you run the latest Windows 10 you should be able to install Windows subsystem for Linux, and use the Linux instructions.

First you have to make sure some tools and libraries are installed:

then we can build the sample project:

If everything goes well the log should end showing “Image manipulating” as follows:

We can find the application in application/Debug/bin directory:

There’s also an ota.bin image which might be usable using OTA firmware update documentation, but for this guide I want to use the J-Link debugger that the company sent me instead. The GCC SDK is not for PADI IoT stamp, but instead for Realtek Ameba Arduino board, and you’ll be asked to connect the board through one of the micro USB port. That won’t work with IoT stamp since there’s no USB port at all, and instead you’ll need to go and back forth between multiple documentation, and connect the board as per the JTAG/SWD connections diagram shown below.

padi-iot-stamp-jlink-swd-connectionThat document also mentions that:

Required external power VCC 3.3V, JTAG/SWD didn’t supply power to the PADI IoT Stamp, VCC connection from PADI IoT Stamp is used by JTAG/SWD as voltage reference only.

At first, I did not see that, and used it without external power supply, but since I was not successful with the J-Link debugger (for another reason), so I ended up inserting PADI IoT stamp into a breadboard and added Ywrobot power board to provide an external 3.3V power source.

Click to Enlarge

Click to Enlarge

I also soldered a 22uF capacitor, since I’ve read it’s not optional, as it may affect WiFi connection due to power issue. Once I complete the wiring, I connected the debugger to my computer:

There are two sets of instructions in UM96 document to download and flash the code: OpenOCD/CMSIS-DAP and JLink, so since I had a J-Link debugger, I went with that latter. First you have to download J-Link Software and Documentation pack and for my system I selected ” Linux, DEB Installer, 64-bit V6.12″. After accepting the EULA, I got JLink_Linux_V612_x86_64.deb file which I installed as follows:

Now we can start JLink GBD server for a Cortex-M3 as explained in the document:

So the JLink debugger is detected, but failed to connect to the target. Apart from the last error, everything looks exactly as in the documentation. That’s when I started to add an external power boar, solder the capacitor, and double check my connection. But finally after many trials and errors, I realized that I had to use a SWD connection (SWCLK/SWDIO signals) instead of JTAG…

Now keep the GDB server running, open a new terminal windows in the same directory (where you’ve built the code), and run make flash to download and flash the code to the board:

There will be a lot of message as above, and the GDB Server windows will show its own set of messages:

Now if you want to debug your code, you can run make debug to start the gdb console:

At this point, you’ll just need to use gdb command out of the scope of this post, but you can find tutorials online, for example this. You can also run make ramdebug in order to write ram_all.bin to RAM then enter gdb debug.

So that’s only the debug part, but if you want to create your own application, you’ll need to study the source code, and there are plenty of examples to help you in project/realtek_ameba1_va0_example/example_sources folder:

Note that this is only useful is you want to use PADI IoT stamp as a standalone module, and if you connect it to another board (e.g. Arduino) you can control it through the AT command set.

So while PADI IoT stamp is a usable platform with its GCC SDK, currently documentation is not always correct, and development should be reserved to experienced developers, as it’s not exactly as straightforward as Arduino, Lua or other firmware often used in ESP8266. Arduino will most likely never supported on IoT stamp due to memory constraints, but mbed support should come to the module in the first part of next year, which will make everything much easier.

If you want to go further, you can read the documentation on PADI IoT stamp resource page and the GCC SDK, checkout rebane’s openocd example, and/or read a forum post about controlling IoT stamp through Pine A64 board using Python.

If you want to play with your own, you can get PADI IoT stamp for $1.99, the breakout board kit for $0.5, the USB to serial debug board for $1.99, and the JLink (SWD) debugger is $7.99 on Pine64 online store. Please note that the two debug boards are standard components, so you may use your own, if you already have such hardware.