Jump to content


  • Posts

  • Joined

  • Last visited

Reputation Activity

  1. Like
    sgjava got a reaction from Igor_K in What would be a good board with 2 Gb RAM for a bitcoin node?   
    @Igor_K See the post below for the parts list. The HC1 wasn't available when I bought them. I have a 480G SSD connected to one of the XU4s and use NFS for backups and security camera videos. I need to be able to swap things in and out based on needs, so the rack was a better choice for me. I can have 9 decent sized SBCs in that tower.
  2. Like
    sgjava got a reaction from Igor_K in What would be a good board with 2 Gb RAM for a bitcoin node?   
    I concur with the others about the XU4. I have 3 of them in my home made SBC server rack which uses active cooling. The nice thing is the XU4 has a built in fan and they are rock solid (been running them over a year 24/7). The price is right too. If you plan on maxing out the CPU you will need more than the built in cooling.
    The ROCK 64 looks promising price wise and the ability to have up to 4G. This will be my next server.

  3. Like
    sgjava got a reaction from Tido in ArmbianIO API proposal   
    Holy smokes, I didn't think the RPi.GPIO clone would be such a pain, but the bonus is I fixed some bugs in the C code and changed how callbacks work a bit. AIOAddGPIOCallback no longer sets pin direction, so you must call AIOAddGPIO and set the pin direction to GPIO_IN. I also added AIORemoveGPIOCallback which sets edge to "none" and causes the pthread to exit. This operated more like RPi.GPIO by leaving the pin set the way it was before the callback and only changes edge. I also fixed AIORemoveGPIO yesterday as it was using the literal pin number and not the mapped pin, so the pin was left in it's previous state (i.e. /sys/class/gpio/gpio123 was still there).
    I was able to implement most of the RPi.GPIO event methods:
    add_event_detect remove_event_detect add_event_callback I still need to work on:
    wait_for_edge event_detected Once this is done I should be able to test Luma.OLED on a few different model SBCs without code changes if I use the same pins. This will be the ultimate test. No more hacked up RPi.GPIO for each SBC! I had to have a custom RPi.GPIO for Odroid C1, Pine A64, the various Nano Pis, etc.
  4. Like
    sgjava got a reaction from gnasch in ArmbianIO API proposal   
    OK, I started on the RPi.GPIO wrapper https://github.com/bitbank2/ArmbianIO/blob/master/python/RPi/GPIO.py which basically supports reading and writing to the pins. None of the event stuff is coded yet, but you can see where I'm going. No pin mappings yet. Just keeping it the way ArmbianIO does it for now. The Led test works
    import time import RPi.GPIO as GPIO GPIO.setmode(GPIO.BOARD) GPIO.setwarnings(False) # Pin 12 set to output GPIO.setup(12,GPIO.OUT) # LED on GPIO.output(12,GPIO.LOW) time.sleep(3) # LED off GPIO.output(12,GPIO.HIGH) GPIO.cleanup()  
  5. Like
    sgjava got a reaction from chwe in ArmbianIO API proposal   
    @chwe I've looked at the Node-Red demo and it looks interesting to make work flows, but if you look at https://github.com/monteslu/node-red-contrib-gpio you'll see it's pretty involved. The nice thing though is it would support many more SBCs by ArmbianIO's very nature. @Larry Bank and I were discussing adding PWM yesterday, board name detection (see @tkaiser's comments above), etc., so there's still some core functionality to add at the C level and then to the wrappers. Of course being an Open Source project any one can contribute
  6. Like
    sgjava reacted to tkaiser in ArmbianIO API proposal   
    See 8 posts above or https://tech.scargill.net/banana-pi-m2/#comment-27947
    Edit: When asking @jernej back then whether he's fine with his code being used in other projects IIRC he had no objections.
  7. Like
    sgjava got a reaction from Larry Bank in ArmbianIO API proposal   
    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"  
  8. Like
    sgjava got a reaction from lanefu in ArmbianIO API proposal   
    I've created Python bindings with Swig using a script that should install all dependencies and create an armbianio module and install locally with pip, so it's globally accessible in Python. I created a PR for Larry, but you can grab it at https://github.com/sgjava/ArmbianIO until the merge happens. I included a simple LED blink program that uses pin 12 (ArmbianIO mapping) for the NanoPi Duo. It would be nice to test other SBCs as well.
  • Create New...