I think that the root of your problem here is your handling of pindirs - how you have done it won't work and will be causing all sorts of other problems.
You are using !OSRE (presumably combined with autopull) to detect the ARM having supplied data to transmit. So the OSR is your transmit buffer and may be full or empty. However, you are also using the OSR as temporary workspace for setting the pindirs!
So the particular behaviour you are seeing here is that you do an input cycle, and as part of that you do MOV OSR,NULL to set the pindirs to input, but that MOV has the side-effect of marking the OSR full - hence when you go back to the main loop, !OSRE is immediately satisfied and you start doing an output cycle. But your send side doesn't work either, because you go there with a character to send but before you do anything with it you MOV OSR,!NULL which will overwrite the data you are about to write!
So you need a different scheme. One possibility is to have the ARM supply 16 or 24 bits rather than 8 - so it would write 0x0000nnFF where nn is the byte to write. You can now do OUT PINDIRS,8 (getting that 0xFF), OUT PINS,8 (getting the data) and OUT PINDIRS,8 (getting that 0x00 and resetting the pins ready for input).
Another approach for an 8-bit bus is to set 5 of the pindirs with SET PINDIRS and the other three with side-set. So that lets you change all 8 pindirs in a single instruction, but does mean you can't readily use SET or side-set for anything else. Possibly if you had the pins in the right order you could do 5 pindirs with side-set, 3 pindirs with SET, and have the adjacent two pins for the strobes - but then you can't change the strobes without also affecting the high three data bits.
Or another option is to split the logic between two SMs - maybe one for output (including pindirs), and another for input (including manipulating the strobes). The output SM can watch what the input SM is doing with the strobes to achieve synchronization.
You are using !OSRE (presumably combined with autopull) to detect the ARM having supplied data to transmit. So the OSR is your transmit buffer and may be full or empty. However, you are also using the OSR as temporary workspace for setting the pindirs!
So the particular behaviour you are seeing here is that you do an input cycle, and as part of that you do MOV OSR,NULL to set the pindirs to input, but that MOV has the side-effect of marking the OSR full - hence when you go back to the main loop, !OSRE is immediately satisfied and you start doing an output cycle. But your send side doesn't work either, because you go there with a character to send but before you do anything with it you MOV OSR,!NULL which will overwrite the data you are about to write!
So you need a different scheme. One possibility is to have the ARM supply 16 or 24 bits rather than 8 - so it would write 0x0000nnFF where nn is the byte to write. You can now do OUT PINDIRS,8 (getting that 0xFF), OUT PINS,8 (getting the data) and OUT PINDIRS,8 (getting that 0x00 and resetting the pins ready for input).
Another approach for an 8-bit bus is to set 5 of the pindirs with SET PINDIRS and the other three with side-set. So that lets you change all 8 pindirs in a single instruction, but does mean you can't readily use SET or side-set for anything else. Possibly if you had the pins in the right order you could do 5 pindirs with side-set, 3 pindirs with SET, and have the adjacent two pins for the strobes - but then you can't change the strobes without also affecting the high three data bits.
Or another option is to split the logic between two SMs - maybe one for output (including pindirs), and another for input (including manipulating the strobes). The output SM can watch what the input SM is doing with the strobes to achieve synchronization.
Statistics: Posted by arg001 — Wed Jul 03, 2024 11:23 am