any raspberry pi people here?

On Monday, 18 July 2022 at 21:30:01 UTC+1, lang...@fonz.dk wrote:
> mandag den 18. juli 2022 kl. 22.18.25 UTC+2 skrev Don: 
> > Lasse Langwadt Christensen wrote: 
> > > John Larkin: 
> > >> The pi doesn't seem to have any general counter/timer hardware, like 
> > >> ARMs usually do. I've seen vague references to using the GPU to do 
> > >> timings. 
> > >> 
> > > 
> > > which version of pi? 
> > > 
> > >> I'd like to measure frequencies and timestamp some edges, in the 1 us 
> > >> sort of domain, several channels. I guess we could hang a small FPGA 
> > >> off to the side if pi can't do it. 
> > > 
> > > using a pi I assume you'll be running some kind of linux I don't see how you 
> > > could do 1us timing in linux 
> > My RPi2B is loaded with BSD 14 and its nanosleep() function provides 1ns 
> > resolution for my iic interface.
> sure as long as your code is running and not interrupted you can busy wait with 
> nanosec resolution up to few ms 
> 
> try reacting on a signal to measure it's frequency or timestamp it ....

The RasPi 4 is a very nice machine.  The CM4 even more so if only you could buy one
at the moment.  The CM4 has a PCI-e interface which gives lots of possibilities.
The Beaglebone Black is also good, but it has less RAM than
the Raspi 4 and only has a 100Mbit/s ethernet port whereas the PI 4 has 1Gbit/s.
The extra processors do allow time critical software to be written though.

There are add-on modules with real time clock chips for the Pi and the BBB.

Alternatively, look at the RasPi pico board or the RP2040 microcontroller which it
uses.  Both of these have the big advantage that they can be bought in large quantities
at the moment.  The RP2040 has multiple programmable state machines  which
allow very complex i/o operations with precise timing.  There are also multiple
counter-timer modules.  It is a two-core ARM M0+.
Finally, don't forget the XMOS devices, many of which support USB and/or ethernet
together with deterministic timing and multiple cores.
John

mandag den 18. juli 2022 kl. 22.58.41 UTC+2 skrev Don:
> Lasse Langwadt Christensen <lang...@fonz.dk> wrote:
> > mandag den 18. juli 2022 kl. 22.18.25 UTC+2 skrev Don: 
> >> Lasse Langwadt Christensen wrote: 
> >> > John Larkin: 
> >> >> The pi doesn't seem to have any general counter/timer hardware, like 
> >> >> ARMs usually do. I've seen vague references to using the GPU to do 
> >> >> timings. 
> >> >> 
> >> > 
> >> > which version of pi? 
> >> > 
> >> >> I'd like to measure frequencies and timestamp some edges, in the 1 us 
> >> >> sort of domain, several channels. I guess we could hang a small FPGA 
> >> >> off to the side if pi can't do it. 
> >> > 
> >> > using a pi I assume you'll be running some kind of linux I don't see how you 
> >> > could do 1us timing in linux 
> >> My RPi2B is loaded with BSD 14 and its nanosleep() function provides 1ns 
> >> resolution for my iic interface. 
> > 
> > sure as long as your code is running and not interrupted you can busy wait with 
> > nanosec resolution up to few ms 
> > 
> > try reacting on a signal to measure it's frequency or timestamp it ....
> BSD nanosleep() suspends execution of the calling thread.

for _atleast_ the time you requested, have you tried looking at the actual signals you get?

anyway, that doesn't help for reacting and timing external signals

Lasse Langwadt Christensen wrote:
> skrev Don:
>> Lasse Langwadt Christensen wrote:
>> > skrev Don:
>> >> Lasse Langwadt Christensen wrote:
>> >> > John Larkin:
>> >> >> The pi doesn't seem to have any general counter/timer hardware, like
>> >> >> ARMs usually do. I've seen vague references to using the GPU to do
>> >> >> timings.
>> >> >>
>> >> >
>> >> > which version of pi?
>> >> >
>> >> >> I'd like to measure frequencies and timestamp some edges, in the 1 us
>> >> >> sort of domain, several channels. I guess we could hang a small FPGA
>> >> >> off to the side if pi can't do it.
>> >> >
>> >> > using a pi I assume you'll be running some kind of linux I don't see how you
>> >> > could do 1us timing in linux
>> >> My RPi2B is loaded with BSD 14 and its nanosleep() function provides 1ns
>> >> resolution for my iic interface.
>> >
>> > sure as long as your code is running and not interrupted you can busy wait with
>> > nanosec resolution up to few ms
>> >
>> > try reacting on a signal to measure it's frequency or timestamp it ....
>> BSD nanosleep() suspends execution of the calling thread.
>
> for _atleast_ the time you requested, have you tried looking at the actual signals you get?
>
> anyway, that doesn't help for reacting and timing external signals

Did you overlooked the iic part of my original followup up there? ^^^
My RPi Apps use nanosleep to react to and time external Inter-Integrated
Circuit signals. ...

OK, maybe you're supposed to say i2c instead of iic.
    
Danke,

-- 
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

On Tue, 19 Jul 2022 00:04:14 +0300, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

>On 7/18/2022 23:55, John Larkin wrote:
>> On Mon, 18 Jul 2022 22:23:21 +0300, Dimiter_Popoff <dp@tgi-sci.com>
>> wrote:
>> 
>>> On 7/18/2022 22:13, John Larkin wrote:
>>>>
>>>>
>>>> The pi doesn't seem to have any general counter/timer hardware, like
>>>> ARMs usually do. I've seen vague references to using the GPU to do
>>>> timings.
>>>>
>>>> I'd like to measure frequencies and timestamp some edges, in the 1 us
>>>> sort of domain, several channels. I guess we could hang a small FPGA
>>>> off to the side if pi can't do it.
>>>>
>>>> Do pi's have crystal oscillators? I guess we could add one too.
>>>>
>>>>
>>>>
>>>
>>> Are you serious about using yet another aliexpress toy for some
>>> real design?
>> 
>> https://en.wikipedia.org/wiki/Raspberry_Pi >
>> Not exactly a toy. But it would save us using up our stock of FPGAs
>> and ARM chips, and I know a guy who would like to do the programming.
>> He's a retired Fellow of United Technologies (Collins) who really
>> likes to code.
>
>Oh I know it is fairly complex and it is widely used in consumer
>stuff, people watch videos on it etc.
>I just don't see that sort of thing in the kind of products you
>seem to be doing. But then if it is the easiest way to do things
>and you find it stable enough why not.

It seems to be pretty serious, from Broadcom, and it's hard to get
ARMs and ZYNQs these days. It's even hard to get opamps.

>
>
>> 
>>> Other than the obvious question above, does not ARM have some
>>> sort of timebase register as part of the core? This might be
>>> usable to some extent, depending on how much jitter you can
>>> tolerate.
>> 
>> The ARM in the pi seems to have none of the usual counter/timer stuff,
>> so we'd have to do that externally, in a small FPGA probably. We might
>> have three frequency counters and maybe six edge time stampers in a
>> FIFO or something. Pretty simple.
>> 
>> Some torque sensors make tricky timing waveforms.
>> 
>
>I was talking of something like the PPC timebase register, it is
>a free running 64 bit counter. If they have something like that
>you could timestamp events using some IRQ, the jitter you would
>get would depend mostly on the IRQ latency then.
>But I am really no ARM person.

We could have a free-running 32-bit counter at some MHz. Every rise or
fall on any of the three inputs, we'd latch the counter and poke it
into the FIFO with an ID tag. Then let the c code figure it all out.

Imagine a shaft with a bunch of gear teeth on each end, each with a
magnetic pickup. Spin it and both pickups make about the same pulse
train. But torque twists the shaft and the pickup phases change. We
can get RPM and torque from the two signals. The F35 fan is driven
with a shaft at something crazy like 30K horsepower, and it twists a
lot.

Sometimes there is one missing tooth, as a rotation index. Or more
complex stuff. The signal conditioning gets interesting.

True sadism would be to just digitize the sensor waveforms.

mandag den 18. juli 2022 kl. 23.04.21 UTC+2 skrev Dimiter Popoff:
> On 7/18/2022 23:55, John Larkin wrote: 
> > On Mon, 18 Jul 2022 22:23:21 +0300, Dimiter_Popoff <d...@tgi-sci.com> 
> > wrote: 
> > 
> >> On 7/18/2022 22:13, John Larkin wrote: 
> >>> 
> >>> 
> >>> The pi doesn't seem to have any general counter/timer hardware, like 
> >>> ARMs usually do. I've seen vague references to using the GPU to do 
> >>> timings. 
> >>> 
> >>> I'd like to measure frequencies and timestamp some edges, in the 1 us 
> >>> sort of domain, several channels. I guess we could hang a small FPGA 
> >>> off to the side if pi can't do it. 
> >>> 
> >>> Do pi's have crystal oscillators? I guess we could add one too. 
> >>> 
> >>> 
> >>> 
> >> 
> >> Are you serious about using yet another aliexpress toy for some 
> >> real design? 
> > 
> > https://en.wikipedia.org/wiki/Raspberry_Pi > 
> > Not exactly a toy. But it would save us using up our stock of FPGAs 
> > and ARM chips, and I know a guy who would like to do the programming. 
> > He's a retired Fellow of United Technologies (Collins) who really 
> > likes to code.
> Oh I know it is fairly complex and it is widely used in consumer 
> stuff, people watch videos on it etc. 
> I just don't see that sort of thing in the kind of products you 
> seem to be doing. But then if it is the easiest way to do things 
> and you find it stable enough why not.
> > 
> >> Other than the obvious question above, does not ARM have some 
> >> sort of timebase register as part of the core? This might be 
> >> usable to some extent, depending on how much jitter you can 
> >> tolerate. 
> > 
> > The ARM in the pi seems to have none of the usual counter/timer stuff, 
> > so we'd have to do that externally, in a small FPGA probably. We might 
> > have three frequency counters and maybe six edge time stampers in a 
> > FIFO or something. Pretty simple. 
> > 
> > Some torque sensors make tricky timing waveforms. 
> >
> I was talking of something like the PPC timebase register, it is 
> a free running 64 bit counter. If they have something like that 
> you could timestamp events using some IRQ, the jitter you would 
> get would depend mostly on the IRQ latency then. 
> But I am really no ARM person.

afaik it has a 64 bit system timer that always runs at 1MHz 

mandag den 18. juli 2022 kl. 23.30.47 UTC+2 skrev Don:
> Lasse Langwadt Christensen wrote: 
> > skrev Don: 
> >> Lasse Langwadt Christensen wrote: 
> >> > skrev Don: 
> >> >> Lasse Langwadt Christensen wrote: 
> >> >> > John Larkin: 
> >> >> >> The pi doesn't seem to have any general counter/timer hardware, like 
> >> >> >> ARMs usually do. I've seen vague references to using the GPU to do 
> >> >> >> timings. 
> >> >> >> 
> >> >> > 
> >> >> > which version of pi? 
> >> >> > 
> >> >> >> I'd like to measure frequencies and timestamp some edges, in the 1 us 
> >> >> >> sort of domain, several channels. I guess we could hang a small FPGA 
> >> >> >> off to the side if pi can't do it. 
> >> >> > 
> >> >> > using a pi I assume you'll be running some kind of linux I don't see how you 
> >> >> > could do 1us timing in linux 
> >> >> My RPi2B is loaded with BSD 14 and its nanosleep() function provides 1ns 
> >> >> resolution for my iic interface. 
> >> > 
> >> > sure as long as your code is running and not interrupted you can busy wait with 
> >> > nanosec resolution up to few ms 
> >> > 
> >> > try reacting on a signal to measure it's frequency or timestamp it .... 
> >> BSD nanosleep() suspends execution of the calling thread. 
> > 
> > for _atleast_ the time you requested, have you tried looking at the actual signals you get? 
> > 
> > anyway, that doesn't help for reacting and timing external signals
> Did you overlooked the iic part of my original followup up there? ^^^ 
> My RPi Apps use nanosleep to react to and time external Inter-Integrated 
> Circuit signals. ... 
> 
> OK, maybe you're supposed to say i2c instead of iic.

you are generating signals, not reacting and measuring. That easy you just burn cycles while waiting 
and iic will work just fine with milli second timing ...

How is nanosleep going to help if you want to time when and for how long and external signal it asserted?

mandag den 18. juli 2022 kl. 23.37.57 UTC+2 skrev John Larkin:
> On Tue, 19 Jul 2022 00:04:14 +0300, Dimiter_Popoff <d...@tgi-sci.com>
> wrote: 
> 
> >On 7/18/2022 23:55, John Larkin wrote: 
> >> On Mon, 18 Jul 2022 22:23:21 +0300, Dimiter_Popoff <d...@tgi-sci.com> 
> >> wrote: 
> >> 
> >>> On 7/18/2022 22:13, John Larkin wrote: 
> >>>> 
> >>>> 
> >>>> The pi doesn't seem to have any general counter/timer hardware, like 
> >>>> ARMs usually do. I've seen vague references to using the GPU to do 
> >>>> timings. 
> >>>> 
> >>>> I'd like to measure frequencies and timestamp some edges, in the 1 us 
> >>>> sort of domain, several channels. I guess we could hang a small FPGA 
> >>>> off to the side if pi can't do it. 
> >>>> 
> >>>> Do pi's have crystal oscillators? I guess we could add one too. 
> >>>> 
> >>>> 
> >>>> 
> >>> 
> >>> Are you serious about using yet another aliexpress toy for some 
> >>> real design? 
> >> 
> >> https://en.wikipedia.org/wiki/Raspberry_Pi > 
> >> Not exactly a toy. But it would save us using up our stock of FPGAs 
> >> and ARM chips, and I know a guy who would like to do the programming. 
> >> He's a retired Fellow of United Technologies (Collins) who really 
> >> likes to code. 
> > 
> >Oh I know it is fairly complex and it is widely used in consumer 
> >stuff, people watch videos on it etc. 
> >I just don't see that sort of thing in the kind of products you 
> >seem to be doing. But then if it is the easiest way to do things 
> >and you find it stable enough why not.
> It seems to be pretty serious, from Broadcom, and it's hard to get 
> ARMs and ZYNQs these days. It's even hard to get opamps.
> > 
> > 
> >> 
> >>> Other than the obvious question above, does not ARM have some 
> >>> sort of timebase register as part of the core? This might be 
> >>> usable to some extent, depending on how much jitter you can 
> >>> tolerate. 
> >> 
> >> The ARM in the pi seems to have none of the usual counter/timer stuff, 
> >> so we'd have to do that externally, in a small FPGA probably. We might 
> >> have three frequency counters and maybe six edge time stampers in a 
> >> FIFO or something. Pretty simple. 
> >> 
> >> Some torque sensors make tricky timing waveforms. 
> >> 
> > 
> >I was talking of something like the PPC timebase register, it is 
> >a free running 64 bit counter. If they have something like that 
> >you could timestamp events using some IRQ, the jitter you would 
> >get would depend mostly on the IRQ latency then. 
> >But I am really no ARM person.
> We could have a free-running 32-bit counter at some MHz. Every rise or 
> fall on any of the three inputs, we'd latch the counter and poke it 
> into the FIFO with an ID tag. Then let the c code figure it all out. 
> 
> Imagine a shaft with a bunch of gear teeth on each end, each with a 
> magnetic pickup. Spin it and both pickups make about the same pulse 
> train. But torque twists the shaft and the pickup phases change. We 
> can get RPM and torque from the two signals. The F35 fan is driven 
> with a shaft at something crazy like 30K horsepower, and it twists a 
> lot. 

you'll need an FPGA or at least an mcu with a capture timer

how about an RP2040 ? with two 133MHz M0+ and fancy HW statemachines
it has plenty of horsepower to do it spit out result on spi/uart or what ever 

> Sometimes there is one missing tooth, as a rotation index. Or more 
> complex stuff. The signal conditioning gets interesting. 

in all cars that how the ECU figure out the engine position

one everything Bosch like your Audi it is  60 minus 2 teeth

Don wrote:
> Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
>> mandag den 18. juli 2022 kl. 22.18.25 UTC+2 skrev Don:
>>> Lasse Langwadt Christensen wrote:
>>>> John Larkin:
>>>>> The pi doesn't seem to have any general counter/timer hardware, like
>>>>> ARMs usually do. I've seen vague references to using the GPU to do
>>>>> timings.
>>>>>
>>>>
>>>> which version of pi?
>>>>
>>>>> I'd like to measure frequencies and timestamp some edges, in the 1 us
>>>>> sort of domain, several channels. I guess we could hang a small FPGA
>>>>> off to the side if pi can't do it.
>>>>
>>>> using a pi I assume you'll be running some kind of linux I don't see how you
>>>> could do 1us timing in linux
>>> My RPi2B is loaded with BSD 14 and its nanosleep() function provides 1ns
>>> resolution for my iic interface.
>>
>> sure as long as your code is running and not interrupted you can busy wait with
>> nanosec resolution up to few ms
>>
>> try reacting on a signal to measure it's frequency or timestamp it ....
> 
> BSD nanosleep() suspends execution of the calling thread.
>      
> Danke,
> 

At the resolution of the thread scheduler.

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

On 7/19/2022 0:37, John Larkin wrote:
> On Tue, 19 Jul 2022 00:04:14 +0300, Dimiter_Popoff <dp@tgi-sci.com>
> wrote:
> 
>> On 7/18/2022 23:55, John Larkin wrote:
>>> On Mon, 18 Jul 2022 22:23:21 +0300, Dimiter_Popoff <dp@tgi-sci.com>
>>> wrote:
>>>
>>>> On 7/18/2022 22:13, John Larkin wrote:
>>>>>
>>>>>
>>>>> The pi doesn't seem to have any general counter/timer hardware, like
>>>>> ARMs usually do. I've seen vague references to using the GPU to do
>>>>> timings.
>>>>>
>>>>> I'd like to measure frequencies and timestamp some edges, in the 1 us
>>>>> sort of domain, several channels. I guess we could hang a small FPGA
>>>>> off to the side if pi can't do it.
>>>>>
>>>>> Do pi's have crystal oscillators? I guess we could add one too.
>>>>>
>>>>>
>>>>>
>>>>
>>>> Are you serious about using yet another aliexpress toy for some
>>>> real design?
>>>
>>> https://en.wikipedia.org/wiki/Raspberry_Pi >
>>> Not exactly a toy. But it would save us using up our stock of FPGAs
>>> and ARM chips, and I know a guy who would like to do the programming.
>>> He's a retired Fellow of United Technologies (Collins) who really
>>> likes to code.
>>
>> Oh I know it is fairly complex and it is widely used in consumer
>> stuff, people watch videos on it etc.
>> I just don't see that sort of thing in the kind of products you
>> seem to be doing. But then if it is the easiest way to do things
>> and you find it stable enough why not.
> 
> It seems to be pretty serious, from Broadcom, and it's hard to get
> ARMs and ZYNQs these days. It's even hard to get opamps.
> 
>>
>>
>>>
>>>> Other than the obvious question above, does not ARM have some
>>>> sort of timebase register as part of the core? This might be
>>>> usable to some extent, depending on how much jitter you can
>>>> tolerate.
>>>
>>> The ARM in the pi seems to have none of the usual counter/timer stuff,
>>> so we'd have to do that externally, in a small FPGA probably. We might
>>> have three frequency counters and maybe six edge time stampers in a
>>> FIFO or something. Pretty simple.
>>>
>>> Some torque sensors make tricky timing waveforms.
>>>
>>
>> I was talking of something like the PPC timebase register, it is
>> a free running 64 bit counter. If they have something like that
>> you could timestamp events using some IRQ, the jitter you would
>> get would depend mostly on the IRQ latency then.
>> But I am really no ARM person.
> 
> We could have a free-running 32-bit counter at some MHz. Every rise or
> fall on any of the three inputs, we'd latch the counter and poke it
> into the FIFO with an ID tag. Then let the c code figure it all out.
> 
> Imagine a shaft with a bunch of gear teeth on each end, each with a
> magnetic pickup. Spin it and both pickups make about the same pulse
> train. But torque twists the shaft and the pickup phases change. We
> can get RPM and torque from the two signals. The F35 fan is driven
> with a shaft at something crazy like 30K horsepower, and it twists a
> lot.
> 
> Sometimes there is one missing tooth, as a rotation index. Or more
> complex stuff. The signal conditioning gets interesting.
> 
> True sadism would be to just digitize the sensor waveforms.
> 
> 

Sounds like you are making some testing setup for someone
(surely you won't put a Rpi on a real F35?!), so if it works for you
why not. Just make sure the counter you put is wide enough, that's
easy to underestimate... [Side story: on a 64 bit power architecture
processor there is that standard 64 bit free running timebase,
same like on 32 bit cores, where in order to read it you read the
upper longword, then the lower, then the upper again and compare
the two uppers you got; if not matching, do it again. Now on
a 64 bit machine you would expect a simple read into a 64 bit
general purpose register to be the normal way - which was the
idea, only the errata sheet says "don't do it, do it the old
way" :-) ].

On 7/18/2022 4:26 PM, Dimiter_Popoff wrote:
> [Side story: on a 64 bit power architecture
> processor there is that standard 64 bit free running timebase,
> same like on 32 bit cores, where in order to read it you read the
> upper longword, then the lower, then the upper again and compare
> the two uppers you got; if not matching, do it again. Now on
> a 64 bit machine you would expect a simple read into a 64 bit
> general purpose register to be the normal way - which was the
> idea, only the errata sheet says "don't do it, do it the old
> way" :-) ].

If you are doing this under the protections of a critical region,
you can read high, read low, read high.  If high1 agrees with
high2, then the result is (high,low).

If, OTOH, high1 and high2 differ, the difference will be limited to
a single "increment" (assuming CPU clock is comparable to timer
clock).  You can then choose to represent the reported time as
"high1 with low just before increment" or "high2, low just after
increment".  No need to go back and try again...

[you can't reliably do low,high,low in a single pass]