Commander X16

Some thoughts on X16 <-> RPi communication

• 
  As far as I can tell, the X16 Kernal is bit banging the I2C protocol. I do not know what speed we are to except.
  


• 
  Furthermore, I assume from skimming over the X16 Kernal source code that it will only work in I2C master mode
  


• 
  Making the RPi act as an I2C slave might not be straightforward, but there seems to be a hardware supported slave mode
  


• 
  I found this discussion thread on using the RPi as a slave
  
  
  
  • 
    Link: https://raspberrypi.stackexchange.com/questions/76109/raspberry-as-an-i2c-slave
    
  
  
  • 
    According to this, you must use GPIO 18 and 19 in slave mode (not the same pins as in master mode)
    
  
  
  • 
    My old RPi (actually the first version ever launched) does not expose those two pins.
    
  
  
  • 
    I need to buy a newer RPi. I have ordered a RPi zero W, which I understand has both GPIO 18 and 19 linked to the header.
    
  
  
  
  

If anyone of you have practical experience on how to set up an RPi as an I2C slave, please share.

If it's possible to make this work, that opens a lot of possibilities beyond printing:

• 
  You could get access to the Internet over the RPi (even over WiFi)
  


• 
  You could use the RPi to store files (may not be very interesting, an SD card holds a lot of data)
  


• 
  You could communicate with other USB devices than printers
  

My plan is to build a test rig with an Arduino as I2C master and RPi Zero W as slave. The Arduino has good I2C support and is mostly using 5V levels as the X16, so I can test that the voltage level converters I have at home are good (fast) enough for this application.

I've made some small progress.

I have managed to setup a Raspberry Pi Zero W as I2C slave and a Ardunio Uno as I2C master:

• 
  Electrical connections
  
  
  
  • 
    The Arduino is powered by USB
    
  
  
  • 
    The RPi is powered from the Arduino 5V pin to RPi pin 2 (5V)
    
  
  
  • 
    The Arduino ground is connected to RPi pin 6 (GND), ensuring a common ground
    
  
  
  • 
    I have a voltage level converter (5V/3.3V). This is driven by the 5V and 3.3 V outputs of the Arduino.
    
  
  
  • 
    Arduino pin A4 (SDA) is connected to the voltage level converter 5V side. The low voltage side is connected to RPi pin 12 (GPIO 18)
    
  
  
  • 
    Arduino pin A5 (CLC) is connected to the voltage level converter 5V side. The low voltage side is connected to RPi pin 35 (GPIO 19)
    
  
  
  
  


• 
  The Arduino runs a program that sends the text "Hello world" once every second to I2C slave address 4
  


• 
  The RPi runs a loop that listens on that slave address and prints incoming text to the terminal
  

 

Arduino code

 

RPi code

The code I used on the RPi is basically identical to the example/instruction published here: https://raspberrypi.stackexchange.com/questions/76109/raspberry-as-an-i2c-slave

 

Attached is a short video showing this contraption running. Not Ben Eater quality, I'm afraid ? But hopefully you get the idea.

As I now might have the basis for a transport layer over I2C I'm thinking about a communication protocol.

So far this is what I have in mind.

X16 to RPi requests

• 
  The first data byte sent would select a command to be executed on the RPi
  


• 
  The rest of the data sent would be command specific
  


• 
  A command that invokes the Linux program lp to print a file could be formatted as follows:
  
  
  
  • 
    A null terminated string containing the command line params to be given lp
    
  
  
  • 
    Then the content to be printed as a stream of characters/bytes
    
  
  
  
  


• 
  A command that invokes curl to fetch a web resource could contain the following:
  
  
  
  • 
    A null terminated string containing the params to curl
    
  
  
  
  

RPi to X16 responses

• 
  Reading from the RPi would always return the response of the last command. 
  


• 
  The response could be formatted as follows:
  
  
  
  • 
    One byte: Response code (interpretation command specific)
    
  
  
  • 
    Three bytes: Length of response stream (three bytes addresses more than a fully expanded X16)
    
  
  
  • 
    The actual response stream
    
  
  
  
  

Please let me know if you see problems or better ways of doing this.

Keeping up the spirit, I just finished a RPi Zero W "hat" that can be used to connect to the X16 over I2C.

It was less than 2 € for 5 pcs + postage, so I also ordered the part.

This would work with my port multiplexor idea.... 

Although now that I'm back to the drawing board, I'm probably going to go with "Plan B", which is a more standard serial interface, with some extra control wires to select which device on the multiplexer is active: make pin 1 active, and the Pi is talking to the console. make pin 2 active, and it's talking to a network device. Pin 3 for serial port 1, and so on....