Never heard of it. But it's a interpreter... so....
I never understood these choices. On one hand embedded devs are bitching about how in efficient, bloated etc all but their hand-optimized asm code is (overstated to make a point
). And on the other hand we create levels of overhead that are just not necessary...
On the other hand, hardware is getting bigger, better, faster and cheaper. So why not use a RaspberryPI and boot into Linux to read a temperature sensor...
So why not use a RaspberryPI and boot into Linux to read a temperature sensor...
Because you use too much power and can be hacked with all the outdated open source sw.
I saw there are now uC that use tens of nA instead of mA.
Never heard of it. But it's a interpreter... so....
Well, as I got it, it was supposed to run on some kind of VM, like Java. Not strictly an interpreter, although I guess you can call it that...
Some people have actually advocated the use of Java on embedded targets. Whether it makes sense is probably a topic that would make for a very long and heated debate.
It's "interesting" though to see how much programming languages still spark initiatives all over the place (while successes are very few...)
I've once seen a embedded Java product. Required lots of memory and didn't perform well.
Perhaps a good prototyping tool, but not for something serious.
I don't think either end of the spectrum is a good place to be. You can't be productive if you have to spell out all the bits in a low level language (ASM) but you can not expect that you can get away with every abstraction (overhead) that works on a normal PC either...
But with hardware becoming bigger and cheaper, the balance can shift more towards the abstract (overhead) end, without paying too much a price - depending on the project of course. Lots of project don't need/have critical timing that would require dropping down to ASM, some do.
Oh and the PI comment was meant as sarcasm...
Yes, but for most that is not the point. Economics and time to market are the point.
For a developer that translates to: the more productive you can be, the better. Productivity lies in tools and language (to some degree).
The main problem is that the vendors do not put much effort in innovating their toolset (compilers, -new- language support etc). That and the conservative nature of the seasoned embedded developer, means that C is still regarded as king (generalizing here of course).
I've once seen a embedded Java product. Required lots of memory and didn't perform well.
Perhaps a good prototyping tool, but not for something serious.
You can't judge from single sample. There are great chances that SIM card in you phone is Java VM (
ETSI TS 102 241). Also many smart cards happen to be
JavaCard type.
I've once seen a embedded Java product. Required lots of memory and didn't perform well.
Perhaps a good prototyping tool, but not for something serious.
You can't judge from single sample. There are great chances that SIM card in you phone is Java VM (ETSI TS 102 241). Also many smart cards happen to be JavaCard type.
Just because it exists almost everywhere and is running on billions of devices doesn't mean it's the best thing ever like a lot of people want it to be. Just look at android, developing anything on android isn't the best experience you're gonna have. IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.
But at the same time I'm not some corporation who prioritizes development speed(ie money) more than the actual outcome.
Just because it exists almost everywhere and is running on billions of devices doesn't mean it's the best thing ever like a lot of people want it to be. Just look at android, developing anything on android isn't the best experience you're gonna have. IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.
But at the same time I'm not some corporation who prioritizes development speed(ie money) more than the actual outcome.
Hammer and screwdriver both are tools, just different. The same about almost everything including programming languages and operating systems - there are and always will be *different* tools for *different* jobs. Speaking of B# language - to me it looks like one of many (failed) startups that hoped to be bought by big business and make founders rich, yet did not succeed.
While the use of the # is annoying, at least they aren't using it to signal a CLR based language.
That said, I'm not sure whether it's better than a main stream Java implementation. Though the no GC is a good point (can't remember if the JVM for embedded provides this or not).
Post back with your findings if you do use it. I'd be interested in hearing them.
TonyG
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.
Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else. These 'unnecessary' layers of abstraction are needed for when project become more complex and elaborate. At a certain point you cannot hold the details of the entire program in you head and you need to hide complexity behind an abstraction. Also when the API is designed well, it's very easy and quick to learn and use it in your program.
As for the language, I think a we can do a lot better than C. I would go for a subset of C++ just because most vendors have some level of support for it. Also meta-programming (C++20) is something to keep an eye on (beyond constexpr). That would allow you to express a lot of static stuff at compile time and control what can and cannot be done at runtime. "
Wrong code should not compile".
I have serious doubts if any custom language could ever get the traction and maturity of a well established language, like C++ (breadth of support, tools, community etc). If you want to try something new, I would take look at Rust, which looks promising.
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.
Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else.
"API language"? What are you talking about?
Hardware Abstraction Layer shall never be part of programming language. It's just library at best, sometimes not even that. Language shall provide hardware *access*, not abstraction.
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.
Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else.
"API language"? What are you talking about? Hardware Abstraction Layer shall never be part of programming language. It's just library at best, sometimes not even that. Language shall provide hardware *access*, not abstraction.
I meant the metaphor or analogy the API is expressed in. The logic and coherence between the different parts of the API. The better this 'language' (not a programming language!) the easier it is to learn it and use it - once you understand the premise on which it is based...
Better?
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.
Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else. These 'unnecessary' layers of abstraction are needed for when project become more complex and elaborate. At a certain point you cannot hold the details of the entire program in you head and you need to hide complexity behind an abstraction. Also when the API is designed well, it's very easy and quick to learn and use it in your program.
As for the language, I think a we can do a lot better than C. I would go for a subset of C++ just because most vendors have some level of support for it. Also meta-programming (C++20) is something to keep an eye on (beyond constexpr). That would allow you to express a lot of static stuff at compile time and control what can and cannot be done at runtime. "Wrong code should not compile".
I have serious doubts if any custom language could ever get the traction and maturity of a well established language, like C++ (breadth of support, tools, community etc). If you want to try something new, I would take look at Rust, which looks promising.
I'm not saying all layers of abstraction are bad, it's the unnecessary layers that are. This is happening more and more these days and is probably the reason why software is getting slower. And not to forget all the extra stuff that isn't really necessary, but that's another topic for another time.
I'm not saying all layers of abstraction are bad, it's the unnecessary layers that are. This is happening more and more these days and is probably the reason why software is getting slower.
If something is unnecessary, then what's the point of using it? Typical example - embedded programmers complaining that stm32 HAL libraries are "bloated". Well.. they are - for those who want to compile their "Hello World" example fast and for free. So what? If you want something better then buy it or create yourself.
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.
Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else.
"API language"? What are you talking about? Hardware Abstraction Layer shall never be part of programming language. It's just library at best, sometimes not even that. Language shall provide hardware *access*, not abstraction.
API is just part of the system knowledge or process knowledge. Nothing to do with programming or programming language itself.. Same with memory management, it is just pea counting.
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.
Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else. These 'unnecessary' layers of abstraction are needed for when project become more complex and elaborate. At a certain point you cannot hold the details of the entire program in you head and you need to hide complexity behind an abstraction. Also when the API is designed well, it's very easy and quick to learn and use it in your program.
As for the language, I think a we can do a lot better than C. I would go for a subset of C++ just because most vendors have some level of support for it. Also meta-programming (C++20) is something to keep an eye on (beyond constexpr). That would allow you to express a lot of static stuff at compile time and control what can and cannot be done at runtime. "Wrong code should not compile".
I have serious doubts if any custom language could ever get the traction and maturity of a well established language, like C++ (breadth of support, tools, community etc). If you want to try something new, I would take look at Rust, which looks promising.
I'm not saying all layers of abstraction are bad, it's the unnecessary layers that are. This is happening more and more these days and is probably the reason why software is getting slower. And not to forget all the extra stuff that isn't really necessary, but that's another topic for another time.
It is how you make the abstraction, if done correctly it simplifies if done poorly is makes things more complex. For my thin (I do mean thin) knowledge and experience with many system with "abstraction" it usually makes things more complex and harder to really understand, like example poorly documented do it all libraries (with usually colliding logic or nomenclature with parent system). Besides when talking general programming languages the interface is always textual functions, calling layers of more or less mystery functions. Which is tried to compensate with fancy monsters (even more hidden behavior with textual interface) and tabulations.
It's "interesting" though to see how much programming languages still spark initiatives all over the place (while successes are very few...)
Other than assembly language, only 3 languages pass the test of time: FORTRAN, COBOL and C. Everything else is just a passing fad.
FORTRAN 1957 - still used for scientific computing
COBOL 1959 - still used in banking
C 1972 - A newcomer but it seems to have staying power. We’ll have to watch and see.
It's "interesting" though to see how much programming languages still spark initiatives all over the place (while successes are very few...)
Other than assembly language, only 3 languages pass the test of time: FORTRAN, COBOL and C. Everything else is just a passing fad.
FORTRAN 1957 - still used for scientific computing
COBOL 1959 - still used in banking
C 1972 - A newcomer but it seems to have staying power. We’ll have to watch and see.
You forgot FORTH 
It's only been around since 1970 (coincidentally, the year I started using the IBM 1130 and Fortran) but I don't consider it in common use. More of a curiousity and popular in certain niche applications but definitely not mainstream. Neither is APL and although Algol is the grandfather of all block structured languages, it too lies on the ash heap of history.