Larry Bank

I have a running obsession with sensors/motors/SBCs and have been creating a collection of C libraries as I learn/conquer each new device. I recently added a few that might interest some of the forum residents here. They include a C library to talk to the RPI Sense Hat, ST Micro VL53L0X time of flight distance sensor, and CCS811 air quality sensor. You can find them all here:
 
https://github.com/bitbank2
 
If anyone has a sensor/add-on that they would like to program in C from their Orange Pi and there isn't any code available, let me know and maybe I can add it to my collection.
 
 

I have a running obsession with sensors/motors/SBCs and have been creating a collection of C libraries as I learn/conquer each new device. I recently added a few that might interest some of the forum residents here. They include a C library to talk to the RPI Sense Hat, ST Micro VL53L0X time of flight distance sensor, and CCS811 air quality sensor. You can find them all here:
 
https://github.com/bitbank2
 
If anyone has a sensor/add-on that they would like to program in C from their Orange Pi and there isn't any code available, let me know and maybe I can add it to my collection.
 
 

I downloaded your image from your google drive yesterday (btw google drive is an awful storage place when you've to download large files from a console, but this small python tool helps a lot).  I mounted the fat partition and extracted script.bin from /bananapi/bpi-m2z/script.bin. A quick look at it wasn't that exciting.
 
3. line:
machine = "Banana Pi BPI-M2-Plus" false board name as Thomas said on one of his first posts in this thread (July 30). 
 
183 - 190:
[uart3] uart_used = 1 uart_port = 3 uart_type = 2 uart_tx = port:PA13<3><1><default><default> uart_rx = port:PA14<3><1><default><default> uart_rts = port:PA15<3><1><default><default> uart_cts = port:PA16<3><1><default><default> defined as uart_type 2 but rts and cts are defined. 
 
start at line 739:
[dvfs_table] pmuic_type = 0 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 11300 pmu_level1 = 1100 max_freq = 1200000000 min_freq = 240000000 LV_count = 6 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 1008000000 LV2_volt = 1300 LV3_freq = 912000000 LV3_volt = 1100 LV4_freq = 648000000 LV4_volt = 1100 LV5_freq = 480000000 LV5_volt = 1100 LV6_freq = 240000000 LV6_volt = 1100  
The only place where people see that it should be PL01 instead of PL06 is your schematics and armbians forum. 
 
If you still asking yourself why Thomas is attacking constantly your company, this might be a valid reason. Besides playing with SBCs I'm doing in science where we have a peer review process for everything we publish.  As a peer reviewer, I would reject your 'script.bin paper' with a short comment that you should do your homework first before I have a more detailed look at it. 
 
FYI: I didn't check everything in the script.bin and I'll not do it until you showed that things are improving. 
BTW: PL06 is used as USB0-id, I've no clue what happens when this pin goes from high to low (or vice versa) every time the CPU clocks up if you have a USB device connected to this port...  (EDIT: https://www.maximintegrated.com/en/app-notes/index.mvp/id/1822 could be interesting if you use USB as OTG with changing roles... )

I've been hitting similar issues trying new builds on various boards. I find it much less stressful to just use a USB wifi dongle when doing these kinds of tests. I'm running Armbian with a 4.13 kernel built for the Orange Pi Zero on my NanoPi Duo and with a USB wifi dongle, it works fine:
 
The Linux build provided by FriendlyElec has a super slow SPI driver, so I went in search of a way to see if it was a hardware or software bug. Running the OPZ build of Armbian on the Duo shows that it's purely a software bug.
 

I've been experimenting with the OP0 for use in a portable gaming device with an inexpensive SPI LCD display. I wrote all of the game emulator code, so it's very efficient between reading input and sending the image to the LCD (without fbtft).

I've been experimenting with the OP0 for use in a portable gaming device with an inexpensive SPI LCD display. I wrote all of the game emulator code, so it's very efficient between reading input and sending the image to the LCD (without fbtft).