New programing language for embedded systems

[HATHA]

Hi all

what you know about B#

B# (Be sharp): The New Object-Oriented Language for Embedded Systems

 

[3v0]

It is a virtual machine. They use real hardware to emulate their B# machine. That could/will slow things down but has its advantages.

It is only for larger uC's

Small footprint (<24KB Flash and <2KB RAM).

I do not think it is going to be free.

Do I like the concept ? Yes.
Do I think it will become a 'standard' language ? No, I expect it to flop. Because most do.
Would I pay money for it ? I would have to see a lot more of it. My guess is that the price will be in the $500+ range. That is a show stopper for me a hobby type. When I was working it would not have been a problem.

We have seen virtual machines in the past. Back in the days of the S100 bus we had the P machine. They even put together a computer that executed the instruction set in hardware.

The idea of "one size fits all" falls apart when it comes to IO. They are going to need unique IO modules to handle each vendors hardware. That may be a problem.

In spite of what I have said I do wish them the best.

3v0

 

[arhi]

its an attempt to "allow bad developers to enter embedded systems" ... make a point & click tool so any moron can program a uC and then hope that uC's will become bigger, faster and cheaper because more and more morons are using them ...

I really hope it will not "come to life" as I hate the "protect bad OS from bad programmers by fencing them in virtual machine" .net postulate on "big" devices with plenty of cheap and unused resources .. I hate the idea of doing that in the embedded market.

The only practical use would be to implement the virtual machine in hardware (like they planed for java and failed miserably) then it would actually not be "virtual" any more

 

[russ_hensel]

SourceBoost C++ is available now, free limited size version. Probably better for PIC 16 and 18

 

[HATHA]

Hi all
I have some question about concept of oo and vm

what is the advantage of virtual machine on embeded systems?
mean how could it be easy when program a embeded system having a VM ?

what is the different of VM and Real time operating systems (RTOs)

what is the advanteage of use of object oriant concept(over non oo language like assembly or c) in embede systems ?

 

[3v0]

Hi all
I have some question about concept of oo and vm

what is the advantage of virtual machine on embeded systems?
The idea is that one could write code that runs on many systems, these systems must run the VM to run the code.

mean how could it be easy when program a embeded system having a VM ?

what is the different of VM and Real time operating systems (RTOs)
Apples and oranges. A VM is one computer simulating another. The other is the virtual machine. A RTOS (Real Time Operating System) is an OS intended to deal with real time IO issues.

what is the advanteage of use of object oriant concept(over non oo language like assembly or c) in embede systems ?
The same as any other programming. In theory it is easier/faster to write bug free (mythical beast) code. Much embedded code is simple enough that OO does not provide much benifit. It is often not worth the overhead. As the system grows more complex the scales tip in favor of OO. Or at least that is the party line.
If you understand OO you do not need an OO language to write code that is OO. But an OO language tends to enforce the OO nature of the code. Along the same line you do not need an RTOS to do multitasking or real time IO.

You have asked a few questions. This is my take, Others may add to or dispute parts of it.
See bold text in quoted material.

 

[HATHA]

hi
thank you Mr.3v0

 

[arhi]

what is the advantage of virtual machine on embeded systems?

NONE
In theory the VM can be used to prevent some poor coding errors like writing to pointers that point to wrong place, nothing else. Implementing the VM in hardware is another story but not really practical .. then you could invent few new benefits but .. it is not that simple

mean how could it be easy when program a embeded system having a VM ?

only if you are bed programmer. VM can only "limit" you, cannot give you anything else... look at modern C compilers now .. you can do "init_pwm(40000); pwm_dc(50);" and you will start pwm at 40KHz and 50% duty cycle .. and it will do so on any uC that compiler support. You can on the other hand directly set all registers in order to achieve the same thing. If you use compiler function it will work but if you do it manually the code will be smaller and you will usually be able to tweak few more things that you cannot from the library function. What will you do is up to you, but you have a choice, the VM just removes the choice and leaves you with single option (to use function)... so you cannot "mess up" anything "by mistake"

in my book - removing the choice to everyone in order to prevent few morons to make the wrong one - is NOT good

what is the different of VM and Real time operating systems (RTOs)

the os/rtos/your application is running normally directly on the cpu so you are getting maximum benefit from hardware you are using. The VM is simulator, it simulates the "virtual computer" ... so it is few times slower then what the possible speed could be. Think amiga and PC... Amiga500 is in range with XT (4.77MHz)+VGA+SoundBlaster ... but you need several generations newer computer (486 @ 33MHz) to be able to simulate Amiga500 on PC

what is the advanteage of use of object oriant concept(over non oo language like assembly or c) in embede systems ?

In theory if compiler is good enough the OO will create as good the code as non OO language. The benefit of OO systems everywhere (including embedded systems) is code maintenance and re usability. Meaning, it is easy the make a set of classes that you can re use in your application, it is much easier to maintain those classes then "flat" libraries in non OO languages.

 

[HATHA]

thank your Mr.arhi

 

[3v0]

@HATHA
Read
P-code machine - Wikipedia, the free encyclopedia pay attention to the section Why p-code?

What they say makes sense but keep in mind that B# requires 24K of flash which does not work on small to midrange microcontrollers. On higher end chips where 24K is a small fraction of available memory they make sense.

You may be interested in reading about microcode.

 

[mdec]

It is a virtual machine. They use real hardware to emulate their B# machine. That could/will slow things down but has its advantages.

It is only for larger uC's
3v0

Hi all,

B# is an OO programming language running on a software VM (not hardware). Its VM (nothing to do with .NET or JavaVM that requires at least 32bits CPU and a minimum of 500Kb RAM and 500Kb Flash if not more) has been designed for small footprint embedded systems, the code generated is extremely compact. The current flag ship implementation is the Renesas M16 with 2KRam and 64K Flash (SPB target Board), it obviously flies on an ARM7. Unfortunately, no implementation on MicroChip Pics, the reason: need a minimum of 2K Ram, but also level of stacks to call functions (or methods).

We have seen virtual machines in the past. Back in the days of the S100 bus we had the P machine. They even put together a computer that executed the instruction set in hardware.

The idea of "one size fits all" falls apart when it comes to IO. They are going to need unique IO modules to handle each vendors hardware. That may be a problem.

In spite of what I have said I do wish them the best.

3v0

You are right, many attempts in the past, VMs, P machine, Pascal Machine (done in hardware). But at that time, speed was the down side, nothing to do really without performance. VM makes sense only if you can afford it? The B# VM contains a soft realtime multitasking, if there is critical code it has to be written in C or Asm.

May be because I wrote too many device drivers in my life, so when I designed B#, I was very cautious to make the IO completely portable in the language itself (the VM takes care of the rest), so you have the opportunity of writing a device drivers for a peripheral once for all (it could be reused with another MCUs). By the way the code generated by the compiler is position independent, so it could be flashed anywhere you want.

Look at the FAQ about "How does the get|set properties of B# help the portability of device drivers...":
**broken link removed**

B# is a small language (smaller than Java v1.0) for small MCUs, was not designed for large ones (then you have Java and C#). By the way for those who knows a bit of music, B# is the same note as C, as a sharper OO reincarnation It was always a challenge to combine the benefits of object orientation with the efficiency of C for small footprint embedded systems. There was simply no language available. Don't get me wrong, I love the C programming language, it is venerable, but old. It is our great portable assembler today, but by porting embedded systems on small MCUs, many C compiler vendors out there are not ANSI C compliant, they have tendency to offer special keywords and pragmas to support interrupt service routines and IOs. I understand and empathize with the programming frustrations of the embedded system programmer. I hope that my humble efforts go a long way to making the implementation of small footprint embedded systems a more pleasurable and productive pursuit.

Best Regards to everybody!

mdec

 

[3v0]

Michel,

First thanks for posting your reply and I do wish you the best.

Industry is using the term "small footprint embedded systems". In the context of this forum these systems are not small. Perhaps we are out of touch.

I will be watching to see what discount if any you will be providing for classroom use.

3v0

 

[mdec]

NONE
In theory the VM can be used to prevent some poor coding errors like writing to pointers that point to wrong place, nothing else. Implementing the VM in hardware is another story but not really practical .. then you could invent few new benefits but .. it is not that simple


only if you are bed programmer. VM can only "limit" you...

in my book - removing the choice to everyone in order to prevent few morons to make the wrong one - is NOT good...

Hi Arhi,

Here some advantages of a virtual machine (VM) on embedded systems.
The B# VM is written in full ANSI C and promotes:
• The reusability of software components expressed in binary
format on any architecture
• The writing of interrupts handlers and access device registers
in a uniform manner, independent of the underlying target
architecture (memory-mapped or port-mapped)
• No dedication to any specific microcontroller architecture
• The ease to test, debug, and maintain embedded applications


A VM provides additional levels of abstraction which isolate the developer from the idiosyncrasies of the underlying hardware architecture. But that's it. It is certainly not an easy ticket to enter in the embedded systems arena. Bad developers or those who underestimate and not objectively understand the constraints of embedded systems applications will always shoot themselves in their foot.

I perfectly agree with you that a VM is not a fence of protection neither a point and click solution for those who are used of unlimited cpu and memory resources. Embedded developers are very cautious about any waste, but a bit more flexibility and reuse will be a plus, if it is affordable.

Best Regards,

mdec

 

[arhi]

Here some advantages of a virtual machine (VM) on embedded systems.
The B# VM is written in full ANSI C and promotes:
• The reusability of software components expressed in binary
format on any architecture
• The writing of interrupts handlers and access device registers
in a uniform manner, independent of the underlying target
architecture (memory-mapped or port-mapped)
• No dedication to any specific microcontroller architecture
• The ease to test, debug, and maintain embedded applications

It is nice that it does that but,
- binary re usability is irrelevant imho when embedded systems are involved, it is not a bad thing, but not worth the overhead
- handling interrupts in a VM is generally a "lie" and one can implement "uniform handling of interrupts" in a compiler if one wants to using "smart compiler" like for example mikroC does or CSC C .. the whole interrupts and vm are not really fitting in the single sentence as you cannot guarantee any timing within vm hence the whole point of interrupt becomes pretty different then what interrupt really is in "real" system, not to mention "real time" system
- No dedication to .... aint really a good thing when "small fast and cheap" is the whole point ... don't get me wrong I work for company that invented Java, but there is a point and place for everything (except .net which is embarrassment for any real developer)
- the ease .. now this I agree with you 10000000% .. limiting developer by fencing the code inside the LVM allows the complete moron with 2 week course to call him self developer (anyone remember the gzilion "VB developers" that came out over night?) but it is LIMITING .. I do not approve that on desktop PC and hell will freeze before I approve it on my micro controller! You can have VM like flash, java and such where overhead is "acceptable" as you have binary independence from os/cpu on a large scale... so your binary works from "phone" to sun mainframe .. with possibility of doing it in hardware ... BUT you are distributing your "binary" to huge population ... in embedded systems, you do not distribute your binary to anyone!!! you distribute the SYSTEM where user have no idea what the firmware is, nor they want to know .. you choose the hardware, you have the source, you compile the source, you burn the source ... where's the need for VM ??? if you know you will be using uC XYZ, compile the darn code for XYZ and burn it?!?

The whole point is in that "ease" ... I do not approve / accept that that "ease" is worth the price ... I do believe C overhead over ASM, the time, the ease .. it is just worth it, the VM - not in the million years... now, that's me - I have a right to have opinion

A VM provides additional levels of abstraction which isolate the developer from the idiosyncrasies of the underlying hardware architecture. But that's it. It is certainly not an easy ticket to enter in the embedded systems arena. Bad developers or those who underestimate and not objectively understand the constraints of embedded systems applications will always shoot themselves in their foot.

allow me to disagree with you... VM provides additional level of abstraction at what cost... that's the major question... I recently fired a client/server developer who had no knowledge of tcp/ip internals ... "he was using components" and then when it stopped working he had no idea where to look ... this is the similar issue, VM is not "easy ticket" but
- the good developer do not need the benefit's VM is offering
- the moron will still be moron but will be able to provide code "That looks like it is working" .. and of course, because that moron works for 20% of what good developer costs, the device manufacturer will get the "moron" and more expensive chip -> so I will have to pay more for my CXYZYZ device, because they hired moron who put 10x more expensive uC inside so he can be able to "program without knowledge of what darn interrupt is" ... look around ... 99% developers have no idea what is the difference between von neumann and harvard architecture ... 90% never heard those terms...

I perfectly agree with you that a VM is not a fence of protection neither a point and click solution for those who are used of unlimited cpu and memory resources. Embedded developers are very cautious about any waste, but a bit more flexibility and reuse will be a plus, if it is affordable.

that's the whole point ... "if it is affordable" .. .it is always affordable .. but someone have to pay the difference .. and it is not going to be developer nor company .. it is going to be end user ... VM's have its use but IMHO embedded systems are just not one of them... especially as everything that you can provide with VM you can provide with "good" compiler, the only difference is that with good compiler you will have to allow "developer" to make mistakes and with VM you do not have to do that, you can put the limit there .. to repeat myself, I have pretty much same opinion of .net as most of the parallels stand

 

[mdec]

Michel,

First thanks for posting your reply and I do wish you the best.

Industry is using the term "small footprint embedded systems". In the context of this forum these systems are not small. Perhaps we are out of touch.

I will be watching to see what discount if any you will be providing for classroom use.

3v0

Hi 3v0,

By out of touch, you mean that the main interests of this forum are microcontrollers 4-8 bits for "very small footprint ES" where C and assembly are a must, such as PICs and the like. Is my assumption on RAM available and stack levels on PICs are still true on the most recent generation? For now, we are targetting the Renesas, AVR, and ARM families.

Are you actually teaching a course on a specific platform?

Best Regards,

Michel

 

[3v0]

Hi 3v0,

By out of touch, you mean that the main interests of this forum are microcontrollers 4-8 bits for "very small footprint ES" where C and assembly are a must, such as PICs and the like.

I have been active on the forum for about 2 1/2 years. I have not seen any 4 bit, mostly 8 and some 16 bit uC's A few members have expressed interest in 32 bit. In addition to asm and C some people are using the Swordfish Basic compiler.​

Is my assumption on RAM available and stack levels on PICs are still true on the most recent generation?

It is in the small uC's: 10F, 12F, 16F, and 18F lines. One would have to know your requirements and check the Microchip uC lines above that.

PIC 12 14 16 (Midrange) 8 Level Stack (13-bit)

PIC 18F Enhanced MCU devices have an 31-level deep x 21-bit wide hardware stack.

​

Are you actually teaching a course on a specific platform?

Yes, I am finishing my 3rd year teaching at Boise City High School. The first year I taught C#. The past 2 years I have taught embedded systems using Microchip PIC18F uC's and C.

Next year I plan to teach OO again. Most possibly C#. Many educators prefer Java as a first language. I use C# because it allows a smoother transitiion between the classes.

The coverage is about the same as university classes but we move at a slower pace. I am retired and teach the class as a service to the community.
​

Best Regards,

Michel

3v0 ......