linux driver

OK, thanks!

On end of lines, most of the code is \n, only the most recent changes appear to be getting \r\n so maybe it's a recent change in editor settings or something?
I don't care that much but I thought you should know in case it was unintended.

Best,

Jim

 

Wrt. Makefile and makefile, it is worth noting that having both won't work on OSX, which by default is case insensitive....

Thorsten

 

I think, you can use:
1) make which uses makefile by default
2) make -f Makefile if the sbigudrv.so is its default place /usr/local/lib or in different directory pointed to it by soft link from /usr/local/lib.

I have always sbigudrv.so in /usr/local/lib.

Regards,
Jan

 

That is normally the case, I agree. But the filesystem on Mac OS X will not store both files if the names differ only in capitalization, as the filesystem is case insensitive.

It is an odd variant of it, however — it will actually store files with both upper and lower case in their names. But a file "abc" and a file "ABC" (or "aBc" or "abC") will all refer to the same file on disk, with the actual filename being whichever was first written.

This is not at all a problem once you look at things on a Linux system (which I gather is the (only?) target for the code in question?), but a number of people will want to at least inspect code on other systems. So perhaps name things e.g. "Makefile" and "Makefile.something" instead of "Makefile" and "makefile"? Most people also don't remember which capitalization form has higher priority with make...

Thorsten

 

Thorsten,
now, I understand the point. I never supposed to use this user-space driver on Mac OSX, because we use native USB support there and not the libusb library.
I thought about using the libusb library on Windows, Linux & Mac sometime ago because it would be much easy to maintain only one solution...
Regards,
Jan

 

In the Makefile I proposed one could change SBIG_LIBS= to SBIG_LIBS=? and then it can be overridden on command line e.g.

make SBIG_LIBS=-lsbigudrv

would use the installed library and we could avoid having two makefiles. Just a thought.

https://github.com/garlick/sbig-util/blob/master/sdk/app/Makefile

 

Hi Jan

Thanks for your continuing contribution on the driver for ARM devices. We successfully use your library for RPi on RK3188 and RK3066 devices for the iAstroHub project.
http://sourceforge.net/projects/iastrohub/

OpenSkyImager supports SBIG cameras and CFWs on arm devices. And it accepts command line scripts.
https://github.com/OpenSkyProject/OpenSkyImager
I use OpenSkyImager as an engine for iAstroHub. We have tested with ST2k, ST10xme, ST-i and CFW10.

Best regards,
Anat

 

Jan

I use the SBIG library version 4.84 as provided in the dropbox. I use STF8300 color. I got "blank" frames occasionally (1 in 100 frames) on my ARM linux box. Is this issue resolved in the newer library?

Best regards,
Anat

 

Doug

Thanks for the update.

Anat

 

Hi, I've posted several messages in the 'general' section about linux support for parallel port cameras and received no reply, so I thought I'd post here where I know the right people are watching. I see that a kernel module sbiglptmod.o is required to use parallel port cameras with the sbigudrv on Linux, and that it was only released as a binary for kernel 2.4. Is there any possibility that this could be released in source form so that someone could port it to a modern kernel? I'd be willing to try to port it if SBIG is willing to release it as open source.

Also, wouldn't it be neat if this could be adapted to work with a GPIO ports on a tiny ARM board?