Using the HAL drivers, it seems that every communications routine (I2C, USART, SPI) has to know exactly how many characters to send, and exactly how many to receive.
Now for sending, that's never a problem. For reception, that's been a constant problem.
Look, for instance, at the I2C slave.
Tell it to receive a message, and it wants to know how many characters. What if you don't know? So tell it the size of the buffer and call the HAL routine, say it's just the programmed/blocking one.
Good, so it returns when the master does a stop condition. What does it return with? HAL_ERROR. Why, because it didn't receive the X number of bytes....
Checked the error conditions after the call, but they've been reset.
Howabout we expand the definition of the HAL errors a little, to give us a better idea of what's going on without having to write the error callbacks?
How about when talking I2C slave receive, getting a STOP condition at the end of the message *doesn't* generate an error?
Looking at the normal serial data, well, unless you use a delimiter character, you never know when the data is done. However, there's no routine that even allows you to have this option.
For SPI, we have all transmissions and receptions under control of the master, so we know all that we need to know.
Can we (at least) get more documentation on the response of these modules under error conditions (and perhaps even the responses out so they make a bit more useful sense)?
