Smartpin questions - undocumented

rogloh

Had a few Smartpin related questions if someone already knows this...it's not readily apparent from the documentation.

1) Is there any known way to determine an existing Smartpin's current mode? I'm guessing not.

2) If a Smartpin mode is already setup and the pin is operational, does a "fltl #pin" also clear it's mode? ie. will I need to rewrite its mode each time I reset it before I raise its DIR pin high to enable it or will the mode data remain intact?

3) What happens if you write the mode (WRPIN) while the Smartpin is already operational?

The main reason for Q2 is that I'm trying to resync a Smartpin based clock output to that of the current P2 instruction pin's phase each time the clock train is generated and am wondering if I need the second line below every time or if I can just leave it in the same transition output mode. I also wonder if I might be able to issue the wxpin when the Smartpin is already up, or if that can't reset the phase unless it the Smartpin in also in reset. I'm also wondering if this resync operation will always have to tri-state/glitch the clock (something I'd like to avoid).

Just trying to save some cycles on this HyperRAM driver I'm working on.

                            fltl    clkpin                  'disable Smartpin clock output mode
                            wrpin   #%1_00101_0, clkpin     'set into Smartpin transition output mode
                            wxpin   #2, clkpin              'configure for 2 clocks between transitions
                            drvl    clkpin                  'enable Smartpin   

cgracey

rogloh wrote: »

Had a few Smartpin related questions if someone already knows this...it's not readily apparent from the documentation.

1) Is there any known way to determine an existing Smartpin's current mode? I'm guessing not.

2) If a Smartpin mode is already setup and the pin is operational, does a "fltl #pin" also clear it's mode? ie. will I need to rewrite its mode each time I reset it before I raise its DIR pin high to enable it or will the mode data remain intact?

3) What happens if you write the mode (WRPIN) while the Smartpin is already operational?

The main reason for Q2 is that I'm trying to resync a Smartpin based clock output to that of the current P2 instruction pin's phase each time the clock train is generated and am wondering if I need the second line below every time or if I can just leave it in the same transition output mode. I also wonder if I might be able to issue the wxpin when the Smartpin is already up, or if that can't reset the phase unless it the Smartpin in also in reset. I'm also wondering if this resync operation will always have to tri-state/glitch the clock (something I'd like to avoid).

Just trying to save some cycles on this HyperRAM driver I'm working on.

                            fltl    clkpin                  'disable Smartpin clock output mode
                            wrpin   #%1_00101_0, clkpin     'set into Smartpin transition output mode
                            wxpin   #2, clkpin              'configure for 2 clocks between transitions
                            drvl    clkpin                  'enable Smartpin   

1) There is no way to tell what mode a smart pin is in.

2) Making DIR low holds a smart pin in reset, but does not cause it to loose its configuration. DIR=0 is the ideal state in which to configure a smart pin, since it will clear its internal state bits per the mode and then certainly start properly when DIR goes high.

3) You can rewrite the mode via WRPIN while DIR=1, but it may not work, as the new mode's state bits may be in an incongruous state for that mode.

Smartpins each have something like 132 flipflops. The mode (via WRMODE) just selects the logic between the flipflops.

rogloh

Thanks Chip. Some of this will probably just need to be experimentally tried out in the transition mode to see its behavior.

I'm hopeful that instead of the above code I will be able to keep the clock pin output driven the entire time (but idling low after the pulse train finishes as I ensure I send an even number of transitions), and yet still reset it's phase like this:

wxpin #1, clkpin ' set to reload on every clock cycle, after current cycle completes
... (at least another instruction doing something useful)
wxpin #2, clkpin ' reset for two clock cycles between transitions
...
wypin clkcount, clkpin ' trigger output which is now resynchronized with instruction phase

Resetting the phase like this is required because of some waits I use (like waitxmi) that may wait an odd number of P2 clock cycles throwing the instruction sequence and transition clock phase output out of sync for next time. All other instructions take an even number of P2 clock cycles, it's just any waits that may upset the timing here.

evanh

That's fine, you're not changing modes. But it won't actually reset the phase of the timebase either. I'm pretty certain all it will do is cleanly transition from one timebase to another at the end of the timebase period.

rogloh

Why won't it work if I am going to 1 clock per output transition first? That should reset the phase at the end of the current two clock phase transition period shouldn't it? Or do you think I have to float the pin first before any wxpin #1 takes effect? I don't want to float the clock pin, especially if !CS is low, but I guess I could float it while !CS is high.

Update: When I say reset the phase to two clock cycle interval, I mean align it with the instruction execution. I later do an odd cycle wait before the streamer is setup to then allow data to be output out of phase with the clock, so the clock pin edges line up nicely with stable data portions in sysclk/2 mode (in the middle of the data bit period).

cgracey

By resetting the smart pin in transition mode, you are certainly resetting the time base counter, no matter what the time base is set to.

rogloh

cgracey wrote: »

By resetting the smart pin in transition mode, you are certainly resetting the time base counter, no matter what the time base is set to.

That's right but the other problem with that approach, apart from the two additional instructions it takes, is that it also tri-states the output clock pin when the Smartpin is reset and that potentially glitches the clock. I can do this operation with CS high I guess, but I'd prefer no clock glitches at all.

evanh

Oh, I read "reset" and didn't get you meant putting it back to normal. I'm not sure you're gaining any advantage over just using a DIRL/DIRH pair though.

rogloh

The advantage is the clock pin won't float temporarily while the Smartpin gets reset. I know it is only for two clock cycles if I was to do a DIRL then DIRH, but I still don't feel comfortable floating a clock output pin that is driving a memory (at any time).

cgracey

I don't have the docs in front of me, but I'm pretty sure that the transition mode, and all output modes, for that matter, continue to output during reset.

evanh

Yes, DIR stops controlling the output with all smartpin modes. The smartpin has to be turned off (M = 0) before DIR will control the pin output again.

EDIT: When a smartpin is on, pin config bit6 (A %TT field bit) is used to control the pin output enable.

rogloh

Ok that is interesting. I still don't fully know when the pin is output. If you issue FLTL, or FLTH to reset the Smartpin I have always assumed the pin's output is also reset because you are setting DIR bit low. Perhaps that is not the case. Some of this Smartpin IO stuff needs to be explained a bit more in the docs at some point.

rogloh

Ok I do see this in the documents which indicates the Smartpin's own output is low in transition output mode, however I was not aware that the real direction bit has no effect while the Smartpin mode is non zero. That is the key thing here to know I believe.

"During reset (DIR=0), IN is low, the output is low, and Y is set to zero."

evanh

Here's a recent snippet I just used:

		fltl	#56 | 5<<6
		wrpin	#0, #56 | 5<<6

It's fully resetting six pins I want to use. I did it because some of those upper pins possibly still have smartpins turned on after boot handover.

EDIT: Actually, I'm not that sure the WRPIN is doing as intended. It's nifty how Chip got single instructions to write to multiple smartpins at once.

EDIT2: Yep, the docs are allowing it.