Lasse Langwadt Christensen wrote:> skrev Don:<snip>>> 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 andYou need to generate and interpret signals with nano second timing to use i2c. Here's a power-on code snippet from my App: /* Initialize when power supply conditions are not met: */ nSleep (15000000L); /* Wait 15 ms, 15000000 ns */ iicWrite(0x00); /* RS=Instruction; RW=Write; */ nSleep (40L); /* Wait 40 ns */ iicWrite(0x34); /* E; DB5=Function Set; DB4=8-bit */ nSleep (230L); /* Wait 230 ns */ 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.
any raspberry pi people here?
Started by ●July 18, 2022
Reply by ●July 18, 20222022-07-18
Reply by ●July 18, 20222022-07-18
tirsdag den 19. juli 2022 kl. 03.01.14 UTC+2 skrev Don:> Lasse Langwadt Christensen wrote: > > skrev Don: > <snip> > >> 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 > You need to generate and interpret signals with nano second timing to > use i2c. Here's a power-on code snippet from my App: > > /* Initialize when power supply conditions are not met: */ > nSleep (15000000L); /* Wait 15 ms, 15000000 ns */ > iicWrite(0x00); /* RS=Instruction; RW=Write; */ > nSleep (40L); /* Wait 40 ns */ > iicWrite(0x34); /* E; DB5=Function Set; DB4=8-bit */ > nSleep (230L); /* Wait 230 ns */it doesn't time the input from an external event... and if you changed 40ns to 10ms I suspect it wouldn't change a thing
Reply by ●July 18, 20222022-07-18
On 7/18/2022 6:01 PM, Don wrote:> Lasse Langwadt Christensen wrote: >> skrev Don: > > <snip> > >>> 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 > > You need to generate and interpret signals with nano second timing to > use i2c. Here's a power-on code snippet from my App: > > /* Initialize when power supply conditions are not met: */ > nSleep (15000000L); /* Wait 15 ms, 15000000 ns */ > iicWrite(0x00); /* RS=Instruction; RW=Write; */ > nSleep (40L); /* Wait 40 ns */ > iicWrite(0x34); /* E; DB5=Function Set; DB4=8-bit */ > nSleep (230L); /* Wait 230 ns */I'm not sure you can rely on that giving you "nanosecond resolution". I can specify delays in nanoseconds, but the "clock" that is *bound* to the timer of my choosing determines the ACTUAL resolution; nanosecond() just ensures AT LEAST the specified amount of time (expressed in units of nanoseconds) has elapsed before the ftn returns. (I.e., if the underlying clock runs at 10Hz, then you'll just have a delay that is a multiple of 100ms)
Reply by ●July 18, 20222022-07-18
Lasse Langwadt Christensen wrote:> skrev Don: >> Lasse Langwadt Christensen wrote: >> > skrev Don:>> <snip>>> >> 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 >> You need to generate and interpret signals with nano second timing to >> use i2c. Here's a power-on code snippet from my App: >> >> /* Initialize when power supply conditions are not met: */ >> nSleep (15000000L); /* Wait 15 ms, 15000000 ns */ >> iicWrite(0x00); /* RS=Instruction; RW=Write; */ >> nSleep (40L); /* Wait 40 ns */ >> iicWrite(0x34); /* E; DB5=Function Set; DB4=8-bit */ >> nSleep (230L); /* Wait 230 ns */ > > it doesn't time the input from an external event... > > and if you changed 40ns to 10ms I suspect it wouldn't change a thingThe timing diagram says something different... 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.
Reply by ●July 18, 20222022-07-18
On 7/18/2022 4:45 PM, John Larkin wrote:> 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.The ARM chip almost surely has a high-resolution timer onboard, the stock Linux kernel in e.g. mainstream distros like Ubuntu isn't configured for hard realtime operation but Linux can be: <https://bristot.me/demystifying-the-real-time-linux-latency/> <https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_is_real-time.3F> "Average latencies of a few uS are possible on single-CPU systems" If you need to measure sub uS accurately Linux is probably the wrong tool.
Reply by ●July 18, 20222022-07-18
On 7/18/2022 9:37 PM, bitrex wrote:> On 7/18/2022 4:45 PM, John Larkin wrote: >> 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. > > The ARM chip almost surely has a high-resolution timer onboard, the > stock Linux kernel in e.g. mainstream distros like Ubuntu isn't > configured for hard realtime operation but Linux can be: > > <https://bristot.me/demystifying-the-real-time-linux-latency/> > > <https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_is_real-time.3F> > > > "Average latencies of a few uS are possible on single-CPU systems" > > If you need to measure sub uS accurately Linux is probably the wrong tool. > > >Sub 10s-of-uS, rather
Reply by ●July 18, 20222022-07-18
On 7/18/2022 5:37 PM, 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.The SoC has multiple CPU cores, there have been some experiments running Linux on some of the cores, and doing realtime stuff on another "bare metal": <https://forums.raspberrypi.com/viewtopic.php?t=245561>
Reply by ●July 18, 20222022-07-18
On Tue, 19 Jul 2022 02:26:33 +0300, Dimiter_Popoff <dp@tgi-sci.com> wrote:>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?!)No, I don't want to make anything that flies. The paperwork multiplies the engineering time by 5x at least. But our stuff is used to test things on the ground. , 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" :-) ]. > >We'd be OK timestamping a 32-bit, 1 MHz or so counter. An FPGA could snapshot times coherently.
Reply by ●July 18, 20222022-07-18
On Mon, 18 Jul 2022 14:05:27 -0700 (PDT), John Walliker <jrwalliker@gmail.com> wrote:>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. >JohnWe use a Zynq for serious projects, dual ARM and a heap of FPGA, but they are hard to get so I'm conserving them for big stuff. This little tach thing will be dinky.
Reply by ●July 19, 20222022-07-19
On 7/18/2022 6:37 PM, bitrex wrote:> "Average latencies of a few uS are possible on single-CPU systems" > > If you need to measure sub uS accurately Linux is probably the wrong tool.The trick to (inexpensive) measuring times/intervals is to use the hardware event to trigger (or capture) something that the software can *later* get around to reading. E.g., let it start a (hardware) timer and let the software (IRQ) read the "current time" as well as the time on the triggered timer and use the two to determine the system time at which the trigger event occurred. (Of course, the two timers must be accessed in a single critical region but you can additionally fudge the math based on the work required to compute the difference) There was an era when counter/timers were truly appreciated (e.g., the 9513) as nearly universal peripherals (timing, analog-digital-analog conversion, etc.). Nowadays, timers are becoming less clever (less real estate).
