Author Topic: Has anyone used C++ or any other non 'C' basic language with STM chips?  (Read 4954 times)

0 Members and 1 Guest are viewing this topic.

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Quote
The C library I use is the one which comes with MSP430 GCC
Is that the one from the Peter Bigot days, or the current TI supported MSP430 gcc?
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
The printf + vuprintf in the library I'm using need less than 1kB.
You can find the mspgcc library here but I don't know if it is still portable. Back then I just had to change the makefile a little bit and remove a minimum amount of assembler. I also changed the makefile to create various versions of the library  for various Cortex Mx instruction sets and optimisations (size and speed).
https://sourceforge.net/projects/mspgcc/files/msp430-libc/

And yes that is the one from the Peter Bigot days.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Thanks.  It doesn't seem to have changed since 2012, so it probably hasn't become much less portable (and old versions still available!)

This sub-discussion illustrates the problems with libraries and language features.  No one really thinks that printf() should NEED to use malloc(), but by the time the library designers are done core printf functions invoke malloc() because the original caller MIGHT have been "asprintf()" (which I never noticed, until today), and making the printf parts understand dynamically allocating the results (by calling malloc) seemed like it would be more efficient, but it certainly isn't if that's the only place you'd call malloc().
Similarly "obvious and useful" stuff in C++ bloats code in non-obvious ways (for instance, virtual functions defeat linker function garbage collection, so an arduino sketch that uses "Serial" ends up including a bunch of HWserial functions whether they're used or not...)
 

Offline bson

  • Supporter
  • ****
  • Posts: 2270
  • Country: us
Just as a note, there's no need to link with libstdc++; it has a tendency to pull in undesirable bits and pieces.  The following stubs out the runtime support needed for g++.  (libstdc++ uses atexit() to register exit-time destructors, something not even remotely desirable in embedded systems.)

Code: [Select]
// ABI stuff (both ELF and EABI stubs, for simplicity, though only one is needed)

extern "C" {
#undef abort
void abort() { panic("ABORT"); }

int __cxa_atexit(void (*func) (void*), void* arg, void* dso_handle);
int __cxa_pure_virtual();
int __aeabi_atexit (void *object, void (*destructor) (void *), void *dso_handle);

}

int __cxa_atexit(void (*func) (void*), void* arg, void* dso_handle)
{
return 0;
}


int __aeabi_atexit (void *object, void (*destructor) (void *), void *dso_handle)
{
    return 0;
}


int __cxa_pure_virtual() { abort(); return 0; }

void*   __dso_handle = (void*) &__dso_handle;

And, if using a custom startup, make sure to run initializers:

Code: [Select]
// Call from startup.S with:
//     bl _Z10init_arrayv
// Somewhere else define:
//  #define __weak gnu::weak for gcc
// For other compilers use other attributes if available, or an empty definition and make the symbols weak in the link script.

[[__weak]] extern void (*__preinit_array_start []) (void);
[[__weak]] extern void (*__preinit_array_end []) (void);
[[__weak]] extern void (*__init_array_start []) (void);
[[__weak]] extern void (*__init_array_end []) (void);

void init_array() {
    size_t count, i;
   
    count = __preinit_array_end - __preinit_array_start;
    for (i = 0; i < count; i++)
        __preinit_array_start[i]();
   
    count = __init_array_end - __init_array_start;
    for (i = 0; i < count; i++)
        __init_array_start[i]();
}

The symbols __init_array_start etc need to match the linker script.  init_array needs to be called from the startup code.

This removes all dependencies on standard libraries other than libgcc.a; but libgcc is a hard dependency, for arithmetic ops, floating point, and such.
 
The following users thanked this post: nctnico

Offline pigrew

  • Frequent Contributor
  • **
  • Posts: 680
  • Country: us
I had a few students this semester using ARM's mbed platform to target a STM32F4. My feeling is that it was somewhat Arduino-esque, but a much better implementation. If you want some quick prototypes done, it's great. I didn't personally use it, so I don't know if I'd suggest it or not. My students used the web-compilation feature, and then downloaded and flashed the binary. It looks like you can also use their libraries through Eclipse.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf