Use the AAAABBBB smartpin field for analog input?

Rayman

Okay, maybe I wasn't paying close enough attention, but I thought that Rev.B could only get analog input from neighboring pin and that Rev.C could only get analog on it's own pin.

But, I seem to be able to use the smartpin AAAABBBB field to get analog input on Pin+1 and Pin+2 (at least).

Is this really possible? I think it must be, but I'm surprised...

Rayman

Here's my smartpin settings that make the top trace from Pin#8 showing a signal that is actually on Pin#10.

cgracey

Those %AAAABBBB bits are only for selecting digital signals.

The ADC only works on the pin, itself (on Rev C silicon). However, you could grab the ADC output of another pin using these 8 bits.

Rayman

That's what I thought...

I'm trying to figure out how my code is giving me an analog signal on P11 with nothing connected to it when I set AAAA to look at another pin...

Rayman

I think it is actually giving me analog data from another pin.

The sigma-delta is actually a digital signal.

When Pin#9 smartpin is set for ADC mode, Pin#11 can see it's data using the AAAA field.

Is this possible?

Rayman

I'm looking at Evanh's diagram... This part looks like it might work:

                |    COMP_DAC|  |Feed    :     |                             [            ]
                |            |  |back    :     |                             [   Odd #    ]
                |            v  |        :  OUT|      -1  -2  -3             [  Smartpin  ]
                |      [=============]   :     |       |   |   |             [ (%MMMMM_0) ]
                | PinB [  Comparator ]   :     |       v   v   v             [            ]
              -------->[             ]   :     |    [=============]      A   [            ]
             |  | PinA [   (%P...P)  ]   :      --->[ Logic Input ]--------->[---o----o---]-------> IN
             |  +----->[             ]   :          [  (%A_B_F)   ]      B   [  (M == 0)  ]
             |  |      [  Pin Input  ]------------->[             ]--------->[            ]
             |  |      [             ]   :          [=============]          [            ]
             |  |      [ Sigma-Delta ]   :             ^   ^   ^             [============]
             |  |      [     ADC     ]   :             |   |   |
             |  |      [=============]   :            +1  +2  +3
             |  |                        :
             |  |                        :

Rayman

I think the trick is that the other pin whose analog data you want to see has to be in ADC smartpin mode...

cgracey

Rayman wrote: »

I think the trick is that the other pin whose analog data you want to see has to be in ADC smartpin mode...

Yes, it would need to be in ADC mode so that its IN output is the ADC bitstream.

Rayman

Ok, thanks. Thought something was horribly wrong with my code for a minute...

I'm trying to think if this is useful for anything...

Rayman

Maybe can do several types of sinc filtering at the same time as well as scope mode

cgracey

Rayman wrote: »

Maybe can do several types of sinc filtering at the same time as well as scope mode

You could do that.

Rayman

Ok, this is pretty neat...

Without any jumper wires, I can look at the VGA signals using neighboring smartpins.

See attached image where bottom analog trace is looking at HSync and top is looking at the blue channel.

The cursors get close to the actual HSync freq of 67.5 kHz.
(shoot, wrong image... But trust me, the cursors show right freq).

Rayman

This took some tricks...

First, I had to move A/V board over to P8..P15 from P0..P7 so that I could get to HSync and blue signals. Otherwise, I'd be messing with serial I/O pins. Maybe it could work that way, but this is cleaner.

Next, I needed to hijack the VGA smartpins from the VGA cog. Apparently, whichever cog does the WRPIN controls the ADC output via their OUT signal (This is what I think I'm seeing anyway). So, I need set OUT high and then write "dacmode_s" to HSync and then "dacmode_c" to blue pin. This is a bit tricky because you can lose video if you do HSync wrong.

Finally, set P6 and P7 to ADC scope mode with AAAA pointing to neighboring VGA pins.

Tubular

wow, thats neat

Rayman

I can trigger in digital mode off of VSync (Pin#12) and see the five HSync pulses showing the vsync width is actually 5.

Also, looking at the actual HSync in Blue pins in digital mode now shows noise, which must be the raw ADC bits...

Rayman

Uh oh, I think I see a bug in my 1080p driver...

Syncing off the start of VSync and shifting the trigger point to the right and then looking at the Blue signal... It appears there are only 3 front porch blanks when there are supposed to be 4.

Not sure I understand that... Code looks right:

NextLine            
            djnz    x99,#line             'another line?
    '        sub     x,#1 wz
    'if_nz   jmp     #line


            mov     x99,#4          'front porch, bottom blanks
            call    #blank
            
            cogatn  #1<<0   'Tell main cog that vsync in progress
               
            drvnot  #vsync          'sync on
            mov     x99,#5            'sync blanks
            call    #blank
         
            drvnot  #vsync          'sync off
            jmp     #field                  'loop

I'm actually able to count lines after sync too and it's one too many... Simple fix though.

evanh

That'll be from the streamer command buffering causing a timing shift wrt the DRVNOT. I was always a little unsure about its impact until recently when I tested it. The effect is obvious once pointed out. Read https://forums.parallax.com/discussion/comment/1491196/#Comment_1491196

evanh

Hehe, I could have documented that snippet a little. The streamer mode is serial out of 8-bit direct data fed from the S operand of XINIT/XCONT. The shift rate is 8 sysclocks per bit. So 64 sysclocks for each 8-bit word to be shifted out.

Therefore, the measured ticks at the end of the third command is for just first byte shifted out. The other two bytes/commands are still being processed by the streamer.

evanh

Here's another version using pins #0 and #1 to compare on a scope:

CON
	XDIV		= 2				'PLL stage 1: crystal divider (1..64)
	XMUL		= 4				'PLL stage 2: crystal / div * mul (1..1024)
	XDIVP		= 20				'PLL stage 3: crystal / div * mul / divp (1,2,4,6..30)
	XOSC		= %10				' OSC    ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
	XSEL		= %11				' XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
	XPPPP		= ((XDIVP>>1) + 15) & $F	' 1->15, 2->0, 4->1, 6->2...30->14
	CLK_MODE	= 1<<24 | (XDIV-1)<<18 | (XMUL-1)<<8 | XPPPP<<4 | XOSC<<2

	DM_1bIMMbe	= (%0100 << 28)|(%1 << 16)	' 1-bit immediate, big-endian
	DM_DIGI_IO	= (1 << 23)

DAT
ORG
		hubset	#$f0				'reliable RCFAST select (workaround for clock selector flaw)
		hubset	##CLK_MODE			'set PLL to 2 MHz, assumes crystal is 20 MHz
		waitx	##250_000			'10 ms pause (RCFAST) for crystal/PLL to stablise
		hubset	##CLK_MODE|XSEL			'engage PLL as sysclock source

		setxfrq	##$1000_0000			'set streamer pacing to sysclock/8
		dirh	#0+1<<6				'enable output drive on pins #0 and #1

'do test
		outnot	#1
		xinit	dm, #$a5
		outnot	#1
		xcont	dm, #$35
		outnot	#1
		xcont	dm, #$c5
		outnot	#1
'done
		jmp	#$


dm		long	DM_1bIMMbe | DM_DIGI_IO | 8

EDIT: Added screenshot