$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [pool] Definition of a static_pool ?
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-04-28 15:16:17
>> Because I never figured out a way to *place* an array at
>> the known physical address in memory where I want it,
>> such as 0xFFE0, or whatever the address of, say, the
>> ADC result registers may be in the microcontroller.
>> Maybe there is a simpler way to do things like this.
>> But I never got it. Any advice would be welcome.
> What about placement new?
> Or an array_ref (not part of Boost).
> Olaf
Sorry, I was unclear. I meant that I never figured out how to
put std::array at an address of my choice. Unfortunately,
I have written countless custom arrays and custom allocators,
etc. for this, constantly making and re-making the same
mistakes over and over again.
I generally use 3 methods for memory-mapped arrays.
The methods 2 and 3 are related to Etienne's OP.
But since I was wrong about the scope of Boost.Pool
in the first place, it might be able to do it and
I just don't know.
1) In C and C++ if I don't need size(), begin(), end(), etc., I use
something like this
#define adc_results ((volatile uint16_t*) 0xFFE0)
2) If I need size(), begin(), end() and also want to give
the compiler freedom for loop unrolling, I use something
like this
template<typename address_type, const address_type addr, const unsigned N>
class memory_mapped_array
{
// And basically write most of std::array, but without data,
// only using the (volatile) address
...
};
3) If I really need the comfort of a container, I use something like this
in combination with an STL container.
template<typename address_type, const address_type addr>
class memory_mapped_allocator
{
// And basically write std::allocator conforming allocator
// but at a volatile address.
};
I keep writing methods 2 and 3 over and over again, probably
never really getting it right. I thought if Etienne wants to
extend Boost.Pool, others might want memory-mapped pools
and allocators.
But we're getting too far off the OP.
Thanks and best regards, Chris.