Larry Bank

I just released a new C library for communicating with those inexpensive 4-digit 7-segment LED displays:
 
https://github.com/bitbank2/tm1637
 
They can run on 3.3V or 5V and draw between 1 and 15mA depending on the brightness setting. I purchased mine from an AliExpress vendor for 68 cents each with free shipping.
They use a custom 2-wire communications protocol and must be "bit-banged" from 2 GPIO pins. In my demo, I assign pins 38 and 40 on my Orange Pi Lite.
 

Thanks for mentioning that @Igor, I share a lot of code, but rarely get any feedback that people are using it.

Thanks for mentioning that @Igor, I share a lot of code, but rarely get any feedback that people are using it.

Thanks for mentioning that @Igor, I share a lot of code, but rarely get any feedback that people are using it.

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
 

H there, 
I am using OPi0 TV out. I know, there are hardcoded PAL and NTSC resolutions only. But I would like to ask, if there is any tutorial how to build it up with my own lower resolution e.g. 320x240? (i know I should recompile driver for it but any help where to start is appreciated)
 
Many thanks.

Well it took me longer than i hoped but i have managed to forward port icenowys code for TVE on the H2+/H3 to mainline armbian.  It seems to work totally fine, with a few caveats.
First: Sample images of it in action -> https://imgur.com/a/vXQEM
Second: the patch itself -> https://github.com/stevenj/h3-tve/tree/v0.0.11
Third a prebuilt image for Orange Pi Zero: -> https://github.com/stevenj/h3-tve/releases/tag/v0.0.11
 
Howto:
just put the patch into userpatches for the sunxi-next kernel, and build.  it should apply cleanly. Its for H2+/H3.  I have only tried it on a orange pi zero, but it should work on all H2+/H3 boards.
 
You then need to edit /boot/armbianEnv.txt
add tve to overlays to enable it.  the driver will only run and enable tv out when the tv out devices are specifically enabled, so i created an overlay which does this.  If you want to turn TV out off, just remove tve from the overlays line.
My armbianEnv.txt overlays looks like this:
overlays=usbhost2 usbhost3 tve If you want copious amounts of DRM debug info in your logs, add this as well:
extraargs=drm.debug=0xF Its not needed, unless you really want the debug info.
 
Notes:
1. The default mode is PAL, with 720x576 resolution.  Thats outside of normal PAL displayable area, and so the screen overscans.
I dont know how to correct this, although its mostly just annoying with terminals.
I also don't know how to change the video mode to NTSC.
 
2. The standard font is a bit thin for composite video, and causes slight strobing and color impurity.  Its because PAL needs pixels to be a certain MINIMUM width or color information can not be properly encoded.
A way to resolve this is use :
# apt-get install fbterm ... $ fbterm -s 20 This will run a terminal which is easy to change the font, and pick a bigger one.  its much easier to read.  Look at the help for fbterm to work out everything it can do.
 
3. I used the program "fim" to display the test images.  there are others for doing stuff on the terminal.
 
4. I haven't tried X.  I am not interested in running an X terminal on a TV, but it should probably work fine.
 
Other than that it all seems good.  I originally tested my hardware with the legacy kernel, and the image quality from this patch seems superior to what the legacy kernel produces. (legacy was noisy)
 
The only other thing you need to know is Orange Pi Zero is missing filter circuity from its Composite Output, the most important thing you need to do is put a 50 ohm resistor between the signal and GND.  i soldered one inside my RCA connector, it fits fine and isn't too difficult.  IF you don't do this the image will bloom and look like total crap, so you have been warned.
 
As this patch allows TVE to be enabled/disabled through use of the Device Tree overlays, i think it should be fine if the Armbian devs want to include it.  I am happy to clean out some of the debug messages i added if they are interested in making a standard part of the build.  If not, its easy enough to build your own image, just follow the guides on how to rebuild armbian.
 
EDIT: I need to mention, all props go to Icenowy Zheng who wrote the original driver.  I just tweaked the device tree stuff and got it in a state where it can apply cleanly to the armbian mainline kernel and build system.
Original code is here:
https://github.com/Icenowy/linux/tree/tve-v2

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

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
 

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

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?

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?

Wow, what a groundbreaking contribution to this thread. Especially cause you pointed clearly out 
What's childish the bigger picture what you think what should change [/sarcasm]
 
For your notes: I've this board at home,  I did some tests with it and finally lost the interest... I'm not a:
guy, so doing this stuff needs much more time for me than for a professional (and get false or not properly written stuff from professionals annoys me quite fast)... Even before I had the board at hand, we (as armbian community) pushed the vendor to:
Fix voltage regulation for CPU Release schematics Figured out that ETH is on CON4 (you could figure it out when reading the schematics carefully, but nowhere else) So even if this board does not get 'official armbian support', the childish armbian community helped to improve the situation for this board. To my knowledge, neither the boardmaker nor someone else sent a PR with the needed patches for full or csc support for this board to armbians github... 

I was chatting with @tido about ways to help the Armbian community and I came up with the idea of a common C library to access the I2C, SPI and GPIOs of all supported boards. There are of course kernel drivers to communicate with these things, but there are differences between boards that this API could help smooth out. For example, different CPUs (and boards) map the GPIO pins very differently. Projects such as WiringOP and WiringNP try to copy the Raspberry Pi library, but this is also flawed because it's based on the BCM283x GPIO numbering. What I propose is to create a set of simple functions for accessing GPIO pins using the physical pin number as a reference. On all boards, the 5V pin will be considered pin 2 and the numbering goes from there. There are also sometimes pushbuttons present on the board which are mapped to GPIO inputs. These are also covered by my API. Much of the code is already written and I will release it shortly.  I'm posting this topic to get feedback and to reach out to people who might make use of this. Here is a list of the functions so far:
 
int AIOInit(void);
void AIOShutdown(void);
const char * AIOGetBoardName(void);
int AIOOpenI2C(int iChannel, int iAddress);
int AIOOpenSPI(int iChannel, int iSpeed);
int AIOCloseI2C(int iHandle);
int AIOCloseSPI(int iHandle);
int AIOReadI2C(int iHandle, int iRegister, unsigned char *buf, int iCount);
int AIOWriteI2C(int iHandle, int iRegister, unsigned char *buf, int iCount);
int AIOReadSPI(int iHandle, unsigned char *buf, int iCount);
int AIOWriteSPI(int iHandle, unsigned char *buf, int iCount);
int AIOReadWriteSPI(int iHandle, unsigned char *inbuf, unsigned char *outbuf, int iCount);
int AIOReadButton(void);
int AIOAddPin(int iPin, int iDirection);
int AIORemovePin(int iPin);
int AIOReadPin(int iPin);
int AIOWritePin(int iPin, int iValue);

I know there are direct means to access GPIOs, but then I would need to write code unique to each CPU. If Armbian only supported AllWinner H3 devices, it would be an easy decision. For now, I think it's best to keep the code simpler and support all SoCs.
 
I'm not sure where this project is headed. I don't have the time to turn it into a support-everything/do-everything library. I saw a need and I put together a simple solution. It would be great if this was given the "blessing" of Armbian and turned into a real community effort.
 

I've changed the way the Python wrapper is generated using ctypesgen instead of Swig. This makes the shared library much smaller because it doesn't have any Swig junk linked in. It's basically just a shared version of what @Larry Bank's make builds with the static library (maybe we should add an #IFDEF for that, so I don't have to compile it). There no need to load the library in your code since ctypesgen handles that in the armbianio.py it creates. Your Python code is more elegant and there's no mixing Swig shit code with ctypes or weirdo interface files just to deal with pointers. I'm going to generate the JNA code as well for Java just so I don't have to maintain the interface file if the underlying C API changes. Not sure about JavaScript yet, but if I can find a generator that deals with pointers well then maybe I'll try that next. Here's the obligatory Button program using a callback:
import time from armbianio.armbianio import * # Simple callback displays pin and value def buttonCallback(iPin, iEdge): print "Button state: pin = %d, value = %d" % (iPin, iEdge) # Detect SBC rc = AIOInit() if rc == 1: # Function returns char array print "Running on a %s" % AIOGetBoardName(); if AIOHasButton(): button = 0 # Button callback AIOAddGPIOCallback(button, EDGE_BOTH, AIOCALLBACK(buttonCallback)); print "Press/release button a few times\n" time.sleep(10) # Remove callback AIORemoveGPIO(0) else: print "%s does not have a button" % AIOGetBoardName(); AIOShutdown() else: print "AIOInit error"  

I really hope ArmbianIO spreads widely. And relying alternatively on /proc/device-tree/* might help with user adoption. For example once DietPi users start to use ArmbianIO it could be surprising that ArmbianIO only works on approx half of the boards DietPi 'supports' (since DietPi relies on Debian OS images found somewhere or uses Armbian's build system to create crippled Armbian images with the DietPi menu stuff on top sold then as 'DietPi' to their users -- so if their OS images started as Armbian there will be /var/run/machine.id... otherwise not).
 
BTW: In Armbian for all the Allwinner boards that run legacy kernel we tried to use exactly the same string as /proc/device-tree/model to let this method work regardless of legacy or mainline kernel. Since other projects out there (H3Droid, RetrOrangePi, Lakka) also use our fex files they should become compatible to this 'other fallback' too (at least that was my intention behind these adjustments made a while ago). Some details: https://tech.scargill.net/banana-pi-m2/#comment-27947
 
 

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.
 

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.
 

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.

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 not 'The grandfather of SoCs', if you think that, you are about 10 years late, and it is a good example of how you can still make a good project of obsolete hardware by having enough people buy into the hype...

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