The code in the Arduino didn't look optimal, so I did a rewrite that is much more satisfying. The code takes an interrupt whenever the SPI inteface completes exchanging a byte. It handles the logic of the frame of 10 bytes, sending out the 8 bytes of inbound signals to the fpga while receiving the 8 bytes that were outbound from the master.
The main loop of the Arduino is thus presented with a steadily refreshed set of signals being exchanged and can operate based on reading and updating those values. For example, by looking at the high order bit of the second outgoing byte, the paper tape reader logic will kick off a cycle of moving the tape one space and send back the value read in the first inbound byte.
The state machine for the paper tape read operation steps through the interlocked protocol - an outbound request for read, an inbound response when done, then the outbound request is dropped and finally the inbound response drops to finish a cycle.
I began testing of the link between the Arduino and fpga, as I hooked up my paper tape reader to be ready for live testing when it was time. I had to make a few adjustments to pin assignments to stay clear of the SPI lines that are hooked to the ztex FPGA board, otherwise it was easy to set up, up until the moment I went looking for one of my Arduino Mega2560 boards. I couldn't find where I had stored them.
I did work on the wiring connections from the PT reader, so that I knew which lines represented the 8 channels to be read, the roller switch that indicates a read cycle in progress, and the ready/not ready indicator. I also had to validate the pick line which would fire the solenoid based clutch and request a cycle. This proceeded with my signal tracer and alligator clips.
Once I debug the logic I should have a paper tape reader operational, accessible from 1130 software, appearing to be a 1054 paper tape reader. That device appears the same as the IBM 1134 reader, the only difference being slower reading speed for the 1054.
My link should also support punching on a paper tape punch as if it were an IBM 1055 unit, however until I finish working on my tape punch device and figuring out the interface, I think the logic in the fpga is correct for this, but haven't written the Arduino functionality that will drive the interface to the unit. Right now, it responds to software but appears to be 'not ready' and thus won't accept punch commands.
The tape reader is driven by a solenoid that engages one cycle of the mechanism, pulling the tape forward by one sprocket hole. During the rotation, the pins rise then fall. If there is a hole in the paper tape for a particular channel, that pin rises up through the hole, whereas any channels which are not punched have their pins blocked. A switch informs the Arduino when the cycle is underway; the controller waits for 2 milliseconds and then senses which pins have risen through holes in the tape. It takes about 85 more milliseconds for the cycle to finish up.
The controller logic in the fpga is triggered by an XIO Control instruction from the 1130, which sets the read tape request bit on the medium SPI link (byte 2 bit 7). When the Arduino side sees this request bit set, it engages the solenoid on the reader and latches in the value of the holes we read. The character read is sent back from Arduino to FPGA on byte 1.
The Arduino also samples the state of the Not Ready microswitch from the reader and reflects that status on byte 2 bit 5 going back to the FPGA. Whenever the reader Not Ready signal is active, the FPGA logic has an all blank character in its buffer, but that gets replaced when the drive goes Ready and then completes an XIO Control operation to read a character. Subsequent XIO Control update the character in the FPGA.
Any time the 1130 issues an XIO Read instruction, it picks up the current character held in the fpga logic - that is blank until we complete an XIO Control. As the tape cycle completes, the Arduino signals this by setting the reader response bit (byte 2 bit 7). The FPGA will trigger an IO interrupt to tell the software that a character is available to be read with XIO Read.
The FPGA drops the read request bit once it sees the response bit come back from the Arduino. To wrap up the operation, the Arduino waits for that request to drop and then clears its response signal. Thus, software issues XIO Control, takes an interrupt when the tape movement finishes, issues an XIO Sense Device to see the reader response bit and clear the interrupt, then issues an XIO Read to move the character into the processor.
The state machine for the paper tape read operation steps through the interlocked protocol - an outbound request for read, an inbound response when done, then the outbound request is dropped and finally the inbound response drops to finish a cycle.
I began testing of the link between the Arduino and fpga, as I hooked up my paper tape reader to be ready for live testing when it was time. I had to make a few adjustments to pin assignments to stay clear of the SPI lines that are hooked to the ztex FPGA board, otherwise it was easy to set up, up until the moment I went looking for one of my Arduino Mega2560 boards. I couldn't find where I had stored them.
I did work on the wiring connections from the PT reader, so that I knew which lines represented the 8 channels to be read, the roller switch that indicates a read cycle in progress, and the ready/not ready indicator. I also had to validate the pick line which would fire the solenoid based clutch and request a cycle. This proceeded with my signal tracer and alligator clips.
Once I debug the logic I should have a paper tape reader operational, accessible from 1130 software, appearing to be a 1054 paper tape reader. That device appears the same as the IBM 1134 reader, the only difference being slower reading speed for the 1054.
My link should also support punching on a paper tape punch as if it were an IBM 1055 unit, however until I finish working on my tape punch device and figuring out the interface, I think the logic in the fpga is correct for this, but haven't written the Arduino functionality that will drive the interface to the unit. Right now, it responds to software but appears to be 'not ready' and thus won't accept punch commands.
The tape reader is driven by a solenoid that engages one cycle of the mechanism, pulling the tape forward by one sprocket hole. During the rotation, the pins rise then fall. If there is a hole in the paper tape for a particular channel, that pin rises up through the hole, whereas any channels which are not punched have their pins blocked. A switch informs the Arduino when the cycle is underway; the controller waits for 2 milliseconds and then senses which pins have risen through holes in the tape. It takes about 85 more milliseconds for the cycle to finish up.
The controller logic in the fpga is triggered by an XIO Control instruction from the 1130, which sets the read tape request bit on the medium SPI link (byte 2 bit 7). When the Arduino side sees this request bit set, it engages the solenoid on the reader and latches in the value of the holes we read. The character read is sent back from Arduino to FPGA on byte 1.
The Arduino also samples the state of the Not Ready microswitch from the reader and reflects that status on byte 2 bit 5 going back to the FPGA. Whenever the reader Not Ready signal is active, the FPGA logic has an all blank character in its buffer, but that gets replaced when the drive goes Ready and then completes an XIO Control operation to read a character. Subsequent XIO Control update the character in the FPGA.
Any time the 1130 issues an XIO Read instruction, it picks up the current character held in the fpga logic - that is blank until we complete an XIO Control. As the tape cycle completes, the Arduino signals this by setting the reader response bit (byte 2 bit 7). The FPGA will trigger an IO interrupt to tell the software that a character is available to be read with XIO Read.
The FPGA drops the read request bit once it sees the response bit come back from the Arduino. To wrap up the operation, the Arduino waits for that request to drop and then clears its response signal. Thus, software issues XIO Control, takes an interrupt when the tape movement finishes, issues an XIO Sense Device to see the reader response bit and clear the interrupt, then issues an XIO Read to move the character into the processor.
No comments:
Post a Comment