Commander X16

53 minutes ago, ZeroByte said:

Ah - that's what I get for just reading the latest post and not going back to the beginning and catching up.

7 hours ago, TomXP411 said:

So news on my latest experiment:



My latest experiment involved driving and sensing the Raspberry Pi’s GPIO pins with the PIGPIO library. This seems to work very well at relatively low data rates, but I have run into an interesting flaw: the nanosleep() and gpiosleep() functions seem to have a minimum execution time that’s far longer than the microsecond range suggested by the documentation. So, in effect, I can’t get more than something like 2000 cycles a second through the GPIO interface. 



So one thing I tried doing is removing the sleep statements out of the transmitter and simply using good old fashioned FOR loops to slow down the transmitter code. I discovered that the receiving code starts dropping packets once I get to the point where I’m sending 64K in less than 2-3 seconds.



For my next test, I plan to introduce a handshaking pin to let the receiver affirmatively acknowledge a packet. This will change the data flow and turn the two devices into equal peers, rather than client/server. In this case, the data flow would look like:



Sender switches Data and CLK pins to write mode. 

Sender sets data on D0-D7, Sender sets CLK high. 

Receiver reads D0-D7 and sets ACK high. 

Sender lowers CLK

Receiver lowers ACK

Sender switches all pins to read mode. 



In this mode, there would be no ready to send/clear to send (ie: buffer state) lines. Instead, either device on the bus would simply raise the CLK line to send a packet. 



This would also mean we could support multiple devices on the bus. That would probably involve an additional ADR pin, so we’d have the following pins on the bus:

D0-D7 - data or command being transmitted

CLK - tells receiver to read the data bits

ACK - tells transmitter the data has been read

ADR - select a specific receiver

CMD - a command is being send to the receiver



 

• 
  System sets data on D0-D7,
  


• 
  System sets CLK high (CMD/ADR both low). 
  


• 
  Current Device reads D0-D7 and sets ACK high. 
  


• 
  System lowers CLK
  


• 
  Device lowers ACK
  

• 
  Device sets data on D0-D7
  


• 
  Device sets ACK high. 
  


• 
  System reads D0-D7
  


• 
  System sets CLK high. 
  


• 
  Device lowers ACK
  


• 
  System lowers CLK
  

• 
  System sets D0-D7 to write
  


• 
  System sets command on D0-D7
  


• 
  System sets CMD, CLK high. 
  


• 
  Current Device reads D0-D7 and sets ACK high. 
  


• 
  {If CMD is a read command, System sets D0-D7 to read}
  


• 
  System lowers CLK and CMD
  


• 
  Device lowers ACK
  

• 
  System sets D0-D7 to write
  


• 
  System sets command on D0-D7
  


• 
  System sets ADR, CLK high. 
  


• 
  All devices read D0-D7
  


• 
  Selected Device sets ACK high. 
  


• 
  System lowers CLK and ADR
  


• 
  Device lowers ACK
  

5 hours ago, TomXP411 said:

Yeah, I've already poked several holes in the design, including collisions and stalled reads. I'm back to needing 14 pins, so if I'm going to do this with a Pi, I need to find pins other than 16-23 that are free.



Pin 24 seems to always be a 1 and pins 0-15 seem to also have data on them. However, I haven't looked that closely at the bit pattern on the low pins, I just saw a number like Cxxx and so shifted my data up by 16 bits to transmit in the high word. 



Either way, if I can't get 14 pins out of the Pi, I'm going to give up on that idea and look at something else.



 

4 hours ago, BruceMcF said:

I think using swapping the roles of CLK/ACK when reading from the device and using commands to sort out whether the device is reading or writing as in the four state version I sketched should avoid collisions and also allow breaking out of stalled reads and does it with the same 12 lines you specified ... I had a DATA control line when I started writing it, but it turned out to be redundant. If there is a 13th pin available, I would make it a DVERR pin input into the User Port.



IOW, using a two line handshake but keeping it client/server so that the command from the client dictates whether the following byte or packet is read or written, so the command makes a separate Data-Direction line redundant.

15 hours ago, TomXP411 said:

That makes for a chatty protocol, though. It also increases the number of times I have to switch the port between reading and writing. If I have a “data waiting” line, I don’t need to issue a command to check the buffer. I just read the state of one pin. If I want to read a byte from the buffer, I just set the Read pin high and raise the clock. One of the original design goals was to prevent unneeded chatter, and removing those lines adds a lot of chatter I’d rather avoid. 

1 hour ago, BruceMcF said:

It IS a protocol the is more efficient for packet transfers then for byte at a time transfers, but I'm not so sure how high a priority is for byte at a time transfers. If one packet is 128 bytes, your original protocol would have required changing the data ports R/W and flipping polarity of the CLK/ACK port twice for every byte of a write. Flipping polarity of CLK/ACK requires a read of the Port B data direction register, and AND #n and an ORA #m and a write to the Port B data direction register, so it's more expensive than flipping the read/write of PortA