908GP32 - Timer Input Pin Access During Interrupt

[PeterHouse]

68HC908GP32

I am using the Timer Input Capture pin to generate an interrupt on BOTH rising and falling edges.  How do you determine which edge is causing the interrupt ???

The following code ALWAYS branches to JumpLabel:

    BRSET   6, PTD, JumpLabel   ; Port D bit 6 is Timer 2 CH 0 Input

I am really surprised the input is not accessible when configured for use as a timer input.

I have a workaround where I change between rising and falling edge INSIDE the interrupt handler but this code seems more complicated.

Thanks,

Peter House



--
Alban Edit: Please always include FSL Part Number in Message Subject line.



Message Edited by Alban on 2007-09-12 02:21 PM

[peg]

Hello and welcome Peter,

The edge that caused the last capture is the edge that it was set for.

So just toggle it.

That's just the way it is.

[peg]

Hi,

I guess a more verbose response is in order.

Yes, this is a limitation! Either edge is only useful when you don't really care which edge, so its usefulness is very limited. If you just want frequency then pick one edge and forget about the other one. If you need to measure the high time and low time, you need to start with one (any one) wait for it, (to sync up) then measure each period while flipping the edge each time.

And yes, I am surprised too.

This makes glitch rejection harder and less effective as well.

[bigmac]

Hello,

I guess a possible approach is, within the ISR code, to disable the TIM channel, read the current port status, and then re-enable input capture interrupt on the channel.  Disabling the channel will permit normal I/O operations to occur.  This process would seem to require only one extra instruction over what might normally be required.

Regards,

Mac

[peg]

Hi Mac,

My main concern with doing this is tripping the edge detection by switching the inputs. Maybe you can get away with it or maybe you need to clear it after the switch just to be sure.

It would be much nicer if you could just read it.

[PeterHouse]

Thanks for all the help.  I did not expect this may responses so quick.

My solution is to change the edge bits ELSxA and ELSxB during each interrupt as follows.

T2Ch0_Interrupt:

    BRSET   b_ELSxA, T2SC0,RisingEdge

FallingEdge:
    bset    b_ELSxA, T2SC0
    bclr    b_ELSxB, T2SC0
    BRA     MoreCode
RisingEdge:
    bclr    b_ELSxA, T2SC0
    bset    b_ELSxB, T2SC0

MoreCode:
    ; Clear Interrupt, Read and Store Timer Values, Etc...
    RTI
 
It seems like I wrote some similar code for the '05 or '11 several years ago and could read the IO pins even though they were dual used by the Timer.

This exercise cost me a couple of hours since I KNEW it should work!!!

I hope I can contribute back to this forum in the future.

Thanks,

Peter House

[rocco]

Wait a minute . . . This is not a limitation. I use that function and it does work.

Here are two independent lines of working code that directly test the I/O pin during the timer processing. The timer registers did not need to be modified for these test to return the correct state of the pin.

;
        brclr   T2C0PIN,TIMPINS,newLow      ;branch if a new LOW duration;; and;        brclr   T2C1PIN,TIMPINS,ct__1       ;branch if it's time for the pulse

"T2C0PIN" and "T2C1PIN" are defined as pins 6 and 7, respectively, and  "TIMPINS" is defined as port-D.

Timer-2, channel 0 was configured as an input-capture for the first line of code. Timer-2, channel 1 was configured as an output-compare for the second line of code. I didn't do anything else out of the ordinary, outside of configuring both pins as inputs (even though the output compare will act as an output). All pull-ups are enabled on port-D and the port-D data register is written with zeros, but neither should make a difference.

[peg]

Hi Rocco,

Well there had been a little niggling doubt about this in the back of my mind.

My commentary was based on the OP's experience combined with what I thought I remembered from several years ago. Rather than hard factual knowledge. Now I am going to have to try it out for myself. My current usage of GP32's timers in a couple of products only involve frequency measurement . AFAIK most (or all) multipurpose pins still function as an input no matter what other function is selected. I thought I was remembering that the timer was different. Where is the experts from Freescale when you need them?

[PeterHouse]

I am very confident I can not read the IO pin during the interrupt while the IO pin is configured as a Timer Input Captrue pin.

The code I submitted earlier is a little suspect since it used labels which could have been defined wrong.  Believe me when I say I spent a couple of hours troubleshooting this!

I checked using the following code to remove any chance of assembler problems:

    BRSET   6,0,JumpLocation

I then verified the bytes in the listing file as 0C0329 Which decodes as BRSET bit 6 (T2CH0), Direct location 03 (PTD), and a program counter adjustment of +29 bytes.

I put then placed distinctive bit wiggle instructions on either side of this instruction so I could see if the jump was taken or not using an HP54622D MSO.  The jump was never taken.  If I used a BRCLR the jump was always taken.  I also used the analog scope channel to makre sure the rise or fall times on the T2CH0 line were not too slow - there were ten of microseconds between the 90% point of the signal and the place where I first toggled my test output which was before the branch test instruction.

I then performed a

    lda   #03
    sta   DebugPort

and bit 6 of the DebugPort was always high.  I put this code inside and then outside the interrupt routine.

I have been working with Motoscale processors since the 6800 using the old XORMACS development system and was very surprised at this behavior.  I am confident anyone else can duplicate it.

The marking on the part is as follows: Freescale Logo, MC68HC908GP32 OL96SCTMD0526

Peter House

[bigmac]

Hello all,

The data sheet for the GP32 seems to be quite clear that, whenever a peripheral module such as a TIM channel is enabled, this will over-ride the underlying general purpose I/O at the pin.  This would make sense since the TIM must determine whether each channel pin is an input or an output , quite independently of the the DDR setting.

The same would also seem to apply to other modules, such as SCI, SPI and ADC.  The one exception appears to be the KBI module, where input status may be read at any time.

Peg, I don't share your concerns that disabling the TIM channel within the ISR would be problematic, provided the timer channel register is read prior to disable.  When a TIM channel is enabled during initialisation,or here within the ISR, I think it is a good policy to ensure than any spurious interrupt flag is cleared.  This needs to be explicitly done within the ISR anyway, so there would be little effect on code complexity.

Peter, I think you have an error with the line -

    BRSET   6,0,JumpLocation

Address 0 refers to Port A; for the timer channel pins at Port D the address should be $03.

Regards,

Mac

[PeterHouse]

bigmac - the error you pointed out was fortunately only in the forum posting.

I agree with you on the documentation stating the use of the Timer overides any settings in the DDR which has been my experience in the past with other processors including Motoscales.  My experience has also shown in the past that if the peripheral makes the pin an input then normal IO instructions have been able to read the input.  I would expect the Timer settings to force the DDR and not totally redirect the input logic.  I apparently expect wrongly

I believe I had some code which used this on a 6805C9A decoding CEBus PL data but I can't put my hands on it at the moment.

Thanks for all the help.

Peter House

[peg]

Hi Peter, Mac and Rocco,

I don't have the time to test this thoroughly or test any other pins but:

I can confirm that with T1CH0 setup for input capture and PTD4 setup for input, I can read the input status of the pin at 4,PTDD while it is performing capture interrupts. Although the manual does say it disables GPIO functionality it really only prevents you from selecting it as output. Peter you do have it set for input, otherwise you will read the output latch.

I am sure this works for other pins that are input in the "other" functions.

Under Port D data register description under MISO it seems to suggest that this is the case here also. It also seems to rule it out for the SS pin, maybe.

If you think about it, they would have to put in additional gates to disable the input function when the "other" functions are enabled and functionality would be reduced. Why would they do that?

Message Edited by peg on 2007-09-16 04:43 PM

[PeterHouse]

peg,

The port is definitely set for input as this code shows:

; Port D bit Definitions
; bit 7 - Out - Prox_Mod
; bit 6 - In  - Prox_Demod
; bit 5 - Out - Prox_Shutdown
; bit 4 - Out - LCD_Backlight
; bit 3 - Out - LCD_A0
; bit 2 - Out - LCD_RST
; bit 1 - Out - LCD_CS1
; bit 0 - Out - Not Used
DDRDInit:       EQU     %10111111
PortDInit:      EQU     %00000000

PORT_Prox_Mod:  EQU     PTD
b_Prox_Mod:     EQU     7
PORT_Prox_Demod:EQU     PTD
b_Prox_Demod:   EQU     6
PORT_IR_Demod:  EQU     PTD
b_IR_Demod:     EQU     6
PORT_Prox_Shut: EQU     PTD
b_Prox_Shut:    EQU     5
PORT_LCD_BL:    EQU     PTD
b_LCD_BL:       EQU     4
PORT_LCD_A0:    EQU     PTD
b_LCD_A0:       EQU     3
PORT_LCD_RST:   EQU     PTD
b_LCD_RST:      EQU     2
PORT_LCD_CS:    EQU     PTD
b_LCD_CS:       EQU     1

I could not read the input with this setup.  I do not believe there would have been any mask changes and I agree it seems like it would take extra steering logic to make it work like this.

I am past this and on to a different phase of the project.  If, for some reason I must reopen it, I may test this out again.

I feel very confident I tested this thouroughly but . . . you know . . . you never know . . . you know ???

Peter