thanks for your answer. these functions are similar to sei (); setinterrupt and cli(); clear interrupt.

does atomic procedure stopps other irq´s like tickerfunctions similar using cli/sei disable_irg/enable_irg? or makes atomic procedure from atmel makes other irqs waiting? is it possible while using disable_irq/enalbe_irg - that tickerfunction-event is lost ?

Yes those are similar to those atmel functions. But AFAIK also CLI/SEI do not clear interrupts, they should just put them on hold. In special case for example of ticker, it has an internal buffer of the coming events so it will never lose events. If you for example have an InterruptIn which fires, it should just be handled as soon as you enable irqs again. Only if it fired two times while they were disabled, than it will only be called once when it is enabled again.

Hi, thanks for your answer. I´ve problem with ticker and fifo. I´m using ticker to measure values from adc and putting them to fifo with put-function. i´d like to send fifo-values to another spi-master. I´m in anxiety to get racecondition while sending data from fifo-buffer to spi-master and next ticker-event to put data into fifo.

it´s my idea to prevent raceconditioning by using atomic functions. when ticker for reading adc-value is started I´d use

// ticker to read adc values
...
value = ADC_port.read_u16();

__disable_irq;
ADC_fifo.put (value);
__enable_irq;
...

is ist also neccessary to do this? when ticker-event breaks sending-function from fifo-data to spi-master will ticker-event-function also be stopped by other functions? do you have experiences in organizing such fifo-access-problem?

It depends on how you organize your program. If both the put and get from fifo run in default priority interrupts, then there is no issue: The interrupts then won't interrupt each other. If both are running in normal context then there is no issue, since they are just handled sequentially. However if you put it there within a ticker, and remove it from interrupt in your main program, or if you have interrupts with different priorities, then you are correct and indeed might need to protect the put and get operations of a FIFO buffer.

The might is because I think it depends on how you created your FIFO. If you use a ringbuffer, with a seperate read and write pointer, then I don't think it is required, if you also do it in correct order (so when writing it should first write the data, then increment the write pointer. Otherwise when it checks if there is something to read and the pointer is already incremented, it might think there is something in the buffer while that has not been written yet.

I don't have much experience myself with this btw, but with some logical thinking you can get quite far :). And the TL;DR is: It depends on your FIFO implementation :).

Yes correct. But then it still depends on how you implement the FIFO. Lets say you have a buffer of 1 - 10. If you made it that a write operation goes from 1 to 10, while a read operation always reads from one, and then moves all current data one position lower including the write pointer, then you will need to protect it.