keithI’ve played around a considerable bit from yesterday. There’s something very strange about the speed the PC can react in certain circumstances, and I can’t quite nail it down.
Now I haven’t changed one thing on the PC. The logic is just too simple, and doesn’t need changed.
On the SX side, I wrote (again, I’ve done this before) a real small routine here:
if pcack <> 0 then repeat
inc loopz
RC = loopz
byteready = 1
waitforpin:
if pcack <> 1 then waitforpin
byteready = 0
goto repeat
This basically sends 0x00 – 0xFF to the PC, one byte at a time, and it waits on the PC — but sends it to the PC as fast as it will take it. I hooked up the byteready and pcack leads to my scope, and then measured the time it took for each cycle. The complete cycle took only 4.25+/- us. This is really fast, and I’m happy the PC isn’t choking. Man the SX is so much faster than the PC responding to signals, raising and lowering leads, etc
I also checked to see if the data is received correctly, and its 100% correct…..
I implemented a 16-byte software fifo (circular buffer) into my actual software and it looks like it works as expected. Within only 50 bytes (sometimes a little longer, like 100+), the circular buffer overflows. My data is coming out at a rate of 8 bits every 16us(ie 1 bit every 2us, or 500kbps), so that means that the PC has 16us PER BYTE. And my earlier tests showed that the PC could take a byte every 4.25, almost 1/4 of the time. But the PC chokes in this environment.
This fifo gives my pc 16 times longer to reply — but I don’t see how it needs it — and this *still* isn’t enough. So I went to my earlier code without the fifo, and added “wait” statements which cause the main program to wait for the PC to become ready, and wait for the pc to ACK the byte. I haven’t put a scope on yet to see how much I’m being penalized. I’m betting 4us. Which is a long time, especially because main has other tasks….
My early conclusions point to the fact that PC seems to process/task-switch to other running applications whenever there is no activity for x number of microseconds. So if you are pounding it, it remains active, and your response times are low. Wait 5 or 10 microseconds, and it switches to do something else, and then takes a little bit to come back to service your new request. Just a guess at this point.
Windows NT (including 2000/XP/2003/Vista/7) will not give you the real time that you need consistantly. While you may do well 99% of the time, Windows will often task out and does not garenty that it will return to your task in any less than 3 seconde (though it is usualy less than 200 microseconds), in this time the uarts FIFO will overflow and you will end up with corrupt data, or the FIFO on the SX will overflow and currupt data.
David,
I appreciate the comment, but the post is about six years old. The original attempted design used the parallel port, the new-er design used a microcontroller and serial over usb, and the latest design uses an FPGA and serial over usb.
Thanks
Keith