lanefu

As already done with other topics this will be the start of a new thread collecting more information over time.
 
Since we had a lot of annoying discussions recently regarding Wi-Fi on Orange Pi Zero and in general I thought let's give it a try a few days ago. I did some preparations in the meantime (monitoring 24/7 Wi-Fi throughput in 2.4 GHz band for example) and then started to test in a not too crowded environment here.
 
As a start some quick Wi-Fi tests with a random 'quality' USB Wi-Fi dongle and 3 different Wi-Fi chipsets that can be found an a few boards Armbian supports:
 
RTL8192CU (used on a lot of cheap USB dongles and even on Lamobo R1) Ampak AP6212 (based on Broadcom's BCM43438 module also used on RPi 3 and Zero W, nearly all Wi-Fi equipped NanoPi and Banana Pi) RealTek RTL8723BS (used on Pine64+ and on CHIP for example) RealTek 8189FTV (used on the more recent Wi-Fi equipped Orange Pi)  
The usual Wi-Fi performance 'benchmark' results available here and there most of the time ignore a lot of important bits, eg.
 
Environment (Wi-Fi means shared media so in crowded areas with a lot of other Wi-Fis around you fight for free slots on the media, even USB3 peripherals or microwave ovens happily interfere with your Wi-Fi performance) Environment (yeah, again: This time aerial/antenna used, position of antenna in relation to AP, distance, free sight or not, walls/stuff that filter or reflect signals) Settings (Wi-Fi powermanagement enabled or not? Which cpufreq governor used? Performance results can vary based on at which clockspeed CPU cores run)  
So for the test I chose to let all boards run with performance governor and Wi-Fi powermanagement disabled. All are equipped with the same el cheapo Xunlong aerial (sent with all Orange Pi that are Wi-Fi capable). Position of antenna is always the same, distance from AP (Fritzbox 7390) to board approx 50 cm, AP in cabinet (20mm MDF). Almost same environmental conditions (due to some testing delays I could not guarantee that Wi-Fi channel utilization was always the same but since I let a constant iperf3 monitoring run for the last couple of days I chose time slots where maximum throughput seemed to be possible).
 
Also no Ethernet connected (since it's easy to f*ck up performance tests in this scenario when wired and wireless interfaces of both device and router/AP are somehow all connected since some kernels then send packets over the wrong interface) and Wi-Fi connection established the usual way (nmtui --> 'Activate connection' --> done) with /etc/network/interfaces being empty (to let network-manager control all devices for smooth networking).
 
Now the results:
 
NanoPi Air with el cheapo Xunlong aerial, AP6212 module, Kernel 3.4.113, no BT configured: 39 Mbits/sec and 188 retransmits on average. Full log: http://sprunge.us/aPXb
 
 
Pine64+ with same el cheapo Xunlong aerial, RTL8723BS module, Kernel 3.10.104, no BT configured: 39 Mbits/sec and 58 retransmits on average. Full log: http://sprunge.us/EffO
 
 
Orange Pi Lite, RTL8189FTV module, Kernel 3.4.113: 41.5 Mbits/sec and 50 retransmits on average. Full log: http://sprunge.us/dWJV
 
 
ODROID-C2 with TP-Link TL-WN823N dongle, RTL8192CU module, kernel 3.14.79: 77 Mbits/sec and 73 retransmits on average. Full log: http://sprunge.us/Njhi
 
 
How to interpret the results?
 
The test setup is stupid for any real world consideration (if distance between device and AP is just 50 cm then use a cable instead!  ) But this set of tests was about identifying the maximum you can get under perfect or at least pretty good conditions (no interference, rather good signal/noise ratio and so on) All 3 onboard Wi-Fi chips perform identical. This is due to single antenna 2.4 GHz Wi-Fi: 65Mbps bit rate resulting in ~40 Mbit/sec TCP/IP throughput with ideal/good/identical environmental conditions The only reason the TP-Link Wi-Fi dongle could outperform the onboard Wi-Fi chips is called MIMO. This is available with 802.11n and makes use of more than one antenna (2 in this dongle's case). Now we're talking about 130 Mbps bit rate resulting in almost 80 Mbit/sec TCP/IP throughput  
Next steps:
 
Let's have a look how worse environmental conditions affect performance. This means increasing distance between AP and device, put a few walls in between, use a more crappy antenna. To save some time I will continue the testing solely with the TP-Link Wi-Fi dongle (connected to the ODROID but here the board doesn't matter at all, it's just about the driver variant/version used) and Orange Pi Lite since this is the cheapest 'general purpose Wi-Fi' enabled board Armbian supports and the same chip is also used on OPi PC Plus and OPi Plus 2E (which are both also priced very competitively for their feature set).
 
But I will add also results from Raspberry Zero W if this board ever arrives (if not I'll take RPi 3 instead, both use same BCM43438 chip that is also contained in Ampak's AP6212 which is the solution present on most Wi-Fi enabled Armbian boards)

Zador, tkaiser, thanks a lot, it helped adding
overlays=sun8i-h3-usbhost2 sun8i-h3-usbhost3 into /boot/armbianEnv.txt and rebooting. DISCLAIMER: the overlay names may change as the development goes on.
 
Of course I realize it's a development kernel, and I'm not going to use it for any production installations. But as I'm evaluating the platform in general, I prefer using the latest development software. Do you feel comfortable if I report any issues in the same format on this forum? It's in my habit to report bugs or thought-to-be-bugs
 

No ! it is using kernel spidev transactions thru /dev/spidev*.* devices.

I don't know about specific WS2812 protocol, but doing an SPI transfer is about as simple as :
from pyA20 import spi spi.open("/dev/spidev0.0", mode=0, delay=0, bits_per_word=8, speed=5000000) data = [0,1,2,3,4,5,6,7,8,9] spi.xfer(data, len(data))

ill have to dig through my notes to show you.... at this point im uninspired to persue wiringOP because it just has so much junk in it. I see why werecat threw a fit on the orangepi forums a while back. 
so ill slowly start chasing the python route. someone forked pya20 specifally for the zero.... i updated the first post of this thread and added it as a resource. i did a quick test with onboard led and it seemed to work
 
anyway i think pursuing an autodetecting pya20.gpio fork is the most straightforward path.
 
Tapatalk thinks its important to tell you im using tapatalk from a phone.

https://www.armbian.com/kernel/
https://forum.armbian.com/index.php/topic/2422-more-proper-testing-better-armbian-experience/
 
We provide even daily builds of this(all) kernel(s), but we won't hear any of pleads for help, because such service is stupid, costly, inefficient, ... supporting stable kernel is already way over for a free amateur service. Developing kernels are built daily for developers and for testing, that we are able to improve them ... and one day, when we are satisfied with quality, put them out.
 
That's the point.

Holy cow.. I had no idea how ugly the wiringpi C library really is... it's really ugly.. not that I know what I'm doing--but It's ugly.  

BTW: Reasons why 1st 'Earth-friendly EOMA68' design relies on an Allwinner SoC: https://www.crowdsupply.com/eoma68/micro-desktop/updates/picking-a-processor

BIG tnx  zador.blood.stained for hi quality answers
 
if you really want to use I2S on this board the best option would be to unsolder R69
 
i have made it and i2s dac work fine , tomorrow i will try fix wifi poweron
 
i still like my tiny board ))))
 
some pics for another guys who like connect i2s dac

PA20 is not available on the header, it is used for controlling wireless chip power. It can only be used by soldering a wire to one of pads for resistor R69 (can be seen on the board between wireless chip and Ethernet transformer, resistor itself needs to be desoldered) and changing wireless driver configuration. 

I managed to write H3 HDMI driver for mainline U-Boot. Source can be found here:
https://github.com/jernejsk/u-boot
 
You should also add CONFIG_VIDEO=y to defconfig for your board.
 
It should work nicely for standard resolutions (720p, 1080p). Other resolutions might work, but some additional work needs to be done. Currently, this can be used for working with U-Boot (instead of serial console) or splash screen.

Instead, we were rewarded. Not many got this privilege.
 
 
 
https://distrowatch.com/weekly.php?issue=20170116#donation

I'd say go with WiringPi, so we could reuse existing projects for Rpi. If you'd go with pyA20, then fork it and make it compatible with Rpi.GPIO so we can reuse those projects for RPi .

My personal preference is that the wiring should follow the Arduino libraries.
My thinking is that it you do that then you get some compatibility with all the Arduino based peripherals to some degree out of the box.
Python should follow based on a solid C/C++ implementation of the drivers/ APIs.
 
But just a biased opinion.
Disclaimer lots of years in the C/C++, C#  world, not so much in the Python world.

Designed a case for it. Available on thingiverse if anyone interested - http://www.thingiverse.com/thing:1918590
 

Great news: linux-sunxi community got boot from SPI NOR flash to work: http://linux-sunxi.org/Orange_Pi_Zero#Mainline_U-Boot
 
Apritzel also managed to hack the function of the 'power button' to become a FEL button instead (so you're able to boot from SD card by pressing the button even if a 'firmware' is already stored in SPI flash -- useful only for OPi PC 2 now since Zero is missing the button).
 
What's missing still? SPI NOR flash soldered on the Zero by default as it's already the case with OPi PC 2. So please make some noise to convince Xunlong soldering the same 16 Mb (2 MB) flash on the Zero starting with next production batch. Please leave feedback in OrangePi forum and on Aliexpress!

You could manually install X without a larger desktop environment on the console-only version of Armbian or strip away the unneeded parts of the desktop version.
You should then be able to use "startx" to run the X server on-demand for a single application. eg. "startx /usr/bin/mpv --fullscreen video.mp4"

I think we should edit all fex files for H3 boards, remove all definitions from [gpio_para] section and add a comment that this section is obsolete.

yes, it has same or better functionality and it must be present anyway (pinctrl) if you want to have useful kernel.

Yes, RPi.GPIO is coming from RaspberryPi community, I'm using the RPi.GPIO-PineA64 derivative since it is already as most pins there, I've submit a PR yesterday to add SPI/I2C borrowed from Olimex pyA20 to this pineA64 derivative, original Pi version still don't support those yet.
 
On H3, I prefer using the orangepi_PC_gpio_pyH3 since it is a derivative directly from Olimex pyA20 : https://github.com/duxingkei33/orangepi_PC_gpio_pyH3

GPIO sysfs interface should be the same on both, mainline and BSP, kernels. I checked that a month or so back. I think the only work which needs to be done here is identifying differences between the boards and implement this in a sane way.

Alrighty -- WiringOtherPi task thread here

Challenge Accepted.
 
WiringOtherPi here we come...
 
As you know I only barely know what I'm doing, but there's plenty of bright minds to steer us straight.    I'll scribble some things and kick off a task.   I need to do some groking on how much different GPIO stuff is or isn't with mainline

Orange boys are very busy nowadays new add-on board for 2$ for the Orange Pi Zero https://es.aliexpress.com/item/New-Orange-Pi-Zreo-Expansion-board-Interface-board-Development-board-beyond-Raspberry-Pi/32770665186.html?detailNewVersion=&categoryId=200004017
 
 

Just take latest version from github repo since I changed all 'machine' entries in there to be compatible with mainline kernel. Reason behind: stop producing yet another WiringOP library, join development efforts and produce a single lib suitable for all H2+ and H3 boards: http://tech.scargill.net/banana-pi-m2/#comment-27946
 
What about forking WiringOP one last time, adding board auto detection (@jernej's read_fex code works flawlessly -- when executed as root) and creating one package that will be installed on sun8i boards automagically?
 
IMO we're not that far away from that since in linux-sunxi and FriendlyARM wiki pin headers are documented (only exception the 'great' Banana Pi M2+), the fex changes to detect the board at runtime are already there so only someone who knows what he's doing (definitely not me if it's about GPIO low-level stuff) is needed to get the job done? Maybe creating a task for this so that others might be able to contribute in a reasonable way?
 
Please see in the aforementioned thread in a few comments above for links to expansion header pin mappings and here for OPi Zero schematics (H2+ is just a stripped down H3, no GbE MAC and no 4K HDMI output are the known exceptions so far).