0
\$\begingroup\$

Do Free-RTOS and mbed OS poll for incoming data to be received (or use interrupts?)? If so, is there a risk that data to be received while the processor is handling another task (e.g. running a program) risks being missed?

Is received data then stored somewhere in memory, so it can be retrieved when a function such as receive(...) is called? I would imagine that receive(...) is simply returning data which the OS has placed in a particular memory location. Is this the case?

\$\endgroup\$
  • \$\begingroup\$ An RTOS is super fast and depends on flags being set/cleared as to whether it pays attention to a given port. In an RTOS all threads/ISR's must complete before the OS goes to something else. Of course priority flags can modify this. Any OS must support unusual conditions. \$\endgroup\$ – Sparky256 Apr 21 '18 at 6:08
  • 1
    \$\begingroup\$ Ethernet cores have large (DMA) buffers where they store the incoming data. On top of that a protocol like TCP/IP can ask for re-transmission. \$\endgroup\$ – Oldfart Apr 21 '18 at 7:58
3
\$\begingroup\$

To generalize your question a bit: how does a system handle data that must be read from the hadware and is only lateron read by the software? (The inverse problem also exists, for instance in an mpeg player: data is generated in blocks, and is consumed at a fixed rate). Sorted by 'response time':

  • peripheral hardware often provides some buffering, ranging from the a-few-bytes buffer in a UART, to chains of data blocks in dedicated (multiported) RAM for Ethernet peripherals.

  • DMA (direct memory access) can be used to put data directly in the CPU RAM, without intervention from the CPU.

  • interrupts can be used to (temporary) get the CPU to handle an urgent task, like setting up a next data block for a Ethernet peripheral.

  • when the action that must be performed in response to an interrupts is more involved, the interrupt routine itself sets a flag, which causes the RTOS to switch to a task that handles the event.

  • when the response time is not very critical, the application can arrange that it polls the peripheral often enough to keep up with the data stream.

  • in a master-slave protocol the master controls when the slave will send data, so it can arrange for this to happen when it (the master) is listening (polling) for it.

  • when all else fails, the communication protocol can arrange for the data to be re-transmitted.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.