Currently, the library wrapper is intended to verify proof of concept on the ARMV8 architecture and ASI178M camera.
Now I'm trying to unify the library for each camera and architecture. Additionally, I have to get rid of one more redundant copy in the GetImage method.

Without library sources, I have a lot of work to do decompiling and creating new code to be easily injected.

Main issues of the library from ZWO:

  • synchronous USB communication.
  • incorrectly handled communication errors - one error causes an avalanche of errors.
  • too much data copying (3x per frame).
  • I suspect the inability to run several cameras on the same instance of the library (common static variable)

On Raspberry PI, the biggest problem is data copying.
The copying speed is ~ 1400 - 2000 MB / s.
The original library does 3 copies per frame + a copy in libusb from USB.
$ make && ./asitest Exposure 10000 HighSpeedMode 1 BandWidth 100 Gain 100
g++ -o asitest main.cpp -I./libasi/include -I./ -lpthread -lusb-1.0 ./libasi/lib/armv8/libASICamera2.a -Wl,--wrap=memcpy -O2
Set 'Exposure' is 10000
Set 'HighSpeedMode' is 1
Set 'BandWidth' is 100
Set 'Gain' is 100
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
timeframe:   280ms                                 <--- issue
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
timeframe:   546ms                                 <--- issue
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
timeframe:   546ms                                 <--- issue

For a 6MB frame, at 60fps this is 6MB * 4 * 60 = 1440MB/s

Speed ​​test for Raspberry PI 4 (64bit userland)
$ ./ramspeed 6
std::vector, size: 6 MB, copy: 0.0043 s, speed: 1396.592 MBps
std::vector, size: 6 MB, copy: 0.0042 s, speed: 1416.900 MBps
memcpy, size: 6 MB, copy: 0.0039 s, speed: 1544.185 MBps
memcpy, size: 6 MB, copy: 0.0039 s, speed: 1546.861 MBps

$ ./ramspeed 6
std :: vector, size: 6 MB, copy: 0.0025 s, speed: 2403.668 MBps
std :: vector, size: 6 MB, copy: 0.0025 s, speed: 2409.675 MBps
memcpy, size: 6 MB, copy: 0.0025 s, speed: 2374.098 MBps
memcpy, size: 6 MB, copy: 0.0025 s, speed: 2378.751 MBps

A large number of copies causes the loss of data from the USB.
Each frame in my case consists of 7 transfers (bulk). If one of them is "damaged" the library cannot handle it in an elegant way.
Apart from the fact that there is no copy space in other programs or on the system.

I think in 2 weeks, I will be able to publish my work.
I still had to eliminate one copy per frame and a lot of tests.
./asitest-boost Exposure 10000 HighSpeedMode 1 BandWidth 100 Gain 100
[ASIOpenCamera]: grab CameraID 0
[libusb_open]: grab libusb_device_handle 0x559d731cd0
[CCameraBase::InitVariable]: grab CCameraBase 0x559d73c9b0
[CirBuf::CirBuf]: link CirBuf 0x559d73afe0 and CCameraBase 0x559d73c9b0
[CirBuf::CirBuf]: link CCameraBase 0x559d73c9b0 and libusb_device_handle 0x559d731cd0
[CirBuf::CirBuf]: link iCameraID 0 and CCameraBase 0x559d73c9b0
Set 'Exposure' to 10000
Set 'HighSpeedMode' to 1
Set 'BandWidth' to 100
Set 'Gain' to 100
[CameraBoost::CameraBoost]: created
[CCameraFX3::initAsyncXfer]: init CameraBoost device 0x559d731cd0, endpoint 0x81, buffer size 6439680
[CirBuf::ReadBuff]: 1 1 0x7f7e85f010
[!!!] Big copy detected: 6439680 Bytes
timeframe:   261ms                       <---- warming up
[CirBuf::ReadBuff]: 2 2 0x7f7c15a010
[!!!] Big copy detected: 6439680 Bytes
timeframe:    16ms                        <---- yeah!
[CirBuf::ReadBuff]: 3 3 0x7f778ff010
[!!!] Big copy detected: 6439680 Bytes
timeframe:    17ms                        <---- yeah!
[CirBuf::ReadBuff]: 4 4 0x7f771fe010
[!!!] Big copy detected: 6439680 Bytes
timeframe:    17ms                        <---- yeah!
[CirBuf::ReadBuff]: 5 5 0x7f7c15a010
[!!!] Big copy detected: 6439680 Bytes
timeframe:    16ms                        <---- yeah!
[CirBuf::ReadBuff]: 6 6 0x7f778ff010
[!!!] Big copy detected: 6439680 Bytes
timeframe:    16ms                        <---- yeah! 60 fps
....

By queuing buffers and passing pointers, there will also be some work with the Indi library to take advantage of the new possibilities.
I will also add the ability to restore the original behavior of the library, without the need to compile or replace files.

Read More...