smart pin question - serial

I am able to use serial fullduplex with smart pin use.

But I need to do something I think should be possible I just do not really understand the documentation.

I do have one COG running using 2 smart pins for fullduplex serial. And I need another COG running fullduplex serial talking to the first one.

The simple solution is to use 2 other smartpins and connect tx/rx and vice versa with some secure resistor.

But do I need to? Shouldn't I be able to take the pins next to them and access them internal?

I feel quite helpless on what to change to use not the pin itself but its neighbor so I can run txMode on say pin 51 in one COG and rxMode on pin 52 in another but using pin 51 as input.

Help!

Mike
I am just another Code Monkey.
A determined coder can write COBOL programs in any language. -- Author unknown.
Press any key to continue, any other key to quit

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.

Comments

  • Each pin is a "one smartpin" independent of the cogs so therefore if it is configured as serial transmit, you cannot have it configured as serial receive just because you are using another cog. Each cog does have its own output and direction registers but that is only for "dumbpin" mode.

    btw, this is super easy to test in TAQOZ.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest Tachyon includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • ozpropdevozpropdev Posts: 2,565
    edited 2019-01-17 - 01:15:53
    Use the input selector control of the smart pin for the rx pins to look at the tx pins of each cog.
    something like this
    	wrpin	##%0111 << 28 | %11111_0,#rx_pin
    
    This should read the data from rx_pin-1
    Melbourne, Australia
  • Mike,
    That is a little hard to understand what you are wanting! The answer is that the maximum pin-range that a smartpin can "see" is +-3 pins.

    So, it is possible to setup another pair of rx/tx pins, as close neighbours, without requiring physically looping between them outside the chip.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Each pin is a "one smartpin" independent of the cogs so therefore if it is configured as serial transmit, you cannot have it configured as serial receive just because you are using another cog. Each cog does have its own output and direction registers but that is only for "dumbpin" mode.

    btw, this is super easy to test in TAQOZ.

    Yes I do understand that. so I want to use the pin next to it from the other COG, but using the other pin as input, as far as I understand smartpins can use other pins in range of +-2(3?)

    I just don't understand how to set this up
      _txmode       = %0000_0000_000_0000000000000_01_11110_0 'async tx mode, output enabled for smart output
      _rxmode       = %0000_0000_000_0000000000000_00_11111_0 'async rx mode, input  enabled for smart input
      bitperiod := 7 + ((CLKFREQ / baudrate) << 16)
    ...
        wrpin txmode, txpin
        wxpin bitperiod, txpin
        dirh  txpin
        wrpin rxmode, rxpin
        wxpin bitperiod, rxpin
        dirh  rxpin
    ...
    

    this works fine and I can use 4 pins to communicate, no problem. But I need to wire a bridge between two pairs.

    if my txpin- smartpin could use the pin next to it (txpin+1) I would not need to wire anything, even if still using 4 pins.

    question better explained?

    Mike


    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Relevant config bits are the %AAAA_BBBB_FFF bit-fields.
    D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0
    
    %AAAA:   ‘A’ input selector
    	0xxx = true (default)
    	1xxx = inverted
    	x000 = this pin’s read state (default)
    	x001 = relative +1 pin’s read state
    	x010 = relative +2 pin’s read state
    	x011 = relative +3 pin’s read state
    	x100 = this pin’s OUT bit from cogs
    	x101 = relative -3 pin’s read state
    	x110 = relative -2 pin’s read state
    	x111 = relative -1 pin’s read state
    
    %BBBB:   ‘B’ input selector
    	0xxx = true (default)
    	1xxx = inverted
    	x000 = this pin’s read state (default)
    	x001 = relative +1 pin’s read state
    	x010 = relative +2 pin’s read state
    	x011 = relative +3 pin’s read state
    	x100 = this pin’s OUT bit from cogs
    	x101 = relative -3 pin’s read state
    	x110 = relative -2 pin’s read state
    	x111 = relative -1 pin’s read state
    
    %FFF:    ‘A’ and ‘B’ input logic/filtering (after ‘A’ and ‘B’ input selectors)
    	000 = A, B (default)
    	001 = A AND B, B
    	010 = A OR B, B
    	011 = A XOR B, B
    	100 = A, B, both filtered using global filt0 settings
    	101 = A, B, both filtered using global filt1 settings
    	110 = A, B, both filtered using global filt2 settings
    	111 = A, B, both filtered using global filt3 settings
    
    	The resultant ‘A’ will drive the IN signal in non-smart-pin modes.
    
    
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • OK,

    thanks @ozpropdev and @evanh

    so
     _txmode       = %0111_0000_000_0000000000000_01_11110_0 'async tx mode, output enabled for smart output
      _rxmode       = %0111_0000_000_0000000000000_00_11111_0 'async rx mode, input  enabled for smart input
      bitperiod := 7 + ((CLKFREQ / baudrate) << 16)
    ...
        wrpin txmode, txpin
        wxpin bitperiod, txpin ' SP txtpin will now use txpin-1 for output, the other COG uses SP txpin-1 as input with 0000 in rxmode input selector
        dirh  txpin
        wrpin rxmode, rxpin
        wxpin bitperiod, rxpin ' SP rxpin will now use rxpin-1 for input the other COG uses SP rxpin-1 as output with 0000 in txmode input selector
        dirh  rxpin
    
    

    Am I getting this right?

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Nope. :P A smartpin output is always to its direct physical pin. The mappings only apply to inputs.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • evanh wrote: »
    Relevant config bits are the %AAAA_BBBB_FFF bit-fields.
    D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0
    
    %AAAA:   ‘A’ input selector
    	0xxx = true (default)
    	1xxx = inverted
    	x000 = this pin’s read state (default)
    	x001 = relative +1 pin’s read state
    	x010 = relative +2 pin’s read state
    	x011 = relative +3 pin’s read state
    	x100 = this pin’s OUT bit from cogs
    	x101 = relative -3 pin’s read state
    	x110 = relative -2 pin’s read state
    	x111 = relative -1 pin’s read state
    
    %BBBB:   ‘B’ input selector
    	0xxx = true (default)
    	1xxx = inverted
    	x000 = this pin’s read state (default)
    	x001 = relative +1 pin’s read state
    	x010 = relative +2 pin’s read state
    	x011 = relative +3 pin’s read state
    	x100 = this pin’s OUT bit from cogs
    	x101 = relative -3 pin’s read state
    	x110 = relative -2 pin’s read state
    	x111 = relative -1 pin’s read state
    
    %FFF:    ‘A’ and ‘B’ input logic/filtering (after ‘A’ and ‘B’ input selectors)
    	000 = A, B (default)
    	001 = A AND B, B
    	010 = A OR B, B
    	011 = A XOR B, B
    	100 = A, B, both filtered using global filt0 settings
    	101 = A, B, both filtered using global filt1 settings
    	110 = A, B, both filtered using global filt2 settings
    	111 = A, B, both filtered using global filt3 settings
    
    	The resultant ‘A’ will drive the IN signal in non-smart-pin modes.
    
    

    hmm, not really clear.

    when I want to use my pin as a input 000 gives me my own pin, 0001 gives me my pin+1
    when I want to use my pin as a output 000 gives me my own pin, 0111 gives me my pin-1

    and I just need the A selector, right?

    so COG A does
     _txmode       = %0000_0000_000_0000000000000_01_11110_0 'async tx mode, output enabled for smart output
      _rxmode       = %0000_0000_000_0000000000000_00_11111_0 'async rx mode, input  enabled for smart input
      bitperiod := 7 + ((CLKFREQ / baudrate) << 16)
      txpin  := 51
      rxpin := 53
    ...
        wrpin txmode, txpin
        wxpin bitperiod, txpin ' SP txtpin will now use txpin for output (51)
        dirh  txpin
        wrpin rxmode, rxpin
        wxpin bitperiod, rxpin ' SP rxpin will now use rxpin for input (53)
        dirh  rxpin
    
    

    and COG B does
     _txmode       = %0111_0000_000_0000000000000_01_11110_0 'async tx mode, output enabled for smart output
      _rxmode       = %0001_0000_000_0000000000000_00_11111_0 'async rx mode, input  enabled for smart input
      bitperiod := 7 + ((CLKFREQ / baudrate) << 16)
      txpin  := 54
      rxpin := 50
    ...
        wrpin txmode, txpin
        wxpin bitperiod, txpin ' SP txtpin will now use txpin-1 for output (53)
        dirh  txpin
        wrpin rxmode, rxpin
        wxpin bitperiod, rxpin ' SP rxpin will now use rxpin+1 for input (51)
        dirh  rxpin
    

    getting better?

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Ah, slightly unexpectedly, the input mappings also apply to IN when smartpin is off.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • msrobots wrote: »
    getting better?

    I would keep them as typical pairs: 50/51 for one pair and 52/53 for the other. The key is to simply map the two rx smartpins to receive from the other cog's tx pin. Eg:
      _txmode       = %01_11110_0
      _rxmode       = %0011_0000_000_0000000000000_00_11111_0    ' +3 mapping
    
      _txmode       = %01_11110_0
      _rxmode       = %0111_0000_000_0000000000000_00_11111_0    ' -1 mapping
    
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • but I am getting it right that input can map to greater pin numbers while output can map to lower pin numbers?

    this sort of confuses me right now, and I shortly am close to hijack TAQOZ and MONITOR from fastspin, it works quite well already but not as I need it.

    Currently I have a PropPlug on the header left next to the usb PC and can compile a fastspin program, open the PASM2 add a starter and change orgh to $10800.

    The starter starts the original fastspin code at $10000 in COG1, leaving the first 64K for TAQOZ and monitor, patches the ROM to use other pins for serial and jumps COG0 into TAQOZ.

    That works, my program runs, can use the serial port, humms along and does not know that I have TAQOZ running in COG0 connected to a terminal, able to watch my program.

    But I would like to use the running TAQOZ subsystem from my SPIN/BASIC/C program as a serial device. Sending commands, receiving answers. How simple is that for any MC programmer.

    Then we have 64 smart pins and a optional smart COG using 64K on the bottom of the ram and 4 pins.

    one could use the power of TAQOZ one liners from any other language the P2 supports.

    But I am getting ahead, first I need to get at the new serial pins running TAQOZ without the need of wiring something, just use for SPs.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • jmgjmg Posts: 13,920
    msrobots wrote: »
    but I am getting it right that input can map to greater pin numbers while output can map to lower pin numbers?

    No, I would have re-ordered the list like this. The OUT in that list is not changing those that follows, it is merely a special choice for Input connection.
    %AAAA:   ‘A’ input selector
    Polarity bit:
    	0xxx = true (default)
    	1xxx = inverted
    Input Source:
    	x000 = this pin’s read state (default)
    Adjacent inputs choices:
    	x001 = relative +1 pin’s read state
    	x010 = relative +2 pin’s read state
    	x011 = relative +3 pin’s read state
    	x101 = relative -3 pin’s read state
    	x110 = relative -2 pin’s read state
    	x111 = relative -1 pin’s read state
    Other Input connection choices :  (useful for lightly driven pins, where OUT may not == this pin’s read state)
    	x100 = this pin’s OUT bit from cogs
    
    

  • ozpropdevozpropdev Posts: 2,565
    edited 2019-01-17 - 02:11:25
    evanh wrote: »
    Ah, slightly unexpectedly, the input mappings also apply to IN when smartpin is off.

    Yep, that's the only way my Logic Analyzer can capture smart pin output states.

    See here for a small example
    http://forums.parallax.com/discussion/comment/1461500/#Comment_1461500
    Melbourne, Australia
  • msrobots wrote: »
    ... while output can map to lower pin numbers?

    Read my code lines again. _txmode doesn't use pin inputs so has no use of mapping.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • ozpropdev wrote: »
    evanh wrote: »
    Ah, slightly unexpectedly, the input mappings also apply to IN when smartpin is off.

    Yep, that's the only way my Logic Analyzer can capture smart pin output states.

    Neat. All makes perfect sense and is best way of course. It wan't mentioned in the docs so my expectations weren't that high. :)

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • so I can not map a qutput?

    uups, not sure if I can convince the rom routines to use a selector for input, will test it soon

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • @msrobots

    I just remebered a while back I was messing around with smartpins and set up multiple serial Rx's looking at pin 63 set at different baidrates. Another example of input selector use.

    See here
    http://forums.parallax.com/discussion/168444/active-autobaud-using-multiple-smartpins
    Melbourne, Australia
  • ok I have my simple fastspin program running on COG1 and TAQOZ+MONITOR are alive and patched to use SmartPins 51 and 53.

    I have a PropPlug connected and can talk to TAQOZ/MONITOR while my program is running on COG1.

    Using the help offered here I can listen to the answer of TACHOZ using a third pin with location -1 and it works fine out of my program.

    So smart pin serial receive works with listening to the pin next to you, while it is talking to somebody else (the prop plug).

    Now I just need to figure out how to trick the ROM routines to listen to a pin with different location, even better would be 2 locations.

    So how do I set the B pin if I would like to look at a B or A combination, or does that not work in async serial mode?

    lot's of questions,

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • This was how we used the monitor on the hot chip.

    Well done.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • exactly,

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Sorry I haven’t been much help :(
    Over Xmas got a tooth abscess and now I’m in the middle of root canal, so pretty much just been going to work and sleeping.
    As soon as the tooth settles down I’ll be back on it.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Sign In or Register to comment.