Questions and Comments for Chip

Cluso99 · 2013-03-19 20:17

Chip,

In the P2 documents I found an example of the RDQUAD delays required after the instruction executes. I could not find a similar example for RDxxxx instructions. What I have found by trial and error is this...

LMM_call01      rdlong  LMM_opcode,LMM_PC       ' read next hub instruction to be executed (pointed to by LMM_PC)
                add     LMM_PC,#4               ' inc LMM_PC (to next hub instr)
                nop                                        ' required delay for rdlong to execute
LMM_opcode      nop                             ' execute the hub instr

Is this correct or should there be more NOP's ?

I just realised that the JMPRET instruction can save the C & Z bits in a CALL version using the WC & WZ modifiers,
and can be restored by RET using the WC & WZ modifiers. I presume the save v restore is triggered by the NR modifier
implied in the instruction bits. This is a really neat no penalty feature

I have noticed that the TX routine in the Rom_Monitor v0.1 dated 11/01/2012...
The bit time delay commences before the start bit is sent, and that the stop bit is untimed. This
probably does not matter here. (it caught me out when I copied your routine)
A simple solution would be to move the "passcnt" after the "setpc" instruction.

'
' Transmit chr (x)
'
tx              shl     x,#1                    'insert start bit
                setb    x,#9                    'set stop bit
                getcnt  w                       'get initial time
:loop           add     w,period                'add bit period to time
                passcnt w                       'loop until bit period elapsed
                shr     x,#1            wc      'get next bit into c
                setpc   tx_pin                  'write c to tx pin
                tjnz    x,#:loop                'loop until bits done
tx_dspace_ret
tx_space_ret
tx_nib_ret
tx_ret          ret

cgracey · 2013-03-19 22:28

I believe in the pipeline section of the doc's it explains that after a register is written, there must be TWO instructions executed before the newly-written register can execute. Otherwise, you'll execute the prior contents. RDxxxx instructions fall under this rule.

The doc's cover the JMPRET/JMPRETD instructions pretty thoroughly and the rules around flag saving and restoring.

The TX routine is written that way intentionally. It assumes that a stop bit is in progress on entry.

Cluso99 · 2013-03-19 23:02

cgracey wrote: »

I believe in the pipeline section of the doc's it explains that after a register is written, there must be TWO instructions executed before the newly-written register can execute. Otherwise, you'll execute the prior contents. RDxxxx instructions fall under this rule.

The doc's cover the JMPRET/JMPRETD instructions pretty thoroughly and the rules around flag saving and restoring.

The TX routine is written that way intentionally. It assumes that a stop bit is in progress on entry.

Thanks Chip.

Yes, that is where I saw the saving and restoring flags info. I had glossed over it before, not realising how simple it is. Congratulations.

I got caught with the TX because I had two different routines following each other and the start/stop bits were getting corrupted between the two different methodologies - not a real world situation - I was debugging a new routine in LMM mode

Ariba · 2013-03-19 23:04

Because the topic of the thread is so open, I ask it here:

How do I set the input and output pins for the counters?
I can do counter outputs over the DACs, but I don't see any info about digital counter pins in the Docs.
Thanks

Andy

cgracey · 2013-03-20 06:28

Ariba wrote: »

Because the topic of the thread is so open, I ask it here:

How do I set the input and output pins for the counters?
I can do counter outputs over the DACs, but I don't see any info about digital counter pins in the Docs.
Thanks

Andy

Andy, that's where I got hung up on the counter doc's. I was having a hard time trying to explain how the pins get mapped. I will get back on it soon. In the meantime, I'll write a program today that outputs function-generator type signals from the counters to the DACs and post it in this thread.

Ariba · 2013-03-20 10:44

I tought it's just a matter of writing the pin number to the right fields in a register and you have just forgotten to show as where this fields are.

But it must be much more complicatetd then. I want to ouput an NCO signal for a faster SPI code but I can also live with the slower variant for now (clock toggling per instructions).

I already figured out the Waveform outputs over the DACs and this is a very nifty feature of the Prop2. One Prop2 chip can replace up to 16 (32?) DDS chips (with the little extra that it has also 8 CPUs) ! But look forward to your example program, there may be things I have not noticed.

Andy

cgracey · 2013-03-20 17:57

Here's a little program that uses both counters in cosine/sine mode to generate DAC signals. You can view these signals on a scope, and be sure to try XY mode, too, with different DAC combinations while you change f2:

CON

  f1		= 100_000.0		'100 KHz
  f2		= 150_000.2		'150 KHz + 0.2Hz (try different values)

DAT		org

		setctra	#%01111		'set cosine/sine mode
		setctrb	#%01111

		setwava	wava
		setwavb	wavb

		setfrqa	frqa
		setfrqb	frqb

		cfgdacs	#%10_01_01_01	'view dac combos in XY mode on scope

		jmp	#$


wava		long	$80<<23 + $80<<9 + $100
wavb		long	$80<<23 + $80<<9 + $100

frqa		long	ROUND(f1 / 30_000_000.0 * FLOAT($8000) * FLOAT($10000))
frqb		long	ROUND(f2 / 30_000_000.0 * FLOAT($8000) * FLOAT($10000))

Tubular · 2013-03-20 18:42

I had a play with this the other day too, and its beautifully simple to set the frequency, phase, dc offset, ac amplitude, and type (sine triangle square etc).

It's also possible to combine video, which uses CTRA, with the waveform generation happening in CTRB of the same cog

However I didn't realize you could calculate the frequency tuning longs like that using floating point in pnut. It just gets better...