Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: john larkin <JL@gct.com>
Newsgroups: sci.electronics.design
Subject: Re: Grounded grid VHF front-end
Date: Sun, 17 Nov 2024 12:49:08 -0800
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <h0lkjjdc28b50fpo6t4rj7f76s12rpujgn@4ax.com>
References: <1r2rj8l.msi28f14weovyN%liz@poppyrecords.invalid.invalid> <vgpiks$e1ei$1@solani.org> <vgq12n$ao84$2@dont-email.me> <vgq4rj$eagg$1@solani.org> <eld1jjl15hq8ohgm3kifpodkktupt1lr3g@4ax.com> <vgqg85$6t1$1@solani.org> <vhbh7j$26abk$1@paganini.bofh.team> <vhc2ts$9v2r$1@solani.org> <vhcvsg$28q26$1@paganini.bofh.team> <p49kjjpfq4t25in8slsak4moi59rj1pusp@4ax.com> <u9dkjj51rak4jjpdp4g7m22k0fc231bof1@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 17 Nov 2024 21:49:11 +0100 (CET)
Injection-Info: dont-email.me; posting-host="13a4d4f9f694eb36db7f924905a0b768";
	logging-data="873127"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ZZjz7+Zs1AYp0FXMVn90M"
User-Agent: ForteAgent/8.00.32.1272
Cancel-Lock: sha1:trOLxkzxh9th2cZkv97N9IAcoU4=
Bytes: 3254

On Sun, 17 Nov 2024 18:28:45 +0000, JM
<sunaecoNoChoppedPork@gmail.com> wrote:

>On Sun, 17 Nov 2024 09:33:54 -0800, john larkin <JL@gct.com> wrote:
>
>>On Sun, 17 Nov 2024 14:50:58 -0000 (UTC), antispam@fricas.org (Waldek
>>Hebisch) wrote:
>>
>>>USB can do milliseconds, ethernet hundreds of microseconds, small
>>>micros can do much better.  Theoretically with a micro connected via USB
>>>one can synchronize clocks of the micro and PC with microsecond
>>>accuracy, I plan to try this but do not know how this will work.
>>
>>We're designing some products around the RP2040, the Pi Pico
>>processor.
>>
>>Turns out that in some cases, it's easier to bit-bang an SPI interface
>>than program an SPI engine. To fine-tune timings in 7 ns increments,
>>we can use no-op instructions.
>>
>>I wonder what's a safe c-language NOP single-clock operation that no
>>compiler is smart enough to optimize out and doesn't add a bunch of
>>loads and stores.
>>
>>We're experimenting with that sort of timing on an oscilloscope. The
>>GCC or whatever code timing tools don't work in this case.
>>
>>Something like
>>
>>        gpio_put(FIRST_GPIO, 1);
>>        gpio_put(FIRST_GPIO, 0);
>>        gpio_put(FIRST_GPIO, 1);
>>        gpio_put(FIRST_GPIO, 0);
>>
>>Makes the port pin change every 7 ns. That's astounding. So maybe a
>>dummy port bang is my no-op. Just repeat what we just set it to.
>>
>
>Code in assembly.  It's trivial to use assembly code with c in gcc.

A  gpio_put  to an unused port pin would work, but we don't have any
unused port pins.

I suspect that we could clear some internal device register, like in a
timer or something, that we don't use. That would kill a clock or so
and the compiler can't know that we don't use it.

My guy did

gpio up
A = 3+5
gpio down

and of course the add takes zero time. 

A = A+5

does take time, looks like four clocks.