Firmware language and style

[Thomas Zimmermann]

Hi

I've got my system set up to work on the SensorWeb firmware and started
actual development. Therefore I'd like to discuss the two questions below.

1) Do we want to adapt Mozilla's coding style? [1] I'd say yes, but
maybe there are good reasons against it.

2) Do we want to support C++? I'd also say yes here. RAII [2] alone
seems worth it. I'm aware of the code bloat that can come from RTTI,
templates, and virtual function. Maybe we want to rule out some of these
features explicitly. I'd also like to use exceptions, but I don't know
about the memory overhead that comes from the exception-handling structures.

Best regards
Thomas

[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
[2] https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization

[Fabrice Desré]

Rust with https://github.com/japaric/xargo and
http://www.hashmismatch.net/freertos-meets-rust/ ?

Only half joking...

--
Fabrice Desré
Connected Devices
Mozilla Corporation

[Fabrice Desré]

And I forgot to point to this nice doc: http://japaric.github.io/copper/

[Dave Hylands]

When doing C++ on embedded projects like this, I normally try to restrict myself to "Embedded C++"  https://en.wikipedia.org/wiki/Embedded_C%2B%2B which removes a bunch of stuff like exceptions, templates, multiple inheritance, etc.

It looks like FreeRTOS doesn't have any issues with using C++ (FreeRTOS itself needs to be compiled in C).

The thing we need to be REALLY careful about is using the heap. Heap fragmentation is the typical killer of many embedded applications. I prefer to use fixed block allocators so that we don't run into fragmentation issues.

Given the size of the project, I'm not sure how much benefit we'll get from using C++, but I also don't have any strong opposition to it, other than using the heap (which applies to any language).

I'm half with Fabrice, in that I'd really love to do this in rust, but I think that creating all of the C interfaces will be a pain in the butt.

[Thomas Zimmermann]

Using FreeRTOS from C++ is possible AFAICT. Embedded C++ looks a bit too
limited (e.g., no casting operators?), but it's definitely a good list
of things to watch out for.

Memory consumption and fragmentation is also my biggest concern, as we
only have 256 KiB available. It seems FreeRTOS doesn't come with
built-in heap allocator, but there are a a number of example
implementations provided. I think we can use statically allocated
task-local memory most of the time.

Some thoughts about memory and message passing: message passing will
require a scheme for transferring buffers between tasks; ideally without
dynamic allocation, blocking, or dead locks. FreeRTOS comes with message
queues, but it doesn't provide good IPC on top of it. Those queues make
full copies of messages, so transferring larger memory blocks will be
slow. And the messages are of fixed size. All messages that can go into
a buffer are required to be as large as the larges message. (The SDK's
FreeRTOS demo has a bug here.)

We want small message to be fast and large messages to be possible.
Usually, you'd do this with page mapping, but that's also not available.
The next best thing is to have a static local buffer for each task that
holds the message data for sending and receiving. Data transfer would be
done with small 'control messages' with an attached data buffer. A set
of helper functions will take care of sharing or transferring the
content of the buffer.

Best regards
Thomas

> <https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization>
>
>

[Juan Gómez]

One of the things that I was looking forward to test is about using C++ Metaprogramming (MTP) [1] techniques on microcontrollers.
MTP is about using templates with some statical techniques to allow the compiler perform compile-time calculations.

The main drawback of this technique, is probably the unhealthy syntax and incomprehensible error logs at compile time, but if you

can have your head around it (... I'm still on the process) some authors[1] claim that important benefits can be achieved in terms

of code size generation and runtime performance. This is of course only possible with C++11 full compliant toolchains, and things

get even better is they support C++14 and C+17...

I personally find this technique very useful for singleton-like pieces of code, like hardware management. But I guess that a mix of

both MTP and classic programming is the key to keep things maintainable and performance-critic.

Regards,

[1] http://sbrc2010.inf.ufrgs.br/anais/data/pdf/wtr/st03_01_wtr.pdf

>     <https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization>
>
>

_______________________________________________
mozilla-dev-sensorweb mailing list
mozilla-dev-sensorweb@lists.mozilla.org
https://lists.mozilla.org/listinfo/mozilla-dev-sensorweb

--

___________________
Juan Gómez Mosquera
Platform Engineer
Mozilla Corporation
_AtilA_

[Thomas Zimmermann]

Hi Juan

As I mentioned in another mail, the problem with C++ is the number of
stub functions it requires. I'd like to have STL and a few helpers,
without the dependencies on the OS. But the C++ language, library and
architecture are tightly coupled. It's hard to get one without the
others. One can write an OS with C++, but I'd expect that it would
remove most of the benefits.

I fully agree on the syntax issues. I just skimmed over the paper you
linked, but it looks like the kind of C++ template I'd not want to have.
Sometimes it's required, but it's also close to un-maintainable. The
idea of a 'highly adaptable device driver' seems questionable in
general. As an alternative, you might want to look at C++11's constexpr
for compile-time computations.

Best regards
Thomas

> > <tzimm...@mozilla.com <mailto:tzimm...@mozilla.com>
> <mailto:tzimm...@mozilla.com <mailto:tzimm...@mozilla.com>>>

> mozilla-de...@lists.mozilla.org
> <mailto:mozilla-de...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/mozilla-dev-sensorweb

[Dave Hylands]

FreeRTOS has several heap implementations:

http://www.freertos.org/a00111.html

>  https://en.wikipedia.org/wiki/Embedded_C%2B%2B which removes a bunch

>     [2]
>     https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization
>     <https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization>
>
>