modm API documentation
|
Classes | |
class | modm::IODevice |
class | modm::IODeviceObjectWrapper< Device, behavior > |
class | modm::IODeviceWrapper< Device, behavior > |
class | modm::IOStream |
Enums | |
enum | modm::IOBuffer { DiscardIfFull, BlockIfFull } |
IOStream & | modm::flush (IOStream &ios) |
IOStream & | modm::endl (IOStream &ios) |
Write a newline. DOES NOT FLUSH THE STREAM! | |
IOStream & | modm::bin (IOStream &ios) |
set the output mode to binary style | |
IOStream & | modm::hex (IOStream &ios) |
set the output mode to hexadecimal style | |
IOStream & | modm::ascii (IOStream &ios) |
set the output mode to ASCII style | |
IOStream & | modm::black (IOStream &ios) |
Set the foreground colour on ANSI terminals. | |
IOStream & | modm::red (IOStream &ios) |
IOStream & | modm::green (IOStream &ios) |
IOStream & | modm::yellow (IOStream &ios) |
IOStream & | modm::blue (IOStream &ios) |
IOStream & | modm::magenta (IOStream &ios) |
IOStream & | modm::cyan (IOStream &ios) |
IOStream & | modm::white (IOStream &ios) |
lbuild module: modm:io
The modm::IOStream
class contains efficient formatting that supports both C++ std::basic_ostream
-like formatting via operator <<
as well as implementing printf
via the modm:printf
module.
printf
are disabled by default to reduce firmware size! Please check the options.modm::endl
does NOT implicitly flush! Flushing is extremely expensive on embedded systems, therefore modm::endl
does not implicitly flush the stream. Please call modm::flush
explicitly.The modm::IODeviceWrapper
transforms any peripheral device that provides static write()
and read()
functions into an IODevice
.
You have to decide what happens when the device buffer is full and you cannot write to it at the moment. There are two options:
Option 1 has the advantage, that none of your data will be lost, however, busy-waiting can take a long time and can mess up your program timings. There is also a high risk of deadlock, when writing to a IODevice inside of an interrupt and then busy-waiting forever because the IODevice requires interrupts itself to send out the data.
It is therefore highly recommended to use option 2, where surplus data will be discarded. You should increase the IODevice buffer size, if you experience missing data from your connection. This behavior is also deadlock safe when called from inside another interrupt, and your program timing is minimally affected (essentially only coping data into the buffer).
There is no default template argument, so that you hopefully make a conscious decision and be aware of this behavior.
Example:
Generated with: no in [yes, no]
On AVRs floating point values can be printed, however, the formatting cannot be specified and all values are printed as scientific-notation exponential floating point
Generated with: no in [yes, no]
Generated with: no in [yes, no]
|
strong |
The preferred behavior when the IODevice buffer is full