Porting C++ code to C

[Frederick Gotham]

I'm porting C++11 code to C90 to run it on a microcontroller. My C++ code uses stuff from the headers <algorithm> <numeric> <functional>.

I hear that "glib" is the best library for C that gives the functionality of the C++ standard library and also Boost.

Looking through the 'glib' reference manual here though, I don't see anything similar to "std::next_permutation".

Is glib the best thing to use for porting C++11 code to C if you're looking for functionality similar to <algorithm> <numeric> <functional>?

[Sam]

Frederick Gotham writes:

>
> I'm porting C++11 code to C90 to run it on a microcontroller. My C++ code
> uses stuff from the headers <algorithm> <numeric> <functional>.
>
> I hear that "glib" is the best library for C that gives the functionality of
> the C++ standard library and also Boost.
>
> Looking through the 'glib' reference manual here though, I don't see
> anything similar to "std::next_permutation".

That's because you shouldn't believe everything you hear.

> Is glib the best thing to use for porting C++11 code to C if you're looking
> for functionality similar to <algorithm> <numeric> <functional>?

Well, I suppose it's just as good as any other random library that has
nothing to do with C++, whatsoever.

glib is part of the Gnome toolkit. It implements some higher-layer
foundational constructs that the rest of this entirely C-based toolkit
needs. It implements several, basic, vaguely C++-like constructs, but
nothing even vaguely resembling algorithms, numerics, and functional C++
libraries.

You're pretty much on your own, here.

[Frederick Gotham]

On Monday, August 17, 2020 at 1:01:47 PM UTC+1, Sam wrote:

> You're pretty much on your own, here.

I just found the 'KLib' library:

https://github.com/attractivechaos/klib

Can't find "next_permutation" in it but it has some other cool stuff.

[David Brown]

On 17/08/2020 13:51, Frederick Gotham wrote:
>
> I'm porting C++11 code to C90 to run it on a microcontroller.

What kind of microcontroller are you talking about? For larger ones,
C++11 is not an issue - many people use newer C++ on microcontrollers.
(Often there are some limitations in what they do - in particular, most
microcontroller software disables exceptions and RTTI.) For anything
but the most outdated and brain-dead devices, C99 is fine if you are
forced to go with C. But while C is a perfectly good choice for
microcontroller programming, it is not a good choice if you are starting
with C++ code.

> My C++
> code uses stuff from the headers <algorithm> <numeric> <functional>.
>

These are not likely to have much place in microcontroller programming.

> I hear that "glib" is the best library for C that gives the
> functionality of the C++ standard library and also Boost.
>

If you heard that, you have not been listening in the right places.

But start by saying what microcontroller you are targetting, roughly
what resources it has (flash, ram, core, speed), and what toolchain you
are thinking of using.

[Frederick Gotham]

On Monday, August 17, 2020 at 1:59:14 PM UTC+1, David Brown wrote:

> But start by saying what microcontroller you are targetting, roughly
> what resources it has (flash, ram, core, speed), and what toolchain you
> are thinking of using.

PIC18F97J60 with onboard Ethernet. I'll use the Pickit2 (or Pickit 3 maybe) to program it, and I'll use MPLAB along with the 'Microchip' compiler.

Non-volatile Program Memory = 128 kB (extendable to 2 MB by connecting another chip)
Volatile Data Memory = 3 kB
Maximum CPU clock = 40 MHz

Datasheet is available here: https://www.mouser.co.uk/datasheet/2/268/39762f-1074147.pdf

[Scott Newman]

Use Cfront, it can cross-compile every C++-code to C.

[David Brown]

You decided to use that one, against advice? OK, you are on your own.
Good luck trying to get it to run anything in standard C with much
efficiency.

[Frederick Gotham]

On Monday, August 17, 2020 at 2:11:14 PM UTC+1, Scott Newman wrote:
> Use Cfront, it can cross-compile every C++-code to C.

Worked back in 1994, not so sure about recent code. Anyway my code uses templates too.

[Scott Newman]

>> Use Cfront, it can cross-compile every C++-code to C.

> Worked back in 1994, not so sure about recent code. Anyway my code uses templates too.

Google for the C++20-version.

[Vir Campestris]

Did I read correctly that your device has 128k of NVRAM and 3k of RAM?

How big is the program on its current platform?

Andy

[Juha Nieminen]

Vir Campestris <vir.cam...@invalid.invalid> wrote:
> Did I read correctly that your device has 128k of NVRAM and 3k of RAM?

I have had to develop for an STM8 system which has 32 kB of flash
memory (for the executable binary) and 1 kB of RAM. And not like
20 years ago. This year.

It is perfectly possible. You just have to watch for that 32 kB
limit.

[David Brown]

All sorts of programs can be written for small microcontrollers - I have
used far smaller ones. And you can use C++ (with limitations and
restrictions) on small microcontrollers.

But you can't use C++ on a PIC18. I don't know the state of Microchip's
C compiler these days - based on what I saw in the past, I'm suspicious
of its quality. (There are good quality PIC18 compilers from other
vendors, at serious prices.)

The killer limit for the PIC18 here is the 3K ram space, not the 128K
flash limit, and this is a core that does not do well with pointers -
they are very inefficient. With just 3K of ram, use of dynamic memory
is pretty much out of the question, which is a very painful restriction
for any kind of networking. The MAC on the chip has 8K dedicated ram
for packets, without which Ethernet would be nearly impossible, but with
3K general ram, basic network standards like DNS, DHCP and TCP/IP are
almost out of the question - they are possible, but only with crippling
restrictions.

[Juha Nieminen]

David Brown <david...@hesbynett.no> wrote:
> The killer limit for the PIC18 here is the 3K ram space, not the 128K
> flash limit, and this is a core that does not do well with pointers -
> they are very inefficient. With just 3K of ram, use of dynamic memory
> is pretty much out of the question, which is a very painful restriction
> for any kind of networking. The MAC on the chip has 8K dedicated ram
> for packets, without which Ethernet would be nearly impossible, but with
> 3K general ram, basic network standards like DNS, DHCP and TCP/IP are
> almost out of the question - they are possible, but only with crippling
> restrictions.

Aren't dedicated chips (of the likes of KSZ9897) used to handle ethernet
in such restricted embedded systems?

[David Brown]

That's a switch chip - you use it for making an Ethernet switch, not for
communicating over Ethernet. (If you open up a simple off-the-shelf
4-port Ethernet switch, it will have a chip like that in the middle, and
no microcontroller.)

There are chips, or modules, that are made for adding Ethernet to
existing small microcontroller designs. There the chip (or module) has
the software to implement TCP/IP, and usually at least some of HTTP,
HTTPS, DNS, SMTP, etc., as servers and/or clients. The chip
communicates with the microcontroller by UART or SPI. The idea is that
as much as possible is handled on that chip, and the microcontroller is
only responsible for executing commands or returning data. You use such
devices when you have an existing design that you want to upgrade to use
Ethernet (or Wifi) but don't want to re-do the design using a more
powerful and modern device.

For a while, many years ago (maybe 15-20 years), there was a demand for
small microcontrollers with Ethernet support. At that time, 32-bit
devices and reasonable ram sizes were big, expensive, and hard to use -
so 8-bit and 16-bit devices were much more popular. There was a market
for such things with very limited and simple network communication -
things like embedded web servers where the page would fit within one
Ethernet frame so that you didn't need fragmentation, and where a TCP/IP
retry was handled by the application re-creating the dynamic page with
the old data because you didn't have enough ram do buffer anything. The
networking code was highly specialised and tied tightly to the
application code, because there were no resources for generalisation.

The PIC18 discussed here is from that era.

These days, you get 32-bit microcontrollers with plenty of flash and ram
and a 100 Mbit MAC for a fraction of the price of the PIC18. There are
off-the-shelf network stacks and plenty of examples around, and you have
enough power to have a web server, and a Modbus server, and telnet
servers, and SSL encryption and whatever else you may want for a useful
device that is suitable for today's networks.

[bol...@nowhere.co.uk]

On Tue, 18 Aug 2020 11:15:37 +0200
David Brown <david...@hesbynett.no> wrote:
>The killer limit for the PIC18 here is the 3K ram space, not the 128K
>flash limit, and this is a core that does not do well with pointers -
>they are very inefficient. With just 3K of ram, use of dynamic memory
>is pretty much out of the question, which is a very painful restriction
>for any kind of networking. The MAC on the chip has 8K dedicated ram
>for packets, without which Ethernet would be nearly impossible, but with
>3K general ram, basic network standards like DNS, DHCP and TCP/IP are
>almost out of the question - they are possible, but only with crippling
>restrictions.

Why would you even bother? If you need proper networking use a PIC with a
bigger memory. They cost buttons and there are plenty to choose from.

[Vir Campestris]

I deliberately quoted part of his message: his code uses templates.

It doesn't mean it _is_ big and complex, but it makes it a whole lot
more likely, and that is what I was concerned about.

(FWIW I've written boot sector code for IBM machines. You have 512 bytes
for the code and all the data. And the smallest amount of RAM I've ever
had to work with was zero. That's right, none at all. POST can't assume
the RAM will work, and has to be able to complain when it doesn't!)

Andy

[Leo]

For a microcontroller, you will probably be served better by using a
smaller library and compiling with -Os and -flto to clean up all the
unused stuff.