StuxNet

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

pcdoodle. That name rings a bell to a local comp rep shop. You local to mn? I could def teach you a thing or two. Hit me up if interested.

The script I gave you was a very loose example and it includes things I was using for my specific project. Things that you don't necessarily need to use for your own. trigPin in this situation is just an 'empty' pin that I use as an LED trigger. If temperature is above X, turn on LED. If temp below X, turn LED off. If you just want a temp and humidity readout, remove every function, set pins how you'd like and just print tempOut() Then go here: https://www.codecademy.com/learn/learn-python Or here: https://www.codewars.com/?language=python Or here: https://www.youtube.com/watch?v=apACNr7DC_s

Got this same wrapper, as well as others to work on an NPiNeo and an OPiZ recently (defining outside ) but you're right it's prolly redundant. I got it working using this wrapper (forked/updated within 1 year opposed to 2yr on the one u link to) https://github.com/jingl3s/DHT11-DHT22-Python-library-Orange-PI and the following script. What happens when you print(instance) after it's defined? from pyA20.gpio import gpio from pyA20.gpio import port import dht import time import datetime # initialize GPIO temPin = port.PG11 trigPin = port.PG7 gpio.init() gpio.setcfg(trigPin, gpio.OUTPUT) # read data using pin 14 instance = dht.DHT(pin=temPin, sensor=22) def tempOut(): celToFar = result.temperature * 1.8 + 32 print("Last valid input: " + str(datetime.datetime.now())) print("Celsius: {0:0.1f} C".format(result.temperature)) print("Fahrenheit: {0:0.1f} F".format(celToFar)) print("Humidity: {0:0.1f} %%".format(result.humidity)) print("\n") def trigPinState(trigPin): trigState = gpio.input(trigPin) # What is state of trigger pin? if trigState == 0: #Then it's low return 'Low: %s' % trigState elif trigState == 1: # then its high return 'High: %s' % trigState else: print('error!) while True: result = instance.read() if result.is_valid(): tempOut() if celToFar < 75: gpio.output(trigPin, gpio.HIGH) elif celToFar > 75: gpio.output(trigPin, gpio.LOW) time.sleep(.2)

You have a problem with the dht22 working. You never specify what the problem actually is. What's the error code you're getting? Ima go ahead and take a wild guess that you don't initiate a configuration for that port. put the following after gpio.init() PIN2 =gpio.setcfg(PIN2, gpio.OUTPUT)

Which is easier to say? Every post previous, or run this? Attached is a bash script that will install and make various dtbo/dts edits automagically in order to install and interface with ds18b20 Thermometer connected to a NPiNeo running Armbian 5.69. I've also attached an image for how the module needs to be physically connected (using 10k resistor between 1 wire and PWR). If you do not have a physical 10k resistor you may use the internal pullup to do so (do not use on long connections?) This is done by adding param_w1_pin_int_pullup 1 on a newline after param_w1_pin=PG11 in the /boot/armbianEnv.txt file. The picture is for a raspi connection. Simply connect blue wire to PG11 on NanoPi Neo, Red to 3.3v PWR. Black wire to GND. All of which are actually located on the exact same pins if you flip the picture 90 degrees clockwise and cross reference it to FriendlyArms standard schematic. Also attached. WARNING: I created the attached script from a default installation of Armbian. It will erase current /boot/armbianEnv.txt file. Use sed or edit printf command to customize. - physical bash script attached - gist copy of script here: https://gist.github.com/BiTinerary/0ab5f3c7bf118456fc02bb0b876dc172 ds18b20ThermoNPiNeoInstall.sh

You guys are awesome. I love you but I also hate you. That is a joke btw. Remember, threads/emails are not ideal communication. When you finalize a thread, maybe wrap it all up in a single coherent, command by command tutorial? Just spent the last hour trying to hodge podge the meaning of this thread + this All I needed to know is that param_w1_pin=PG11 shoulda been on a seperate line while a simple dump of the full amrbianEnv.txt woulda sufficed... verbosity=1 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=armbian-add-overlay usbhost1 usbhost2 w1-gpio param_w1_pin=PG11 rootdev=UUID=41c3101b-b077-456b-b9cd-a7717422b4b3 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Not to mention how to actually de/recompile dbto's and dts's. I would love to post back here those simple commands that were just glossed over in this thread but I can't guarantee I'll be able to do that. Anyone with a life outside themselves would understand how valuable 1 hour of uninterrupted time to decompiling text based gibberish is, all the while knowing it could legit, be automated. If there's any doubt to the tone of this message. I prove my point and thank you guys.

Which Armbian kernel and version? When this happens to me, I typically just revert to a previous version that has the support and/or features I'm looking for. I would recommend doing the same, in addition to making an image of SD card (if you've spent a good deal of time setting it up) before updating to the latest kernel. This is one fix. Without booting up my own device with latest version, and taking your word for it that it's not available in armbian-config menu. It's likely because the armbian-config is being worked on, and you will not be able to enable specifically through armbian-config menu temporarily. You may need to either, do as suggested above (easiest) or setup manually, here's a post with 2 tutorials towards the end that may help in doing so.

For when the link goes dead and for those looking to buy on the english version of Aliexpress. FFC FPC Ribbon cable 0.5mm pitch 24 pin 24PIN Front Length 250mm Width 12.5mm Ribbon Flex Cable

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.

The actual better ending to this story is not a post of the working camera but actually the underlying issue in the first place. I'm not a newb but I also don't know every schema of every board I own. Does the cable connect N/E/S/W on OPi/NPi/RPi/BPi? Perhaps include a picture of the correct orientation of the connected camera's ribbon cable? No one seems to ever talk about that. Not going to spend the next 4 hours yakshaving the cam across 6+ boards, 3 OS's in an attempt to port, decipher posts and problem solve. Multiply every attempt by 3 because I wonder "is the camera actually connected properly?". Just to document [accurately on GitHub] a more universal method for all. Moderators hate it when they go out of their way to provide software solutions to newbs with simple hardware problems. Strike that, reverse it.

@Larry Bank hit up this guy >>> https://github.com/rm-hull <<< He has very similar projects to what your working on, ie: universal SBC's wrappers, except mainly for screens. He has one repo "OPi.GPIO" that aims to accomplish something similar to ArmbianIO project but is limited to OPi as you can imagine. He has recent commits that suggest branching out into NanoPi (Duo) territory though. I talked to him awhile back, pretty cool dude but seems pretty busy and the OPi.GPIO isn't his main focus. In any case this is all to say, without looking at your source and knowing what you do/don't have, maybe he has some goods you can snag. All in all. Awesome work. Had this idea for a long time, but lack the hardware/expertise to do it (this was as far as I could go) but it's awesome to see you follow up bitbank with ArmbianIO. Keep it up. I'll absolutely be sending you some beer money when I get the chance.

Yea I get that. Totally understandable. In some situations, especially bigger companies, you would want to go with a more professional solution like you describe. Of course people forget to stamp, isn't that going to be an issue regardless of the device though? I don't think you need to be a mathematician, to do a timeclock. Let a spreadsheet do that for you. All that aside, as a whole SBC's represent (to me) the option and freedom to do without those kinds of proprietary (usually expensive) devices that offer zero control. On top of doing without the service fees and support. At the end of the day everyone (company) is different. This solution works excellently for my situation. Another good situation I've been in previously, was working for a fairly large company (as in multiple local locations) that had hours averaging 1, maybe 2, employees per location. I imagine it would be cost prohibitive to buy 6-7 devices, for a grand total of 8 employees. Granted, some of these positions were salary and timecards were based on the honor system but I could see an SBC making an appearance here.

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