[time-nuts] Linux PPS clues?

[Ilia Platone]

On 10/20/16 18:12, Attila Kinali wrote:
> On Thu, 20 Oct 2016 10:59:21 +0100
> "David J Taylor" <david-taylor at blueyonder.co.uk> wrote:
>
>> Actually, of the 15 Raspberry Pi cards I have only one is used in a graphics
>> application.
> Yes, the rpi are used for all kind of stuff and there is a huge community
> around them that helps with all kind of questions. Unfortunately, the
> rpi is also used for all kind of stuff that it is a suboptimal choice
> (to put it mildly), but people do not care or do not want to check
> for alternatives. It kind of works, that's all they care about.
>
>> On the positive side they work very well with external devices for control
>> and measurement,
> And for most of these applications a 32bit uC that uses a fraction of
> the power would be the right choice. Often a clock of 1MHz would be enough.
>
>> and have a huge amount of software and hardware support for
>> a vast range of devices which makes for fast and easy development.
> That's the only plus side. But then, most of the code written in C
> can be used on a uC just the same with little to no modification.
>
>> I will be interested to see what is recommended for a 100 kHz event rate.
> This is actually a very tough question. 100kHz means that for each event
> there is only 10µs available for detection, processing and output. Using
> a uC that would be something in the order of 1000-2000 CPU cycles. On an
> application processor (rpi and its cusins) that would be 2000 to 20'000 cycles.
> While 1000 cycles on a uC is quite a lot, you cannot do any fancy processing
> with so few cycles.
I can use one of my boards, which have (checked better) 6MHz sampling 
frequency on the GPIO, but the sysclock runs at 180MHz, this should be 
enough except logging support bandwidth. check the NXP3130 uC which is 
powering these boards: it's old but its dirty job is done perfectly.
> On the application processor 20k cylces is plenty, but you have the complex
> OS that eats up a few thousand cycles itself. Addtionally there comes
> the interrupt latency that the application processors suffer from, which
> is in the order of 1-10µs... So they would need a kind of (hardware) system
> to queue up the events to process them in badges. Because of this, an rpi
> wouldn't work at all (bitbanging takes several µs for each operation).
>
> Going for an uC is easier in that regard as they have very little interrupt
> latency (usually just 5-10 cycles), but then you have problems with
> getting the output out of the uC as their I/O subsystems are usually
> optimized to work in a stand-alone fashion.
> Maybe one way would be to use an arm9/cortex-a5 based uC (ie not an application
> processor) and use their high speed I/O.
yes.
> For better answers, I would need to know what kind of events these are
> and what exactly need to be done/measured.
>
> 			Attila Kinali
These events are random photon arrivals (converted to 5vTTL pulses), 
their rate was measured using the pulse width of the smaller detected, 
which was 5~10 uS during an observation in low-light environment.
The photon arrival and pulse width were random with a minimum pulse 
width of 10uS. What I want to do is measuring the photon arrival 
precisely (low to high transition - interrupt I guess), consider that 
the maximum rate would be 100Kcps because the photon events would 
overlap if higher. If the 3130 controller can handle such rate it would 
be great :)

Best Regards,
Ilia.

-- 
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999