Larry Bank

I just received my BPI-M2 Zero board and put it through its paces. Seems to perform similar to other H2+ boards. I added a Pin->GPIO map to my SPI_LCD and ArmbianIO projects (https://github.com/bitbank2). Observations: 1) The SPI driver has that same odd issue where it occasionally spits out errors and runs a little slower than it should. 2) It doesn't come with an IPX antenna, but you need to add one to use wifi unless you're sitting on top of your access point. 3) A small passive heat sink seems to be plenty when running the mainline (4.1x) kernel. 4) The default HDMI out resolution is 1920x1080p@60fps. This causes a "jumpy" display on my monitor. Switching to 1280x720 fixed it. I've seen this on other AllWinner H2/H3 boards, so it's probably something strange with the mainline kernel hdmi code. Overall I'm happy with the board. It would be nice to use the bluetooth. Does anyone know how to enable it?

I just added support (header pin to GPIO table) for the Banana Pi-M2 Zero board. Even though it's an H2+ SoC, BPI decided to use very different GPIO mappings from Orange Pi. The Armbian build supplied by BPI looks to be a hacked up 5.36 release. Hopefully their changes will get merged into the main Armbian builds soon. The bluetooth chip is not enabled by default and probably requires some magic DTB numbers to get it working. Wifi works fine, but you need to add your own IPX antenna because it doesn't come with one.

I merged in Steven's python changes and changed the init function to allow specifying the board name. This allows it to work on older Armbian and non-Armbian Linux builds. I'll update my Nokia LCD library to reflect this change.

https://photos.app.goo.gl/u3N8Drw54kMDl6DE2

Here's the text file output from dtc: https://www.dropbox.com/s/30sdoj02tit2snc/dt.txt?dl=0

I activated uart1 and now I get the error "bcm43xx_init Initialization timed out."

I just tried this on my Orange Pi Zero Plus 2 (H5) and get the following error when running hciattach: Can't get port settings: Input/output error Can't initialize device: Input/output error Any ideas? Are you using this on the H3 or the H5 version of the OPZ+2?

I just released my multi-system game emulator (GameBoy+NES+GameGear for now). Optimized for directly outputting to SPI LCD displays (e.g. ili9341). Runs on any CPU type, but has optimizations for ARM+X64. I wrote 100% of the code, so it might be behave differently than other game emulators. GB+GG are nearly perfect. NES is missing some popular mappers. The code is very optimized to begin with, but also uses a dirty-tile system to minimize the data sent to the SPI bus. This allows inexpensive SPI displays (e.g. ili9341) to run at or near 60 frames per second for many games even though the SPI bus can only do 30FPS of full screen updates. https://github.com/bitbank2/sg_free The SPI display access uses my SPI_LCD library (https://github.com/bitbank2/SPI_LCD). This means that it doesn't need fbtft nor fbcp and can run on any Linux board. It has built-in code to talk to GPIO pushbuttons, so no special drivers/software are needed to run on "GBZ" systems. Below is a photo of SmartGear running on an Orange Pi Lite with the PiPlay Portable prototype hardware.

It will probably be months (years?) of software problems before a decent Linux distro works on it, but I ordered one anyway

The latest kernel (4.1x) handles the thermal control better with dynamic voltage scaling. It still gets warm, but not too bad. You can always set the max frequency to something like 480Mhz and disable 2 CPU cores. It would still be faster than an RPI0.

I just released a new library to act as a DNS filter. This differs from pi-hole in that it runs as a user-level program and doesn't depend on dnsmasq. This allows you to run it on a machine without changing your network configuration. It hasn't been rigorously tested, but appears to work properly. It can either proxy the packets to a trusted DNS server or spoof the return address using RAW sockets to route the response back to the requestor. It can fool web pages (like CNN) as it blocks ads and replaces dynamic ad script requests with innocuous javascript responses. https://github.com/bitbank2/bb-hole

According to their docs, it can run at 1.8Ghz and since it's a 28nm chip, it should use less power than the H5. This doesn't mean that the OrangePi boards will run at 1.8Ghz, but at least it's a possibility. It also supports USB 3.0 and DDR4 RAM. Again, these are capabilities of the chip and not necessarily exposed on the SBCs sold by Orange Pi.

Nice - thanks for the heads up. I'd like to see the other H6 offerings too before I buy because I'll probably just get one H6 board for testing.

Is it available yet? Any other H6 boards have pricing availability?

I just updated my LCD library to make use of ArmbianIO. Now you can easily talk to those inexpensive LCDs from your ARM SBC. You can find the code here: https://github.com/bitbank2/nokia5110

I'll have to dig up the LEDs, but if they're used by the system then you won't be able to access them through the sysfs GPIO interface; you'll have you use the kernel LED driver. The button on the NanoPi Duo is GPIO 355

I2C devices normally have a "register" structure where you write the register number before reading its value. I also initialize the sampling/power mode of the device. It's hard to make heads or tails of the python code because I can't see the variable types. Some of the BME280 registers are signed values and some are unsigned. It's easy to mess things up if you're not careful with the handling of signed/unsigned values and overflowing 32-bits.

My bme280 is on a little breakout board (see lower right corner of photo). The fusable links are pre-set and I only connect the 4 wires (GND, VCC, SCL, SDA). Show us what you're using.

I use that sensor on all of my boards (Orange Pi Zero, RPIs, NanoPis) and it gives consistent results. I'm not sure why you're seeing an issue, but it would be helpful to see your code. I've written C code to directly read the calibrated values from the sensor. You can try it as another test: https://github.com/bitbank2/bme280

I wrote it specifically for Armbian, but it doesn't hurt to support RPI boards. This way I can test my code across a wider range of boards. I have a desk full of ARM SBCs from various vendors (including RPF). I tend to write code to support the hardware I own.

ok, I finished the armbian_oled library. It uses ArmbianIO to talk to I2C and SPI SSD1306 OLED displays: https://github.com/bitbank2/armbian_oled

Hopefully no one will object, but I just added support for the Raspberry Pi Zero to the ArmbianIO supported boards. It's easy to detect with uname (the only ARMv6 board). If I find a reliable way to detect the other RPI boards, I'll add support as well. Makes it easier for me to test code. I also wrote a SSD1306 OLED library (I2c and SPI support) using ArmbianIO. I'll share it on my github account hopefully later today.

Thanks for your contribution. I'm on the road today and will add it to the master branch when I return.

Yes, I don't own all of the boards supported by Armbian. The library needs the board name and a pin-to-GPIO table for each supported board. Perhaps you can add the necessary info. You need to add the board name (found in /run/machine.id). Then add the corresponding pin to gpio table for that board.

Try my ArmbianIO project, it provides a simple C interface for GPIO and supports the Tinkerboard: https://github.com/bitbank2/ArmbianIO