topic Re: Virtual shortcircuit ? in MQX Software Solutions

Virtual shortcircuit ?

nitinharish — Mon, 14 Dec 2015 19:22:40 GMT

I am using MK64FN1MOVMD12 device.

I want to pass through data between PTE9--->PTC17 and PTC16--->PTE8 WITHOUT any CPU intervention, sort of like a virtual short circuit between the pins. Diagram below (virtual connections are drawn by the RED, GREEN, PURPLE, ORANGE lines):

I have tried configuring the PINS as UARTs and then used DMA but this approach entails setting up the baud rate (which I don't want to do as my chip is unaware of any baud rate), secondly I have tried configuring them as GPIOs and then using DMA but again the shortcoming is GPIO DMA trigger acts PORT wise not PIN wise.

What is the smartest way of doing it other than physically shorting the pins.

Any MQX/Kinetis experts want to pitch in ?

mjbcswitzerland, soledad, DavidSeymour, RadekS, macl, Jorge_Gonzalez , sito, danielchen, foosechek, ed_smith_mqx_level2

I am sure, I am NOT the first one to have this sort of application !

Thanks and Regards

Nitin

Re: Virtual shortcircuit ?

GarySegal — Mon, 14 Dec 2015 21:25:36 GMT

Nitin,

Can you provide details on the type of signals you want to connect? What are the minimum and maximum frequency? Are there any latency limits? If there are any other details about the signals that will help, please share.

There is no "virtual short circuit" available between GPIO pins on Kinetis devices. There are ways to move data between pins without CPU intervention by using the various communication ports and DMA, but each port brings different trade offs. I see from another thread you started that you've explored using UARTs, but it does not appear to meet your requirements. If you can provide more information, that will let us determine if your requirements can be meet by the K64's hardware.

Thanks,

-Gary Segal

Re: Virtual shortcircuit ?

nitinharish — Mon, 14 Dec 2015 21:36:08 GMT

Thanks GarySegal,

My data is SERIAL, which can vary from 4800 to 115200 baud but at any given time I do not know what is the baud.

DMA with serial needs Baud rate registers to be set, which I cannot do!

DMA with GPIO triggers on port basis and even destination is also PORT wise NOT pin wise.

I have both of the above working BUT both do NOT meet my requirements.

Re: Virtual shortcircuit ?

mjbcswitzerland — Mon, 14 Dec 2015 21:51:16 GMT

Nitin

Is it not possible to move the PTC16 (UART 3 Rx) input to PTB10 (UART 3 Rx input)?

Wouldn't that solve all problems in allowing the DMA-port-mirroring method to work on all 4 links?

Regards

Mark

Re: Virtual shortcircuit ?

GarySegal — Mon, 14 Dec 2015 22:23:14 GMT

Can you make pinout or other hardware changes?

Could you add an external circuit to connect the lines when needed?

Thanks,

-Gary Segal

Re: Virtual shortcircuit ?

nitinharish — Tue, 15 Dec 2015 16:02:42 GMT

Thanks mjbcswitzerland, I wish that was possible but it is NOT, as all other ports are used for something else at this point.

I was wondering if their is some sort of autobauding possible with DMA/serial ?

Re: Virtual shortcircuit ?

nitinharish — Tue, 15 Dec 2015 16:04:52 GMT

Thanks GarySegal, Both are NOT possible at this stage. We have many boards already produced.

I was hoping this to be very simple but surely it is NOT !

Any other trick up your sleeve ?

Re: Virtual shortcircuit ?

mjbcswitzerland — Tue, 15 Dec 2015 17:34:51 GMT

Nitin

There may be a "final" possibility:

1. Use the DMA based port-mirrorring on three of the four channels, leaving your PTC3 to PTD7 not yet solved.

2. Configure PTC3 as CMP1_IN1 input.
Program the comparator's DAC to half-rail, connected to the CMP's other input.

Configure the comparator to generate DMA on rising and falling edges

Use the DMA to trigger the same port toggle as the other channels do.

This would result in the same behavior but using the CMP as trigger on PTC3 rather than the port input trigger that the others can use.

Regards

Mark

Re: Virtual shortcircuit ?

GarySegal — Wed, 16 Dec 2015 18:55:34 GMT

Nitin,

Hmm, this is really a tough set of requirements you've got. This is a unique set of constraints that I've not seen at other customers nor have I found similar issues on this community or NXP internal problem databases.

The best approach is to find a way to use the UARTs, as that will give the most reliable data transfer. If the baud doesn't change frequently, an auto-baud approach could work but you might loose some data during rate changes. Further, the K64's UARTs don't have an auto-baud feature, so it would have to be implemented in software. Auto-baud is not in MQX 4.2, so you'd have to implement it yourself.

It might be possible to over sample the input lines and then drive this over sampled data to the output lines. For example, a timer could be programmed to generate DMA requests at a frequency of 115,200x16 or faster (1.8432MHz). The DMA would then read the RX pins and write to the TX pins. However, since all of your pins are not on the same port, this would have to use two DMA transfer for PTC and PTD. The 2nd DMA transfer would need a 2nd timer channel to trigger it.

I'm not sure how well this would work as the resulting transmit signals would be time quantized to the DMA period. Some baud rates might not fair well through this. Higher DMA rates might help, but of course this comes with the cost of greater bus bandwidth. Depending on what else is going on in the system the DMA transfers could have a system level impact.

Thanks,

-Gary Segal