MOD5324 ETPU pin help

[seulater]

i need 16 GPIO pins, since the ETPU pins available I figured I would use them.
I looked at the examples and found that the DEV-70 kit uses them for the 8-pos switch and leds. However, digging into the code that actually controls those pins is rather lengthy.
I looked in the sim5234.h file and found "vubyte pddr_etpu" for the Port Data Direction Register. looking in the manual this register is only 3 bits! what gives.

I am looking to do something simple like:

sim.gpio.pddr_etpu =0xff; // set this port as an output port

sim.gpio.ppdsdr_etpu=0xff; // set the port high
or
sim.gpio.pclrr_etpu=0xff; // set the port low (clear)

Though I have tried the above with no success.

anyone used pins J2-5 through J2-20 without using the built in libs to control them ?

[lgitlitz]

The eTPU channels are not part of the GPIO peripheral so there is no CPU register to toggle the pins. These will be the slowest form of GPIO on this processor. This peripheral is meant to run complex I/O timing functions independent of the main processor. It is an amazingly powerful peripheral for many types of motor control and complex sensor reading but not so great for quick I/O response from the main CPU.

This peripheral is actually its own processor that runs microcode and has shared RAM with the main CPU. There is no direct connection from the main CPU and the the eTPU channels. When you toggle an eTPU output in GPIO mode, the main CPU first writes that value to the shared RAM. The eTPU is running its own microcode that uses this value to set the channel value. When the GPIO is set to be an input then the eTPU microcode will constantly poll this channel and then change the shared RAM when it sees a change in the channel. One nice feature of the GPIO on the eTPU is that every channel can be configured to trigger an interrupt on input change, but this will still have a bit more lag then the direct IRQ lines.

[Ridgeglider]

Seulater: I have used the 5234 on the 5270LC board quite a bit... Sometimes I've run into issues because the eTPU is on the same pins as the LEDs and DIPsw. However, I've found that with care you can often tiptoe around that setup and get useful, easy GPIO without burrowing deep under the hood. On occassion I have de-soldered several of the pullups on the switch lines, or the LED current limit resistors as a last-resort workaround. On the other hand, if you don't need the LEDs or DIPsw, the Mod-Dev-50 board is pretty good for quick proto use. I typically use the NNDK_etpu_set.h which includes: GPIO, PWM, IC, OC, FPM, PPA, QOM, TEST, SPI, UART, UART_FC functionality super easily. The GPIO uses the standard pins class API for J2[5] to J2[20] as you requested. The necessary #includes are in C:\Nburn\MOD5234\include\ETPU. For some reason, the eTPU examples do not seem to have made it to the C:\Nburn\examples\MOD5234 folder (NB Guys, take note!).

I've zipped a bunch of eTPU examples and appnotes that it sounds like you may have missed. (If any of the NB team read this, please consider adding an AppNote folder to the standard distribution so these kind of things are a bit easier to locate.) Some of the ZIP contents are from a distribution Larry posted a year or so ago somewhere(?). Another example is also a later yahoo-post from Larry for an eTPU fd-based UART. You probablyFinally, I included a little excel chart I use that clarifies the use of the 5234 on the 5270LC board. The AppNote shows you how to use the typical pins class to control eTPU IO. It may be a bit slow, but it works in the standard way for many apps while also supporting all the cool eTPU functionality as alternate configurations for all the pins. The simplest example is:

#include <pins.h> //These includes should go after any standard includes
#include <eTPUinit.h>
#include <eTPU.h>
eTPUInit(); //Call once with initialization functions, puts all channels in hiz state

while(1) {
J2[10] = 0;
OSTimeDly( 2 * TICKS_PER_SECOND );
J2[10] = 1;
OSTimeDly( 2 * TICKS_PER_SECOND );
}

Hope it helps, and hope it all goes thru as a fairly big zip attachment. If not, let me know and I can get it to you some other way.

[seulater]

Thanks guys for the help and the quick responses.
After I made this post I then found the eTPU example on the MOD5234 page. I gave it a whirl and Larry is right it is WAY to slow for GPIO usage in my application.

Here's the deal. We made a product that used the MOD5270 which worked great! Upper management then decided that we need a industrial temp version as well. So I went with the MOD5234. In my haste to get the PCB out I used the data bus on the MOD5234 like I did for the MOD5270. The only problem was that when the boards came back nothing worked because I over looked the fact that the data bus on the MOD5234 is the most upper data pins and cannot be used for GPIO like the MOD5270's can. So now I am in a panic, I cut the foils and soldered the 16 address/data pins to the eTPU pins in hope that would get me out of this jam, but as Larry mentioned it is desigened for a whole other purpose that GPIO and thus makes it way to slow for GPIO use.

My external IC does have ~CS, ~RD & ~WR signals, and in earlier versions of the mod5270 I have tried to get this IC to talk on the bus but with no success. The best I was able to do is read from it, writing proved unsuccessful. Its clearly a timing issue, with the R/~W pin on the mod5234, and when I moved the ~WR pin from my IC to the ~BS3 pin I could then write to it but not at full speed. It get flaky now and then. I have used other things on the MOD's bus before and they worked fine, but this IC just has me stumped why its not working.

My next plan is to slap something like a '573 to latch the outgoing address and data signals to my device, once they are latched I can then tickle the ~CS, ~RD & ~WR signals on my IC to read in that data. Its a total hack and I hate it, but I just cannot get it to work on the address and data bus on the MOD boards. If anyone has any suggestions please feel free to throw them out. If someone loves a challenge I have the data sheet, I tried attaching it here but this site does not allow .pdf's for some reason.

This chip is a ML7204 from OKI, its a VoIP Codec IC