If you went through the trouble of going over the source code for the TCD1304 driver, you’ll have read something about the sampling time, and you might have noticed that the comments weren’t all in accord with the actual code (at least not for the last few updates).
Very briefly I’d done some back of the envelope calculations to figure out the longest possible sampling time.
And it just wasn’t working.
The ADC didn’t keep up with the output rate of the TCD1304. I figured the dog was buried¹ in the setup of the ADC trigger, because I had done such thorough calculations on everything else (cough).
It turned out I hadn’t read the datasheet for the STM32F401RE properly. The ADC is such a hardworking creature that it needs a small break (tstab) of app. 2 µs between each conversion. During this much needed break it squanders something like 80% of the available sampling time.
And here are the calculations:
The ADC runs with a typical frequency of 30 MHz. That means each cycle takes:
(30 MHz)⁻¹ = 33 ns
It’s a 12 bit ADC, and each bit takes one cycle during the conversion:
12·33 ns = 0.40 µs
The output rate is 350 kHz, so the total conversion time cannot exceed:
(350 kHz)⁻¹ = 2.86 µs
With 0.40 µs for a 12 bit conversion, there’s 2.46 µs to sample in. This gives a sampling time (in ADC clock cycles) of:
2.46 µs / 33 ns = 73
This is all good and well, but when taking the tstab into account, it shrinks to:
(2.46 µs – 2 µs) / 33 ns = 13
And the nearest available setting is 3 cycles. So there you have it.
Oh, and here’s a recent screenshot of a recorded photogram (crap I had lying around, that I partly covered the CCD with:
Btw while I was investigating the ADC I also made this little plot:
That’s all folks.
¹I know this isn’t an english idiom, but I just love the expression so much (all our real dogs are buried in the back yard, all the dead ones at least).