I also find it very helpful to extensively unit test my embedded code on
the host machine. Even sensor handling code can often be tested by writing
signedness tests (given a change in input value what is the expected sign
of the change of the output).
-Anton
On Sun, Apr 11, 2021 at 5:32 PM
Well, if you want a flame war, then let me chime in - you are wrong,
Trampas is right.
You are /wrong/ to suggest that "commercial embedded systems ALWAYS
directly benefit from being small and fast". Some do - for many, it is
irrelevant as long as they are small enough and fast enough. Once you
"The man who grasps principles can successfully handle his own methods.
The man who tries methods, ignoring principles, is sure to have trouble."
-Ralph Waldo Emerson
When you understand your requirements, processor, and tools (compiler) then
you can pick the best method to optimize for desired
On 10/04/2021 22:11, Klaus via Gcc-help wrote:
> Hi,
>
>
>
> Am 10.04.21 um 17:26 schrieb Jonathan Wakely:
>
>>
>> Dummy<1> d1;
>>
>>
>> This doesn't cause the instantiation of the member function.
>>
>> Have you tried an explicit instantiation?
>>
>> template class Dummy<1>;
>
> Did not
In C++ for interrupt vectors in drivers I set up an array of pointers to
function all the peripheral driver code like this for timer counters.
static voidCallback_t _isr_funcs[TC_INST_NUM]={NULL};
Then in each handler if the pointer is not null I call it. This is a lot
of work and overhead but
David,
On the real cost of C++ I do not see the problems with debugging you do.
That is when I debug code I turn optimizations off, as such I can debug C++
just like C. Now with compiler optimizations on all bets are off as to
what the compiler does. At this point you have to have near
