AnsweredAssumed Answered

Does ST have any control over the serial comm protocol?

Question asked by Andrei Chichak on Dec 17, 2014
Latest reply on Jan 16, 2015 by Andrei Chichak

I'm quite sure that I don't understand the expected use of the SPWF01 modules. Perhaps I've been doing this stuff too long and have become a crufty old guy, but the command/response protocol seems like it's written expecting a human on the end of the serial port instead of a micro. Help me out here.

Here's the problem; the wifi modules have a response structure that is great for humans but a tad odd for parsing by computers. If I was to use the facilities of C for a parser, I would use something like gets() to get input up to the end of line. The module prepends cr/lf to its responses, so it looks great on hyperterm, but it terminates a gets() call before getting to any actual data. So, I have to bring in a "whole bunch" of data and parse it. The alternatives are to know the number of characters to expect, keep reading until you hit a terminator, or wait for a timeout.

Okay, bring in a bunch of data and look for the terminator. The terminator comes first, then a bunch of data, then a terminator. Well, that's going to be a weird parser, do two pieces perhaps, but what if it isn't a response. AND all of this stuff is coming "in band" with my application data being transferred. If the module messages had some kind of "escape sequence" in front of them instead of cr/lf I could write a parser for that. 

The messages don't have a standard length of response, so you can't just use a read X characters.

Then the messages have to be parsed, so every single customer had to write an english language parser, instead of a machine to machine <escape><command><data><terminator> packet that can be used directly. Or JSON, or compact binary - anything is better than human readable - after debugging there is no human.

Next, to get reasonable throughput I run the module at 115,200 baud, but the backend processor (STM32F407) will overrun unless I use interrupts or DMA input (since it doesn't have a hardware UART FIFO like the old NS16450s). To get interrupt or DMA input running on the F4 (and others) HAL from CubeMX, you have to tell the input routines how many characters to receive or else they will hang waiting and give you a busy return if you ask for too many, or get out of sync if you ask for too few. BUT the SPWF doesn't give a byte predictable response size, therefore you have to use polled or single character interrupt input and run at a lower baud rate to avoid overrun (or rewrite the HAL to give partial results). Typically you would expect "<cr><lf>OK<cr><lf>" for a count of 6, but you might get an error with its own format and length, so you have to expect the longest possible packet and parse it.

Do you ask for 100 or 200 characters and hang on a timeout, then somehow clobber the interrupt and see what is left in the receive buffer? Do you bring in one character at a time until you hit the terminator (which are the first characters so you don't actually get the data, you see where this is going?)? Or do you rewrite the HAL interrupt routines?

Many questions. Basically, does ST have any flexibility in this project, or are the developers just working with what the original company sold them, expecting that someone thought about how the customer will actually use it?

Outcomes