linux driver

Discussion in 'STF Series CCD Cameras' started by Martin Aube, Oct 14, 2014.

  1. Martin Aube

    Martin Aube Standard User

    Joined:
    Oct 11, 2014
    Messages:
    2
    Hi, I need the linux static library for X86 arch (libsbigdvr.a) to support a st-402 camera under linux. In the SBIG archive, there is a .so file but no .a file. I already have an older 32 bit version of the .a files but wonder to obtain the latest 32bit version and also the 64 bit version.
     
  2. Jan Soldan

    Jan Soldan Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    239
    Location:
    Czech Republic
    Martin,
    I am working on it and will deliver ASAP.
    Thank you,
    Jan
     
  3. Jan Soldan

    Jan Soldan Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    239
    Location:
    Czech Republic
    Martin,
    it took me much longer time than expected, due to merging our latest Windows stuff with Linux and some problems with libusb library, but finally the LinuxDevKit is available for download. It contains:
    - 32 and 64 bit static (*.a) and shared (*.so) libraries
    - testing application
    - cameras' firmware
    - udev file
    - and doc
    - makefile

    I have tested it on 32 and 64 bit Debian 6 distros, generated some FITS file and results seems to be all right. Please check it and in the case of some problems, let me know.

    Link to LinuxDevKit-2014-10-16T09-43.tar.gz in DropBox:
    https://www.dropbox.com/s/5d3wt3o4b9ddpk8/LinuxDevKit-2014-10-16T09-43.tar.gz?dl=0

    Thank you,
    Jan
     
  4. Jim Garlick

    Jim Garlick Standard User

    Joined:
    Oct 17, 2014
    Messages:
    24
    Hi Jan,

    Will there be ARM support in future Linux dev kits? I grabbed 2014-01-10 from the SBIG site and was really pleased to find ARM libs in there, and began to transition my camera control to ARM hardware. Maybe that was premature?

    Thanks,
    Jim Garlick
     
  5. Jan Soldan

    Jan Soldan Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    239
    Location:
    Czech Republic
    Jim,
    yes, I will add ARM support there ASAP. The first version, you have mentioned , was tested on Raspberry PI, which is a bit slow, but now I have tested it on UDOO-Quad with four A9 cores: http://shop.udoo.org/usa/product/udoo-quad.html and even on much powerfull ODROID XU3, which has 8 cores (4xA7 & 4xA15). I have 64 GB of eMMC on Android OS and 32 GB of eMMC on Ubuntu 14.x on ODROID UX3, so such a combination is really very fast. I can even develop this driver directly on this powerfull machine, using Eclipse for Ubuntu and Android Studio for Android.
    http://www.hardkernel.com/main/products/prdt_info.php?g_code=G140448267127
    So, please let me some time to finish this development.
    Thank you,
    Jan
     
  6. Jim Garlick

    Jim Garlick Standard User

    Joined:
    Oct 17, 2014
    Messages:
    24
    Sounds good! Thank you very much.
    Jim
     
  7. Jan Soldan

    Jan Soldan Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    239
    Location:
    Czech Republic
    Jim,

    below is a link to our latest LinuxDevKit delivery which contains libraries, simple command line testing application and makefiles. There are *.so and *.a sbigudrv libraries for 32 and 64 bit linux including the same libraires for ARM processors. The Linux stuff was compiled on Ubuntu 14.04, while the ARM stuff was compiled on Raspberry PI and Odroid XU3 machines. See subdirs x86/app, x86/lib32 and x86/64 for Intel/AMD processors and arm/app, arm/rpi and arm/odroid for ARM processors. I will also add the same stuff for UDOO next time.
    The libraries were tested against the folowing SBIG cameras: ST-i, STF-8300, STT-8300 and ST-1603 and all resulted images were all right.

    DropBox link:
    https://www.dropbox.com/s/xc314r5td01rh6x/LinuxDevKit-2014-10-21T14-29.tar.gz?dl=0

    Regards,
    Jan
     
  8. Jim Garlick

    Jim Garlick Standard User

    Joined:
    Oct 17, 2014
    Messages:
    24
    Got it! Thank you!

    Just curious: is it not possible to create one 32bit ARM executable that works on both those platforms?
    Also what's the OS on each? I'll be running on a BeagleBone Black (1GHz AM335x ARM Cortex-A8), currently Debian 7.0.

    Jim
     
  9. Jim Garlick

    Jim Garlick Standard User

    Joined:
    Oct 17, 2014
    Messages:
    24
    Hi Jan,

    Maybe for a given OS major version, a unique build is only needed for each unique "gcc --print-multiarch" triplet?
    I see both my Raspberry Pi and Beaglebone black report arm-linux-gnuabihf.

    (assuming libs are being built with default toolchain options)

    Jim
     
  10. Jan Soldan

    Jan Soldan Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    239
    Location:
    Czech Republic
    Jim,
    you are right, I have to compile one 32 bit executable running on all platforms, so need to probably set the proper gcc options for ARM.
    My RPI has Raspbian GNU/Linux v7, while on odroid there is: Ubuntu 14.04.1. I do not use cross-development, rather compile ARM
    stuff directly on XU3, but have to confirm, that moved driver compiled on that platform doesn't work on RPI - Illegal instruction.
    Any advice would be very appreciated and save a lot of time...

    Thank you,
    Jan
     
  11. Jim Garlick

    Jim Garlick Standard User

    Joined:
    Oct 17, 2014
    Messages:
    24
    Jan,

    I am not an expert, but looking around, it seems that Debian and Ubuntu both support ARMv7 and above, while raspbian supports ARMv6.
    It could be that ARMv6 works on ARMv7 and beyond - at least so far I have had no problems running your pi-compiled sbigudrv on my Beaglebone.
    But I don't know what the "cost" is, e.g. what features of ARMv7 might benefit sbigudrv. On those little boards every bit of performance counts.

    My suggestion would be to build for both. I am not sure if it matters much if you build ARMv7 on Debian or Ubuntu. I think they both use the same ABI.

    Then I would make it very clear in the release what is what and use the official architecture names, e.g. put the generated .so and .a files in:

    arch/arm6l
    arch/arm7l
    arch/i386
    arch/x86_64

    And document in the README or somewhere which OS was used to build each.

    One other thing while we're on the topic: it would be nice to ship only one copy of the sample app/header. Duplicating it in the arch-specific directories makes me always wonder what might be different between them, but I think they are generally the same. A ChangeLog would also be nice but now maybe I am going too far :)

    Regards,

    Jim
     
  12. Jim Garlick

    Jim Garlick Standard User

    Joined:
    Oct 17, 2014
    Messages:
    24
    Or maybe

    arch/raspbian7-arm6l
    arch/ubuntu14-arm7l
    arch/fedora20-i386
    arch/centos7-x86_64

    then you don't have to remember to update README :)
     
  13. Jan Soldan

    Jan Soldan Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    239
    Location:
    Czech Republic
    Jim,
    Thanks! It will be the best solution to create several drivers for different architectures you have proposed. I will try it during this weekend.
    Regards,
    Jan
     
  14. Jan Soldan

    Jan Soldan Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    239
    Location:
    Czech Republic
  15. Jim Garlick

    Jim Garlick Standard User

    Joined:
    Oct 17, 2014
    Messages:
    24
    Nice improvement to the tree, thanks Jan.
    I tested arm_v7 libs on my beaglebone and ST-8XME and it works.

    Incidentally, a bug in the test app:
    Taking a series of SBIG format images results in files named:

    LF_2014-10-26T10:45:24.536
    LF_.sbig2014-10-26T10:45:29.836
    LF_.sbig.sbig2014-10-26T10:45:35.137

    Finally, not sure if this is helpful but I made some changes to your app/makefile to build with rpath so the app can be run from the source tree without LD_LIBRARY_PATH. It also selects the library architecture directory by calling 'arch':

    http://github.com/garlick/sbig-util/tree/master/sdk/app/makefile

    (don't pay any attention to the sbig-util project - just a hack I am working on for now)

    Regards,
    Jim
     
  16. Jan Soldan

    Jan Soldan Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    239
    Location:
    Czech Republic
    Jim,
    I have seen this name problem, but forgot to fix it...I think some string has to be set to zero.
    Also, I will merge your makefile with that in distribution.
    BTW, I was not able to compile arm_v6 lib with arch=arm_v6 on my XU3 while it passed all right with arm_v8, so I had to switch to RPI for v6, a bit mess, but I hope we can support several ARM CPUs
    now. Also, many thanks for testing this stuff on Beaglebone microcomputer.
    Regards,
    Jan
     
  17. Jan Soldan

    Jan Soldan Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    239
    Location:
    Czech Republic
  18. Jim Garlick

    Jim Garlick Standard User

    Joined:
    Oct 17, 2014
    Messages:
    24
    Hi Jan,

    I wanted to report that over the past week I exercised the previous drop of the SDK pretty heavily on both i386 and arm_v7 for actual astrophotography with a cooled camera and everything is working fine.

    A few more suggestions for minor improvements if I may
    • convert to uniform UNIX \n end of line style (newer changes are windows style \r\n)
    • conditional build with cfitsio is awkward: suggest driving entirely from Makefile
    • one Makefile would be less confusing that both makefile and Makefile with former taking precedence
    • doc/README.txt should be updated for ARM and to add instructions for apt-get fxload and cfitsio-dev packages
    If it would help I would be happy to send you a new Makefile that could replace the two. Let me know.

    Regards,

    Jim
     
  19. Jim Garlick

    Jim Garlick Standard User

    Joined:
    Oct 17, 2014
    Messages:
    24
  20. Jan Soldan

    Jan Soldan Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    239
    Location:
    Czech Republic
    Jim,

    all source files come from Windows driver, hence different end of line styles. I can/will update Makefile with your one, no problem, although these days I am working on a bit different things,
    so I will do it a bit later. Thank you for your inputs.
    Regards,
    Jan
     

Share This Page