Author Topic: Taking a C++ class, looking for a C++14 compatible microcontroller to play with.  (Read 26363 times)

0 Members and 1 Guest are viewing this topic.

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
template metaprogramming

about the capability of making a generic interfaces
and let the compiler to instantiate things for you
I really like the "generic" method offered by ADA:
generic parameters, instances of generic packages
 

Offline lukier

  • Supporter
  • ****
  • Posts: 634
  • Country: pl
    • Homepage
about the capability of making a generic interfaces
and let the compiler to instantiate things for you
I really like the "generic" method offered by ADA:
generic parameters, instances of generic packages

I always wanted to do something in Ada. It has even stronger type safety than C++ (probably because there is no C backward compatibility to maintain), it has generics, exceptions etc. But I never had time to properly learn it and prepare the entire BSP or port RTEMS to my devkits, especially the bare metal MCU ones, not big-ARM devboards.

Even with Ada one can go wrong :)
https://en.wikipedia.org/wiki/Cluster_(spacecraft)
 

Online IanB

  • Super Contributor
  • ***
  • Posts: 11882
  • Country: us
Kings Langely

Is Kings Langley (interestingly, the spellchecker catches it for me). Clever spellchecker!  :)
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
I think that anything with a recent enough version of GCC or LLVM will work. So far I know that there are up-to-date versions of GCC for ARM, AVR and x86 (yes Intel is making microcontrollers based on x86 and amd64 architecture, but so far those are all BGA chips), and LLVM can target ARM and x86.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
(yes Intel is making microcontrollers based on x86 and amd64 architecture, but so far those are all BGA chips)
The Quark D2000 is (only) available in a QFN package.

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
(yes Intel is making microcontrollers based on x86 and amd64 architecture, but so far those are all BGA chips)
The Quark D2000 is (only) available in a QFN package.

I don't think that core runs AMD64 or x86 though...
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
The Quark D2000 is (only) available in a QFN package.
I don't think that core runs AMD64 or x86 though...
The D2000 uses the P5 ISA (sans floating-point), it's the D1000 that's not x86-compatible.

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
The Quark D2000 is (only) available in a QFN package.
I don't think that core runs AMD64 or x86 though...
The D2000 uses the P5 ISA (sans floating-point), it's the D1000 that's not x86-compatible.
So not exactly either x86 or amd64, but a weird cut-down version of it. I want to know if there is any open-source compiler support for those chips. Those are not cheap either by the way.

If I need a 3.3V MCU at 40 pins with similar features I would prefer STM32F103CB or PIC18F46K20 anyway.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
I want to know if there is any open-source compiler support for those chips.
GCC should work with the D2000, but I'm not aware of any compiler other than Intel's own supporting the D1000.

EDIT: I would consider those two chips as more of a technology preview/proofs of concept anyway. They're available in exactly one version each, both with pretty anemic flash and memory sizes, and some of the documentation for the D2000 is available only if you're an Intel industry partner. There's also no D1000 board for sale to the general public, even though there's mention of one in the documentation.
« Last Edit: October 16, 2016, 05:14:30 pm by andersm »
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
I want to know if there is any open-source compiler support for those chips.
GCC should work with the D2000, but I'm not aware of any compiler other than Intel's own supporting the D1000.

EDIT: I would consider those two chips as more of a technology preview/proofs of concept anyway. They're available in exactly one version each, both with pretty anemic flash and memory sizes, and some of the documentation for the D2000 is available only if you're an Intel industry partner. There's also no D1000 board for sale to the general public, even though there's mention of one in the documentation.
GCC may not be aware of the instructions cut from normal i586 architecture.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
GCC may not be aware of the instructions cut from normal i586 architecture.
Intel's own System Studio uses GCC. The -msoft-float and -mno-fp-ret-in-387 options should be enough to suppress generation of floating-point instructions, though I assume FPU emulation is also possible.

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
and people can actually live
without blathering -G-C-C-
*in every topic*, ain't it?

long life and prosper  :palm:
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
and people can actually live
without blathering -G-C-C-
*in every topic*, ain't it?

long life and prosper  :palm:
So what is your problem with GCC?

GCC and clang/LLVM are probably the two best free (both as in beer and as in speech) compilers out there, and those are also the two compilers that almost always implement the latest language standards and features. There are more companies and government agencies than you can imagine out there that uses and supports those projects.
 

Offline EBRAddict

  • Contributor
  • Posts: 26
  • Country: us
In case nobody pointed this out there are a couple issues that I've found with the Raspberry Pi 3 B GPIO: the UART/serial port doesn't function out of the box because the Bluetooth peripheral took it. To use UART you have to enable a secondary peripheral and slow down the system clock for it to work. Also, the I2C/smbus does not support clock stretching.

BeagleBone Black/Wireless/Green may be a linux alternative (albeit with much smaller community support).

I like the Pi and have several, but when I need GPIO I find myself reaching for an Arduino or a PSoC.

 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
GCC
GCC
GCC

GCC
the best free


it's annoying since a while, dude
it's so f*cking annoying to hear
the same record again, and again
you are making me round like
a record, round round round

what's your problem about life?
money? girls? wife? ….
 
The following users thanked this post: neil555

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
but when I need GPIO I find myself reaching for an Arduino or a PSoC.

yeah, for those things we'd better go for the YUN approach
 

Offline farsi

  • Regular Contributor
  • *
  • Posts: 66
just to add that a list of getting started with embedded unix boards is here: http://embeddednodejs.com/sbc/ - I can confirm that the plug and play experience of the upboard (with ubilinux) was quite good http://www.up-board.org/
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
GCC
GCC
GCC

GCC
the best free


it's annoying since a while, dude
it's so f*cking annoying to hear
the same record again, and again
you are making me round like
a record, round round round

what's your problem about life?
money? girls? wife? ….
So what is YOUR problem then? Way too much money or girls? I'd happy to take some if you'd like to share, then maybe I can stop being a cheapskate and start looking into those costly tools you are so fascinated about.

Even for basic C support paid tools like Keil or IAR is lacking. C99 support is just added and if your code calls for C11, well dream on. By the way, even Keil have gave up on their own compiler as there is not going to be any ARMv8-M support in their own compiler, and if you target ARMv8-M in uVision 5 you ended up using clang/LLVM. A modified version, but silll based on the open source LLVM code.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11248
  • Country: us
    • Personal site
dude, the problem is: YOU are so
so f*cking annoying with that
Actually no, you are getting into every thread and bash GCC.
Alex
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Actually no, you are getting into every thread and bash GCC.

oh, really?  in this topic it's happening again:
title "Taking a C++ class, looking for a C++14 compatible microcontroller to play with"
we were talking about *the language itself* (with an interest for some features)
and … oh, see, GCC once again is actually the topic


so, everything, even the hardware MUST be gcc-compilant
because blablablablabla  :blah:

fsck off, last time I waste my time
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Actually no, you are getting into every thread and bash GCC.

oh, really?  in this topic it's happening again:
title "Taking a C++ class, looking for a C++14 compatible microcontroller to play with"
we were talking about *the language itself* (with an interest for some features)
and … oh, see, GCC once again is actually the topic


so, everything, even the hardware MUST be gcc-compilant
because blablablablabla  :blah:

fsck off, last time I waste my time
Point me to one of your favorite compiler on any architecture that is 1) not based on GCC or LLVM/clang, and 2) supports C++14.

If the compiler does not support the language any more talk is BS. And so far the most famous compilers that advertise C++14 support are either GCC, LLVM/clang or a derivative of them. So as of October 2016 talking about C++14 is synonymous with talking about "supported by latest GCC or LLVM/clang"
« Last Edit: October 17, 2016, 07:06:19 pm by technix »
 

Offline nbrittonTopic starter

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: us
Actually no, you are getting into every thread and bash GCC.

oh, really?  in this topic it's happening again:
title "Taking a C++ class, looking for a C++14 compatible microcontroller to play with"
we were talking about *the language itself* (with an interest for some features)
and … oh, see, GCC once again is actually the topic


so, everything, even the hardware MUST be gcc-compilant
because blablablablabla  :blah:

fsck off, last time I waste my time

lol, funniest thing I read all day.
 

Online amyk

  • Super Contributor
  • ***
  • Posts: 8270
The Quark D2000 is (only) available in a QFN package.
I don't think that core runs AMD64 or x86 though...
The D2000 uses the P5 ISA (sans floating-point), it's the D1000 that's not x86-compatible.
It's a 486SX core with some P5 instructions added on. If I remember correctly, many of the diagrams and text in the datasheet were identical to those in the 486 manual, but with the name changed.
 

Offline nbrittonTopic starter

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: us
There's also no D1000 board for sale to the general public, even though there's mention of one in the documentation.

It exists, but apparently it's not available to the general public...

http://www.cnx-software.com/2015/11/10/intel-quark-d1000-customer-reference-board-and-intel-system-studio-for-microcontrollers/

The D2000 development kit is available at mouser for $15...

http://www.mouser.com/ProductDetail/Intel/MTFLDCRBDAL/?qs=sGAEpiMZZMvzNxwKcL67%252bpwZleYEABNkLLpgXezJXXQ%3d

« Last Edit: October 18, 2016, 07:23:27 pm by nbritton »
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Historical reasons and Linus' personal animosity towards C++, probably related to the former. When Linux was started C++ wasn't that mature, compilers buggy and the UNIX tradition has always been K&R C.
I've never spoken to Linus, but spent some time trying to guess at this animosity... and he may have a point. One of the problems with a large distributed project like Linux is making sure that lots of folks are able to contribute. C++ as a language could work against that because it *is* a very complicated tool and can be used so many different ways that one programmer's C++ may be almost unrecognizable to another. That's something Linus probably can't afford.

OTOH, a focused team with experienced engineers and the ability to adhere to coding standards can mandate certain restrictions in the C++ they write and do good work. Again, clang and LLVM are a positive example. Google has 100 million lines of C++, so it seems they've found a way to tame the complexity beast too.

Where I work, everything from the reset handler on up is written in C++ 11. All that stuff runs on a Cortex-M0, and is a pleasure to work with.
 
The following users thanked this post: lukier


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf