Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 57 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

15455575960160

Comments

  • Cluso99 wrote: »
    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
    



  • Cluso99Cluso99 Posts: 18,066
    edited 2016-06-24 07:40
    ozpropdev wrote: »
    Ray
    Remove the '#' in the line
    		mov	txdata, #rxdata		' do something with rxdata
    

    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.
  • ozpropdevozpropdev Posts: 2,791
    edited 2016-06-24 09:33
    Ray
    Try using a RDPIN instruction to get the 'busy flag' from the transmitter.
    Here's a snippet of code that works OK. :)
    con
    	sys_clk = 80_000_000
    	baudrate = 3_000_000
    	nco_baud = round(float($1_0000) / (float(sys_clk) / float(baudrate)))
    	tx_pin = 62
    
    dat		org
    
    		wrpin	#%1_11110_0,#tx_pin
    		wxpin	##$8000_0000 | nco_baud << 16 | %1_00000 | 7,#tx_pin
    		setb	dira+tx_pin>>5,#tx_pin
    
    wait4key	testb	inb,#63 wc	'wait for key press on PST
    	if_c	jmp	#wait4key
    
    		loc	ptrb,#@message
    		call	#send_msg
    here		jmp	#here
    
    send_msg	rdbyte	adra,ptrb++ wz
    	if_z	ret
    .tx_busy	rdpin	status,#tx_pin wc	'get 'busy flag'
    	if_c	jmp	#.tx_busy
    		wypin	adra,#tx_pin		'send byte
    		jmp	#send_msg
    
    status		res	1
    
    		orgh	$400
    
    message		byte	"Hello world",0
    
    
  • Cluso99Cluso99 Posts: 18,066
    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
    
  • RaymanRayman Posts: 13,797
    edited 2016-06-24 10:51
    Was pinack renamed to akpin? Surely ackpin would be better name, right?
  • 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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2016-06-24 11:17
    Yes, BeMicro CV-A9.
    Interesting that it works fine on P123-A9.
  • ozpropdevozpropdev Posts: 2,791
    edited 2016-06-24 13:00
    Cluso99 wrote: »
    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.



  • Cluso99Cluso99 Posts: 18,066
    ozpropdev wrote: »
    Cluso99 wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2016-06-25 01:52
    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.
  • Cluso99 wrote: »
    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.
    :)
  • RaymanRayman Posts: 13,797
    What is output enable supposed to mean for async serial receive?
    I guess it shouldn't have any effect, right?
  • evanhevanh Posts: 15,126
    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
    
  • cgraceycgracey Posts: 14,133
    Cluso99 wrote: »
    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?
  • cgraceycgracey Posts: 14,133
    edited 2016-06-25 22:30
    ozpropdev wrote: »
    Cluso99 wrote: »
    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.
  • SETPIN, WRPINX, WRPINX, RDPIN

    or...

    PINMODE, PINSETX, PINSETY, PINREAD
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    ozpropdev wrote: »
    Cluso99 wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    Cluso99 wrote: »
    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 :)
  • Cluso99Cluso99 Posts: 18,066
    On another thread I asked about how to set the clock in P2. Here is Chip's reply...
    cgracey wrote: »
    'CLKSET #$FF' sets 80MHz and this is already done when your program starts using PNut.exe.
  • evanhevanh Posts: 15,126
    cgracey wrote: »
    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 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.
  • evanhevanh Posts: 15,126
    Cluso99 wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,066
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-06-26 02:27
    Seairth wrote: »
    SETPIN, WRPINX, WRPINX, RDPIN

    or...

    PINMODE, PINSETX, PINSETY, PINREAD

    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)




  • jmgjmg Posts: 15,140
    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.


  • 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.
  • jmg wrote: »
    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.

  • Cluso99Cluso99 Posts: 18,066
    How about

    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2016-06-26 10:58
    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.
  • evanhevanh Posts: 15,126
    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.
Sign In or Register to comment.