the blocking HAL_Receive will be fast enough to
nothing else.
* so it won´t hold up UART receive ... but it will stall all other activity
It is well known (and discussed here) that blocking functions are ineffective.
It is well known that blocking functions stop any other software activity. (besides ISRs)
but indeed I find these "what if" and "theoretically" discussions rather useless.
thus I ask myself. Knowing all this. Knowing all problems of blocking funcions.
--> Why do you insist in those (problematic) blocking functions.
* when one knows how to avoid problems. Why you don´t even try to talk about it? It seems you like those problems.
Believing means "not knowing".I don't believe that HAL_UART Receive nor Transmit has less than couple of thousands instruction. There comes my doubt.
Wrong math!For 1Mbaud it has 1 uS
I agree. The user will be much slower than the microcontroller.And how fast the user can take the data before new byte arrives.
Your "believe" is so far from reality.I don't believe 3440 instructions per 86 us or 40 instructions per 1us is enough to read the whole receive function both for receive and for receive IT.
Believing means "not knowing".
The better way is "to know".
--> So just compile the code and look at the machine code. (or look at any compiled code of your choice)
I guess if there were 10 more people telling you, you still won´t believe. So it´s useless for us to further discuss.
1Mbaud = 1000000 bits per second.Wrong math!
Your "believe" is so far from reality.
10, 15, 30 machine instructions....Okey approximately how much instruction can receive function have ? From top to bottom of that function. Just approximately.
so you already did a test? .. but are too lazy to measure the time between start and return of the function?But it somehow worked.
10, 15, 30 machine instructions....
As already said: Some C lines don´t cause machine code
And not every machine code that exists needs to be executed. For example when an "IF"-condition is not true.
Minimally it´s just
* waiting for a byte to be received. (that´s the blocking part)
* Read the UART_data into a register
* Write the register value to the SRAM
* Increment SRAM address pointer.
so you already did a test? .. but are too lazy to measure the time between start and return of the function?
something like: (pseudo code)
* while UART_receive_empty; // just to ensure the HAL function does not need for a byte to receive .. and thus gives false high timing values
* uint32_t tMeas = micros();
* HAL_UART_Receive...
* tMeas = micros() - tMeas;
But now I will leave the thread. It´s way overdue.
Please do internet search on your own. Do tests on your own. SET/CLEAR port pins and use a scope.
Use the microcontroller internal features for debugging.
When I started microcontrollers we had no internet , need to find out every simple thing on our own.
There are so many documents, explanations, application notes, videos, tutorials...
Now that you have internet: use it.
you are just talking nonsense. All you do is "not read" but talk/write.But at least I try. The thing is I just don't know how to check it or measure it.
At A - You really don't care how long this part takes// A
HAL_UART_Transmit(tx_buffer, tx_length, HAL_MAX_DELAY); //B
// C
HAL_UART_Receive(rx_buffer, rx_length, HAL_MAX_DELAY); // D
// E
you are just talking nonsense. All you do is "not read" but talk/write.
What did you try? I see nothing.
I gave you at least three different ways to measure timing on your own.
But still you only talk and worry, but you did nothing I recommended.
But now I will leave the thread. It´s way overdue.
Please do internet search on your own. Do tests on your own. SET/CLEAR port pins and use a scope.
Use the microcontroller internal features for debugging.
When I started microcontrollers we had no internet , need to find out every simple thing on our own.
There are so many documents, explanations, application notes, videos, tutorials...
Now that you have internet: use it.
At A - You really don't care how long this part takes
At B - As has already been mentioned, the actually executed code is probably only a few 100 machine instructions, but again you really don't care as the complete command has to be sent before the 'other' device will start responding. This function will not return until at best all of the values have been queued and at worst all of the values have been sent. Bottom line- you don't care about the timing here either.
At C - Here you really CAN spend a lot of time that will really mess up the timing. However this part is totally under your control. Do nothing here and there is no delay.
At D - @KlausST has already gone over this part. Yes there will be a very short preamble before it starts to read the received values, but then it will sit in a very tight loop until it has read as many values as you ask it to (in the 'rx_length' parameter). Once the last character has been received this function will return but by then you have stopped caring about the timing.
At E - Do what you like. If the 'other' device sends values when you are here, then you have not coded to handle the reality of that other device
There has been mention of SPI and I2C.
The key difference between these and the UART is that SPI and I2C have a 'master' that controls the transfer - the 'other' (often called the 'slave') simply responds.
SPI is an exchange standard. The 'master' will only ever receive a value when it sends a value. No send - no receive.
Enjoy learning - but I really do suggest that you learn by 'doing' - start small and work your way up.
In the case of I2C the situation is more or less the same. The I2C packet must contain the address of the 'other' device so the identified deice knows that it is being communicated with. After that it really depends on what the 'other' device is as to what follows. But again, the 'master' has (almost) complete control over the transfer process.
Bottom line: with all of these things, just use them and worry about the higher level operation of your program.
Last option: are you still using blocking functions? Especially on Rx?
My bet is you are.
Use interrupt or DMA as we have been saying all along.
Susan
OK - Im know I'm going to hate myself for saying this but....
Not that we have finally left the hypothetical after 51 posts in this thread,I suggest that you:
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?