tms570LS3137 N2HET pulse detection

Gobind,

First, I think this will be tough and you'll likely need to dedicate an N2HET to the task.  This is because 250ns is only 25 cycles at 100MHz and your loop resolution might need to be 1/2 of that.

But first, I'm having problems understanding the coding scheme.  It sounds like you are trying to do manchester decoding, but you didn't mention anything about a preamble.    Lets assume you have a long string of 250ns high, 250ns low, 250ns high, 250ns low.  You need some scheme to determine where the first symbol is or else it's ambiguous whether this is a string of 0's or 1's.  The HET program would need to take that into account.    If you are trying to decode a standard of some sort, and you can let me know which standard, this could also help.

Anthony,

Yes, it is manchester decoding. I should detect a 750ns low, then 750ns high followed by 500ns low. When i detect this, whatever follows this is the valid data. So, after this if i get 250ns high and then 250ns low, it is one. If it is 250ns low and then 250ns high, it is zero.

Hi Gobind,

Ok got it.  I think a state machine type implementation might work but again I'd be concerned about the speed.  Let me think this one over a bit.

Gobind,

Thinking this through some more - it seems tight to try to implement this 100% on the N2HET given the sample rates are in the > 1MBit/s range and you have to do clock recovery.  I sketched out a possible state diagram w. everything in N2HET and it just looked so tight I don't think it's worth starting on it if there are other options.

The other option I would suggest if this would work is to just do the clock recovery on the N2HET.   Then send the recovered clock to one of the SPI ports as a clock but use the SPI port to shift in the data.   This way you can focus the N2HET work on robust clock recovery.

I don't know how long your messages are and how stable your input transitions are going to be.  You could start with the assumption that you would just detect the edges on the synchronization pulse and then generate "N" equally spaced clock edges to the SPI at 500ns intervals starting from 450ns (or more, you adjust based on the desired sample setup time) after the sync.   i.e. generate a shift clock right before the end of the data period when you can just read the input bit '1' or '0' directly from the pin state.    N would be the # of bits in the message.

You can then decide if you want to schedule *all* N bits ahead of time based on the sync pulse or try to adapt the scheduling of each new bit a little as each edge of the Manchester encoded data comes in.   i.e. you might give the more recent edge a heavier weight and prior edges lower weights when estimating the next sampling position.

The good thing about this approach is that you can observe the sampling points on a HET output pin, so that you can debug the algorithm you make to pick the sampling points by comparing the sample edge v.s. the input data stream.

The downsides of this approach would occur:

  a) if messages can be variable length - you would need to generate additional clocks for the SPI to complete it's shifting to the next 16-bit interval but there should be time for this during the 750s sync pulse that starts the next message.

  b) if you need to handle very long messages with lots of bits between sync pulses...   you might use a MIbSPI for this job because of it's buffering.   But on the N2HET side the clock recovery would be more challenging too because there can be more 'drift' between sync pulses.

But I think the downsides are probably manageable by giving yourself a lot more time for N2HET instructions and moving the shift part into SPI.

Now, when generating the shift clock out of the N2HET, the other point to note is that the N2HET pulse output can be spaced at a resolution of 10ns.   This is a lot better than the resolution of the N2HET sampling an input pin, which is basically the loop resolution period unless you're going to use a PCNT and then figure out if you should shift in a 1 or a 0 based on which edge occurred and what time it occurred [state machine approach].

Anthony,

Can i get some sample code for manchester decoding with twice or more the rate i mentioned in the previous posts (i.e 500ns low and 500ns high =0)? I will then try to implement the clock recovery method you suggested.

Anthony,

Is it possible to run N2HET at 128MHz speed?

Gobind

Not currently.  The N2HET runs on the VCLK2 clock domain on parts like the RM48L952.

I believe the RM48L952 is the fastest we have today.  It's spec is 220MHz for the CPU and 110MHz for the VCLK2 domain.   There is a table in it's datasheet Table 3-1. Clock Domain Timing Specifications that tells you this information.  You can find a similar table in the datsheets of the other parts that you might look but I believe the 952 is currently the fastest.

 BTW - regarding your prior question - sorry I don't have any example code for manchester on N2HET. 

Thanks Anthony.

Could you please give me an idea how do i detect the sync bit?

Gobind,

I would suggest your program go something like this:

1)  a PCNT to measure the pulse width

2)  if edge is detected:

      2a) categorize edge.  pulse width 'w' must  w1 < w < w2  where w1, w2 are the tolerances you allow around your nominal

     2b)  if edge is valid, dispatch to 'next state' else 'reset state'

3) To dispatch, you can use a branch instruction to the next state.  You might just have 7 of these branches:

         1. 750ns rise,  2. 750ns fall,  3 500ns rise, 4 500ns fall, 5 1000ns rise, 6 1000ns fall, 7 invalid width

 4)   When you exit a state in your detection state machine, you can use the "MOV64" instruction to change the branch address of the previous 5 branches so that they go to the correct point in the HET code given the specified event occurs.

5)    implement code for as many state transitions as needed.  the 7 branches represent the state transition code for the current state based on any of the possilbe measurements.    you might be able to collapse some of this code.  I think you'll need to keep track of whether you're at the beginning or end of the bit time, and at the end of the bit time you'll do your shifting of the bit into the data register.   

Thanks Anthony,

I have some questions:

1) Do i have to use two PCNT instructions, one for high pulse width and one for low pulse width? Is it possible to use two PCNT instructions in single LRP?

2) Categorizing: To check (w1 < w < w2), I should check it for 7 different edges, (750 rise, 750 fall etc). Am I right? And for each check of (w1 < w < w2), i need to use two MCMP instructions. Is it possible to do it in a single instruction?

3) PCNT instruction sets the Z flag for each edge detected, i can use Z flag to check if edge has been detected. Am I right?

Hi Gobind:

Gobind Singh said:

1) Do i have to use two PCNT instructions, one for high pulse width and one for low pulse width? Is it possible to use two PCNT instructions in single LRP?

I'd suggest going with 2 PCNT but to do this you must have the HRSHARE feature configured.

This means you will be using 2 pins worth of HET logic for each physical pin; and your signal needs to be on the EVEN pin number.   So lets' say your pin is pin 2,  you will set HRSHARE for pins 2/3 and one PCNT will work on pin 2 while the other will be (coded) to work on pin 3.    However, the PCNT that's coded to use pin=3 will actually get input from physical pin 2 when you have HRSHARE on.

Gobind Singh said:

2) Categorizing: To check (w1 < w < w2), I should check it for 7 different edges, (750 rise, 750 fall etc). Am I right? And for each check of (w1 < w < w2), i need to use two MCMP instructions. Is it possible to do it in a single instruction?

No one instruction that you can use in this case.   We have an *angle* compare instruction that does the comparison above, but you could only control 'w1' with it, not 'w2' which is computed as the sum of 'w1' and an angle increment.  The problem is you can't set the increment in this case so you can't use the instruction.

So you need to use either 2 different MCMP or 2 SUB/BR pairs.  If you stick w. PCNT then the MCMP is probably OK.   If you move to WCAP and use a free running counter, you'd want to use SUB because it would work correctly through counter rollover.

Gobind Singh said:

3) PCNT instruction sets the Z flag for each edge detected, i can use Z flag to check if edge has been detected. Am I right?

Thanks Anthony.

Another question: Now my code is ready. I have two codes and i want to use both the N2HETs. I tried configuring the second N2HET with same configurations as first N2HET, but i do not see the output. Is there any special setting for the second N2HET other than making it slave.

Can we make any of the N2HETs as master?

I see that there are 2 HTUs in the 3137, 1 for each N2HET. How do i configure the second HTU? There is only one set of registers in HTU, how do i tell the HTU that it should transfer the data to/from N2HET 1 or 2?