Larry Bank

I just released a simple library for the MAX7219 LED matrix controller. It allows controlling any number of cascaded controllers in a very simple way. I tested it on an Orange Pi Lite. Even though it says it needs 5V, I ran the board @ 3.3v, it worked fine and didn't require any 3.3v->5v level converters. Here's the code: https://github.com/bitbank2/MAX7219 And a video of it in action: https://photos.app.goo.gl/iO66bsy6Wk13lT1y2

A refresh rate of 5-10fps through SPI is plausible for a 320x480 display, but at 800x480 it will be slower much slower. The maximum I've been able to run SPI reliably is about 40Mhz, at that rate, your display refresh (at best) would be: 40,000,000 / (800 x 480 x 16) = 6.5fps. The reality is more likely that the SPI controller on those displays only runs reliably at up to 16Mhz and the inter-byte delays cause the refresh rate to be closer to 1-2 FPS. Very unpleasant to watch a screen update at that speed. Is there a reason for avoiding HDMI or even composite video? Could you use a "sacrificial" $7 Orange Pi board to drive the display through HDMI and communicate with it over SPI? P.S. Running FBTFT or some other kludge to get X11 output onto the display will add another level of headache. P.P.S The touchscreen output is usually over SPI, not I2C.

I just released a new C library to draw text and graphics on the UC1701 128x64 monochrome LCD. It makes use of my ArmbianIO library to manipulate the GPIO lines: https://github.com/bitbank2/uc1701

Do you mean directly read/write the current time to the RTC registers? Take a look at my C code: https://github.com/bitbank2/rtc_eeprom

That display is easy to work with if you don't need direct Linux/X11 support. What I mean is that I've written code to talk to those LCDs and it can draw text and graphics through direct function calls (e.g. Draw a string a of text at a specific x,y in a specific color). If that's sufficient for your project, give it a try: https://github.com/bitbank2/SPI_LCD

Thanks for noticing that. I've got mine sitting on my desk as a paperweight waiting for someone to release a working Linux distro for it. I'll report back my power consumption and speed measurements later today. Ugh - now I remember why I appreciate Armbian so much. The Linux distro provided by OrangePi is 1.5GB, yet somehow is missing everything I need. This may take a while... Update: The board doesn't really seem to have any advantage over H5 boards. The max CPU frequency in the kernel shows as being 1.8Ghz, with the min set to 480Mhz. When pushed by my gcc_perf test, the results didn't fare much better than an RPI3. The power usage is what's really disappointing. The other H2+/H3/H5 boards I've tested usually max out at about 580mA when all 4 cores are cranking. The H6 is supposed to be a 28nm process and I thought that would mean lower power usage. The Orange Pi One Plus maxes out at 830mA when all 4 cores are stressed by gcc. Can anyone else do some testing to see if it matches my results?

This is even more interesting. Pine64 is apparently going to release a low cost RK3399 board ($60!). Here are the details: https://forum.pine64.org/showthread.php?tid=5614

https://www.aliexpress.com/item/Orange-Pi-RK3399-2GB-DDR3-16GB-EMMC-Cortex-A72-Type-C-Double-CSI-interface-Development-Board/32850569302.html $114 with shipping from AliExpress. Interesting board. I don't have a specific use for it, but it's great to see more powerful ARM chips being offered as SBCs.

Are you willing to give ArmbianIO a try? It has C, Java and Python bindings and should work fine on your board. I'm not sure if your board name is in the list of supported boards, but you can pass it the name of the Orange Pi Zero (which should have the same gpio mapping). https://github.com/bitbank2/ArmbianIO

The PhoenixCard tool is the one I was referring to. When I run it, it makes the cursor change to "busy" for one second and then nothing. Is there some secret to install/run it besides unpacking the archive into a directory?

I sent a complaint through AliExpress and Steven Zhou (director of Xunlong) responded that I needed to use his special microsd image burning tool. The tool he directed me to use is supposedly the only way to get Android images onto microsd cards for the board. I downloaded the tool on my Windows 10 laptop and it doesn't even run. I told him this and now he tells me to run the program in a VirtualBox running Windows inside of Linux. I asked if I could use a beta copy of Linux and he said he would not provide one. Basically SOL

That worked - thanks. I just loaded the latest Armbian Next build and it's still messed up. Can someone please fix this?

Hi Stuxnet, Thanks for the encouragement. Richard Hull's project is pure python and doesn't have any additional useful info for me. In fact, his project takes a very simplistic approach to the GPIO numbering and won't work properly on all boards. I'll keep improving ArmbianIO with the goal of it being easy to use and having support for all boards supported by Armbian.

This looks like a solution for 4.x kernel, but what about supporting 3.x? There doesn't seem to be any board-specific info in the /proc directory.

I'll explore fixing the board name situation using your suggestion. Another reason I shared ArmbianIO as open source was for other people to contribute. @sgjava has already made some significant contributions such as Python and Java wrappers for it.

ArmbianIO is not a fork of WiringOP. I wrote ArmbianIO because of the terrible situation with WiringOP and WiringNP. Using the BCM numbering on Allwinner boards is understandable for RPI compatibility, but limits what you can do with non-BCM chips. I thought a fresh start which treats all boards as unique and allows more than 40-pins of GPIO header would be wiser than another "crutch" of a hacked up WiringPi copy. I have a wide variety of boards and ArmbianIO (even running on Raspberry Pi boards) allows a consistent way to work with GPIO/I2C/SPI. I know that when I hook an LED or switch to a GPIO pin, I can run the same code on any of my boards and connect it to the same header pin and it will work without modifying my code. chwe: splited from https://forum.armbian.com/topic/6197-hardware-line-is-missing-on-proccpuinfo/ cause I think it's better to keep this in this thread.

That misses the point of ArmbianIO. The purpose of it is that when you connect your device to pin X (e.g. 1-40) on the GPIO header, you reference X in your code and don't have to deal with the specifics of each SoC/board. The only way to accomplish that is to have a specific pin map for each board and properly identify the board. I recently added a new option that lets you manually specify the board by name if it doesn't see the machine.id.

There is no "SoC specific pin map". The SoC info is not enough to know the pin map because it's completely arbitrary and up to the board manufacturer. The 40-pin header on the NanoPi boards use different GPIO ports from the 40-pin header on OrangePi boards.

I haven't tried to build a Linux image. There is no serial output with the Android image I tried. Can you share a Linux image for me to test?

I received my Orange Pi One Plus (H6) yesterday. I tried the Android img provided by OrangePi.org. It doesn't boot and just sits there with no output on TTY nor HDMI. The board is drawing a constant current of 90mA and doesn't appear to work. Anyone seen this or have any suggestions?

A new wrinkle to this idea. I've been working with Arduinos lately and thought it would be useful to extend the ArmbianIO concept to use them as "slave" interfaces for sensors/displays/etc. This is an experiment I'm working on and would like some feedback. The idea is that the ArmbianIO API can be used identically on Windows/Mac/Linux. On a remote setup, an Arduino will be used as an I/O slave listening for commands over the serial port. The ArmbianIO you compile on your PC will translate the I2C/SPI/GPIO functions into strings of commands/data over the serial port. Below is a video of my https://github.com/bitbank2/oled_example project running on my Mac and the same exact C code running on my Orange Pi Lite board next to it: Please let me know your thoughts.

RPI is married to Broadcom because that's where their engineers used to work. They cobbled together their SBCs from older, inexpensive parts to be able to hit their "amazing" price points. The Broadcom SoCs were designed for set top boxes and are not necessarily the best for Linux SBCs due to their long list of limitations (e.g. slow USB, slow+old ARM cores, slow+limited RAM). For me, the worst offender is the Raspberry Pi 0. It's 11 year old technology (armv6) released with a "teaser" price that was never meant to succeed as an actual product. The other end of the spectrum for offensive Linux SBC board vendors is Qualcomm. They tease out their overpriced chips in a watered down board with odd and half-working (e.g. GPS) parts to get their feet into "this IoT market thing". The Chinese chip vendors are the only ones who are willing to put their best chips (e.g. RK3399) onto publicly available boards running Linux. I have a feeling that this is more of a "try anything to conquer all markets" than a real understanding or effort to help the IoT community.

More important question - anyone know when a Linux boot image will be available for the OrangePi H6 boards?

I have the good fortune of owning an Asus Flip CP100A which is a RK3288 1.8Ghz w/4GB RAM and USB 3 ports running Linux via Crouton. No heat/power problems and runs about 5x faster than an RPI3 Maybe the new "S" version of the Tinkerboard will fix some of the issues you're seeing.

They don't use the same processor. Tinkerboard: RK3288: fast 32-bit Cortex-A17 Rock64: RK3328: average 64-bit Cortex-A53 The Tinkerboard actually is faster even though it's a 32-bit CPU compared to the ROCK64's 64-bit CPU