View Single Post
Old 15-01-2017, 12:36 AM
gehelem (Gilles)
Registered User

gehelem is offline
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
Originally Posted by luka View Post
Gilles, got the driver working on Beaglebone Black. Few observations:
Also what do lines like this mean?
Try 2000 since 11778624<>12008000
Quick explanations time - be carefull i have flu, my head is "high in space"
There are two libraries we can use to talk to ft2232
  • Original D2XX from ftdi
  • LibFTDI from intra2net
The first one is the one used in ukrainian sofware, under windows.
I've first coded my cam84 driver with this one on linux. It is working quite well, no lines, no transmission troubles.
BUT : under linux, using bitbang mode with this library forces to unload ftdi_sio module.
The delicate consequence is that you can no more use other ftdi device, in a classical usb/serial converter for example. This is really annoying : can't use Eqmod on raspberry, nor any device using these devices (arduino/Moonlite focuser in my case)

The second library allows to keep module ftdi_sio module loaded, you "only" have to unbind it from kernel for a specific device (purpose of the udev file).
BUT : function calls are very similar, but there are a few specific items.
One of the biggest is the bitbang reading process. when you start a reading call, if there is nothing to read, function returns immediatly. This is the purpose of "ftdi_read_data_modified", wich is a hack submited by Toups on Indi forum :
This function is reponsible of the messages you get ("Try 2000 since 11778624<>1200800").
What do they mean ?
1200080 is the size of the data buffer we try to recieve (twice the number of pixels, in fact)
The function is trying to wait 2000x1us (max) that buffer is fullfilled.
I also have often these messages : i'm not really sure, but i think it is because the reading process is not synchronized with the "rythm" given by atmega.
Here, with "Try 2000 since 11778624<>1200800", we certainly have missed some data, because reading is starting too late.
In that case, your image is incomplete, and gives misplaced blocks you are talking about.
This is why i try to find good values of parameters : latency, baudrates and timeouts.

To investigate, we have a simple solution i've already done for cam84 : switch back to D2XX library. i will try to do that this week end.

Your point about CPU usage is really interesting, i didn't noticed that.
For sure it is the reading process itself
On my Odroid XU4, reading the image takes a few seconds (<5/6s)

I had no time to try my raspberry 3, too many things at the same time (wife's car KO...)

Reply With Quote