I have struck a problem getting smart serial to work.
Send works fine, but receive doesn't seem to be receiving anything. I am using PST connected to the propplug.
Can anyone see my bug?
BTW I have discovered that if you don't transmit a character, then the instruction
.send testb inb, #tx_pin wc 'wait for buffer empty on tx pin
doesn't return buffer empty. Can anyone verify please?
Yes, when you first set the mode and haven't transmitted anything yet that's what it will do.
TF2# 0 PIN 115,200 TXD ok
TF2# 0 PIN@ . 0 ok
TF2# $55 TX ok
TF2# 0 PIN@ . -1 ok
Brian,
The transmitter is working fine. I can output a series of characters without problems, except that you must output something first before checking for busy.
However, I cannot get the receiver to work at all. The testb inb,#rx_pin wc never returns c=1 for a data char received.
This is the subset receive part that does not work for me.
wrpin pm_rx, #rx_pin 'set asynchronous rx mode in smart pin rx
wxpin bitper, #rx_pin 'set rx bit period
setb dirb, #rx_pin 'enable smart pin rx
.recv testb inb, #rx_pin wc 'wait for smart pin rx to signal rx data received
if_nc jmp #.recv '''#.send ' ping-pong tx/rx
akpin #rx_pin 'acknowledge rx pin
rdpin rxdata, #rx_pin 'get data from rx pin
mov txdata, rxdata ' do something with rxdata
jmp #.recv '''#.send 'loop
pm_tx long %0000_0000_000_0000000000000_01_11110_0 'async tx mode, output enabled for smart output
pm_rx long %0000_0000_000_0000000000000_01_11111_0 'async rx mode, output enabled for smart input
Ray
Your code as posted earlier with the '#' fix works fine on my P123-A9 board.
Your code Rx's key press from PST OK and Tx's back OK.
Your running a BeMicro CV-A9 right?
@Ray
Can you confirm that pin #63 is a smartpin?
Maybe try a pulse count mode.
The Pnut loader is bit-banged so maybe it's a standard pin on the CV-A9 build.
Yes, BeMicro CV-A9.
Interesting that it works fine on P123-A9.
Ok I was able replicate the fault on my BeMicro-A2 board.
pm_rx long %0000_0000_000_0000000000000_01_11111_0 'async rx mode, output enabled for smart input
change to
pm_rx long %0000_0000_000_0000000000000_00_11111_0 'async rx mode, output enabled for smart input
Both variants work on P123-A9 but the later only on the A2 board.
Rx pin is being driven as output.
Yes, BeMicro CV-A9.
Interesting that it works fine on P123-A9.
Ok I was able replicate the fault on my BeMicro-A2 board.
pm_rx long %0000_0000_000_0000000000000_01_11111_0 'async rx mode, output enabled for smart input
change to
pm_rx long %0000_0000_000_0000000000000_00_11111_0 'async rx mode, output enabled for smart input
Both variants work on P123-A9 but the later only on the A2 board.
Rx pin is being driven as output.
Thanks Brian. Will try this in the morning if I have time before we go out.
I will have to check out the TT options again.
Thanks Brian, problem solved
Curious why it worked on P123-A9 though.
Next step is to checkout the internal fifo/stack depth, and what happens when you overflow.
No worries Ray.
I suspect that the FTDI device (FT231x IIRC) on the P123-A9 board can override the FPGA pin whereas the FTDI device on the Propplug cannot.
The output enable is a general Smartpins config rather than specifically serial. Also, those two TT bits apply to the physical pin while the Smartpin input may well be pulling it's serial data from a neighbouring pin.
On that note a more verbose way of labelling such constants might be in order, not sure what can be done though ... say
pm_rx long %0000\ 'immediate pin for input A
_0000\ 'immediate pin for input B
_000\ 'A and B direct logic
_0000000000000\ 'immediate pin is plain logic
_00\ 'immediate pin control is input
_11111_0 'async rx mode
Chip,
Here are a couple of instruction opcode swaps that may make the decoding more efficient, and the compilers simpler, and instruction set look more regular.
These just make the first set of instruction opcodes 0xxxxxx identically formatted.
You might not want to change anything. If you are interested, there are a few changes in the 1xxxxxx that may make sense too.
BTW I posted the whole instruction set summary a few posts back.
-------------------------------------------------------------------------------------------------------------------------
Cond Opcode CZ I Dest Source Instr00 01 10 11 Operand(s) Flags
-------------------------------------------------------------------------------------------------------------------------
CCCC 0111000 ff I DDDDDDDDD SSSSSSSSS ALTI ALTR ALTD ALTS D,S/# -- -- -- --
CCCC 0111001 CZ I DDDDDDDDD SSSSSSSSS DECOD D,S/# CZ
CCCC 011101f CZ I DDDDDDDDD SSSSSSSSS TOPONE BOTONE D,S/# CZ CZ
CCCC 011110f CZ I DDDDDDDDD SSSSSSSSS INCMOD DECMOD D,S/# CZ CZ
CCCC 011111f fZ I DDDDDDDDD SSSSSSSSS MUL MULS SCLU SCL D,S/# -Z -Z -Z -Z
replace with
CCCC 01110ff CZ I DDDDDDDDD SSSSSSSSS TOPONE BOTONE INCMOD DECMOD D,S/# CZ CZ CZ CZ
CCCC 01111ff CZ I DDDDDDDDD SSSSSSSSS TESTN TEST ANYB TESTB D,S/# CZ CZ CZ CZ
-------------------------------------------------------------------------------------------------------------------------
CCCC 10100ff CZ I DDDDDDDDD SSSSSSSSS TESTN TEST ANYB TESTB D,S/# CZ CZ CZ CZ
replace with
CCCC 1010000 ff I DDDDDDDDD SSSSSSSSS ALTI ALTR ALTD ALTS D,S/# -- -- -- --
CCCC 1010001 CZ I DDDDDDDDD SSSSSSSSS DECOD D,S/# CZ
CCCC 101001f fZ I DDDDDDDDD SSSSSSSSS MUL MULS SCLU SCL D,S/# -Z -Z -Z -Z
-------------------------------------------------------------------------------------------------------------------------
I have been looking at the smart pins for async.
WRPIN sets the mode, WXPIN sets the baud/length.
WYPIN writes the data byte/word/long, RDPIN reads the data byte/word/long.
This seems wrong to me. I would think WRPIN & RDPIN should write/read the data, while WXPIN & WYPIN should set the mode & baud/length.
Have I got this the correct way around???
BTW
WRPIN used to be PINSETM
and RDPIN used to be PINGETZ
I agree that these names are not, yet, optimal, given the way users are likely to view them. The problem is that under different modes, X and Y serve different purposes. There is one 'M' register and an 'X' and 'Y' that need writing. There's a 'Z' that needs to be read for result.
Maybe this would be a little better:
WMPIN - write Mode
WXPIN - write X
WYPIN - write Y
RZPIN - read Z
That's still not good enough. Does anyone want to make some suggestions? Sorry, I know this has been changed a lot, already. It just doesn't feel right, yet.
I have been looking at the smart pins for async.
WRPIN sets the mode, WXPIN sets the baud/length.
WYPIN writes the data byte/word/long, RDPIN reads the data byte/word/long.
This seems wrong to me. I would think WRPIN & RDPIN should write/read the data, while WXPIN & WYPIN should set the mode & baud/length.
Have I got this the correct way around???
BTW
WRPIN used to be PINSETM
and RDPIN used to be PINGETZ
I agree that these names are not, yet, optimal, given the way users are likely to view them. The problem is that under different modes, X and Y serve different purposes. There is one 'M' register and an 'X' and 'Y' that need writing. There's a 'Z' that needs to be read for result.
Maybe this would be a little better:
WMPIN - write Mode
WXPIN - write X
WYPIN - write Y
RZPIN - read Z
That's still not good enough. Does anyone want to make some suggestions? Sorry, I know this has been changed a lot, already. It just doesn't feel right, yet.
Guess we need to look at all the uses of these functions first and then see what the pattern is. In the async mode, the data is always read from the Z register. Here, as it is the single read register, RDPIN makes the most sense, as you have done. When you write data (to Y), to me WRPIN makes the most sense, and there are two sets of parameters M & X, so perhaps WMPIN (M=mode) and WPPIN (P=parameters).
But lets have a good look at the other cases first to avoid too many changes.
Chip,
Here are a couple of instruction opcode swaps that may make the decoding more efficient, and the compilers simpler, and instruction set look more regular.
These just make the first set of instruction opcodes 0xxxxxx identically formatted.
You might not want to change anything. If you are interested, there are a few changes in the 1xxxxxx that may make sense too.
BTW I posted the whole instruction set summary a few posts back.
-------------------------------------------------------------------------------------------------------------------------
Cond Opcode CZ I Dest Source Instr00 01 10 11 Operand(s) Flags
-------------------------------------------------------------------------------------------------------------------------
CCCC 0111000 ff I DDDDDDDDD SSSSSSSSS ALTI ALTR ALTD ALTS D,S/# -- -- -- --
CCCC 0111001 CZ I DDDDDDDDD SSSSSSSSS DECOD D,S/# CZ
CCCC 011101f CZ I DDDDDDDDD SSSSSSSSS TOPONE BOTONE D,S/# CZ CZ
CCCC 011110f CZ I DDDDDDDDD SSSSSSSSS INCMOD DECMOD D,S/# CZ CZ
CCCC 011111f fZ I DDDDDDDDD SSSSSSSSS MUL MULS SCLU SCL D,S/# -Z -Z -Z -Z
replace with
CCCC 01110ff CZ I DDDDDDDDD SSSSSSSSS TOPONE BOTONE INCMOD DECMOD D,S/# CZ CZ CZ CZ
CCCC 01111ff CZ I DDDDDDDDD SSSSSSSSS TESTN TEST ANYB TESTB D,S/# CZ CZ CZ CZ
-------------------------------------------------------------------------------------------------------------------------
CCCC 10100ff CZ I DDDDDDDDD SSSSSSSSS TESTN TEST ANYB TESTB D,S/# CZ CZ CZ CZ
replace with
CCCC 1010000 ff I DDDDDDDDD SSSSSSSSS ALTI ALTR ALTD ALTS D,S/# -- -- -- --
CCCC 1010001 CZ I DDDDDDDDD SSSSSSSSS DECOD D,S/# CZ
CCCC 101001f fZ I DDDDDDDDD SSSSSSSSS MUL MULS SCLU SCL D,S/# -Z -Z -Z -Z
-------------------------------------------------------------------------------------------------------------------------
Cluso, I agree. What else would you do?
Thanks Chip. I will mark up the other suggestions over the next day or two - family commitments and P2 testing to do
WMPIN - write Mode
WXPIN - write X
WYPIN - write Y
RZPIN - read Z
That's still not good enough. Does anyone want to make some suggestions? Sorry, I know this has been changed a lot, already. It just doesn't feel right, yet.
I like that arrangement. It certainly looks tidy and they are distinct from other mnemonics which I believe was one of the earlier criteria. They do what the mnemonic says and no more.
Guess we need to look at all the uses of these functions first and then see what the pattern is. In the async mode, the data is always read from the Z register. Here, as it is the single read register, RDPIN makes the most sense, as you have done. When you write data (to Y), to me WRPIN makes the most sense, and there are two sets of parameters M & X, so perhaps WMPIN (M=mode) and WPPIN (P=parameters).
I guess the registers could be called M P Q R respectively.
To me, the read and write data registers should be RDPIN and WRPIN (or PINRD and PINWR). The other configure registers should be xxPIN (or PINxx) for consistency.
Having said this, the other modes do need to be checked for consistency, and I haven't had time to check the docs yet. I think it's just mnemonics changes only, so it's less urgent.
I'm glad you guys are thinking about this because it would be nice to have them clearly labeled, it leads to far less confusion when writing and reading assembly, that's for sure. So I like the SETPIN words but perhaps SETPIN WRPIN RDPIN for most uses and then the second write register as WRXPIN (baud settings etc) with perhaps an alias of WRYPIN for WRPIN which I know in the case of serial transmit is the data register. Just a quick thought but I will look into actual uses and see if I can offer better solutions.
SETPIN - Set the modes
WRPIN - write data
RDPIN - read data
WRXPIN - write eXtra data (maybe just plain WXPIN)
Actually, I liked them so much that I coded all my high level equivalents as SETPIN RDPIN WRPIN WXPIN and now it is a lot clearer to read and remember.
SETPIN - Set the modes
WRPIN - write data
RDPIN - read data
WRXPIN - write eXtra data (maybe just plain WXPIN)
Sounds ok, if there is some rare case where these do not fit, it is always possible to alias the opcode.
I threw together a summary of the register use in all smartpin modes. (Needs checking )
Peter's suggested names seem to fit with WYPIN becoming WRPIN, WRPIN becoming SETPIN and WXPIN can stay as it is.
Seems we all like something with "PIN" as prefix or suffix. WR and RD also seems to be coming through for the data write/read.
So we need something for the M (mode) and X (parameters) opcodes.
Just finished verifying the internal stack. It is a depth of 8.
As you push more onto the stack, the bottom one will drop off when full.
As you pop off the stack, the bottom value moves up one and the new bottom value is the same as it was previously. ie once you empty the stack, the last legitimate value popped will continue to be delivered on underflow.
I needed to verify this behaviour as I am building some hubexec routines where I want to use the internal stack but I do not know what depth is available for use. So I can now save the stack (to hub???), and restore it when I am finished.
Ah, thanks to Oz, I just noticed the ADC operations are mixed in with the DAC operations. There appears to be three identical ADC modes overlaid on the three DAC modes. Is this correct?
Next question: Is RDPIN word length defined by mode register or is there something in the instruction itself? I'm not seeing anything obvious.
I'm thinking a faster 8-bit ADC mode would be a nice addition. One of those three modes could be an 8-bitter.
Comments
Yes, when you first set the mode and haven't transmitted anything yet that's what it will do.
Thanks but that wasn't it. I previously had this and forgot to remove the"#"
mov txdata, #"-" 'rxdata ' do something with rxdata
I am just not seeing the inb flag being set. So I figure I have something amiss with the initial receive setup.
Try using a RDPIN instruction to get the 'busy flag' from the transmitter.
Here's a snippet of code that works OK.
The transmitter is working fine. I can output a series of characters without problems, except that you must output something first before checking for busy.
However, I cannot get the receiver to work at all. The testb inb,#rx_pin wc never returns c=1 for a data char received.
This is the subset receive part that does not work for me.
Your code as posted earlier with the '#' fix works fine on my P123-A9 board.
Your code Rx's key press from PST OK and Tx's back OK.
Your running a BeMicro CV-A9 right?
Can you confirm that pin #63 is a smartpin?
Maybe try a pulse count mode.
The Pnut loader is bit-banged so maybe it's a standard pin on the CV-A9 build.
Interesting that it works fine on P123-A9.
Rx pin is being driven as output.
I will have to check out the TT options again.
Curious why it worked on P123-A9 though.
Next step is to checkout the internal fifo/stack depth, and what happens when you overflow.
I suspect that the FTDI device (FT231x IIRC) on the P123-A9 board can override the FPGA pin whereas the FTDI device on the Propplug cannot.
I guess it shouldn't have any effect, right?
On that note a more verbose way of labelling such constants might be in order, not sure what can be done though ... say
Cluso, I agree. What else would you do?
I agree that these names are not, yet, optimal, given the way users are likely to view them. The problem is that under different modes, X and Y serve different purposes. There is one 'M' register and an 'X' and 'Y' that need writing. There's a 'Z' that needs to be read for result.
Maybe this would be a little better:
WMPIN - write Mode
WXPIN - write X
WYPIN - write Y
RZPIN - read Z
That's still not good enough. Does anyone want to make some suggestions? Sorry, I know this has been changed a lot, already. It just doesn't feel right, yet.
or...
PINMODE, PINSETX, PINSETY, PINREAD
Guess we need to look at all the uses of these functions first and then see what the pattern is. In the async mode, the data is always read from the Z register. Here, as it is the single read register, RDPIN makes the most sense, as you have done. When you write data (to Y), to me WRPIN makes the most sense, and there are two sets of parameters M & X, so perhaps WMPIN (M=mode) and WPPIN (P=parameters).
But lets have a good look at the other cases first to avoid too many changes.
Thanks Chip. I will mark up the other suggestions over the next day or two - family commitments and P2 testing to do
I like that arrangement. It certainly looks tidy and they are distinct from other mnemonics which I believe was one of the earlier criteria. They do what the mnemonic says and no more.
Having said this, the other modes do need to be checked for consistency, and I haven't had time to check the docs yet. I think it's just mnemonics changes only, so it's less urgent.
I'm glad you guys are thinking about this because it would be nice to have them clearly labeled, it leads to far less confusion when writing and reading assembly, that's for sure. So I like the SETPIN words but perhaps SETPIN WRPIN RDPIN for most uses and then the second write register as WRXPIN (baud settings etc) with perhaps an alias of WRYPIN for WRPIN which I know in the case of serial transmit is the data register. Just a quick thought but I will look into actual uses and see if I can offer better solutions.
SETPIN - Set the modes
WRPIN - write data
RDPIN - read data
WRXPIN - write eXtra data (maybe just plain WXPIN)
Sounds ok, if there is some rare case where these do not fit, it is always possible to alias the opcode.
I threw together a summary of the register use in all smartpin modes. (Needs checking
Peter's suggested names seem to fit with WYPIN becoming WRPIN, WRPIN becoming SETPIN and WXPIN can stay as it is.
SETPIN (mode)
SETXPIN (extra params)
WRPIN (write data) previously WYPIN
RDPIN (read data)
or
PINMODE (mode)
PINXPAR (extra params) (or PINSETX or PINxxxx - other suggestions please)
PINWR (write data) previously WYPIN
PINRD (read data)
Seems we all like something with "PIN" as prefix or suffix. WR and RD also seems to be coming through for the data write/read.
So we need something for the M (mode) and X (parameters) opcodes.
As you push more onto the stack, the bottom one will drop off when full.
As you pop off the stack, the bottom value moves up one and the new bottom value is the same as it was previously. ie once you empty the stack, the last legitimate value popped will continue to be delivered on underflow.
I needed to verify this behaviour as I am building some hubexec routines where I want to use the internal stack but I do not know what depth is available for use. So I can now save the stack (to hub???), and restore it when I am finished.
Next question: Is RDPIN word length defined by mode register or is there something in the instruction itself? I'm not seeing anything obvious.
I'm thinking a faster 8-bit ADC mode would be a nice addition. One of those three modes could be an 8-bitter.