I haven’t spent much time within the last few days on the project. Looking at the data on the PC, I think that there are still some problems. I think the problems lie in the fact that the interface to the parallel port that I’m using is too slow. Or I should say that the WAY in which I’m reading the port is slow. I need to change some things around. This timing diagram shows what it looks like when it IS working. Top line is the acknowledgement pin from the PC which tells the SX it has received the byte. Here’s the data flow and how it relates to what you see:
When the SX receives 8 bits worth of data, it raises pin 10 (bottom trace). The PC is waiting on pin 10, when it sees it going high, it reads the byte and then raises pin 1(top trace). SX waits for pin 1 to go high, and drops pin 10 whenever that happens. The PC then drops pin 1, and waits on pin 10 again.
The total cycle takes about 11-12us, the breakdown is
8.25us for the PC to grab the byte(store it to the harddrive, right now anyways) and raise pin 1
2.10us for the SX to realize pin 1 is raised and drop pin 10
1us for the PC to realize 10 has dropped and to lower pin 1
The SX is fairly unrelenting with the speed — and there is no advanced logic. If the PC takes longer than 15-16us in any one case, the data just gets plain corrupted. I think that in worst case scenarios this is happening. I see these diagrams get goofy — and I’m not sure exactly why yet.
I didn’t want to get into complicated flow-control issues, but I might not have a choice. I’m think I’m going to set up a simple software FIFO on the SX — like perhaps 16 bytes. This should be plenty and should handle situations when the PC isn’t ready to received. This will be a mandatory ACK situation before the next byte comes — this is different than how it is now. Right now I didn’t want the SX to block waiting on an ACK……