Thomas, the eos terminal will produce short pulse, typically corresponding to BUS_CLOCK. Many components require longer pulse for triggering, thus PulseConverter component comes handy. Consider using SDONE output instead of EOS because of timing delay which eos have. This time delay is variable and depends on ADC_SAR settings. In your case, PulseConverter component has input clock 12MHz, which is lower than pulse frequency (BUS_CLOCK), so input pulse is simply missed (see timing requirements of component), I believe that pulse length should be longer than 2 clock periods. Consider using 1-shot timer instead of PulseConverter for more deterministic timing. Lastly, external clock for ADC_SAR probably not required. Internal clock may suffice.
Carefully with the sdone output: The conversion is not complete when this signal comes! Only the sampling time is over at that point. Normally it is used to switch a multiplexor to the next channel allowing for the signal to settle as early as possible.
Thanks for the tips.
I increased the sample-clock at the Pulse Converter (with an additional clock) to 24MHz and now it works :-)
There is of course a jitter within 10 microseconds of the pulse-start coming out of the Pulse Converter, but I don't mind.
The sdone-signal wouldn't work because my ADC_SAR measures four times and saves the average. That would result in four pulses out of sdone, and three of them came to early.
I do worry a bit that I miss some eoc-pulses because, as odissey1 writes, with 24MHz I'm a the limit of detecting a pulse width of less than 50 ns. I could do the pulse-width conversion outside of the PSoC, but isn't there a way to make the pulse longer inside the chip?
Great, that OneShot_02 works perfect! Thanks a lot!
Though I get a warning I dont understand:
Warning-1366: Setup time violation found in a path from clock ( CyHFCLK ) to clock ( CyHFCLK ).
The Timing Analysis Report shows a violation because the maximum frequency of the CYHFCLK is 38.473 MHz (see picture).
Warning suggests that current design is not optimal and has max clock limitation 38MJz due to pulse front skew. Notice that HFCLK was set at 24MHz. I will look into it (try to remove SR latch). This gives general idea. Try to do same using fixed function TCPWM to save resources.