any raspberry pi people here?...

[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.

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.

 

[Dimiter_Popoff]

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?
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.

 

[Grant Taylor]

On 7/18/22 1:13 PM, John Larkin wrote:

The pi doesn\'t seem to have any general counter/timer hardware, like
ARMs usually do.

My understanding is that the /Raspberry/ Pi(s) don\'t have hardware for
keeping time when the CPU isn\'t running.

Some of the other Pi(s) and the likes do have timer hardware.

The Raspberry Pi is like Ethernet, in that it\'s the most inexpensive
thing that gets done what 80% of the users need. If you\'re in the other
20%, you want something else, be it a hat or different board.



--
Grant. . . .
unix || die

 

[Lasse Langwadt Christensen]

mandag den 18. juli 2022 kl. 21.13.15 UTC+2 skrev 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

maybe look at this: https://beagleboard.org/black
it uses an SoC that has two extra risc cpus with access to everything on the chip
for realtime tasks

chapter 4
https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf

Do pi\'s have crystal oscillators? I guess we could add one too.

a PI has everything it needs, just add power (and an SC card*)

*or get a CM4 compute module with eMMC

 

[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.

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.

 

[Lasse Langwadt Christensen]

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 ....

 

[John Larkin]

On Mon, 18 Jul 2022 12:36:41 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

mandag den 18. juli 2022 kl. 21.13.15 UTC+2 skrev 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?

May as well go with 4B.

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

Of course I need hardware to do microsecond timings. The c programs
would pick up the numbers from the hardware.

maybe look at this: https://beagleboard.org/black
it uses an SoC that has two extra risc cpus with access to everything on the chip
for realtime tasks

chapter 4
https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf


Do pi\'s have crystal oscillators? I guess we could add one too.

a PI has everything it needs, just add power (and an SC card*)

4B seems to have a 19.2 MHz crystal, but it doesn\'t look like it
accessable to an external gadget, like an FPGA. I can add a VCXO.

*or get a CM4 compute module with eMMC

 

[John Larkin]

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.

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.

 

[Don]

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,

--
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.

 

[Dimiter_Popoff]

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.

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.

 

[John Walliker]

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

 

[Lasse Langwadt Christensen]

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

 

[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.

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.

 

[John Larkin]

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.

 

[Lasse Langwadt Christensen]

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

 

[Lasse Langwadt Christensen]

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?

 

[Lasse Langwadt Christensen]

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

 

[Phil Hobbs]

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

 

[Dimiter_Popoff]

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\" ].

 

[Don Y]

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]