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.
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
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
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
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
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
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
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
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
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
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
Jim, here is the latest linux/arm delivery: https://www.dropbox.com/s/nu9bcm8u7yo5qzc/LinuxDevKit-2014-10-26T18-10.tar.gz?dl=0 Inside the libs directory, there are several subdirs, namely arm_v6, arm_v7, arm_v8, i386 and x86_64. I have tested all of them except libs inside the arm_v8. There is also app subdir with one simple testing application. Regards, Jan
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
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
Jim, here is a new DiffractionLimitedForum DropBox directory which contains the latest SBIG Linux/ARM stuff: https://www.dropbox.com/sh/b1jw66sg6wxuvkl/AABuaoTzXVBvXZaRhaU0s8mua?dl=0 Last changes: - makefile updated to your one, previous renamed to Makefile - fixed bug in unique file name generation Thank you for testing, Jan
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
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