StuxNet

For personal simplicity I would git clone https://github.com/duxingkei33/orangepi_PC_gpio_pyH3
Setup whatever pin you're connecting the switch to using the PYA20 library's (above) example code as seen here: https://pypi.python.org/pypi/pyA20
Use that library read the switch. For example: If pin high/low or on/off, use python subprocess or os.system functions to run linux shutdown, reboot command.

I might be able to give you a sample script or more concise instructions but don't hold your breath. For now I'll give you this, which is a pretty damn good start for having not really started
This is a script I was using on a NanoPiNeoAir using a reed (magnetic) switch attached to a door but could be easily changed to suit your needs. I've commented out the stuff that you won't need but much of the variable names are the same soo.... pretend the door is your switch! Or you can change the prompts/names yourself.

https://gist.github.com/BiTinerary/2734ac46e80af2b1a2158c9f0ba79e25

P.s. You'll need to specify the pin you're using for your button but if you use my script in tandem with the tutorial you link to (replace LED with switch) it should 'technically' work. Hack away at it, see what you can come up with and report back. Also..... you have heatsinks on your RAM dies but not your CPU? Sup with that?

From start to finish, here's how I did it.
 
Go to the following link, download build root, unzip it and 'cd' into the directory:
https://git.busybox.net/buildroot/
 
Then issue the following commands that are in italics and follow the bullet point directions.
 
make friendlyarm_nanopi_neo_defconfig
          - Where friendlyarm_nanopi_neo_defconfig is the name of your board's def config located in the /buildroot/config/ folder
make menuconfig
         - A UI will pop up and you can add/remove packages or libraries from here. ie: Python, nano, libgpiod, etc... (Use "/" key to search)
make uboot-menuconfig
         - This is the direct answer to OP's question
         - From this prompt, scroll all the way to the bottom
         - Device drivers --> USB Support --> Uncheck all boxes
         - There's also another option to reduce boot time. Go all the way back to the first page of uboot-menuconfig
         - Change delay in seconds before automatically booting to 0
make
 
This will output /output/images/sdcard.img. use Etcher or w/e to write to sd card like usual. Make command took ~1hr to compile the first time so...
The link below is a NanoPi Neo image, with no password. It boots in 4 seconds and has Python, libgpiod and nano installed and nothing else. No USB or Ethernet.
https://fastupload.io/2vykAzhretXuft1/file
 

From start to finish, here's how I did it.
 
Go to the following link, download build root, unzip it and 'cd' into the directory:
https://git.busybox.net/buildroot/
 
Then issue the following commands that are in italics and follow the bullet point directions.
 
make friendlyarm_nanopi_neo_defconfig
          - Where friendlyarm_nanopi_neo_defconfig is the name of your board's def config located in the /buildroot/config/ folder
make menuconfig
         - A UI will pop up and you can add/remove packages or libraries from here. ie: Python, nano, libgpiod, etc... (Use "/" key to search)
make uboot-menuconfig
         - This is the direct answer to OP's question
         - From this prompt, scroll all the way to the bottom
         - Device drivers --> USB Support --> Uncheck all boxes
         - There's also another option to reduce boot time. Go all the way back to the first page of uboot-menuconfig
         - Change delay in seconds before automatically booting to 0
make
 
This will output /output/images/sdcard.img. use Etcher or w/e to write to sd card like usual. Make command took ~1hr to compile the first time so...
The link below is a NanoPi Neo image, with no password. It boots in 4 seconds and has Python, libgpiod and nano installed and nothing else. No USB or Ethernet.
https://fastupload.io/2vykAzhretXuft1/file
 

@lanefu will help around admin duties.

because it is an electron programm.
 

this guy figured it out with PCA9685 but what do we have to change to drive servos

I've gotten higher than 1A ratings from a USB port (usb 3.0) before and absolutely gotten less than 1A from a similarly rated 'ac/dc module'

Can never go wrong with getting an appropriate, reliable setup. In my experience, FriendlyArm boards are no where near as fickle (power wise) than OPi boards. I can boot any of them from just about any power source I connect them to. For this reason I prefer the Neo.

OPiZ's are absolutely a different case. For me, they rarely work just from USB, unless I use a specific, good quality cable.  Forget compiling/installing more robust libraries.  I can't speak too much on the relays you mention. I can tell you though that I've purchased 4+ OPiZ boards, all serve a purpose. Require dependable power supply setup. I have a Powerstrip that genuinely pumps out 2 amps + to USB port. So I use that with a good cord and I've never had a power issue since.

Tl,DR; OPiZ over all design quality isn't the best but it's still proven to be a working product. I've purchased many of them, the only power issue I've really run into has been at fault of my own setup.

Congrats! You're one of the first thinking about non appropriate powering, so we don't have to move the thread in this subforum.   
 
The USB of my notebook delivers more than 1amp stable on USB, the reason why I never mention it in terms of SBCs is that it is above the specifications for a USB port. Not every notebook will deliver and I don't recommend it at all. 
 
1A is a bit low, normally we recommend 2A at 5V. But let's see if we get it reliable working. Cause your use case seems to be not that calculation intensive, it might be OK when you rund your OPi0 with a minimal power consumption setup. I suggest you read through this thread here:
Reduce peak consumptions seems to be important for your case (which could be problematic with wifi ). 
 
For debugging, do you have a USB-TTL dongle so that you can connect to your board in case wifi isn't on but it is powered through your 'box setup'?
 
 

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
 
 

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);

Hi,
Larry patiently showed my how to use the armbianIO library to talk to the GPIO pins.
While all other go for Python and compatible to RPi - this is different.
This is designed native for SBC (Single Board Computer). No translation to the GPIO numbering necessary it fits 1-to-1.
We have built a first show case where 3 LED show you the temperature of your SoC. I guess you can imagine yourself several scenario's where this can be very helpful.
If you have some LEDs, 25min time it would be great to hear from you if it worked with your SBC
To start, please look here !
 
Cheers
Tido

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 see that you are using /sys/class/gpio to access GPIOs.
But other libraries are using /dev/mem to do a "mmap" directly to SoC registers located at 0x01C20800, which is faster and allows also to access to Pn_PUL0/Pn_PUL1 registers at offset 0x1c and 0x20 respectively.
Maybe you can take a look at this library : https://github.com/duxingkei33/orangepi_PC_gpio_pyH3
 

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.

I got a MFRC522 module working on Orangepi Zero. I could get really long winded about how it took 3-4 tutorials, hopping around between GPIO libraries getting irritated with people for not posting kernel specifics and referring to Orangepi Zero/PC/One simply as 'OrangePi' but I'm not going to. Instead I took the information I gleaned, put it all together in one spot, all nice and tidy for the community.

All in all the steps are pretty similar to what I found here, other forums and tutorials. Except uses a better GPIO library specifically for the Orangepi Zero. Not a clone of RPI.GPIO, ported to Orangepi PC, ported to the Zero. So give this guy some credit! https://github.com/rm-hull/OPi.GPIO

You can download, install all dependencies and start reading tags with this one line. It goes without saying that it should be executed as root.
git clone https://github.com/BiTinerary/OrangePiZeroMFRC522.git && bash ./OrangePiZeroMFRC522/getAllTheStuff.sh  
All the source of that one liner as well as pinout etc... is available at this repo.
https://github.com/BiTinerary/OrangePiZeroMFRC522

Wanted to automate payroll. Needed to be as simple/easy on the eyes as possible for your run of the mill user.

General functionality is that it makes digital timecards for every employee action/swipe of an RFID tag. Every swipe also punches a Google Sheet based on company department, by utilizing regex to find column associated with employee name, then the row based on today's date. It then punches current military time to corresponding clock in/out offset. The timecard math is all done using the Google spreadsheet functions to discern overtime, total hours, etc... More will be included later to automate even the spreadsheet template even though copy/pasting once every 15 days is trivial.

It's comprised of a OPi-Zero, MFRC522 RFID Module (for employee badges) a modified case, multi LED for clock in/out prompting, Google Sheet API and several existing dependencies/repos on GitHub. The most important 'juicy', details are documented on GitHub which will get you installed and running with the API, Module, LED, etc.... With more details to come, including step by step instructions on setting up Google Sheet API, etc.... Let me know what the community thinks.

https://github.com/BiTinerary/TimeClockPi

Installation >> Connect MFRC522 Module and run >> git clone https://github.com/BiTinerary/TimeClockPi && bash ./TimeClockPi/requirements.sh

Welp. It currently works for...more than a couple employees and has been tested using various means/devices for months.

I could go into more detail but your opinion does not apply to my specific circumstance. Regardless, thanks for the criticism. (seriously)
In my experience every 'small business' solution to this has been to simply, not have a time clock. Again, I could go into details but I'm not the trend that every local business owner I've met, has set.

I don't know what you mean by terribly complicated but I beg to differ. Let OPiZ offer RFID interface to a Gsheet. Let Gsheet functions calculate all the math.
This solution in tandem with a 'profession' timeclock that costs several hundred not $25 dollars, to create a physical timecard that needs to be digitized later, produces (dare I say) foolproof results.

Wanted to automate payroll. Needed to be as simple/easy on the eyes as possible for your run of the mill user.

General functionality is that it makes digital timecards for every employee action/swipe of an RFID tag. Every swipe also punches a Google Sheet based on company department, by utilizing regex to find column associated with employee name, then the row based on today's date. It then punches current military time to corresponding clock in/out offset. The timecard math is all done using the Google spreadsheet functions to discern overtime, total hours, etc... More will be included later to automate even the spreadsheet template even though copy/pasting once every 15 days is trivial.

It's comprised of a OPi-Zero, MFRC522 RFID Module (for employee badges) a modified case, multi LED for clock in/out prompting, Google Sheet API and several existing dependencies/repos on GitHub. The most important 'juicy', details are documented on GitHub which will get you installed and running with the API, Module, LED, etc.... With more details to come, including step by step instructions on setting up Google Sheet API, etc.... Let me know what the community thinks.

https://github.com/BiTinerary/TimeClockPi

Installation >> Connect MFRC522 Module and run >> git clone https://github.com/BiTinerary/TimeClockPi && bash ./TimeClockPi/requirements.sh

1. No (4 non shared USB ports + separate LAN)
2.  No idea,  not the fields I'm interested in...  (personal opinion H2+, H3 SBCs aren't best for multimedia purposes, but this just an opinion)
3. No (4 non shared USB ports + separate LAN)
4. No (it's also called CSI, but not the same)
 
Edit: When you consider using mainline:
No camera support at the moment (to my knowledge) No hardware accelerated video decoding

You can find a 4.11.9 rt patch here: https://www.kernel.org/pub/linux/kernel/projects/rt/4.11/older/
 
I have a vanilla mainline kernel with that patch applied and it works for me. I think armbian uses a separate github directory, so you might need to tweak the patch. 

What Igor said. From what I've seen mentioned, it sounds like in this case "newer != better" :-( I have two V1.1 Orange Pi Zeros that I purchased 2-3 months ago via their aliexpress page, and (after testing that both worked!) I have had one running 24x7 since I got it, open air without a case, plugged into ethernet running node-red and some other bits. I turned everything down power-wise and down-clocked it using the h3consumption script, and haven't had any issues with it, and it runs nice and cool. It does have a heatsink on it, but it certainly doesn't *need* it, but it helps keep it cool and let it throttle up for longer when needed. 

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).

If this is so, then why have many podcasts this in use ?
 
In my opinon Patreon would be a good additional option to:
   PayPal: Make This Recurring (Monthly) - option
 
Patreon, beside being an american company like PayPal, I see no bad thing about it, you keep 90%.
"It is popular among YouTube videographers, webcomic artists, writers, podcasters, musicians, and other categories of creators who post regularly online."
 
What are my responsibilities as a Patreon creator?
As I was reading this, does @Igor hold a Trademark for "armbian" - otherwise such donations could also be used to register it.
 

I have a NanoPi Neo Air now working as wifi accesspoint, showing SSID and allowing me to connect. My first trials with the apmode.sh (thanks FergusL) gave me the same problem that most of you had: There was an SSID being broadcast but I simply couldn't connect. In my case I believe the problem was doing:
rmmod dhd modprobe dhd op_mode=2 Because this brought down the wlan0 module and I found out that thereafter the wlan0 doesn't have an IP address anymore. This causes problems for dnsmasq and leads to dnsmasq not issueing ip-addresses to devices that connect to hostapd. So hostapd accepts the password but dnsmasq doesn't provide an IP address so you cannot connect..
 
So here's what I did:
1. I disabled NetworkManager once (that then makes that permanently disabled at boot up):
/bin/systemctl stop NetworkManager /bin/systemctl disable NetworkManager 2. Because Armbian in my case started up hostapd and dnsmasq during boot I disabled those too.
/bin/systemctl disable hostapd /bin/systemctl disable dnsmasq 3. I wrote a script that first brings down wlan0 (ifdown wlan0), then runs the ' rmmod dhd' and 'modprobe dhd op_mode=2' commands. After that it brings up wlan0 (ifup wlan0), so that it again gets an IP address (it uses the 'interfaces'  file for that). Finally the script starts hostapd and dnsmasq:
ifdown wlan0 rmmod dhd modprobe dhd op_mode=2 ifup wlan0 /bin/systemctl start hostapd /bin/systemctl start dnsmasq  
I created a service based on that script and enabled it with systemctl so that at each boot automatically the nanopi neo air is in wifi accesspoint mode and will broadcast SSID and allows connections.
I need to look up the exact script and the service files and will post those. It worked for my set up, hope it helps.
 

To bring up this board or in general? State of general A64 development within mainline kernel: http://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix 
 
If you want just help, there are many things to do:
 
Docs:
https://docs.armbian.com/Process_Contribute/

Build system sources:
https://github.com/armbian/build
 
Configuration sources:
https://github.com/armbian/config
 
Documentation sources:
https://github.com/armbian/documentation
 
Even the smallest help save us time. For example altering typo, whether in apps or documentation. Code cleaning, testing, fixing ... core drivers, which is the problem here, come into action last.