Timing in digital signals.

[Xenon02]

Hello !

I've wanted to ask for a need teaching help. I wanted to learn more about digital circuits itself, so I've been playing around with STM32 nucleo boards.
The things I was pretty much lost was about signal timings and timing itself, I'll try to describe it as best as I can, if there are any problems please give let me know I'll try to clarify everything I want to ask, also I want to add that there won't be any code, basically theoretical stuff I wanted to understand or know the place where I can read about it.
First of all is timing in digital signals, I've stumbled in this timing thing in some places and didn't understand how do they affect to each other sometimes. One of these occurance happened while trying to find out why my ESP8266 didn't work as I2C slave (which has been resolved), one user said that the I2C standard speed is like 100kHz and the ESP chip has a clock of 80MHz and he somehow calculated that the chip has like 5us time ??? This is the first thing which confused me in man ways in the way that I didn't know what one frequency had something to do with another frequency but okey. I found out that timing can be pretty helpfull in some situations, but didn't know how to approach this topic, I can imagine some stuff but couldn't find the conflicts in it or this "gap" of free time.

Second thing is maybe a bit weird to ask but okey.
I also have a hard time imagining how fast are some protocols/functions/communication lines etc. like it is in ms,us, ns. Some say it is fast or not but it is less than a second and I find it sometimes hard to say whether it is fast or not ...
Also I just found out practicing programming that the amount of code doesn't say whether the whole code is proceeded slower, or faster, even small code can be proceeded slower than the longer code.
But basically I had a problem understanding like the communication lines like UART or I2C, and not in concept. I know that UART uses RX and TX lines and sends data using start byte, data, parity byte etc ... and I know how I2C works as well. The problem lies somewhere else, to be more specific and to give an example, I have 2 devices, one is STM and the other is let's say a Bluetooth device. I have to initialize in both deviced UART pins. But here is the thing what if STM32 will initialize his ports faster than Bluetooth device, and will start sending data, in this situation the bluetooth shouldn't even receive or store any data that was sent by STM32 because his pins didn't initialize yet (I know weird example). Why did I think about it like that ? I don't know how each functions are proceeded how fast are they proceeded ! if function starts and finishes in us or ns is unknown for me so I don't know which device will be faster (I know it always works so why bother).
Or another example which still occupies my mind, Let's say we have STM32 which first transmits data (HAL_UART_Transmit), and after that function he calls (HAL_UART_Receive). The device on the other end is already sending data after (HAL_UART_Transmit) call, and (HAL_UART_Receive) is being processed, so data comes while function is still being processes, the data comes with 9600 baud rate, so will the function finishes it's stuff before the full 8 bits will arrive ? How fast will the function finishes it's stuff ? there are other faster speeds/bigger baud rates or faster communication lines like I2C or SPI or CAN (I haven't learned how CAN work yet), USB, PCI-Express.

Those are very random and maybe no one thinks about it but I found it confusing and couldn't find answers to it, so I wanted to ask here if maybe someone know the answers. I am not an expert in those stuff because I know some basics and was having fun with STM32, but these stuff came in mind while setting I2C in both devices and didn't know which one will initialize faster, usually I had a device which didn't require from me to set it's pins to work as I2C or UART, so I wondered how do these people know it will initialize fast enough or something ...

Thanks for reading this long post, have a nice night !

 

[Xenon02]

the blocking HAL_Receive will be fast enough to

Why?
for baud 115200 it has 86uS. For 1Mbaud it has 1 uS
For clock 40MHz 86uS is equal to 3440 machine code instruction executed after 86uS, for 1 us it is 40 instructions.

I don't believe that HAL_UART Receive nor Transmit has less than couple of thousands instruction. There comes my doubt.

nothing else.
* so it won´t hold up UART receive ... but it will stall all other activity

Yup I agree and understand.

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)

Yup ISR is better that is understandable.

Although I wonder how it works In context of taking data from buffer to the microcontroller buffer SRAM.

ISR UART that was let's say called at the begging of the program and can wait for infinite for the data so there is no problem in calling it. The other problem comes because ISR has lines of code like any other functions either if it's blocking or nonblocking.
So is ISR fast enough to read it's lines of code / lines of instructions to take data and put them in microcontroller buffer then read that happens in ISR call back and go back to be waiting again for new byte before even new one will come while UARt is doing ISR callback function.

So many if. I know it works but I don:t get it why they are that fast.
I understand the analogy with mail box but this is different it's like we have the person that takes the mail has to be fast enough to pick mail before next one comes.


So it is all up to user which in this context is software. Hardware will handle it but on the side of software. And how fast the user can take the data before new byte arrives.

but indeed I find these "what if" and "theoretically" discussions rather useless.

Yup I know it works so why asking question on what if.
Because I don't get it why it is that fast. And there are other interfaces like I2C it is faster. So how software or rather how fast is the microcontroller to read and execute all lines of Instruction of receiving function before overflow

Although the functions are called one after another like in my examples for blocking I don't believe that the whole function of receive is less than let's say 3000 machine codes. Same goes to nonblocking like ISR it trigger when data is full then he has to take the data from UART buffer and put it in STM buffer so there are more lines of code/lines of machine code to read for 1Mbaud it has 1 us time to read data. Each instruction for 40MHz is 25ns so after 1 us we get merely 40 instructions read before 1us passes which means new data came and if microcontroller didn't execute all machine lines of receive function then it didn't read what's inside of that UART buffer and the peripheral which is UART will overwrite the buffer and he won't bother whether STM got it in time or not.

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.

Blocking functions is one of them that is my problem. For nonblocking as well like I have mentioned above. 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. For faster interfaces it will be even less instructions like 10 or less for 40MHz clock.

 

[KlausST]

I don't believe that HAL_UART Receive nor Transmit has less than couple of thousands instruction. There comes my doubt.

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.

*********

For 1Mbaud it has 1 uS

Wrong math!

****

And how fast the user can take the data before new byte arrives.

I agree. The user will be much slower than the microcontroller.
Now we came from "timing of electrical signals" --> to speed of hardware --> speed of software --> speed of humans

****
I had an 8 bit AVR clocked at 8MHz and transferred several kilobytes of data
* from AVR_external SRAM --> internal registers --> parallel interface --> FTDI USB bridge --> PC
With an average data rate of 300kBytes/s. (This is 2.4MBits/s.)
Aagin: with an 8MHz clocked 8 bit microcontroller.
If I remember right, then it was in 1024 byte frames with response back from PC to AVR.

It was heavily optimized, mainly written in Assembler, just as speed test.

******

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.

Your "believe" is so far from reality.

Klaus

 

[Xenon02]

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.

I don't know how to check machine code in STM cube ide from c code.

Okey approximately how much instruction can receive function have ? From top to bottom of that function. Just approximately.

Wrong math!

1Mbaud = 1000000 bits per second.
1 bit per 1us
10 bits per 10 us.

So for microcontroller that has 40 MHz, 1 instruction per 25 ns, so 400 instructions after 10us.

My bad.

Is really receive function really that small ? Smaller than 400 instructions ? It's hard to imagine really looking at how big is this function inside.

Your "believe" is so far from reality.

The I change my words. I don't know if 3440 per 86 us or 400 instruction per 10us is enough for the function receive before the time pases which is 86us or 10 us. Which should give overflow. But it somehow worked.

Same goes.with IT I understand the general concept but I am still talking about the speed of reading the instruction code and how many is in that function and if it's able to read all these instruction before overflow.

I know IT works in the background but I don't know when he takes data. Like UART receive IT it works and triggers when data came so he triggers when buffer flag is full. So when he takes the data ? In ISR we do different stuff ehhhhh

Okey I mixed myself and I don't really much know how code works in IT.

Sorry for wasting time ... I lost a bit what is going on and don't know how IT code works or DMA. Not In concept but as code and how fast it is read ... I just didn't understand why it always work everytime I call it although it has delay because microcontroller has to read each line of the code ... Or rather each line of machine code

 

[KlausST]

Okey approximately how much instruction can receive function have ? From top to bottom of that function. Just approximately.

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.

And the ISR does not need to wait. The "receive event" is the condition for the interrupt to be raised. Thus it´s clear when the ISR is called there surely is new data.

Mind that an STM32 is a 32 bit machine, thus maybe it can process 4 bytes at the same time as 1 byte.
In worst case it needs to additionally mask the result and shift the result when only one byte needs to be processed.
*****

But it somehow worked.

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.

Klaus

 

[Xenon02]

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.

I thought it would be much more ...
Well yea good to know. I somehow understand this part. As I understood these variables also take less machine code so that's why it is small like 10,15,30 or so, but maybe not as big like 1000 machine code ? I guess.

so you already did a test? .. but are too lazy to measure the time between start and return of the function?

What did I mean by it worked is that I usually write this command (Receive function), and it worked.
I haven't measured the time because I don't know how ... I am really new to this software etc and it gets really complex what to use where etc.
I haven't encountered any problem yet using these interfaces but I used only single one like 1 UART or only 1 SPI etc.

The problem comes when I have more interfaces like 2 UARTs, what if both are ready then how should I control it, when there is so small gap (small gap I mean for 1Mbaud it is 10us or rather 400 instructions so it must read from both and do some other stuff in the main ... I know there is IT but with IT i also have some problems but I don't know if I can ask here ... ), and I don't know how long each function in C or line code in C takes time.

I know there is sysTick function but it measures only in ms.

I can +/- imagine how fast this function can be I guess ... But for 10Mbaud it could be still pretty hard 1Mbaud maybe not ...
But how it works in IT ? I don't know. I want to check it but also I don't know how... Because I wanted to analizy the IT the same way as blocking Receive 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;

Yes depends on the speed ... Usually I would consider if *uint32_t tMeas = micros(); would interfere in HAL_UART_Receive. What do I mean ? That uint32_t tMeas = micros(); will take some time, which can be a lot, and will cause that microcontroller won't be fast enough to read HAL_UART_Receive in time before new data will arrive in the RX buffer. If you know what do I mean ...

I mean I am a bit scared in timing because they are very small and I don't want to calculate everytime, so I wondered why it worked every single time and when can I receive data a bit later.
Ehh like I see in it that while uart is empty, but what if during the executing the inside of the while stuff the receive is now full, how much time will it take to check again this while if it was bigger ...

There are so many if's I know but even the smaller while makes me think about whether the microcontroller will read this receive on time.
I still do have a problem when it comes to IT and for I2C and SPI that are a lot faster ... That's why I seeked guidance in understanding this part.

So many if's and I worry way to much but I feel like I have to understand. Like I see it and I see like okey I added something before receive and data is coming, will it make in time ?

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.

I know I have internet and I am trying to use it,
I know long before there was no internet, what can I say maybe I am just bad at it ... But at least I try. The thing is I just don't know how to check it or measure it.

I just usually see that no one really watches these times except me, so I couldn't find the source on the internet.
So I decided to ask here on the forum. The problem was that I was asking about the time microcontroller was trying to execute it, but I heard about alternatives, although the alternatives also makes me wonder about time it executed to receive data like for IT, but I don't know how to get that information though. And yea I am from times where internet was from the beginning but I don't know how to find these information's. Sorry for my clumsiness.

Maybe all this confusion came from the fact that I didn't know how to formulate my question ...
Sorry again.

 

[KlausST]

But at least I try. The thing is I just don't know how to check it or measure it.

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.

Klaus

 

[Aussie Susan]

Just to pick up on one point (and possibly go down a rabbit hole...) and then I'm out too.

As @KlausST has said, the UART is asynchronous with respect to the Tx and Rx sides. The work completely independently. That means the Rx side has no control over when the 'other' sender sends over a value. (This is why you sometimes see the Tx side written as blocking but the Rx side almost always as interrupt driven.)

However, given the scenario that @Xenon02 is using where a command is sent and then a response is expected, it would be very strange if the 'other' device starts responding before the complete command is given. (And yes I know there are cases where this is possible but then you would certainly NOT use the type of coding that is being shown in post #37.) Therefore you have a situation such as:

// 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

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.

(The 'other' system does need to worry about timing in the case of a 'command-response' arrangement. Take the case of an SPI FLASH chip where the master sends the read command value is followed by an address but then by one or more dummy values so that it receive the stored value(s). The chip MUST respond with the stored value before the 'master' dos the SPI exchange to receive it. This is where the data sheet comes in as it will state the maximum clock rate that the 'other' chip can accept to allow it to perform the required action in time. If the 'master' exceeds that speed then all bets are off. An alternative is to employ a higher level 'protocol' that might (say) have the 'other' device send back an 'im not ready' value and the 'master' then keeps requesting the response until it gets something else.)

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.

The reason I say 'almost' is that the 'other' device can use 'clock stretching' as a way of telling the 'master' that it is not quite ready. But it is very bad practice to have the clock stretching used for more than a few normal clock cycles.

Enjoy learning - but I really do suggest that you learn by 'doing' - start small and work your way up.

Susan

 

[Xenon02]

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.

Here are the recommendations :

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.

SET/CLEAR ports pin and use a scope, what does it mean ? On a software, what it does, it is not specified. I see only a pin name and what can I do with it. I can set some random pin and name it SET/CLEAR but what then ? I can use it to set a value "1" or "0"

Debugger, I've used before to debug C code, usually didn't help a lot because it went into HAL instructions and yup ... Pretty messy and the Error told me nothing what happened. It hasn't shown me how the machine code looks like.

Just because there are many sources to learn doesn't mean there is everything like my question, I have found nothing about it. But when I see some threads about interfaces they mention timing.
Not every information is correct which once made me think incorrectly about Op Amp. Some tutorials are just like : copy the code and it works, no explanation on how the code works or why it needs some special functions to even function.

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

So as I thought.
B was indeed doing it's thing and I understood it.
The D was the question, and it is then correct that it takes time for the Receive to be "ready", thus even if data is coming or not the Receive function is fast enough like 100 machine instructions like it was mentioned before. Like when the B point is finished then the data from other device is coming to the microcontroller and D is being executed line after line of machine code, but even if the data happened to start coming right after the B finished and the D started reading it's code, the D will be on time, because it is fast as I understood, because it has less machine code (although for faster speeds like 10Mbaud it would be hard in my opinion, just 40 instruction this is gambling though if after point B the data was coming and D has just started executing it's code which will take like 30 instructions).

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.

Aha, so I can transfer data, but until I give the information that master want to receive data he won't send anything back.
Very interesting because I don't have to worry whether Master which will be my STM will have to worry about timing because it does not have to, like he transfer data to set a device and long long later he can transfer that master want to receive data, even though the device was already working.
Interesting. Like if the receive was very fast then the master just slows the clock, to make in time I guess. Heh

Well there is still a thing if my master waits to long after sending the data to slave to turn on a temperature measurement then let's say he measured 5 degree celsius, and master hasn't read it yet, so either the device still reads and updates the data like now it measured 10 degree celsius and overwritten the 5 degree or it still stays 5 degree and the new one just dissapeared.

If the first one happened which is overwritten then there is a change that master reads from slave while is in the middle of overwritting like half way changing half of the data (or it is a complete nonsense and it changes in one shot), or there is no problem at all because master takes new or old value.

So I guess there is no overflow in this place rather the Slave has to worry in losing data if it's very fast. Which comes back to the problem with UART but only when the device in I2C or SPI is in slave mode, and good to notice is that they are a lot faster so maybe faster Core ? Like 100MHz they usually have ? Dunno

Enjoy learning - but I really do suggest that you learn by 'doing' - start small and work your way up.

Yes I will proceed in it, I have used simple codes with UART, and tried with I2C but something happened.
I want to do 2 UARTs but don't know how to manage them because both of them can signal ready to read at the same time hmmm and if I take to long I can lose data/overflow, but usually I don't know how much free time I have even in IT version.

Well a way to go, usually tutorials doesn't help me sort it out.
Sorry for problems.

 

[Xenon02]

BTW

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.

One last thing to ask.
If I asked for 6 bytes to receive from I2C, then processor has to take the data from I2C buffer or something to the SRAM buffer for each byte right ?
Then if so the processor has to also be ready to read each byte like in UART ? But in contrast to UART, in I2C I have more controll of the data which will come or not. I just start when I want to read or write not like in UART.
But the problem still remains in reading because 1st byte will come and the processor has to read this byte, take it into SRAM and that's all, but it requires time like in UART.
The problem I have is that I2C is faster than UART as far as I know. Or perhaps 115200 is as fast as the I2C. Don't know how fast they are or if their function/instruction is shorter than for UART but for speed like 1Mbaud the processor only had 400 instruction time gap before new byte so yea ...

I'll end it here of course just this thing though.

 

[Aussie Susan]

It's really the same as a UART - at least for the STM32 devices that you are talking about.

The HAL functions all take a buffer to send or receive - and there are special versions that allow you to read and write to devices such as memories that require an internal address.

As before, the HAL library functions will do all of the work for you - you just provide the buffers and sizes that you read from or write to.
The standard speeds for I2C are 100kbps and 400kpbs and the newer 3.4Mbps. Just let the HAL know when you configure the I2C hardware which speed to use and it will handle the rest.

It is a bit hard to compare the speed for I2C and the UART because the UART requires a start bit, 1 or 2 stop bits and possibly a parity bit (plus the fact that there are typically 8 bits of the data bit this can vary from 5 to 9 bits), whereas the I2C standard has a number of bits at the start to specify which device on the bus is being addressed (7 or 10 bits) plus a bit to say if it is read or write plus the 'Start', 'Stop' and 'Ack/Nak' bits that are sent by the appropriate device. In the middle of all that there are the values that are being read or written.

So both standards have overheads but all that is normally hidden by the hardware and (in this case) some of the HAL software.

Bottom line: with all of these things, just use them and worry about the higher level operation of your program.

Susan

 

[Xenon02]

Bottom line: with all of these things, just use them and worry about the higher level operation of your program.

Well my worries about UART not being able to work happened.
I had 2 UART one for WIFI and one for Bluetooth. And it is for sure about timing ... Well maybe not that simple one like Transmit and after that Receive. But yea it happened. The bluetooth one is slower and happens to trigger callback at the same time as wifi callback, so they clash one of them is complited while the other one is overflowed.
And here comes the obsession of the timings that I wasn't supposed to think about. But I don't know how to measure how long the callback takes or a specific function, sysTick is measuring in miliseconds. So this one is nah ...


Found out as well that this low level thinking might not be great, but found some forums that legit calculates times in ns ...
Also their code was a lot bigger but is somehow faster ... ehhhh this logic kills me.

However, I tried to print the values of the specific registers but sometimes they just didn't want to print on so my methods on how to check what is wrong maybe in timing (or rather for sure) is problematic.

Second thing is I know the Callback should be short but, the code must be proceeded in callback, because the while is maybe not long but takes a while, and when the function I want to actualize after the callback will be called second callback can be called in the middle of the function and can overwrite my function results or before my function get's called the receive is callbacked many times, so I had to put my function inside of callback.

But okey, things happened, I sayed it will be over so here it is over, you don't have to reply, thanks.

 

[Aussie Susan]

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

 

[Xenon02]

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

Nope, I have used the IT.

That's where the timing actually mattered I guess.

 

[Aussie 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:
1) start a new thread - this one has too much baggage
2) tell us what you are trying to do - what are the requirements; what are the data streams you are reading - what are their characteristics: UART or SPI or ?; soeed; continuous or packets or which size etc.
3) show us all of your code - I would normally ask only for a small example code that shows the problem and if you can do that then great
4) describe exactly what you are seeing; how are you testing; what works that shouldn't and what vdoesn;t work that should etc.

Susan

 

[Xenon02]

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:

Why hate yourself ?

I am partly still convinced with the hypothetics I've said in the beginning but ok. And they happen to probably occure in the actual program as well. But sure.