<p><span class="h-card" translate="no"><a href="https://notnow.dev/users/zhuowei" class="u-url mention">@<span>zhuowei</span></a></span> wouldn&#39;t it get chunked?</p>

in hindsight, sending 8KB on a USB ep0 endpoint with a bMaxPacketSize0 of 64 bytes was a terrible idea

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Yes.</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> at least that&#39;s not as cursed as eSPI with the weird non-byte-sized fields in some message types...</p>

<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> you could also do it SD/eSPI-style: return all-ones while not ready</p>

<p>SPI plus an extra IO for flow control would work but of course now it&#39;s a 5 wire bus competing with 2. So difficult to justify the pin cost in most cases</p>

<p>I&#39;m getting increasingly fed up with making SPI peripherals in software because you have unnecessarily tight hard realtime constraints to make the protocol work (if you don&#39;t respond within the set time the other side reads garbage).</p><p>In gateware you can easily enforce cycle accurate timing and on the host side the timing isn&#39;t critical.</p>

<p>Thinking about switching my supervisor MCUs to use i2c instead of spi for interfacing to the main CPU.</p><p>Rationale: uses two less pins, can be combined with sensors and other system health stuff on 3v3_sb power domain, simpler code with no hard realtime constraints since you can clock stretch if the other side isn&#39;t ready, and it doesn&#39;t need to be fast at all.</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> oh god. forbidden ARM fanfiction</p>