NetBurner Community Forum

I have gotten my QD code to initialize without returning an error, but now it won't read the inputs. I've put this in Software since I think it is a problem in the eTPU code somehow (or rather, a problem with my use of the eTPU code, I know it works for others).

...
iprintf("\nApplication %s started.\n",AppName);
Pause("Before eTPUInit"); // so that if it hangs or traps it can be re AutoUpdated here.
int QDError = eTPUInit();
iprintf("eTPUInit error = %d\r\n",QDError);
Pause("After eTPUInit"); // so that if it hangs or traps it can be re AutoUpdated here.
char ChanA = 2;
QDError = fs_etpu_qd_init(
ChanA,
ETPU_CHAN_NOT_USED,
ETPU_CHAN_NOT_USED,
FS_ETPU_QD_PRIM_SEC,
FS_ETPU_PRIORITY_MIDDLE,
FS_ETPU_QD_CONFIGURATION_0,
FS_ETPU_TCR1,
0,
10,
100,
1000,
10000,
0x00400000,
0x00C00000,
FS_ETPU_QD_HOME_TRANS_ANY,
FS_ETPU_QD_INDEX_PULSE_POSITIVE,
FS_ETPU_QD_INDEX_PC_NO_RESET,
etpu_a_tcr1_freq,
100);
iprintf("EncoderInit error = %d\r\n",QDError);
Pause("After fs_etpu_qd_init"); // so that if it hangs or traps it can be re AutoUpdated here.
...

Here is the output:
Application Encoder started.
Before eTPUInit
Enter to continue...
eTPUInit error = 0
After eTPUInit
Enter to continue...
EncoderInit error = 0
After fs_etpu_qd_init
Enter to continue...

Before the eTPUInit call, the encoder will put nice clean pulses on my 'scope when I twist the shaft. After the eTPUInit it still will. After the fs_etpu_qd_init call, it will allow a few pulses, then seems to go into output mode. Both channels are pulled low, I can see them trying to go high when I spin the encoder, but they are only about 0.1V.
The encoder is a magnetic encoder, the outputs pull up in the encoder to 5V, I have 1K resistors on both channels between the encoder and the MOD5234 inputs to protect the inputs.
The encoder does not seem to count the pulses that I see on the scope.
??
Sam

I use the following for QD init. Try this.

fs_etpu_qd_init(GPIO_ENC_A,
0,
0,
FS_ETPU_QD_PRIM_SEC,
FS_ETPU_PRIORITY_MIDDLE,
0,
FS_ETPU_TCR1,
0, 0, 0, 0, 0,
0,
0,
0, 0, 0,
FS_ETPU_QD_ETPU_A_TCR1_FREQ,
15);

fs_etpu_qd_set_pc(GPIO_ENC_A, 0);

fs_etpu_qd_disable(GPIO_ENC_A, 0, 0, FS_ETPU_QD_PRIM_SEC);

fs_etpu_qd_enable(GPIO_ENC_A,
0,
0,
FS_ETPU_QD_PRIM_SEC,
FS_ETPU_PRIORITY_MIDDLE);

fs_etpu_qd_set_slow_mode(GPIO_ENC_A);

fs_etpu_qd_set_pc(GPIO_ENC_A, 0);


It could be the lack of calls to qd_enable so try them with you code too.

Dave...

Thanks Dave,
I know you've gotten this to work so I have hope. I do have the enables, I just didn't show all my code. But the inputs go to outputs at the call to fs_etpu_qd_init(), before I have a chance for the enables. I can't imagine any reason for those inputs to ever be switched to output mode, even when disabled. I'm suspecting that my set3.h is bad, I think you are using a custom set?
Anyone else gotten QD to work with the standard set3.h?
Sam

FWIW, if I change my eTPU channel to 0 in firmware, instead of the 2 (and 3 for Chan B) that I'm wired to, then the inputs aren't changed to outputs on chan2 and 3, but then of course the encoder doesn't count either. If I change the channel to 1, then only chan 2 is effected. This makes sense since the QD assumes that chan B is one more than Chan A. So I do think the problem is with the fs_etpu_qd_init().
Sam

If I change ETPUInit.cpp to include etpu_set4.h (which also has QD)(instead of set3 that had been giving hardware problems) and rebuild the system files, and clean and build the program, it traps on the call to ETPUInit(). If I set it back to include etpu_set3.h and and rebuild everything, I get the old problem of the channels being turned into outputs.
I'm obviously doing something wrong, either etpu_set*.h should work for me.
I've tried making a custom set but can't get it to rebuild w/o errors.
??
Sam

We have found differences in some code in the different code sets as you have pointed out.

barttech

I've tried making a custom set but can't get it to rebuild w/o errors.

Contact me about the build errors you are seeing.

Most of the standard sets were developed with a different version of the eTPU C compiler than the current release. The development version for the standard eTPU sets is available on the Byte Craft website as part of the support downloads. If you have questions contact support@bytecraft.com.

w..

Thanks Walter,
One of the first problems stems from etpu_qd_auto.h. If I've followed the NB App Note directions properly, after I make my qd and gpio set, I'm supposed to only copy over (and rename) my new etpu_set.h, and overwrite the etpu_qd_auto.h and etpu_gpio.h. The rest I'm supposed to ignore (if I read the AN right). If I do that I get errors since the fs_eptu_qd_init() in etpu_qd.c (the old file from NB) is looking for FS_ETPU_QD_HOME_INIT and FS_ETPU_QD_INDEX_INIT in etpu_qd_auto.h, but they aren't there, although they are in the original etpu_qd_auto.h.
I also tried replacing everything from the _etpu_set package. This resulted in the missing file "typedefs.h". I think NB uses <basictypes.h> for this, but I'm not sure they are interchangable.
Any help you can give would be appreciated.
Sam

Hi Sam,

Do you actually use the INDEX and the HOME inputs as part of your QD input?

If not, why not set those values to ZERO as per my init code or at least try with them set to ZERO?

Can you post your SET and I can see it it works here?

Dave...

Dave,
I'm using the pre-defined ETPU_CHAN_NOT_USED which is -1, I'll tried the 0 instead but it made no difference.
I've attached my etpu_set file, I'd be glad to hear if you can make it work. I know I've got something weird going on with one of my NB setups but I think one is working properly, and both of them give me the same results as far as the interaction with the encoder is concerned. If I use set3 it sets the encoder channels to inputs, if I use set4 I get a trap when I call ETPUInit(). If I use my custom set (just QD and GPIO) it just doesn't seem to see the inputs, ie it doesn't count when I spin the shaft. I know I've got the connections right because if I just use a J2[8].Read() it picks up every pulse.
Thanks!
Sam

I just found that my system has two instances of ETPInit.cpp. The App Note for ETPU says:
"To switch between sets you must change the included set file in ETPUinit.cpp. After the
set header file is changed then the MOD5234 system directory must be recompiled to
reflect the changes. "

It seems I have sometimes been changing the one in nburn/MOD5234/system/etpu and sometimes the one in
nburn/MOD5234/include/etpu. I hadn't realized I was doing this. I assume the right one is in the system directory since that is one that gets recomplied, but is that so? Should I delete the one in include?
Sam