[time-nuts] Linux PPS clues?

Adrian Godwin artgodwin at gmail.com
Fri Oct 21 05:53:57 EDT 2016

What is the circuit driving that signal ? It appears to have too little
positive drive to overcome the capacitance. Perhaps it's an open collector
with too large a pull-up ?

On 21 Oct 2016 12:23 a.m., "Ilia Platone" <info at iliaplatone.com> wrote:

> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list