On Monday, July 18, 2022 at 3:13:15 PM UTC-4, 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.Not sure why you targeted a RPi. You may want to consider an arduino, it does have a 16bit timer/counter. You may also want to look at the arduin MKR Vidor 4000. It uses the Cortex-M0 32-bit SAMD21 processor that has 5 - 16 bit TC and one 32bit RTC https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwizsqGZjIn5AhViEmIAHaFNCSYQFnoECAwQAw&url=http%3A%2F%2Fww1.microchip.com%2Fdownloads%2Fen%2Fdevicedoc%2F40001884a.pdf&usg=AOvVaw2NAKz5dp_sNt6jgwimyt2S You will probably want to strip away the arduino operating interface to what will work for you. It has onboard a Intel Cyclone® 10CL016. It is 'sort of' integrated with the DAMD21 processor and programming the FPGA is a little awkward, IMHO. I think it is a sweet little board - used it in a couple of projects. Good luck J
any raspberry pi people here?
Started by ●July 18, 2022
Reply by ●July 21, 20222022-07-21
Reply by ●July 24, 20222022-07-24
On 2022-07-18, John Larkin <jlarkin@highland_atwork_technology.com> 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.Raspberry PI is a media player SOC, current models seem to be available only from scalpers.> Do pi's have crystal oscillators? I guess we could add one too.There seems to be a "125", "25" and "54" the 54 seems closest to the SOC, the other two seem closest to the ethernet chip and PCIe to USB3 bridge. You could check the schematic. -- Jasen.
Reply by ●July 24, 20222022-07-24
On 2022-07-19, Don <g@crcomp.net> 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 */Ah right, so not actually "doing" IIC at all. just naively calling "iicWrite()" not even checking the response, just waiting and hoping. I can see how timing could be critical for that. -- Jasen.
Reply by ●July 25, 20222022-07-25
Jasen Betts wrote:> 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 */ > > Ah right, so not actually "doing" IIC at all. just naively calling > "iicWrite()" not even checking the response, just waiting and > hoping. I can see how timing could be critical for that.Ah, you're confused. ;) You naively assume my own iicwrite() is the same as a unix write(). My iicWrite() merely changes the state of combinational logic for presentation to the target as part a single, larger, I2C write message. It only changes the data sent down the SDA at precise (in some case ns) times, per the target's protocol. My /code snippet/ shows only /a part/ of a single message from the RPi2 controller to a target. With I2C you must wait until the /whole/ message is delivered before "checking." 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 25, 20222022-07-25
On a sunny day (Mon, 25 Jul 2022 03:42:49 -0000 (UTC)) it happened "Don" <g@crcomp.net> wrote in <20220724b@crcomp.net>:>Jasen Betts wrote: >> 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 */ >> >> Ah right, so not actually "doing" IIC at all. just naively calling >> "iicWrite()" not even checking the response, just waiting and >> hoping. I can see how timing could be critical for that. > >Ah, you're confused. ;) You naively assume my own iicwrite() is the same >as a unix write(). > My iicWrite() merely changes the state of combinational logic for >presentation to the target as part a single, larger, I2C write message. >It only changes the data sent down the SDA at precise (in some case >ns) times, per the target's protocol. > My /code snippet/ shows only /a part/ of a single message from the >RPi2 controller to a target. With I2C you must wait until the /whole/ >message is delivered before "checking."I2C is a not-time critical protocol, that is why you can use it on a multitasking system where it is interrupted on a regular basis. I wrote my own i2c routines years ago and have used those on PIs many times see my website download link for code. No nano-nano stuff needed anywhere, usleep is fine..>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 25, 20222022-07-25
Jan Panteltje wrote:>>> Don Wrote:<snip>>>>> 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 */<snip>> I2C is a not-time critical protocol, > that is why you can use it on a multitasking system > where it is interrupted on a regular basis. > I wrote my own i2c routines years ago and have used those on PIs many times > see my website download link for code. > No nano-nano stuff needed anywhere, usleep is fine.."Brevity is the soul of wit" and "I2C is a not-time critical protocol" says it all, doesn't it? Here's the "Write Mode Timing Diagram" for the target of interest, my RPi2's target for this thread: https://crcomp.net/iic44780/timing2.png The third line down on the first table shows the "E Rise/Fall Time" Characteristic, tR. And tR's Max. is specified as 25 nS. Upon further reflection, it's clearly outside of my control. Ergo, the RPi2 itself must accomplish the rise time within spec. Beings I2C doesn't qualify, another RPi2 to test for nsleep() must be devised. Stand by. And, it turns out my homegrown iicWrite() actually does test for an error condition: void iicWrite(char iicByte) { rdwr.msgs[0].buf[1] = iicByte; if (ioctl(fd, I2CRDWR, &rdwr) < 0) { perror("ioctl"); snprintf(errMessage, sizeof(errMessage), "ioctl: error %d sending write", errno); errorExit(); } } 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 25, 20222022-07-25
On 2022-07-25, Don <g@crcomp.net> wrote:> Jasen Betts wrote: >> 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 */ >> >> Ah right, so not actually "doing" IIC at all. just naively calling >> "iicWrite()" not even checking the response, just waiting and >> hoping. I can see how timing could be critical for that. > > Ah, you're confused. ;) You naively assume my own iicwrite() is the same > as a unix write().It's fairly clear that iicwrite take an integer (probably byte) parameter. I didn't miss that. You know what I'm thinking about as well as you understand IIC. You should check for an ack bit after every byte sent, and I'm not seeing evidence of that above. If you're having rate problems it's also possible you're not watching the clk line. -- Jasen.
Reply by ●July 25, 20222022-07-25
Jasen Betts wrote:> Don wrote: >> Jasen Betts wrote: >>> 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 */ >>> >>> Ah right, so not actually "doing" IIC at all. just naively calling >>> "iicWrite()" not even checking the response, just waiting and >>> hoping. I can see how timing could be critical for that. >> >> Ah, you're confused. ;) You naively assume my own iicwrite() is the same >> as a unix write(). > > It's fairly clear that iicwrite take an integer (probably byte) > parameter. I didn't miss that. > > You know what I'm thinking about as well as you understand IIC. > You should check for an ack bit after every byte sent, and I'm not > seeing evidence of that above.My apologies to you and the others who tried to get your point through my thick head. Jan's a polyglot. He's a superb communicator. And it finally sunk in. Now, let's talk about the ack bit you mention. You correctly note how my code does not look for it. You can blame it on this profoundly lazy guy within me. He reasons, "Why not let a PCF8574A take care of all of the I2C ack housekeeping for you?" And, presto, the PCF8574A simplifies error checks: void iicWrite(char iicByte) { rdwr.msgs[0].buf[1] = iicByte; if (ioctl(fd, I2CRDWR, &rdwr) < 0) { perror("ioctl"); snprintf(errMessage, sizeof(errMessage), "ioctl: error %d sending write", errno); errorExit(); } } In the end, it's very poor communication on my part to lazily copy-and- paste a "code snippet" into my followup. My plan is to ultimately write- up my RPi BSD version of Jan's OLED code and publish it to my website. 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 30, 20222022-07-30
In article <ilhbdhp4i6lcl486j5u3gijh9a7mbrej9c@4ax.com>, John Larkin <xx@yy.com> 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. > > >>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.The Raspberry pi 1 has a 64 bit counter offset 0x9100 in the Virtual Memory IO Space This is the Forth code, fetching a double precision number of the addres : TICKS ^clk 2@ ; This seems to be more reliable of the counters in the Intel. It is running at 1 Mhz. Others pi's (Orange pi) have similar counters.> >Some torque sensors make tricky timing waveforms. >Groetjes Albert -- "in our communism country Viet Nam, people are forced to be alive and in the western country like US, people are free to die from Covid 19 lol" duc ha albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Reply by ●July 30, 20222022-07-30
albert@cherry.(none) (albert) wrote in news:nnd$224d213a$6ed2eb7a@d7dff6696c7ccdd2:> In article <ilhbdhp4i6lcl486j5u3gijh9a7mbrej9c@4ax.com>, > John Larkin <xx@yy.com> 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. >> >> >>>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. > > The Raspberry pi 1 has a 64 bit counter offset 0x9100 in the > Virtual Memory IO Space > This is the Forth code, fetching a double precision number > of the addres > >: TICKS ^clk 2@ ; > > This seems to be more reliable of the counters in the Intel. > It is running at 1 Mhz. > Others pi's (Orange pi) have similar counters. > >> >>Some torque sensors make tricky timing waveforms. >> > > Groetjes AlbertCheck out the new pico W rPi... <https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-iot- platform/>
