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.
Reply by Martin Brown●April 23, 20232023-04-23
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
Reply by ●April 22, 20232023-04-22
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.
Reply by John Larkin●April 22, 20232023-04-22
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.
Reply by John Larkin●April 22, 20232023-04-22
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.
Reply by Dimiter_Popoff●April 22, 20232023-04-22
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.
Reply by Lasse Langwadt Christensen●April 22, 20232023-04-22
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
Reply by Dimiter_Popoff●April 22, 20232023-04-22
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.
Reply by Lasse Langwadt Christensen●April 22, 20232023-04-22
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
Reply by John Larkin●April 22, 20232023-04-22
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
Why not? It's sure easy. Other processes can just use the int part of
TIME.