any raspberry pi people here?...

[Joe Gwinn]

On Mon, 18 Jul 2022 13:55:37 -0700, John Larkin
<jlarkin@highland_atwork_technology.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.

Well, we seem to have only two options, a RaspberryPi or an ARM, one
being too small and the other being too large.

But there is actually a third option that falls between these two
options in size, a Microchip AVR microcontroller. Programmed in a
dialect of Ansi C, with code in a flash memory and loaded on startup.

..<https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/avr-mcus>

Joe Gwinn

 

[Lasse Langwadt Christensen]

tirsdag den 19. juli 2022 kl. 22.29.11 UTC+2 skrev John Larkin:

On Tue, 19 Jul 2022 10:50:49 -0700 (PDT), John Walliker
jrwal...@gmail.com> wrote:

On Tuesday, 19 July 2022 at 17:08:53 UTC+1, lang...@fonz.dk wrote:
tirsdag den 19. juli 2022 kl. 17.04.13 UTC+2 skrev jla...@highlandsniptechnology.com:
On Tue, 19 Jul 2022 09:10:41 -0400, Phil Hobbs
pcdhSpamM...@electrooptical.net> wrote:

jla...@highlandsniptechnology.com wrote:
On Mon, 18 Jul 2022 14:05:27 -0700 (PDT), John Walliker
jrwal...@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.
John

We 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.


Well, you probably have a lot of MC68332s still in stock. They\'re
pretty nice for timing stuff, if you don\'t mind using external memory.

Cheers

Phil Hobbs

(Whose first embedded design used a 68332, but never got built)
68332 has been around for decades and is still available. It\'s a
wonderful chip. It has 16 TPU timer channels that could do what I
want. But it\'s big and expensive, and doesn\'t have USB or ethernet.
if USB will do almost any MCU with USB will do

https://www.digikey.dk/da/products/detail/raspberry-pi/SC0914-13/14306010
https://www.digikey.dk/da/products/detail/winbond-electronics/W25Q16JVSNIQ/6193768

plenty in stock

or if feeling lazy, https://www.waveshare.com/product/raspberry-pi-pico.htm?sku=19310

Yes, it really is worth looking closely at the RP2040 or the pico board. It is probably
massive overkill for what you want to do, but at a cost of 1USD for the chip and 4USD
for the assembled pico board it hardly matters.
Digikey and Mouser between them have over 166000 chips in stock and around
33000 pico boards. In the UK Farnell and RS between them have about another
517000 RP2040 chips in stock.
There is also a version of the pico with WiFi, but you probably don\'t need that.
I am planning to use an RP2040 for a multi-phase switched mode isolated power
supply.

John
Pico doesn\'t have ethernet. I\'d like that.

https://www.digikey.dk/da/products/detail/wiznet/W5100S-EVB-PICO/15516855

 

[Lasse Langwadt Christensen]

tirsdag den 19. juli 2022 kl. 23.22.28 UTC+2 skrev Joe Gwinn:

On Mon, 18 Jul 2022 13:55:37 -0700, John Larkin
jlarkin@highland_atwork_technology.com> wrote:

On Mon, 18 Jul 2022 22:23:21 +0300, Dimiter_Popoff <d...@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.

Well, we seem to have only two options, a RaspberryPi or an ARM, one
being too small and the other being too large.

But there is actually a third option that falls between these two
options in size, a Microchip AVR microcontroller. Programmed in a
dialect of Ansi C, with code in a flash memory and loaded on startup.

.<https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/avr-mcus

in what world does an ancient 8 bit AVR fall between RaspberryPi and ARM* ?

*raspberry pi is also ARM, it is just a Cortex-A CPU, the smaller MCUs are Cortex-M

 

[Joe Gwinn]

On Tue, 19 Jul 2022 14:29:58 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

tirsdag den 19. juli 2022 kl. 23.22.28 UTC+2 skrev Joe Gwinn:
On Mon, 18 Jul 2022 13:55:37 -0700, John Larkin
jlarkin@highland_atwork_technology.com> wrote:

On Mon, 18 Jul 2022 22:23:21 +0300, Dimiter_Popoff <d...@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.

Well, we seem to have only two options, a RaspberryPi or an ARM, one
being too small and the other being too large.

But there is actually a third option that falls between these two
options in size, a Microchip AVR microcontroller. Programmed in a
dialect of Ansi C, with code in a flash memory and loaded on startup.

.<https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/avr-mcus

in what world does an ancient 8 bit AVR fall between RaspberryPi and ARM* ?

*raspberry pi is also ARM, it is just a Cortex-A CPU, the smaller MCUs are Cortex-M

Far more I/O stuff, and timers et al.


Joe Gwinn

 

[Clifford Heath]

On 19/7/22 07:37, John Larkin wrote:

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.

If you aren\'t a determined patriot, there are some impressively
inexpensive ARMs readily available from Chinese vendors like GigaDevice
and WCH now:

<https://www.gigadevice.com/products/microcontrollers/gd32/>
<http://www.wch-ic.com/products/categories/66.html?pid=5>

 

[Don Y]

On 7/19/2022 3:18 PM, Joe Gwinn wrote:

On Tue, 19 Jul 2022 14:29:58 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

tirsdag den 19. juli 2022 kl. 23.22.28 UTC+2 skrev Joe Gwinn:
On Mon, 18 Jul 2022 13:55:37 -0700, John Larkin
jlarkin@highland_atwork_technology.com> wrote:

On Mon, 18 Jul 2022 22:23:21 +0300, Dimiter_Popoff <d...@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.

Well, we seem to have only two options, a RaspberryPi or an ARM, one
being too small and the other being too large.

But there is actually a third option that falls between these two
options in size, a Microchip AVR microcontroller. Programmed in a
dialect of Ansi C, with code in a flash memory and loaded on startup.

.<https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/avr-mcus

in what world does an ancient 8 bit AVR fall between RaspberryPi and ARM* ?

*raspberry pi is also ARM, it is just a Cortex-A CPU, the smaller MCUs are Cortex-M

Far more I/O stuff, and timers et al.

The ARM A-family (A=Application) are intended to host more sophisticated
environments; primarily made possible by support for VMM.

The M-family (and R-family) -- along with the AVRs, et al. -- are intended
more for control/mechanisms applications without support for more advanced
*operating* system features.

Of course, (ARM) licensees can choose to package whatever I/Os they deem
appropriate with any family offering. So, once *could* have an I/O-rich
A-series processor but you can\'t (?) have VMM bolted onto an M/R series
device (nor the AVRs).

 

[David Eather]

Just been biking in the heatwave here, code orange well only 31 C,
wintercoat and hat on.. its cooler on the bike (airflow) than standing still in the sun!

31 degrees? We call that \"summer\"

 

[Lasse Langwadt Christensen]

onsdag den 20. juli 2022 kl. 00.18.53 UTC+2 skrev Joe Gwinn:

On Tue, 19 Jul 2022 14:29:58 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

tirsdag den 19. juli 2022 kl. 23.22.28 UTC+2 skrev Joe Gwinn:
On Mon, 18 Jul 2022 13:55:37 -0700, John Larkin
jlarkin@highland_atwork_technology.com> wrote:

On Mon, 18 Jul 2022 22:23:21 +0300, Dimiter_Popoff <d...@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.

Well, we seem to have only two options, a RaspberryPi or an ARM, one
being too small and the other being too large.

But there is actually a third option that falls between these two
options in size, a Microchip AVR microcontroller. Programmed in a
dialect of Ansi C, with code in a flash memory and loaded on startup.

.<https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/avr-mcus

in what world does an ancient 8 bit AVR fall between RaspberryPi and ARM* ?

*raspberry pi is also ARM, it is just a Cortex-A CPU, the smaller MCUs are Cortex-M
Far more I/O stuff, and timers et al.

most if not all cortex-m have far more horsepower,memory,timers, and IO than an AVR

 

[John Walliker]

On Tuesday, 19 July 2022 at 23:18:53 UTC+1, Joe Gwinn wrote:

On Tue, 19 Jul 2022 14:29:58 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

tirsdag den 19. juli 2022 kl. 23.22.28 UTC+2 skrev Joe Gwinn:
On Mon, 18 Jul 2022 13:55:37 -0700, John Larkin
jlarkin@highland_atwork_technology.com> wrote:

On Mon, 18 Jul 2022 22:23:21 +0300, Dimiter_Popoff <d...@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.

Well, we seem to have only two options, a RaspberryPi or an ARM, one
being too small and the other being too large.

But there is actually a third option that falls between these two
options in size, a Microchip AVR microcontroller. Programmed in a
dialect of Ansi C, with code in a flash memory and loaded on startup.

.<https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/avr-mcus

in what world does an ancient 8 bit AVR fall between RaspberryPi and ARM* ?

*raspberry pi is also ARM, it is just a Cortex-A CPU, the smaller MCUs are Cortex-M
Far more I/O stuff, and timers et al.


Joe Gwinn

One interesting thing I noticed about the new AVR series (AVR-DA, AVR-DB, AVR-DD)
is that the maximum clock speed dependency on power supply voltage has gone.
They have an on-chip power supply regulator and work from 1.8 to 5.5V
at a maximum of 24MHz at all voltages in that range.
They are being promoted for safety critical applications and have some
hardware features to support that together with a certified toolchain.
A very simple architecture can have advantages in such domains. It does look
as if Microchip have taken the AVR range and enhanced it in some very useful
ways that could make these devices a good choice for a new design.
John

 

[Joe Gwinn]

On Wed, 20 Jul 2022 00:32:25 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

onsdag den 20. juli 2022 kl. 00.18.53 UTC+2 skrev Joe Gwinn:
On Tue, 19 Jul 2022 14:29:58 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

tirsdag den 19. juli 2022 kl. 23.22.28 UTC+2 skrev Joe Gwinn:
On Mon, 18 Jul 2022 13:55:37 -0700, John Larkin
jlarkin@highland_atwork_technology.com> wrote:

On Mon, 18 Jul 2022 22:23:21 +0300, Dimiter_Popoff <d...@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.

Well, we seem to have only two options, a RaspberryPi or an ARM, one
being too small and the other being too large.

But there is actually a third option that falls between these two
options in size, a Microchip AVR microcontroller. Programmed in a
dialect of Ansi C, with code in a flash memory and loaded on startup.

.<https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/avr-mcus

in what world does an ancient 8 bit AVR fall between RaspberryPi and ARM* ?

*raspberry pi is also ARM, it is just a Cortex-A CPU, the smaller MCUs are Cortex-M
Far more I/O stuff, and timers et al.


most if not all cortex-m have far more horsepower,memory,timers, and IO than an AVR

Yes, most likely. My point being that we were bouncing between the
guard-rails (too big, too small), and needed to widen our ken.

If I recall, the AVR does not need any VHDL or external FPGAs.

Joe Gwinn

 

[Three Jeeps]

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

 

[Jasen Betts]

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.

 

[Jasen Betts]

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.

 

[Don]

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.

 

[Jan Panteltje]

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.

 

[Don]

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.

 

[Jasen Betts]

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.

 

[Don]

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.

 

[none]

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

 

[server]

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 Albert

Check out the new pico W rPi...

<https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-iot-
platform/>