[time-nuts] Linux PPS clues?

Ilia Platone info at iliaplatone.com
Thu Oct 20 19:23:25 EDT 2016


sorry, no attachment, this mail contains two images, one is the previous 
attempt, the second (IMG_003.JPG) was taken at 5us/div, 1v/div with a 
different oscilloscope setup.

Best Regards,
Ilia.

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.
>
> 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.
>
> For better answers, I would need to know what kind of events these are
> and what exactly need to be done/measured.
>
> 			Attila Kinali
>
>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: P_20161021_003338.jpg
Type: image/jpeg
Size: 40667 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20161020/75b36291/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_0003.JPG
Type: image/jpeg
Size: 111705 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20161020/75b36291/attachment-0001.jpe>


More information about the time-nuts mailing list