MediaTek-Labs / mt3620_m4_software

mt3620_m4_driver
Other
32 stars 29 forks source link

Data splitting on High Level App when receiving data from UART. #38

Closed nishithvpoojary closed 3 years ago

nishithvpoojary commented 3 years ago

Hi... I am using the FreeRTOS MBOX sample. Why does HLApp display only 12 bytes of data? The rest of the data is displayed on the next line. What should I do if I need it to display more data? Thank you.

kevinwh-chou commented 3 years ago

Hi,

Not sure if any of the setting in your Visual Studio has been modified? Here is my output for HLApp from FreeRTOS MBOX sample, it displays what's received or what's sent from/to each RT cores in one line.

HLapp_output_MBOX

BTW, I'm using Visual Studio Enterprise 2019.

nishithvpoojary commented 3 years ago

Hi,

Not sure if any of the setting in your Visual Studio has been modified? Here is my output for HLApp from FreeRTOS MBOX sample, it displays what's received or what's sent from/to each RT cores in one line.

HLapp_output_MBOX

BTW, I'm using Visual Studio Enterprise 2019.

Thanks for your response. I too use Visual Studio 2019. I got perfect output for this. But if you increase the message bytes that has to be displayed in the HLApp, then the message gets cut and is displayed in the next line. If you check the Azure UART High Level App Sample, there they have mentioned about this in Readme.md that the receiving message splits. How can I avoid this?

LawranceLiu commented 3 years ago

I tried to reproduce this issue by increasing the string length from 15B to 50B. And everything still works fine.

Here is my SW modification: RTApp main.c: image image

HLApp main.c: image

Test Result: image

You could try to have the same modification and see if you have the same test result.

nishithvpoojary commented 3 years ago

Thank you very much LawranceLiu. I got the same output. Will this work if I have to receive large amount of data? I removed RTApp B and now I am using only 1 RTApp(i.e.. RTApp A). I connected a jumper wire on Click1 Tx Rx(Loopback) and sent the RTApp A output to the Click1 and I'm trying to display the RTApp A output on the High Level App itself. I removed the "Hello World" conversion program on the RTApp A main.c and I put Click1 Rx data to mbox_buf[i]. This is what I used as given below.... mbox_buf[i] = mtk_os_hal_uart_get_char(uart_port_num1)

kevinwh-chou commented 3 years ago

Will this work if I have to receive large amount of data?

The max message size per transfer between HLapp and RTapp is 1KB, see here. Then probably that's the cause, exceeding the max size?

nishithvpoojary commented 3 years ago

Will this work if I have to receive large amount of data?

The max message size per transfer between HLapp and RTapp is 1KB, see here. Then probably that's the cause, exceeding the max size?

Even when I have to transfer 14 bytes, only 12 bytes get displayed on 1 line and 2 bytes get displayed on the 2nd line. I want to receive the data from HLApp the way I sent it from RTApp.

nishithvpoojary commented 3 years ago

I tried to reproduce this issue by increasing the string length from 15B to 50B. And everything still works fine.

Here is my SW modification: RTApp main.c: image image

HLApp main.c: image

Test Result: image

You could try to have the same modification and see if you have the same test result.

I tried using the "Hello World" conversion function inside this "for loop"... I got this Output image How can I remove these dots... Did u get these too?

What is the use of this line in below image? image

LawranceLiu commented 3 years ago

Hi nishithvpoojary,

mbox_buf_len@CM4 specifies the length of the message to be sent to CA7. It includes the 20byes header. So, when you set it to 70, it means you want to send "20bytes header+50bytes data" to CA7. This sample code is just to show the message length 50B is still works. Please configure it according to your real message length.

bytesReceived@CA7 specifies the length of the message received from CM4. It does not include the 20bytes header. If you have mbox_buf_len=70@CM4, you will see bytesReceived=50@CA7. And the following is the reason why you see the dots. image

nishithvpoojary commented 3 years ago

Thank you LawranceLiu. I was able to learn various things from your explanations. I use Starter Kit Rev2 I tried to receive varying data from the Clicks, I tried to measure the length of the data in the ISU2 port and use it as " mbox_buf_len=sizeof(OS_HAL_UART_ISU1)". It didn't work. And if I have to transfer 10Kb data from RTApp to HLApp and if the max data size to transfer data from RTApp to HLApp is only 1kb, is there any possible way to keep on sending a certain number of data until all the data is sent?

LawranceLiu commented 3 years ago

Hi nishithvpoojary, You could refer to the UART sample code here: https://github.com/MediaTek-Labs/mt3620_m4_software/blob/master/MT3620_M4_Sample_Code/FreeRTOS/MT3620_RTApp_FreeRTOS_UART/main.c#L91 And you could try to write a simple function or while loop to get the 10KB data.

Then, you could try to send the data from CM4 to CA7 by 1KB for 10 times.

nishithvpoojary commented 3 years ago

Hi nishithvpoojary, You could refer to the UART sample code here: https://github.com/MediaTek-Labs/mt3620_m4_software/blob/master/MT3620_M4_Sample_Code/FreeRTOS/MT3620_RTApp_FreeRTOS_UART/main.c#L91 And you could try to write a simple function or while loop to get the 10KB data.

Then, you could try to send the data from CM4 to CA7 by 1KB for 10 times.

Thank you LawranceLiu. Will try it and respond.

nishithvpoojary commented 3 years ago

Hello. Sorry for the late reply. Sending more data works fine. Thank you very much. I have made few more changes, Now I used the Tera Term terminal as input in RTApp and I'm trying to send the data to HLApp. I have removed all the sending functions in the HLApp. But it is not working. Do I have to set a timer for the receiving functions? When I set the timer my output is as below....

image

I have also made sure that the terminal input data is sent to the buffer. There is some problem with the HLApp receiving part. Please help me with this... I also have one more doubt. Does this have anything to do with the Component Id being little Endian or Big Endian? Thank you.

LawranceLiu commented 3 years ago

Hi nishithvpoojary, I would suggest you based on the exisiting MBox HLApp/RTApp as the golden example. Modify it step by step and see if everything still works. I'm not sure what's the purpose of the timer, but the current MBox HLApp/RTApp shows you how to send/receive message between CA7 and CM4 without using a timer.

Regarding the ComponentId, you could check it in the following files: app_manifest.json launch.vs.json The ComponentId does nothing to do with the Big/Little Endian. All you have to do is to make sure the ComponentId does match in the above files of HLApp/RTApp.

nishithvpoojary commented 3 years ago

Sending data from HLApp to RTApp and then sending it back again works perfectly. But when I remove the sending functions from the HLApp and when I try to take data from buffer, it doesn't work. I made changes in RTApp so that I can input data to RTApp using Terminal. I have have checked that the msg is moved to the buffer. But the HLApp wont take it. So I thought timer was necessary as the HLApp wont know when to take data from the buffer.

LawranceLiu commented 3 years ago

Hi nishithvpoojary, I'm not sure what happened in your HLApp/RTApp, but I tried to write a CM4 to CA7 unidirection MBox message sample code for your reference.

HLApp: Remove the send logic. image

RTAppA: Send 8 byte data. image

RTAppB: Nothing to be changed.

Test Result: image

I hope the above example could help you fix the issue.

nishithvpoojary commented 3 years ago

I don't have any output. image

HLApp Changes image

RTApp Changes image

image

LawranceLiu commented 3 years ago

Before you apply the patch, remember to rollback all your local modifications. The sample code is to show you when sending a 8 Bytes MBox message from CM4 to CA7, you should have a 8+20 bytes buffer.

LawranceLiu commented 3 years ago

Welcome to reopen it if any further discussion.