Questions and Comments for Chip
![Cluso99](https://forums.parallax.com/uploads/userpics/035/nJPU0EF20AFBB.png)
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...
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![:) :)](https://forums.parallax.com/resources/emoji/smile.png)
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.
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 instrIs 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
![:) :)](https://forums.parallax.com/resources/emoji/smile.png)
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
Comments
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.
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
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.
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
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...