sgjava

  • Posts

    304
  • Joined

  • Last visited

Reputation Activity

  1. 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.
  2. 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.


     

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


     

  4. 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.
  5. 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
  6. 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 #.
     
     
     
  7. 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.
     
     
  8. 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!
  9. 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!
  10. 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.
  11. 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.
  12. 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.
  13. 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
  14. 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:
     
  15. Like
    sgjava got a reaction from lanefu in Java Periphery released!   
    Java Periphery has finally been released! Java Periphery is a high performance library for GPIO, LED, PWM, SPI, I2C, MMIO and Serial peripheral I/O interface access in userspace Linux. This will replace User Space IO. I'm seeing GPIO write speeds of 500K/s from userspace. Compared to User Space IO and libgopid speeds of 2K/s. I switched from JNA wrapper generation to JNI wrapper generation. The build process is much simpler (only single install.sh) and building libgpiod is no longer required. The API follows c-periphery, python-periphery and lua-periphery. This should cover the widest array of SBCs and languages around.
     
    Java Periphery should work on Armbian/Ubuntu/Debian, but also other non-Armbian distributions. If you run into issues please use Github issues to report.
     
    Nano Pi Duo
    13:30:43.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 13:31:23.062 [main] INFO com.codeferm.periphery.demo.GpioPerf - 500613.25 writes per second 13:31:23.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 13:31:54.471 [main] INFO com.codeferm.periphery.demo.GpioPerf - 318440.91 reads per second Nano Pi Neo Plus 2
    15:06:51.946 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 15:07:22.522 [main] INFO com.codeferm.periphery.demo.GpioPerf - 654964.63 writes per second 15:07:22.524 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 15:07:46.696 [main] INFO com.codeferm.periphery.demo.GpioPerf - 413770.27 reads per second  
  16. Like
    sgjava got a reaction from Tido in Using Zabbix to monitor all your IP devices on Armbian server   
    Actually Zabbix is monitoring software that collects telemetry and allows actions such as emailing, texting, restarting services or servers based on conditions and escalations. I've totally automated network admin type roles with it and things at home like monitoring the power state of my beer refrigerator in the garage. It's super flexible and easy to add stuff to the agent for client specific needs. It can also scale to millions of devices or just a handful at home. Also, the agent is now golang, not C.

    Cockpit looks more like Webmin on steroids. It's also Linux only from what I can tell. Zabbix is cross platform if you ever have to manage a mixed environment with Linux and Windows servers.
  17. Like
    sgjava got a reaction from Werner in Using Zabbix to monitor all your IP devices on Armbian server   
    I've used Zabbix professionally and at home to monitor servers, IoT, and IP devices. I've built scripts for the server and client to automate the install process including moving the MySQL database, so you can locate it to a NFS mount instead of serving the database from the slower SD card. The deb packages do not work for ARM, so you have to build it from source using my scripts.
     
    Install Zabbix
  18. Like
    sgjava got a reaction from Igor in Nanopi M1 nightly image not expanding/booting   
    @Igor I can verify M1 image now works, thanks!
  19. Like
    sgjava got a reaction from Werner in Nanopi M1 nightly image not expanding/booting   
    @Igor I hate when that happens. I've been stuck on something for days and weeks sometimes and it's something crazy like that. Happens to every dev.
  20. Like
    sgjava got a reaction from Igor in Nanopi M1 nightly image not expanding/booting   
    @Igor I hate when that happens. I've been stuck on something for days and weeks sometimes and it's something crazy like that. Happens to every dev.
  21. Like
    sgjava got a reaction from devman in Java Periphery released!   
    Java Periphery has finally been released! Java Periphery is a high performance library for GPIO, LED, PWM, SPI, I2C, MMIO and Serial peripheral I/O interface access in userspace Linux. This will replace User Space IO. I'm seeing GPIO write speeds of 500K/s from userspace. Compared to User Space IO and libgopid speeds of 2K/s. I switched from JNA wrapper generation to JNI wrapper generation. The build process is much simpler (only single install.sh) and building libgpiod is no longer required. The API follows c-periphery, python-periphery and lua-periphery. This should cover the widest array of SBCs and languages around.
     
    Java Periphery should work on Armbian/Ubuntu/Debian, but also other non-Armbian distributions. If you run into issues please use Github issues to report.
     
    Nano Pi Duo
    13:30:43.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 13:31:23.062 [main] INFO com.codeferm.periphery.demo.GpioPerf - 500613.25 writes per second 13:31:23.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 13:31:54.471 [main] INFO com.codeferm.periphery.demo.GpioPerf - 318440.91 reads per second Nano Pi Neo Plus 2
    15:06:51.946 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 15:07:22.522 [main] INFO com.codeferm.periphery.demo.GpioPerf - 654964.63 writes per second 15:07:22.524 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 15:07:46.696 [main] INFO com.codeferm.periphery.demo.GpioPerf - 413770.27 reads per second  
  22. Like
    sgjava got a reaction from Tido in Java Periphery released!   
    Java Periphery has finally been released! Java Periphery is a high performance library for GPIO, LED, PWM, SPI, I2C, MMIO and Serial peripheral I/O interface access in userspace Linux. This will replace User Space IO. I'm seeing GPIO write speeds of 500K/s from userspace. Compared to User Space IO and libgopid speeds of 2K/s. I switched from JNA wrapper generation to JNI wrapper generation. The build process is much simpler (only single install.sh) and building libgpiod is no longer required. The API follows c-periphery, python-periphery and lua-periphery. This should cover the widest array of SBCs and languages around.
     
    Java Periphery should work on Armbian/Ubuntu/Debian, but also other non-Armbian distributions. If you run into issues please use Github issues to report.
     
    Nano Pi Duo
    13:30:43.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 13:31:23.062 [main] INFO com.codeferm.periphery.demo.GpioPerf - 500613.25 writes per second 13:31:23.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 13:31:54.471 [main] INFO com.codeferm.periphery.demo.GpioPerf - 318440.91 reads per second Nano Pi Neo Plus 2
    15:06:51.946 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 15:07:22.522 [main] INFO com.codeferm.periphery.demo.GpioPerf - 654964.63 writes per second 15:07:22.524 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 15:07:46.696 [main] INFO com.codeferm.periphery.demo.GpioPerf - 413770.27 reads per second  
  23. Like
    sgjava got a reaction from Igor in Java Periphery released!   
    Java Periphery has finally been released! Java Periphery is a high performance library for GPIO, LED, PWM, SPI, I2C, MMIO and Serial peripheral I/O interface access in userspace Linux. This will replace User Space IO. I'm seeing GPIO write speeds of 500K/s from userspace. Compared to User Space IO and libgopid speeds of 2K/s. I switched from JNA wrapper generation to JNI wrapper generation. The build process is much simpler (only single install.sh) and building libgpiod is no longer required. The API follows c-periphery, python-periphery and lua-periphery. This should cover the widest array of SBCs and languages around.
     
    Java Periphery should work on Armbian/Ubuntu/Debian, but also other non-Armbian distributions. If you run into issues please use Github issues to report.
     
    Nano Pi Duo
    13:30:43.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 13:31:23.062 [main] INFO com.codeferm.periphery.demo.GpioPerf - 500613.25 writes per second 13:31:23.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 13:31:54.471 [main] INFO com.codeferm.periphery.demo.GpioPerf - 318440.91 reads per second Nano Pi Neo Plus 2
    15:06:51.946 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 15:07:22.522 [main] INFO com.codeferm.periphery.demo.GpioPerf - 654964.63 writes per second 15:07:22.524 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 15:07:46.696 [main] INFO com.codeferm.periphery.demo.GpioPerf - 413770.27 reads per second  
  24. Like
    sgjava got a reaction from Tido in Fast GPIO access   
    https://en.wikipedia.org/wiki/Bit_banging where you write you own protocols in software without the need for I2C, UART, SPI, etc. https://calcium3000.wordpress.com/2016/08/19/i2c-bit-banging-tutorial-part-i Thus with two GPIO pins I can simulate I2C. With the slower speeds, not so much. You can also do square wave 1 bit PCM sound too. I'm going to date myself, but I was doing this on a C64 in the 1980s. https://github.com/sgjava/garage/blob/master/commodore/c64/digisound/src/digisnd.asm Then you only need a simple piezoelectric speaker.
     
    There are probably a bunch of other uses, but this should give you an idea. Just the fact that I'm half the speed of Bulldog with many more platforms is a good thing. I was shooting for a generic high performance solution instead of coding directly to the GPIO chip like Bulldog.
  25. Like
    sgjava got a reaction from lanefu in Fast GPIO access   
    After working with sysfs and libgpiod as cross platform solutions I was wondering if there was a faster way using /dev/mem or mmio? I know this gets more bare metal and SBC specific, but for some things you may want absolute speed. https://opensource.com/life/16/4/bulldog-gpio-library for instance claims 1 MHz GPIO writes in Java. However it only supports 3 SBCs as you can see from https://github.com/SilverThings/bulldog. Is there a more generic way to do this and not lose performance? Using my generated JNA wrappers for libgpiod I get about 2K writes per second. In Python I think it's about 70K using libgpiod Python bindings. I realize you may not always need 1 MHz GPIO writes, but it would be neat to offer this in a more generic way.