robot
Posts: 3
Joined: Sat Nov 14, 2015 7:40 am

MICO 2.3.0.2

Wed Dec 09, 2015 6:37 am

Hi everyone - i've had great success with the MICO 2.3.0.2 - the framework is quite decent. I have been removing libraries to lighten the footprint, which has been productive.

I have heavily modified the \Demos\COM.MXCHIP.BASIC\http\http_server project from the 2.3.0.2 version

I have also modified the UART hardware definition to include CTS and RTS flow control, which is necessary for my application because it runs at 3.3 mbps on both uarts

Now, i've examined the code regarding the ring buffer, and the STM32 UART wrapper - i do have one question... When the ring buffer is full, does the flow control of the UART also get used in this scenario? Meaning, does the dma use the flow control to stop additional information from being transmitted from the remote host?

I have a remote device connected over UART that is transmitting data to the 3165 with flow control at 3.3 mbps. The data being read from the UART is transmitted over TCP. Now, if the DMA ring buffer is full becauase the TCP is slow and the data has not been transmitted, will the DMA use flow control to tell the UART host to stop sending with the CTS/RTS?

Or, am i supposed to do this pragmatically?

petesoper
Posts: 10
Joined: Mon Dec 07, 2015 2:02 am

Re: MICO 2.3.0.2

Tue Dec 22, 2015 4:45 pm

I'm a beginner with the EMW3165, but I've studied the STM32 platform uart code and the STM32 chip datasheet a little bit recently and I'm convinced that if the hardware flow control is being properly enabled (still picking through the config code), the mechanism would have to be the opposite of what you conjecture: the USART would postpone it's next request to the DMA engine for another byte of data. This holds off the DMA completion, which holds off it's interrupt, the completion semaphore, and so on. As far as I can see the init code does the right thing to set up flow control at the lower level than your changes.

But what I find interesting is that control does not return from this function (platform_uart_transmit_bytes) until the last byte has gone to the USART and the final USART transmit completion happens. I guess this is why you're using such a high baud rate: to minimize the time spent hung in that empty while loop! I was very surprised to see this code the way it is. So the point of using the DMA engine is to avoid per-character interrupt handling complexity? I guess all of this code is designed for proof of concept prototyping. Not being able to accomplish other work during a send is a real drawback. I'd love to find that I've missed something basic and the driver is not so trivial as it seems.

Also, in your "introduction" posting you asserted that Lua can't be transparent for byte data because strings have to be null-terminated. This isn't true. I've been teaching myself Lua and recall one of the designer's tutorials asserting that strings do not use C-style null termination. But even if they did, the null terminator in a C-style string is not part of the string. So I think you should revisit your "problem #1" in the other posting.

Best of luck with your project. I'm also exploring the Smart Arduino wifimcu and see the Lua implementation is a tremendous convenience for learning about the board. My first "lesson" was about the watchdog timer interrupt: forgetting to "pet the dog". :)


Return to “Firmware Development”

Who is online

Users browsing this forum: No registered users and 1 guest