On 4/20/2023 12:41 AM, upsidedown@downunder.com wrote:> The problem is that if an other big frame has been started to be > transmitted when the "GO" frame is received, the previous frame is > transmitted fully before the GO packet. Things get catastrophic, if 9 > Kbyte Jumbo frames are allowed on the network.Note that there may be *more* than one such frame competing for access to *a* particular port (where "a" is any port that you're trying to "notify"). Because it's *not* a physically shared medium ("switched fabric"), it is possible that every other device on the switch (or with access to the switch) can choose to send datagrams to that port simultaneously. No collisions involved as each port operates simultaneously with all others. But, as only one packet can be emitted on the (any) port at a given time, these other datagrams are queued *in* the switch to be transmitted to the device on that port when time permits. *Your* packet gets thrown in as the switch deems appropriate. Damn near all COTS products "chatter" even when idle (network discovery, keepalives, DHCP lease renewals, NTP, routing protocols, name resolution, syslogd, etc.). So, you can't predict when someone else's device will decide that it wants to send datagrams. Or, their nature (size, frequency, etc.). Windows machines tend to have oodles of services running that each feel free to use the wire as *they* desire. (note that every application can avail itself of the network services -- to check for updates, other identical licenses elsewhere in the enterprise, etc.). Always amusing to look at the number of open ports and wonder "why?"... With something as ubiquitous as a PC, the traffic is likewise more generalized (e.g., you didn't see idle chatter on HPIB networks).> IIRC the maximum IP frame size can be limited to 576 bytes, this > reducing the maximum Ethernet frame size from 1500 to under 600 bytes.But only by constraining all clients anywhere on the fabric to such a restriction. And, requiring your customers to know how to do this and do so reliably, for all devices. [If ethernet users were so savvy, we wouldn't have duplex problems, wouldn't need autonegotiation ports, MDIX, etc. "It *looks* like an ethernet cable... what else is there to know?? This one is BLUE!"]
triggering things with ethernet
Started by ●April 17, 2023
Reply by ●April 20, 20232023-04-20
Reply by ●April 20, 20232023-04-20
On Thu, 20 Apr 2023 10:41:37 +0300, upsidedown@downunder.com wrote:>On Tue, 18 Apr 2023 14:40:35 -0700, John Larkin ><jlarkin@highlandSNIPMEtechnology.com> wrote: > >>On Tue, 18 Apr 2023 16:42:19 -0400, Joe Gwinn <joegwinn@comcast.net> >>wrote: >> >>>On Mon, 17 Apr 2023 19:26:22 -0700, John Larkin >>><jlarkin@highlandSNIPMEtechnology.com> wrote: >>> >>>>On Mon, 17 Apr 2023 21:38:52 -0400, Joe Gwinn <joegwinn@comcast.net> >>>>wrote: >>>> >>>>>On Mon, 17 Apr 2023 17:49:33 -0700, John Larkin >>>>><jlarkin@highlandSNIPMEtechnology.com> wrote: > > >>>The modern equivalent of a "hub" is an "unmanaged switch". They are >>>just that, but are internally buffered. If one chooses a >>>gigabit-capable unit, the latency will be quite small. For instance, >>>consider a NETGEAR 5-Port Multi-Gigabit (2.5G) Ethernet Unmanaged >>>Switch: >>> >>>.<https://www.downloads.netgear.com/files/GDC/MS105/MS105_DS.pdf> >>> >>>The datasheet specifies the latency for 64-byte packets as less than >>>2.5 microseconds. Again, this ought to suffice. Web price from >>>Netgear is $150. Slower units are cheaper, with increased buffering >>>latency. > > >The 64 byte minimum Ethernet frame size is from the 10Base5 vampire >tap Ethernet so that collisions could be reliably detected. > >>That's encouraging. Thanks. >> >>I like the idea of the switch forwarding the packet in microseconds, >>before it's actually over. >> >>A short UDP packet should get through fast. > >The problem is that if an other big frame has been started to be >transmitted when the "GO" frame is received, the previous frame is >transmitted fully before the GO packet. Things get catastrophic, if 9 >Kbyte Jumbo frames are allowed on the network.I can tell my users: don't do that.> >IIRC the maximum IP frame size can be limited to 576 bytes, this >reducing the maximum Ethernet frame size from 1500 to under 600 bytes. > ><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.> >Of course using a binary counter with say 0x8000 for no frequency >error would simplify things.
Reply by ●April 20, 20232023-04-20
On 18/04/2023 22:40, John Larkin wrote:> 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.Depending on the frequency that you want to generate and the jitter that you can tolerate you can sometimes get away with calibrating local slave system clock ticks per reference second (or 10 seconds) in each unit. Assuming here that you do have a good reference frequency available in the master. I have used a free running loop counter in some entirely software driven low power clock devices to allow fractional corrections every 1,2,4,8, 16 times around the loop so that you can adjust phase by one CPU cycle every 16. Actually it had a once per day fiddle in the same vein. You only need to be able to trim out about +/- 50ppm or so (often less). It worked well enough that I never bothered to temperature compensate it since the lab environment was so always so close to 20C. -- Martin Brown
Reply by ●April 22, 20232023-04-22
On Thu, 20 Apr 2023 07:21:18 -0700, John Larkin <jlarkin@highlandSNIPMEtechnology.com> wrote:>On Thu, 20 Apr 2023 10:41:37 +0300, upsidedown@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. Windows has a 63 bit time counter which counts 100 ns time steps, which is updated by the clock interrupt only 100 times a second, by adding a number close to 100 000 at each interrupt.This addend number can be adjusted with system calls, making implementing the NTP client easy.> > >> >>Of course using a binary counter with say 0x8000 for no frequency >>error would simplify things.Using two addend vales N and N+1 and applying each in every other clock interrupt, the jitter can be further reduced.
Reply by ●April 22, 20232023-04-22
On Sat, 22 Apr 2023 10:22:09 +0300, upsidedown@downunder.com wrote:>On Thu, 20 Apr 2023 07:21:18 -0700, John Larkin ><jlarkin@highlandSNIPMEtechnology.com> wrote: > >>On Thu, 20 Apr 2023 10:41:37 +0300, upsidedown@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. This is basically a DDS concept. The progression of Time can now be tuned to parts-per-trillion at production calibration, and tweaked later on if some external correction is available. The actual interrupt rate could be trimmed in a similar manner if some hardware counter-timer is available with enough bits, maybe in an FPGA. Hybrid tricks are possible. If the interrupt rate is high, one could also just skip the occasional IRQ to get the apparent rate exact. Nobody will notice.> >Windows has a 63 bit time counter which counts 100 ns time steps, >which is updated by the clock interrupt only 100 times a second, by >adding a number close to 100 000 at each interrupt.This addend number >can be adjusted with system calls, making implementing the NTP client >easy.Same idea.>> >> >>> >>>Of course using a binary counter with say 0x8000 for no frequency >>>error would simplify things. > >Using two addend vales N and N+1 and applying each in every other >clock interrupt, the jitter can be further reduced.
Reply by ●April 22, 20232023-04-22
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
Reply by ●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 ideaWhy not? It's sure easy. Other processes can just use the int part of TIME.
Reply by ●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 ●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 ●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
