triggering things with ethernet...

[Dimiter_Popoff]

On 4/22/2023 20:34, Lasse Langwadt Christensen wrote:

lørdag den 22. april 2023 kl. 19.26.25 UTC+2 skrev Dimiter_Popoff:
On 4/22/2023 19:49, Lasse Langwadt Christensen wrote:
lørdag den 22. april 2023 kl. 18.21.54 UTC+2 skrev John Larkin:
On Sat, 22 Apr 2023 08:17:52 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

lørdag den 22. april 2023 kl. 16.26.03 UTC+2 skrev John Larkin:
On Sat, 22 Apr 2023 10:22:09 +0300, upsid...@downunder.com wrote:

On Thu, 20 Apr 2023 07:21:18 -0700, John Larkin
jla...@highlandSNIPMEtechnology.com> wrote:

On Thu, 20 Apr 2023 10:41:37 +0300, upsid...@downunder.com wrote:

On Tue, 18 Apr 2023 14:40:35 -0700, John Larkin

snip

The clock on the Raspberry Pi is a cheap crystal and is not tunable.
It might be interesting to do a DDS sort of thing to make a variable
that is a local calibrated time counter. We could occasionally send
out a packet to declare the time of day, and the little boxes could
both sync to that and tweak their DDS cal factors to stay pretty close
until the next correction. All software.

If the crystal has a reasonable short term stability but the frequency
is seriously inaccurate, some DDS principle can be applied. Assuming
the crystal drives a timer interrupt, say nominally every millisecond
and the ISR updates a nanosecond counter. If it has been determined
that the ISR is activated every 1.001234 milliseconds, the ISR adds
1001234 to the nanosecond counter. Each time when the million changes,
a new millisecond period is declared. Using two or more slightly
different adders and fractional nanoseconds can be counted.

Yes, something like that. On a dual-core 130 MHz ARM, one of the cores
could run a reasonable periodic interrupt at, say, 50 KHz. I\'ve run
non-trivial IRQs on an ARM at 100 KHz with a 70 MHz clock.

The option is to clock the Pico externally, which can probably be
done, or at least fire an IRQ externally. That adds a VCXO and some
other parts to the board, which isn\'t terrible. Adds a little hardware
in place of a lot of thinking and software; better path to done.

Typically a timer interrupt increments by one. Why not add a semi
constant value to the counter, it is not much slower than INCin a
counter.
Given a periodic interrupt interrupt based on a cheap non-adjustable
clock, evey tick just do

Time = Time + Kcal

where Time and Kcal are both long floats, and Kcal is near 1.00000.

floats might not be the best idea
Why not? It\'s sure easy. Other processes can just use the int part of
TIME.

adding a large and a small float

32bit integer as fractional time, add to that, carry out increments 32 integer time



Floats are really necessary if you need magnitude at the cost of
absolute accuracy.
Adding large and small float should be no issue, FPUs I have used
always convert both operands to large, do the busyness then convert
the result to small if that was asked for.
However if you have an FPU anyway and you know how what you are
doing why not use it, if this can simplify your work or speed up
things or both.

rp2040 doesn\'t have an FPU

Oh I see.
But I won\'t be surprised at all if people are using some FPU emulation
which must come with it simply because \"processing power is cheap,
thinking is expensive\". Justifiable but well, I\'d have a hard time
making myself to follow that path.

 

[John Larkin]

On Sat, 22 Apr 2023 09:49:27 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

lørdag den 22. april 2023 kl. 18.21.54 UTC+2 skrev John Larkin:
On Sat, 22 Apr 2023 08:17:52 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

lørdag den 22. april 2023 kl. 16.26.03 UTC+2 skrev John Larkin:
On Sat, 22 Apr 2023 10:22:09 +0300, upsid...@downunder.com wrote:

On Thu, 20 Apr 2023 07:21:18 -0700, John Larkin
jla...@highlandSNIPMEtechnology.com> wrote:

On Thu, 20 Apr 2023 10:41:37 +0300, upsid...@downunder.com wrote:

On Tue, 18 Apr 2023 14:40:35 -0700, John Larkin

snip

The clock on the Raspberry Pi is a cheap crystal and is not tunable.
It might be interesting to do a DDS sort of thing to make a variable
that is a local calibrated time counter. We could occasionally send
out a packet to declare the time of day, and the little boxes could
both sync to that and tweak their DDS cal factors to stay pretty close
until the next correction. All software.

If the crystal has a reasonable short term stability but the frequency
is seriously inaccurate, some DDS principle can be applied. Assuming
the crystal drives a timer interrupt, say nominally every millisecond
and the ISR updates a nanosecond counter. If it has been determined
that the ISR is activated every 1.001234 milliseconds, the ISR adds
1001234 to the nanosecond counter. Each time when the million changes,
a new millisecond period is declared. Using two or more slightly
different adders and fractional nanoseconds can be counted.

Yes, something like that. On a dual-core 130 MHz ARM, one of the cores
could run a reasonable periodic interrupt at, say, 50 KHz. I\'ve run
non-trivial IRQs on an ARM at 100 KHz with a 70 MHz clock.

The option is to clock the Pico externally, which can probably be
done, or at least fire an IRQ externally. That adds a VCXO and some
other parts to the board, which isn\'t terrible. Adds a little hardware
in place of a lot of thinking and software; better path to done.

Typically a timer interrupt increments by one. Why not add a semi
constant value to the counter, it is not much slower than INCin a
counter.
Given a periodic interrupt interrupt based on a cheap non-adjustable
clock, evey tick just do

Time = Time + Kcal

where Time and Kcal are both long floats, and Kcal is near 1.00000.

floats might not be the best idea
Why not? It\'s sure easy. Other processes can just use the int part of
TIME.

adding a large and a small float

32bit integer as fractional time, add to that, carry out increments 32 integer time

I said that both were long floats, the 8-byte thing.

 

[John Larkin]

On Sat, 22 Apr 2023 10:34:13 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

lørdag den 22. april 2023 kl. 19.26.25 UTC+2 skrev Dimiter_Popoff:
On 4/22/2023 19:49, Lasse Langwadt Christensen wrote:
lørdag den 22. april 2023 kl. 18.21.54 UTC+2 skrev John Larkin:
On Sat, 22 Apr 2023 08:17:52 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

lørdag den 22. april 2023 kl. 16.26.03 UTC+2 skrev John Larkin:
On Sat, 22 Apr 2023 10:22:09 +0300, upsid...@downunder.com wrote:

On Thu, 20 Apr 2023 07:21:18 -0700, John Larkin
jla...@highlandSNIPMEtechnology.com> wrote:

On Thu, 20 Apr 2023 10:41:37 +0300, upsid...@downunder.com wrote:

On Tue, 18 Apr 2023 14:40:35 -0700, John Larkin

snip

The clock on the Raspberry Pi is a cheap crystal and is not tunable.
It might be interesting to do a DDS sort of thing to make a variable
that is a local calibrated time counter. We could occasionally send
out a packet to declare the time of day, and the little boxes could
both sync to that and tweak their DDS cal factors to stay pretty close
until the next correction. All software.

If the crystal has a reasonable short term stability but the frequency
is seriously inaccurate, some DDS principle can be applied. Assuming
the crystal drives a timer interrupt, say nominally every millisecond
and the ISR updates a nanosecond counter. If it has been determined
that the ISR is activated every 1.001234 milliseconds, the ISR adds
1001234 to the nanosecond counter. Each time when the million changes,
a new millisecond period is declared. Using two or more slightly
different adders and fractional nanoseconds can be counted.

Yes, something like that. On a dual-core 130 MHz ARM, one of the cores
could run a reasonable periodic interrupt at, say, 50 KHz. I\'ve run
non-trivial IRQs on an ARM at 100 KHz with a 70 MHz clock.

The option is to clock the Pico externally, which can probably be
done, or at least fire an IRQ externally. That adds a VCXO and some
other parts to the board, which isn\'t terrible. Adds a little hardware
in place of a lot of thinking and software; better path to done.

Typically a timer interrupt increments by one. Why not add a semi
constant value to the counter, it is not much slower than INCin a
counter.
Given a periodic interrupt interrupt based on a cheap non-adjustable
clock, evey tick just do

Time = Time + Kcal

where Time and Kcal are both long floats, and Kcal is near 1.00000.

floats might not be the best idea
Why not? It\'s sure easy. Other processes can just use the int part of
TIME.

adding a large and a small float

32bit integer as fractional time, add to that, carry out increments 32 integer time



Floats are really necessary if you need magnitude at the cost of
absolute accuracy.
Adding large and small float should be no issue, FPUs I have used
always convert both operands to large, do the busyness then convert
the result to small if that was asked for.
However if you have an FPU anyway and you know how what you are
doing why not use it, if this can simplify your work or speed up
things or both.

rp2040 doesn\'t have an FPU

It does have fp math operations in the hard rom, with some hardware
assist. Looks like floating math ops take a few hundred ns.

 

[server]

On Sat, 22 Apr 2023 09:21:36 -0700, John Larkin
<jlarkin@highlandSNIPMEtechnology.com> wrote:

On Sat, 22 Apr 2023 08:17:52 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 22. april 2023 kl. 16.26.03 UTC+2 skrev John Larkin:
On Sat, 22 Apr 2023 10:22:09 +0300, upsid...@downunder.com wrote:

On Thu, 20 Apr 2023 07:21:18 -0700, John Larkin
jla...@highlandSNIPMEtechnology.com> wrote:

On Thu, 20 Apr 2023 10:41:37 +0300, upsid...@downunder.com wrote:

On Tue, 18 Apr 2023 14:40:35 -0700, John Larkin

snip

The clock on the Raspberry Pi is a cheap crystal and is not tunable.
It might be interesting to do a DDS sort of thing to make a variable
that is a local calibrated time counter. We could occasionally send
out a packet to declare the time of day, and the little boxes could
both sync to that and tweak their DDS cal factors to stay pretty close
until the next correction. All software.

If the crystal has a reasonable short term stability but the frequency
is seriously inaccurate, some DDS principle can be applied. Assuming
the crystal drives a timer interrupt, say nominally every millisecond
and the ISR updates a nanosecond counter. If it has been determined
that the ISR is activated every 1.001234 milliseconds, the ISR adds
1001234 to the nanosecond counter. Each time when the million changes,
a new millisecond period is declared. Using two or more slightly
different adders and fractional nanoseconds can be counted.

Yes, something like that. On a dual-core 130 MHz ARM, one of the cores
could run a reasonable periodic interrupt at, say, 50 KHz. I\'ve run
non-trivial IRQs on an ARM at 100 KHz with a 70 MHz clock.

The option is to clock the Pico externally, which can probably be
done, or at least fire an IRQ externally. That adds a VCXO and some
other parts to the board, which isn\'t terrible. Adds a little hardware
in place of a lot of thinking and software; better path to done.

Typically a timer interrupt increments by one. Why not add a semi
constant value to the counter, it is not much slower than INCin a
counter.
Given a periodic interrupt interrupt based on a cheap non-adjustable
clock, evey tick just do

Time = Time + Kcal

where Time and Kcal are both long floats, and Kcal is near 1.00000.

floats might not be the best idea

I would also avoid using floats in ISRs. Just look what exceptions and
faults your intended FP instruction might generate. You just don\'t
want such things to happen in the clock ISR.

If you are using 64 to 128 bit entities (float or integer) better hope
the load and store instructions are atomic.

Why not? It\'s sure easy. Other processes can just use the int part of
TIME.

Taking integer part of a float is a time consuming operation due to
the de-normalization, unless the processor has a proper barrel
shifter.

 

[Martin Brown]

On 22/04/2023 19:05, John Larkin wrote:

On Sat, 22 Apr 2023 09:49:27 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 22. april 2023 kl. 18.21.54 UTC+2 skrev John Larkin:
On Sat, 22 Apr 2023 08:17:52 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

lørdag den 22. april 2023 kl. 16.26.03 UTC+2 skrev John Larkin:
On Sat, 22 Apr 2023 10:22:09 +0300, upsid...@downunder.com wrote:

On Thu, 20 Apr 2023 07:21:18 -0700, John Larkin
jla...@highlandSNIPMEtechnology.com> wrote:

On Thu, 20 Apr 2023 10:41:37 +0300, upsid...@downunder.com wrote:

On Tue, 18 Apr 2023 14:40:35 -0700, John Larkin

snip

The clock on the Raspberry Pi is a cheap crystal and is not tunable.
It might be interesting to do a DDS sort of thing to make a variable
that is a local calibrated time counter. We could occasionally send
out a packet to declare the time of day, and the little boxes could
both sync to that and tweak their DDS cal factors to stay pretty close
until the next correction. All software.

If the crystal has a reasonable short term stability but the frequency
is seriously inaccurate, some DDS principle can be applied. Assuming
the crystal drives a timer interrupt, say nominally every millisecond
and the ISR updates a nanosecond counter. If it has been determined
that the ISR is activated every 1.001234 milliseconds, the ISR adds
1001234 to the nanosecond counter. Each time when the million changes,
a new millisecond period is declared. Using two or more slightly
different adders and fractional nanoseconds can be counted.

Yes, something like that. On a dual-core 130 MHz ARM, one of the cores
could run a reasonable periodic interrupt at, say, 50 KHz. I\'ve run
non-trivial IRQs on an ARM at 100 KHz with a 70 MHz clock.

The option is to clock the Pico externally, which can probably be
done, or at least fire an IRQ externally. That adds a VCXO and some
other parts to the board, which isn\'t terrible. Adds a little hardware
in place of a lot of thinking and software; better path to done.

Typically a timer interrupt increments by one. Why not add a semi
constant value to the counter, it is not much slower than INCin a
counter.
Given a periodic interrupt interrupt based on a cheap non-adjustable
clock, evey tick just do

Time = Time + Kcal

where Time and Kcal are both long floats, and Kcal is near 1.00000.

floats might not be the best idea
Why not? It\'s sure easy. Other processes can just use the int part of
TIME.

\"int()\" is expensive for a number in IEEE FP format unless the FP
hardware has a barrel shifter - it will be glacially slow in an emulator
- slow enough that the computed answer will be out of date!

If you don\'t mind large systematic errors then do it your way!

adding a large and a small float

32bit integer as fractional time, add to that, carry out increments 32 integer time

I said that both were long floats, the 8-byte thing.

It might be marginally faster to have the increment as a 4 byte real
depending on the architecture.

Floating point for this is still a really bad idea even if you do have
hardware assist.

Making them a 32 bit unsigned increment and a 64 bit sum would be a much
more natural choice and then use the high 32 bit integer as the clock.

That still lets you have ~10^9 fine adjustments and integer operations
on most modern CPUs are single cycle. BTW You will be lucky to get
anywhere near 0.1ppm unless you control the temperature of the crystal...

It might be more sensible to accumulate the signed error relative to the
system clock hardware value instead. That overflows much less often.

--
Martin Brown

 

[server]

On Sun, 23 Apr 2023 18:07:59 +0100, Martin Brown
<\'\'\'newspam\'\'\'@nonad.co.uk> wrote:

On 22/04/2023 19:05, John Larkin wrote:
On Sat, 22 Apr 2023 09:49:27 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 22. april 2023 kl. 18.21.54 UTC+2 skrev John Larkin:
On Sat, 22 Apr 2023 08:17:52 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

lørdag den 22. april 2023 kl. 16.26.03 UTC+2 skrev John Larkin:
On Sat, 22 Apr 2023 10:22:09 +0300, upsid...@downunder.com wrote:

On Thu, 20 Apr 2023 07:21:18 -0700, John Larkin
jla...@highlandSNIPMEtechnology.com> wrote:

On Thu, 20 Apr 2023 10:41:37 +0300, upsid...@downunder.com wrote:

On Tue, 18 Apr 2023 14:40:35 -0700, John Larkin

snip

The clock on the Raspberry Pi is a cheap crystal and is not tunable.
It might be interesting to do a DDS sort of thing to make a variable
that is a local calibrated time counter. We could occasionally send
out a packet to declare the time of day, and the little boxes could
both sync to that and tweak their DDS cal factors to stay pretty close
until the next correction. All software.

If the crystal has a reasonable short term stability but the frequency
is seriously inaccurate, some DDS principle can be applied. Assuming
the crystal drives a timer interrupt, say nominally every millisecond
and the ISR updates a nanosecond counter. If it has been determined
that the ISR is activated every 1.001234 milliseconds, the ISR adds
1001234 to the nanosecond counter. Each time when the million changes,
a new millisecond period is declared. Using two or more slightly
different adders and fractional nanoseconds can be counted.

Yes, something like that. On a dual-core 130 MHz ARM, one of the cores
could run a reasonable periodic interrupt at, say, 50 KHz. I\'ve run
non-trivial IRQs on an ARM at 100 KHz with a 70 MHz clock.

The option is to clock the Pico externally, which can probably be
done, or at least fire an IRQ externally. That adds a VCXO and some
other parts to the board, which isn\'t terrible. Adds a little hardware
in place of a lot of thinking and software; better path to done.

Typically a timer interrupt increments by one. Why not add a semi
constant value to the counter, it is not much slower than INCin a
counter.
Given a periodic interrupt interrupt based on a cheap non-adjustable
clock, evey tick just do

Time = Time + Kcal

where Time and Kcal are both long floats, and Kcal is near 1.00000.

floats might not be the best idea
Why not? It\'s sure easy. Other processes can just use the int part of
TIME.

\"int()\" is expensive for a number in IEEE FP format unless the FP
hardware has a barrel shifter - it will be glacially slow in an emulator
- slow enough that the computed answer will be out of date!

Taking the int() is time consuming, since it requires denormalization
(shifting the mantissa by N bits) and remember to add the \"hidden\"
bit. The situation is problematic with simple 8 bit processors, say
6800, 8080 and the likes.

The problem can be improved by first doing the 0, 8, 16, 24,..56 bit
shift by simple byte moves and then do the 1 to 7 bit shift the
traditional way. Even this can be improved if 2-3 suitable byte
resister are available and some shift and masking can be done for any
combinations of 1 to 7 shifts.