topic Re: Sending Packet by UART on KEAZ64 in Kinetis Design Studio

Sending Packet by UART on KEAZ64

stevencornett — Tue, 23 Jun 2015 14:25:46 GMT

I am building an application that requires a response to commands be sent through a UART. I am sending an 11 byte response string at 115200 baud, but it is taking twice as long to transmit than if it was send as one block.

I looked at the UART code, and it appears that the code is sending the data in the block one byte at a time.

Is there a way to pass the send the information in one packet so that we can get the transmission time to the proper period?

Re: Sending Packet by UART on KEAZ64

Alice_Yang — Wed, 24 Jun 2015 06:32:09 GMT

Hello Steven,

(1) Do you want a UART function that send numbers of bytes ?

If yes, which IDE do you use , if you use KDS, you can create e PE project , then utilize the function of

"LDD_TError AS1_SendBlock(LDD_TDeviceData *DeviceDataPtr, LDD_TData *BufferPtr, uint16_t Size)"

the "Size" is the number of bytes.

(2) "I looked at the UART code" , which code ?

Have a great day,

Alice

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Sending Packet by UART on KEAZ64

stevencornett — Wed, 24 Jun 2015 15:35:56 GMT

I am looking at the PE generated AsynchroSerial component for UART1. It has a UART_SendBlock method that I called, where the SerialLdd1_SendBlock function is called, and it is sending only one bit at a time.

Re: Sending Packet by UART on KEAZ64

Alice_Yang — Thu, 25 Jun 2015 01:38:00 GMT

Hello Steven,

As we know, the UART Data register only have 8 bits, so it sending only one byte at a time .

Alice

Re: Sending Packet by UART on KEAZ64

stevencornett — Thu, 25 Jun 2015 12:59:35 GMT

It sounds to me like I've made the wrong point.

I understand that the routine will write to UART1 Data Register one byte at a time, but it's the transfer rate between writes that is the problem with the routine generated by PE in KDS.

It appears to have the effect of creating a delay between character writes such that the packet transfer time is twice as much as expected. Is there example code that uses AS1_SendBlock such that the inter-character spacing is more normal (resulting in a transfer time of 1.05ms instead of > 2ms?

Re: Sending Packet by UART on KEAZ64

stevencornett — Thu, 25 Jun 2015 17:34:49 GMT

I just noticed that you are using the Serial_LDD code package. I derived my UART code from the AsynchroSerial package.

Is the SendBlock implementation going to be slower than the one derived from the Serial_LDD? If so, would it then behoove me to refactor my top level to use routines derived from Serial_LDD?

Re: Sending Packet by UART on KEAZ64

Alice_Yang — Fri, 26 Jun 2015 08:09:15 GMT

Hello Steven,

(1) "AS1_SendBlock" and the "AS1_SendBlock" are the same .

(2)Sorry i can not know your problem clearly. Could you pleas tell me how can i repeat your situation ? Especially repeat "resulting in a transfer time of 1.05ms instead of > 2ms?" thank !

About "have the effect of creating a delay between character writes" ,i have checked the code , there have not intended delay, the delay is the necessary configuration .

Alice

Re: Sending Packet by UART on KEAZ64

stevencornett — Fri, 26 Jun 2015 12:09:50 GMT

Instead of using the SendBlock function in the Serial_LDD component, I loaded the AsynchroSerial UART component and used the UART_SendBlock routine from that component.

They may be the same in the prototype level, but the later calls the former.

Re: Sending Packet by UART on KEAZ64

stevencornett — Fri, 26 Jun 2015 12:38:27 GMT

Here is a scope trace showing the issue.

The bottom trace (Channel 2) is the packet put out on the UART TX line. If the byte-to-byte spacing is the way it ought to be, it should take up a little more than one major division of the scope, or 1ms. It's taking up two milliseconds, or two divisions.

When you run a packet through SendBlock in Serial_LDD, what are you seeing?

Re: Sending Packet by UART on KEAZ64

stevencornett — Mon, 29 Jun 2015 20:10:40 GMT

Does that mean that, for the KEA64, the functions to send and receive block data are really only capable of passing one character at a time?

In which case, the ReceiveBlock can only capture one byte at a time, and can only take 1U as the length parameter? Is that the same for the SendBlock function as well?

Re: Sending Packet by UART on KEAZ64

Alice_Yang — Wed, 01 Jul 2015 07:22:13 GMT

Hello Steven,

The baud rate 115200 meaning UART can transmit 115200 bit every second .

And you can use the " time / bits " , the result is about 115200 .

Hope it helps

Alice

Re: Sending Packet by UART on KEAZ64

stevencornett — Mon, 20 Jul 2015 18:23:19 GMT

(2)Sorry i can not know your problem clearly. Could you pleas tell me how can i repeat your situation ? Especially repeat "resulting in a transfer time of 1.05ms instead of > 2ms?" thank !

About "have the effect of creating a delay between character writes" ,i have checked the code , there have not intended delay, the delay is the necessary configuration .

Which code are you talking about? Are you using an interrupt-based (non-blocking) TX and RX setup with the Serial_LDD routines? I was using the AsynchroSerial library generated by Processor Expert.

Do you have sample code for the earlier, if you created it with Serial_LDD?

Re: Sending Packet by UART on KEAZ64

stevencornett — Thu, 06 Aug 2015 20:27:23 GMT

When nothing intervenes between the characters, then the transfer time is reasonably close.

However, the library I was using incorporates a EnterCritical() function just before the transmission of each character. That adds about 109 microseconds per character send; for 11 bytes that adds more than a millisecond to the transfer time. Once I put the EnterCritical and ExitCritical functions outside of the loop, that fixed the problem.

I figured I should make mention of what the solution finally turned out to be.