PI Zero IEC Device

[rje]

I've thought about this very generally, and figured that to a large degree, data can be buffered in RAM on the storage device until transmission is done.  Since the X16's RAM footprint is small, a Pi buffer might remove any potential flash lag.

***

Quote

A multi-tasking multi-user operating system such as Linux is not suitable for this task.

^ Given.

So I wrote a simple one-wire noiseless no-ack ("SOWNONO") protocol between two Pi Zeros, in C, using WiringPi, on Raspbian.  It looks like I can get a whopping 500 bits per second. 

In theory, then, plain old C with wiringPi and no ACK can get me 62 bytes per second.  No optimizations, no special nothing, and of course once they go out of sync it's disaster.

But it was fun to write and is a start.

***

I think if I revisit my simple talker, I'll define a frame and add an ACK.  I've seen a Michael Steil video where communication can slowly drift out of sync over dozens of bits...

But I'm also thinking about using my Arduinos -- I've got a Nano and a Mega 2560.

[TomXP411]

On 4/11/2022 at 12:51 PM, rje said:

I think if I revisit my simple talker, I'll define a frame and add an ACK.  I've seen a Michael Steil video where communication can slowly drift out of sync over dozens of bits...

That's why single-wire-per-direction protocols like RS-232 have a start and stop bit. The longer duration acts as a sync marker to keep the two UARTS lined up. 

I'm still inclined to do something SPI over the User port. The Pi does hardware SPI just fine, and the only limiting factor there should be how fast we can bit-bang the port on the Commander side. (Which should be pretty fast if we have a bit shifter available.)

[rje]

On 4/11/2022 at 7:04 PM, TomXP411 said:

The Pi does hardware SPI just fine, and the only limiting factor there should be how fast we can bit-bang the port on the Commander side. (Which should be pretty fast if we have a bit shifter available.)

Ok, that sounds useful.  I've done I2C but not SPI, so I'll start reading.

There's also the UART (pins 8 and 10 / GPIO 14 and 15).

 

[BruceMcF]

On 4/11/2022 at 8:04 PM, TomXP411 said:

That's why single-wire-per-direction protocols like RS-232 have a start and stop bit. The longer duration acts as a sync marker to keep the two UARTS lined up. 



I'm still inclined to do something SPI over the User port. The Pi does hardware SPI just fine, and the only limiting factor there should be how fast we can bit-bang the port on the Commander side. (Which should be pretty fast if we have a bit shifter available.)

If we have access to the serial shift register lines, it can be used as MISO. If PB0 is used as the master SCLK, connected through to the serial shift register clock line so it can clock the input in, PB1 as MOSI, and PB2 to however high you want to allocate as SPI_SELECT, you can:



SPI_LSB:

   LDX #7

   LDA UPORT_PB

   ORA #%00000001

   AND #%11111101

   TAY

-   TYA

   LSR DATA

   BCC +

   ORA #%00000010

+  STA UPORT_PB

   DEC UPORT_PB

   INC UPORT_PB

   DEX

   BPL -

... with the MISO byte available in the Serial Shift Register data register when the process is finished, and with an accelerated loop when MOSI is "don't care", which can therefore be #0:



   LDX #7

   LDA PORTB

   ORA #%00000001

   AND #%11111101

-  STA UPORT_PB

   DEC UPORT_PB

   INC UPORT_PB

   DEX

   BPL -