> On Feb 2, 2025, at 3:23 PM, Jonathan Stone via cctalk <[email protected]>
> wrote:
>
>
> On Sunday, February 2, 2025 at 11:47:24 AM PST, Steve Lewis via cctalk
> <[email protected]> wrote:
>
>
>> [...] "bit banging" (imo) is the
>> host system doing the work of producing the start/stop bits on its own.
>> Which seems to be a "lost art" and why I've wondered if anyone has tried
>> bit-banging on a modern-day 3GHz system - but bit-bang onto what?
>
> CAN bus (low-speed, subset, like CANhack); GPIB; I^C hardware that was
> designed before the Philips(?) patents expired.
>
> I know there are controllers for SPI that eliminate the need for bit-banging,
> and message-layer CAN controllers; but some people still do low-speed
> bit-banging implementations, or subset implementations. IMHO hardware
> controllers are so cheap that bit-banging doesn't make sense, given
> development time, and that it consumes a dedicated CPU core while sending or
> receiving.
Bit banging also works if you have devices that specialize in it. A nice
example is the Programmable I/O (PIO) engines in the Raspberry Pico
microcontroller.
I did a DDCMP implementation with those, including the "integral modem"
feature. That includes clock recovery and demodulation of the FM signal, at
speeds up to 10 Mb/s or so though of course no DEC DDCMP device ever ran nearly
that fast. It looks like it could also do 10 Mb/s Ethernet directly (handling
AUI waveforms in software) -- I haven't tried that but I might just for fun.
It would also be an easy way to do the 10 bit UART and 19 bit USRT needed to
drive a PLATO terminal.
I also used this machinery to drive a software-defined radio chip from
Harris/Intersil, on a board I originally designed for EPP mode parallel printer
port interfacing. It has a 16 bit serial port that just runs continously, and
the PIO handles that nicely. Similar but different is the bit-serial interface
you'll find on audio DAC devices, that too would be a very simple case.
As for SPI, the standard driver for the CYW43439 WiFi chip on the Pico uses PIO
to deal with the not quite standard SPI used by that device. Or at least the
mismatch in expectations.
SPI is only barely standardized and it suffers very badly from the Dave Clark
effect ("so many standards to choose from"). For example, the ENC28J60
Ethernet MAC chip has a SPI interface that does multi-byte transfers with the
CS signal asserted for the entire time, while the "mode 0" SPI standard
apparently says it's dropped in between every byte. One solution is to ignore
the built-in SPI blocks and use the PIO; another is to use the standard SPI
block but override the CS pin in software so it remains asserted even though
the SPI block dropped the assert. Ugh.
This sort of bit banging design is very effective as well as cost-effective,
considering that a Pico sells for $4 (quantity one, a whole module -- the chip
alone is under a dollar if I remember right).
paul
