Jump to content

sgjava

Members
  • Posts

    411
  • Joined

  • Last visited

Reputation Activity

  1. Like
    sgjava got a reaction from gounthar in NanoPi Duo + I2C SSD1306 + Luma.OLED = Cool   
    The Luma library allows you to display text, graphics, animation, etc. on multiple display types. Here I will describe the easiest one to configure which is Luma.OLED and the I2C version of the SSD1306. You can find these displays on EBay and Amazon for less than $10 US each (you can get them for less than $3 US if you order from China, but it might not show up). I've configured Luma on many SBCs and it's my go to library if I need a small display for projects.
     

     
    Requirements
    NanoPi Duo (I used V1.0 board with 512 MB RAM) flashed with Armbian image. This will work with or without the mini shield. Small nylon nuts, bolts and standoffs if you want to mount display I2C OLED display (check http://luma-oled.readthedocs.io/en/latest/hardware.html) 4 female to female jumper wires If you want to configure wifi the easy way just edit the following file on the SD sudo nano /media/username/43296f0d-fc9e-4cec-b3bf-f335fc72f371/etc/network/interfaces and add:
    allow-hotplug wlan0 iface wlan0 inet static address 192.168.1.69 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.1 wpa-ssid your_ssid wpa-psk your_password Comment out the eth0 stuff. You can do it the hard way with the debug serial interface though if you want When I ordered my Duos I forgot to order the USB dongle, so I would have been out of luck otherwise. Boot up and configure the Duo the way you like, power off and wire up the display as follows:
    VCC to either 5Vin or 3V3 GND to GND SCL to SCL SDA to SDA Power up Duo and configure I2C:
    sudo nano /boot/armbianEnv.txt and add i2c0 to overlays= sudo apt-get install i2c-tools sudo usermod -a -G i2c username (non-root user you created) sudo i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- If you see the 3c on i2c0 then you are in business. Let's install Luma.OLED:
    sudo apt-get install python-dev python-pip libfreetype6-dev libjpeg-dev sudo -H pip install --upgrade pip sudo apt-get purge python-pip sudo -H pip install --upgrade pip setuptools sudo -H pip install --upgrade luma.oled sudo -H pip uninstall RPi.GPIO (this will not work on Duo and is not needed for I2C) OK, let's create a simple demo program to make sure things are working nano i2chello.py:
    import time from luma.core.interface.serial import i2c from luma.core.render import canvas from luma.oled.device import ssd1306 serial = i2c(port=0, address=0x3C) device = ssd1306(serial) with canvas(device) as draw: draw.rectangle(device.bounding_box, outline="white") draw.text((3, 3), "Hello", fill="white") time.sleep(10) And you should see (screen shot from the Luma emulator):
     

     
    Now we can install the Luma examples:
    sudo apt-get install git-core libsdl-dev libportmidi-dev libsdl-ttf2.0-dev libsdl-mixer1.2-dev libsdl-image1.2-dev
    git clone https://github.com/rm-hull/luma.examples.git
    cd luma.examples
    sudo -H pip install -e .
    Let's run an example: sudo python examples/invaders.py -d ssd1306 --i2c-port 0 --i2c-address 0x3c
  2. Like
    sgjava got a reaction from GoGerriko in Providing MRAA as common GPIO Library as a Replacement for WiringPi   
    https://github.com/sgjava/userspaceio already does this, but using the latest userspace libraries. I took a peek at mraa and the gpio source uses sysfs which is deprecated. See https://blog.adafruit.com/2018/11/26/sysfs-is-dead-long-live-libgpiod-libgpiod-for-linux-circuitpython/ No need to bake this into Armbian in my opinion. Also, I can install Userspace IO on other Linux distributions besides Armbian, so I'm not limited to a distribution.
     
    This whole idea of mapping pins the same seems kind of silly to me since a lot of my SBCs have a variable number of GPIO pins, some have multiple I2C, some have multi purpose pins, etc. This is something that should be done a layer above the actual APIs and is trivial to implement (using a pin map or table).
     
    There's no wheel reinvention going on here. I started Userspace IO over 2 years ago and it still remains the only true cross SBC API (there is no need to detect board type). Basically if your kernel is > 4.8 and supports devices mapped to userspace then it should work. mraa has limited ARM support (Pi is the only ARM SBC supported that I have out of 10 different SBCs).
     
    As far as non-root access see https://github.com/sgjava/userspaceio#non-root-access
     
    I'd love to just install Linux and have everything working, but that's not reality now. I'm not dissing mraa, but it's not something I'd use personally.
     
  3. Like
    sgjava got a reaction from Tim Makarios in RTL8188FU driver install   
    @Tim Makarios Yeah, I suspect there's going to be consistency issues depending on the distro and board. I'll go ahead and add the build stuff since it wont hurt if it's already there.
  4. Like
    sgjava got a reaction from Tim Makarios in RTL8188FU driver install   
    @Tim Makariosall set. I added BRANCH for the linux headers. I also fixed the prompt for /etc/issues asked during apt upgrade.
  5. Like
    sgjava got a reaction from Tim Makarios in RTL8188FU driver install   
    Good catch, I need to get the release as well. I'll fix that tomorrow. For now you can use the manual steps and "current".
  6. Like
    sgjava got a reaction from gounthar in Luma.OLED on NanoPi Duo with SPI?   
    I figured it out. I had it wired to MI instead of MO! I'll do a write up once I have everything working the way I want.
  7. Like
    sgjava got a reaction from jimt in Rock Pi 4C green LED   
    I can use 
    echo 0 >/sys/class/leds/status/brightness  
    to turn off the status led (blinking blue one, but I was to turn off the bright ass green one. I assume this is mmc1::, but I cannot turn it off.
  8. Like
    sgjava got a reaction from Keerati in Java UIO   
    @KeeratiI replied to your post on github. The input file is for MMIO GPIO mappings and not used by LedBlink. Use --help argument on any demo or tool for list of arguments such as gpio chip, pin, etc.
  9. Like
    sgjava got a reaction from Keerati in Java UIO   
    Java UIO provides high performance Java interfaces for Linux Userspace IO. Java UIO was built from the ground up to use modern kernel APIs, libraries and code generation techniques to provide a best of breed cross platform approach. It does not make sense to recreate the wheel like so many other IO libraries. JDK 17 LTS is supported out of the box.
     
    I've been committing code to U8g2 that utilizes the same userspace code at the C level and dramatically improved the performance of HW/SW SPI and I2C in the arm-linux port. I also made the arm-linux port thread safe and multi display capable (you can use this in C as well obviously). It made sense to add modularization to the Java Periphery IO library since I can take advantage of the same code generation techniques. I will continue to wrap optimized C libraries moving forward in the same modular fashion.
     
    So now you can develop against IO and small displays with one code base in Java.
     



  10. Like
    sgjava got a reaction from lanefu in Video : Armbian North-America and the work Lanufu does for it   
    @lanefuI love the device tree (the one with the boards welded on). I ended up using a storage box with little drawers I got off Amazon and made the cut outs with a rotary tool. This was right after I had it complete. Those Android sticks were quad cores running Linux. That's how I started before most SBCs were sold. Note the active cooling
     

  11. Like
    sgjava got a reaction from gounthar in Fast GPIO access   
    OK, so no answers  Well as usual I pressed on. My first mistake was using JNA generation (but it was easy), so I researched JNI. Well JNI is very cumbersome to do by hand, so I looked for a JNI code generator and found one call HawtJNI. Of course it wouldn't work with Java 11 which is the Java LTS version, so I created a fork. Use the JDK11 branch if you want to play with it because I don't know if the PR will be accepted. I started wrapping c-periphery since it now supports the new /dev/gpiochip way of accessing the GPIO chips. I ran a performance test (I validated on a scope) and I'm getting ~235 KHz on a v1 Nano Pi Duo! That's over 500K writes per second compared to 2K using JNA and libgpiod. Even python-periphery yields ~37 KHz which is a pure Python version.
     
    Any ways exciting news for bit bangers of the world or anyone needing high performance GPIO. Once I have the GPIO code working I'll post on my Github site and announce. Since Bulldog only supports three boards this is good news for Armbian folks with a wider array of supported boards. I still need to test ARMv8 64 bit.
  12. Like
    sgjava got a reaction from lanefu in XU4 loses network connections over time   
    I'll report back once I see the issue resolved. I think a couple days was the maximum time without losing the NICs.
  13. Like
    sgjava got a reaction from devman in Security cameras   
    OK, so I have things dialed in a bit better now. FFMPEG seems to like TCP over UDP for these streams. I'm seeing a lot less artifacts in the videos. Below is 12 hours of network and CPU activity for 3 4K cams at 12.5 FPS and 1 4K cam at 15 FPS (four 4K cams total) at highest quality. CPU seems to max out around 10% per camera and network maxes out around 45 mb total. I'm using a 1G PoE switch, so the bandwidth will never be an issue. The question then becomes how much more real-time processing can I do. CV routines are typically expensive even though I've learned tricks using ROI (region of interest). This isn't as much of a problem with a single camera, but I'm planning on six cameras. Obviously the most important thing for me now is to capture motion videos.
     
    Once the bread and butter stuff is done then I can look at adding various detection code (besides motion). The question becomes do I want real-time detection or perhaps offload that to another SBC. The fact that I can record this many 4K cameras with an Odroid XU4 is pretty amazing. Look at Blue Iris requirements https://ipcamtalk.com/wiki/choosing-hardware-for-blue-iris/ and this really doesn't cover electrical costs and heat dissipation. I'm working on a Pine 64 today with USB cam, so I'll test single camera encoding. Basically the code will scale to many cameras or a single camera.


     

  14. Like
    sgjava got a reaction from lanefu in Security cameras   
    OK, so I have things dialed in a bit better now. FFMPEG seems to like TCP over UDP for these streams. I'm seeing a lot less artifacts in the videos. Below is 12 hours of network and CPU activity for 3 4K cams at 12.5 FPS and 1 4K cam at 15 FPS (four 4K cams total) at highest quality. CPU seems to max out around 10% per camera and network maxes out around 45 mb total. I'm using a 1G PoE switch, so the bandwidth will never be an issue. The question then becomes how much more real-time processing can I do. CV routines are typically expensive even though I've learned tricks using ROI (region of interest). This isn't as much of a problem with a single camera, but I'm planning on six cameras. Obviously the most important thing for me now is to capture motion videos.
     
    Once the bread and butter stuff is done then I can look at adding various detection code (besides motion). The question becomes do I want real-time detection or perhaps offload that to another SBC. The fact that I can record this many 4K cameras with an Odroid XU4 is pretty amazing. Look at Blue Iris requirements https://ipcamtalk.com/wiki/choosing-hardware-for-blue-iris/ and this really doesn't cover electrical costs and heat dissipation. I'm working on a Pine 64 today with USB cam, so I'll test single camera encoding. Basically the code will scale to many cameras or a single camera.


     

  15. Like
    sgjava got a reaction from lanefu in Security cameras   
    So I have two 4K @ 12 FPS cameras that stream to a buffer file. Currently I'm only doing motion detection, but that drives everything else obviously detection wise. On an Odroid XU4 each camera uses only 10%. Motion videos are just copied from the buffer file. I'm using H265+ without any transcoding. So far so good. Not quite ready to post up to github yet though. I doubt you get better CPU utilization than this. I'm using the substream at 4 FPS 640x480 for motion detection.

    One other thing to note is I proxy mjpeg and h265+ streams, so for cameras that only allow one stream you can have security software running and still stream live. I'm using PoE cameras and will have six 4K cameras running soon. So in essence you can build a cheap NVR without the hardware requirements of Blue Iris etal or just build a single smart camera. Armbian allows hardware encoding with ffmpeg on some models, so you can even encode USB cams with low overhead.
  16. Like
    sgjava got a reaction from TRS-80 in XU4 gpio device line names   
    So if you look at the device tree you'll see pin controllers like GPA0, GPA1, etc. I'm not sure how the kernel gpio device enumerates them, but basically a chip is a pin controller and lines are the pins. The main thing is soon you'll be able to look at a pin map and know exactly which physical pin it is.
     
    Also gpioinfo seems to sort by chip string instead of int, thus 2, 21, 22, etc. are all 2s
  17. Like
    sgjava got a reaction from TRS-80 in XU4 gpio device line names   
    OK, so while documenting the Armbian patch process I needed something actual to patch. I added gpio-line-names to the device tree, so now all lines are defined. Once I finish the documentation I'll PR this patch. No more guessing what physical pin is! At some point it might make sense to put in jumper and physical pin #.
     
     
     
  18. Like
    sgjava got a reaction from TonyMac32 in Fast MMIO GPIO for H2+, H3, H5, H6 and S905   
    I was able to build the property file for the NanoPi M1 in about 20 minutes, so now basically you can do ~2 MHz GPIO square wave on all Allwinner and S905 CPUs (you listening @TonyMac32?) without any special code or adapters. All other libraries require one off code to support GPIO register access thus they only support limited boards. In my mind this is the holy grail for cross platform GPIO performance. I plan on going through some more diverse boards, but I'm happy with the results so far. Since only one core is utilized you'll average 25% CPU utilization on quad core systems. That may be another goal using two threads to improve performance further. I have currently mapped Nano Pi Duo, Nano Pi M1,  Nano Pi Neo Plus2 and Odroid C2.
     
    Check out Java Periphery for more information.
     
    Another thing to consider is that you can utilize the property files in other languages as well since there's Periphery APIs for C, Python and Lua as well.
     
     
  19. Like
    sgjava got a reaction from TonyMac32 in 20.11.0-trunk.32_Odroidc2 dies after apt upgrade   
    @IgorArmbian_20.11.0-trunk.41_Odroidc2_focal_current_5.9.10.img did the trick. No hangs or death after apt upgrade and reboot!
  20. Like
    sgjava got a reaction from Igor in 20.11.0-trunk.32_Odroidc2 dies after apt upgrade   
    @IgorArmbian_20.11.0-trunk.41_Odroidc2_focal_current_5.9.10.img did the trick. No hangs or death after apt upgrade and reboot!
  21. Like
    sgjava got a reaction from TRS-80 in Cross platform high performance GPIO   
    So my whole goal with java-periphery was to create a decent cross platform userspace IO library which I believe I have achieved. One of my other goals was to create a high performance GPIO API that's also cross platform. If you look around there aren't any from what I can tell. Most high performance GPIO libraries support only a few boards. What I've done is use a well known interface (GPIO device) and some MMIO code to detect deltas and generate the required resisters and masks from an input file. This surely beats doing this by hand which I tried at first. The result is code that supports Allwinner H2+/H3 and H5/H6 by using just an input file. I'm going to look at other CPU types next, but this is promising. For more info check out High performance GPIO using MMIO.
  22. Like
    sgjava got a reaction from JMCC in Cross platform high performance GPIO   
    So my whole goal with java-periphery was to create a decent cross platform userspace IO library which I believe I have achieved. One of my other goals was to create a high performance GPIO API that's also cross platform. If you look around there aren't any from what I can tell. Most high performance GPIO libraries support only a few boards. What I've done is use a well known interface (GPIO device) and some MMIO code to detect deltas and generate the required resisters and masks from an input file. This surely beats doing this by hand which I tried at first. The result is code that supports Allwinner H2+/H3 and H5/H6 by using just an input file. I'm going to look at other CPU types next, but this is promising. For more info check out High performance GPIO using MMIO.
  23. Like
    sgjava got a reaction from lanefu in FriendlyArm wiringPi on Armbian   
    So I'm working on a generic way to do MMIO GPIO on Armbian and chatting with @diozeroit seems like a wiringPi implementation is a good place to start for ideas.  Armbian supports many FriendlyArm boards, so I took a look at https://github.com/friendlyarm/WiringNP. Of course out of the box it fails because it's probing for things found only in its home made OS distros. I found a way to hack the getBoardType function to hard code your board type for Armbian and probably other distros. This will work only on the board you hack it for. Honestly there should have been a way to pass in a parameter to override the detection code. In any event here's the method to use.
     
    Look up your board in BoardHardwareInfo in my case it's a NanoPi Duo, so I'd use this. Since arrays are zero based it falls on element 32. Now I hack getBoardType and right after that line add:
    *retBoardInfo = &gAllBoardHardwareInfo[32]; return gAllBoardHardwareInfo[32].boardTypeId; Then follow normal build instructions here.
    gpio readall +-----+-----+----------+------+---+-NanoPi-Duo--+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | | | MIC_N | | | 1 || 2 | | | EPhySPD | | | | | | MIC_P | | | 3 || 4 | | | EPhyLinK | | | | | | LineOutR | | | 5 || 6 | | | EPhyTXP | | | | | | LineOutL | | | 7 || 8 | | | EPhyTXN | | | | | | CVBS | | | 9 || 10 | | | EPhyRXP | | | | 198 | 8 | GPIOG6 | ALT5 | 0 | 11 || 12 | | | EPhyRXN | | | | 199 | 9 | GPIOG7 | ALT5 | 0 | 13 || 14 | | | USB-DP2 | | | | 15 | 7 | GPIOA15 | ALT5 | 0 | 15 || 16 | | | USB-DM2 | | | | 16 | 0 | GPIOA16 | ALT5 | 0 | 17 || 18 | | | USB-DP3 | | | | 14 | 2 | GPIOA14 | ALT5 | 0 | 19 || 20 | | | USB-DM3 | | | | 13 | 3 | GPIOA13 | ALT5 | 0 | 21 || 22 | 0 | OFF | GPIOG11 | 16 | 203 | | 12 | 12 | GPIOA12 | ALT5 | 0 | 23 || 24 | 0 | IN | GPIOL11 | 18 | -1 | | 11 | 13 | GPIOA11 | ALT5 | 0 | 25 || 26 | | | 0v | | | | | | 0v | | | 27 || 28 | | | 3.3v | | | | 4 | 14 | GPIOA4 | ALT5 | 0 | 29 || 30 | | | 5v | | | | 5 | 15 | GPIOA5 | ALT4 | 0 | 31 || 32 | | | 5v | | | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+-NanoPi-Duo--+------+----------+-----+-----+ If you search there were other solutions by using /etc/sys_info, but I was too lazy to create that file.
  24. Like
    sgjava got a reaction from Tido in User Space IO is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C, PWM and Serial interfaces   
    @Tido I made an edit to top of post. https://github.com/sgjava/java-periphery
  25. Like
    sgjava got a reaction from Technicavolous in User Space IO is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C, PWM and Serial interfaces   
    Edit: User Space IO depracated. Use Java Periphery instead https://github.com/sgjava/java-periphery
     
    https://github.com/sgjava/userspaceio
     
    After a lot of work and testing I have produced the User Space IO project! It provides Python 3 and Java 8 bindings for Linux user space GPIO, SPI, I2C, PWM and Serial interfaces. This allows cross SBC and cross language development using a common API. I took two best of breed C APIs for Linux user space libgpiod and c-periphery and produced CFFI bindings for Python and JNA bindings for Java. Since all the bindings closely match the C API it's easy to move from language to language. The side effect of using the Java library is that it should work with many different JVM based languages. How about creating your programs in Kotlin or Scala for instance?
     
    GPIO access uses the new gpiod interface and not the deprecated sysfs interface using libgpiod v1.1 (head from git repo). GPIO, SPI, I2C and serial interfaces expose all the low level functionality. I have added some helper methods for handling repetitive functions like building I2C messages, reading words from two registers, etc. You can of course go as low level as you need to. Please use Github to post any issues, pull requests, etc. I have tested Nano Pi Duo for 32 bit and NanoPi Neo +2 for 64 bit compatibility. I'll test more SBCs as I have time. Also, I have deleted https://github.com/sgjava/libgpiod-extra since User Space IO supersedes it.
     
    Based of some of the questions I had in the past please note the following:
    gpiod_ctxless_event_loop_multiple can handle GPIO interrupts Miscellaneous GPIO request flags GPIOD_LINE_REQUEST_FLAG_OPEN_DRAIN, GPIOD_LINE_REQUEST_FLAG_OPEN_SOURCE, GPIOD_LINE_REQUEST_FLAG_ACTIVE_LOW Non-root access using rc.local. Demo program using hardware PWM to flash LED:
     
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines