RFC: Regulator Submission and Inclusion in RTEMS
Joel Sherrill
joel at rtems.org
Wed Jun 21 19:45:39 UTC 2023
Hi
I wrote a handy application helper named the Regulator (movie sounds
there). It was designed to address a customer's challenge where they had a
bursty input where immediately sending those bursts led to overflowing the
destination. But there was plenty of time between bursts to deliver and
process if the data flow rate was regulated. From the README
"The regulator library supports accepting an input stream of messages from
a source and metering those to a destination sink. The regulator assumes
that the input stream contains sporadic bursts of data which can exceed the
output rate of the sink. However, if the messages are metered to the
destination in a regulated fashion, an overflow of the receiver can be
avoided. The input buffering required to manage the maximum burst as well
as the metering rate for the output shall be configurable. The regulator
provides a configuration capability to allow for adaptation to different
message streams. The regulator also supports multiple instances which could
be used on independent message streams."
The API is generally named and source code written per RTEMS conventions
although I'd need to add rtems_ prefix in places. It is written using
Classic API objects. There is 100% source and branch level test coverage.
The APIs are:
+ regulator_create
+ regulator_delete
+ regulator_obtain_buffer
+ regulator_release_buffer
+ regulator_send
The user provides configuration information and a "delivery function". The
regulation of the data flow is independent of the source and sink.
All resources are pre-allocated at regulator instance create time. A
regulator instance can be used in a way which avoids adding an extra data
copy when using this.
I've attached the header file which should explain the APIs and usage.
I'd like feedback on this being added as cpukit/regulator. I think it's a
nice solution to a recurring issue faced in embedded systems.
Thanks.
--joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230621/79f0bfb0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: regulator.h
Type: application/octet-stream
Size: 12540 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230621/79f0bfb0/attachment-0001.obj>
More information about the devel
mailing list