<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Regions and message queues are
completely independent.<br>
<br>
Regions, like all RTEMS objects with IDs, have a control block<br>
associated with them. The memory used for the region for <br>
allocations is provided by you. It can come from anywhere.<br>
The maximum number of regions you can create is configured<br>
by CONFIGURE_MAXIMUM_REGIONS.<br>
<br>
Similarly, message queues have Ids and a similar maximum,<br>
CONFIGURE_MAXIMUM_MESSAGE_QUEUES. But the memory<br>
for message buffers to hold pending messages comes from<br>
the RTEMS Workspace and must be accounted for. This is what<br>
a couple of configuration parameters are for.<br>
<br>
CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE(_messages, _size) <br>
CONFIGURE_MESSAGE_BUFFER_MEMORY<br>
<br>
CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE is used to calculate<br>
the memory required for a SINGLE queue based on the message<br>
size you use and the maximum pending. RTEMS has no idea what<br>
those will be.<br>
<br>
CONFIGURE_MESSAGE_BUFFER_MEMORY is the summation of <br>
the memory used by all of the message queue buffers.<br>
<br>
Alternatively, you can take the quick way out and use <br>
CONFIGURE_UNLIMITED_OBJECTS and CONFIGURE_UNIFIED_WORK_AREAS<br>
and not worry about this. [1]<br>
<br>
By default, RTEMS wants you to configure hard limits in a precise<br>
way. The thinking is that on many embedded systems, you should
know<br>
exactly what you are creating, how much memory you are using,
etc..<br>
<br>
The alternative is to put all the C Program Heap and RTEMS
Workspace<br>
together in a single pool and create/malloc until the system runs
out of<br>
memory.<br>
<br>
Both are valid approaches to take. It depends on the goals of the
<br>
application and the control you want over resource allocation and
the<br>
effort you are willing to invest in configuring that.<br>
<br>
For testing and playing around, using the unlimited/unified option
is<br>
a lot simpler.<br>
<br>
--joel<br>
<br>
[1] Unlimited only applies to threads, tasks, semaphores, etc.
Objects<br>
with Ids in the Classic and POSIX threads APIs. For example, it
does not apply to<br>
any file system or disk related configuration.<br>
<br>
<br>
On 3/7/2013 8:21 AM, Matthew J Fletcher wrote:<br>
</div>
<blockquote
cite="mid:CAPy9Tinc0YiOrPsJLd_nsaATQM68zmu2cK766VWLYaOCQ0gSMQ@mail.gmail.com"
type="cite">
<p dir="ltr">Hi,</p>
<p dir="ltr">Its 20, but I believe that would return
RTEMS_TO_MANY, if that was not enough.<br>
</p>
<div class="gmail_quote">On 7 Mar 2013 14:09, "Gedare Bloom" <<a
moz-do-not-send="true" href="mailto:gedare@rtems.org">gedare@rtems.org</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Check how many message queues your application has configured.<br>
<br>
#define CONFIGURE_MAXIMUM_MESSAGE_QUEUES ?<br>
<br>
On Thu, Mar 7, 2013 at 7:05 AM, Matthew J Fletcher <<a
moz-do-not-send="true" href="mailto:amimjf@gmail.com">amimjf@gmail.com</a>>
wrote:<br>
> Hi,<br>
><br>
> Reading the documentation for rtems regions is a bit
vague about the<br>
> overhead of the lists that behind the scenes manage the
blocks. Its quite<br>
> possible i am not fully understanding the operation. I
have a call sequence<br>
> as follows.<br>
><br>
> rtems_region_create( length = 19800, page_size = 128 )<br>
> rtems_region_get_segment( size = 160 )<br>
> rtems_message_queue_create ( count = 160, max_size =2
)<br>
> rtems_region_get_segment( size = 400 )<br>
> rtems_message_queue_create ( count = 400, max_size =2
)<br>
> rtems_region_get_segment( size = 1600 )<br>
> rtems_message_queue_create ( count = 1600, max_size
=2 )<br>
> rtems_region_get_segment( size = 40 )<br>
> rtems_message_queue_create ( count = 40, max_size =2
)<br>
> rtems_region_get_segment( size = 4000 )<br>
> rtems_message_queue_create ( count = 4000, max_size
=2 )<br>
> rtems_region_get_segment( size = 40 )<br>
> rtems_message_queue_create ( count = 40, max_size =2
)<br>
> rtems_region_get_segment( size = 40 )<br>
> rtems_message_queue_create ( count = 40, max_size =2
)<br>
> rtems_region_get_segment( size = 40 )<br>
> rtems_message_queue_create ( count = 40, max_size =2
)<br>
> rtems_region_get_segment( size = 40 )<br>
> rtems_message_queue_create ( count = 40, max_size =2
)<br>
> rtems_region_get_segment( size = 120 )<br>
> rtems_message_queue_create ( count = 120, max_size =2
)<br>
> rtems_region_get_segment( size = 400 )<br>
> rtems_message_queue_create ( count = 400, max_size =2
)<br>
> rtems_region_get_segment( size = 400 )<br>
> rtems_message_queue_create ( count = 400, max_size =2
)<br>
> rtems_region_get_segment( size = 2000 ) // total size
upto here 7320<br>
> rtems_message_queue_create ( count = 2000, max_size
=2 )<br>
> // returns RTEMS_UNSATISFIED - unable to allocate
message buffers here<br>
><br>
> I dont fully understand why RTEMS_UNSATISFIED is being
returned from the<br>
> queue_create(), is there really a 50%+ overhead in
managing 128 byte pages ?<br>
> out of a 19800 length.<br>
><br>
> I am presuming that the RTEMS_UNSATISFIED is because of
the region size, but<br>
> i could be wrong about that.<br>
><br>
><br>
> regards<br>
> ---<br>
> Matthew J Fletcher<br>
><br>
><br>
> _______________________________________________<br>
> rtems-users mailing list<br>
> <a moz-do-not-send="true"
href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
> <a moz-do-not-send="true"
href="http://www.rtems.org/mailman/listinfo/rtems-users"
target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
><br>
</blockquote>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985 </pre>
</body>
</html>