mikroElektronika ARM compilers: Development Update

[anikolic]

mikroElektronika ARM compilers: Development Update



Our software developers posted a new blog related to ARM development. Check it out:
1. mikroC PRO for ARM blog
2. mikroBasic PRO for ARM blog
3. mikroPascal PRO for ARM blog

[AndyIvan]

That is fantastic news, I will definitely be buying this compiler.
Just a question, will there be an inbuilt Mikroe RTOS? Pretty much all of my applications I would like to use RTOS.

Warm regards,
Andrew

[mLaki]

Judging by this blog update, mE is developing its own hardware cortex-m3/m4 debugger. Is this official "no" for third party hardware like J-Link, ST-Link, ARM-USB-OCD...?

[rmteo]

Judging by this blog update, mE is developing its own hardware cortex-m3/m4 debugger. Is this official "no" for third party hardware like J-Link, ST-Link, ARM-USB-OCD...?

I sure hope that your mE is NOT thinking along those lines.

@Andrew, the toolchain that I am currently using does provide a built-in RTOS (with integrated monitoring). I think that this feature is necessary for any kind of serious development work and hope that it will be included. Just like you, I use an RTOS in all my applications.

[seulater]

I think that this feature is necessary for any kind of serious development work and hope that it will be included. Just like you, I use an RTOS in all my applications.

I agree 110%, an RTOS is a must have for ARM development.

[octal]

I think it would be better stop asking mikroE about RTOS implementation. Sincerly I think that RTOS building is already a full time work for an entire company!!!
Having a stable RTOS, fully functionnal and maintaining it is a huge effort.
MikroE is mainly a hardware and compilers company. I think that what would be nice is that users asks them to do their best to provide and maintain the tool they are already doing.

What I would say, is that I would more expect from mikroE to provide the most stable compiler and the best code optimizer and to implement all standard debug tools (DWARF, ELF, COFF, ..., std JTAG support ....).
With those tools, users or even other companies can specialize in making RTOS specifically to mikroE compilers. This would lead to the best of all worlds: Best tools and best libraries.

Stop asking mE to provide the compiler and all the HIGH LEVEL libs, or someday we will finish up having users asking mE to delegate developers to make their own projects!

And as an example, I would suggest to anyone asking since years for RTOS to download something like FreeRTOS and to do port it to mikroC for example.

[seulater]

I think it would be better stop asking mikroE about RTOS implementation. Sincerly I think that RTOS building is already a full time work for an entire company!!!

Hardly the case. The best one out there MicroC/OS-II was written by one man in his basement. Likewise, Crossworks CTL was also written by one man. I have used CTL in every arm project i have and it has not once given me any problems or troubles. RTOS is not a vastly complicated thing to have a whole company efforts put to it.

There is nothing wrong with requesting anything to make a product better. Some things in life need certain things to bring them to full potential.
One would not have a race car engine with stock exhaust on it.

Sure, there is FreeRTOS, which i have ported over to two other compilers with little effort. when you try to do it to mikro, you run into all sorts of problems due to it does not carry many of the standard libs as a typical C/C++ compiler has, so your really going to have to go through some serious hoops to get that to work.

If they are smart enough to make a compiler, they have the smarts to throw in a simple RTOS, it does not need to be a full featured ROTS, threading, messaging, priority's and so on will be enough.

The bottom line is simple, if your going to use an ARM without an RTOS your most likely using the wrong processor for the job. It would be better to drop way down to a mega 8,16,32.

[octal]

The best one out there MicroC/OS-II was written by one man in his basement. Likewise, Crossworks CTL was also written by one man

I know both developers, and those are not "simple one man"

and btw. MicroC/OS-II is far from being the best

Second, you are talking only about the BASE RTOS ... this is not rocket science and you could do it (since YOU ARE ONE MAN ).

When RTOS development becomes a nightmare? When you'll want to use ANY of the actual libs with it, nothing will work.
All libs must be reworked to be compatible with the RTOS (mainly pb with interrupts vs scheduler and stack usage). and all that must be documented.

This is a huge work!

If they are smart enough to make a compiler, they have the smarts to throw in a simple RTOS, it does not need to be a full featured ROTS, threading, messaging, priority's and so on will be enough.

Sure, but in contrast to Rowley with its 3 GCC ports (they dont make compilers, only make the RTL for GCC and integration modules for hardware debug) or Micrium (which dont make compilers nor hardware), they are providing and maintaining actually more than 12 compilers and they making all sort of tools to be in harmony with their hardware dev team.

Sure, there is FreeRTOS, which i have ported over to two other compilers with little effort. when you try to do it to mikro, you run into all sorts of problems due to it does not carry many of the standard libs as a typical C/C++ compiler has, so your really going to have to go through some serious hoops to get that to work.

Read AGAIN my post!!! Instead of asking for additional HIGH level libs, try to spot out the problems when porting code and ask them to modify their compilers accordingly. I personally would prefer 9999999 customers asking MikroC to be 100% ansi compatible or implementing code relocation the way other compilers do, instead of bothering the dev team with standard and high level libs. Such demands will keep mE developers working on what they do best "writing compilers" and would make it easy to other companies or users to do port existing code.

I think this is better strategy for everybody!

[octal]

The bottom line is simple, if your going to use an ARM without an RTOS your most likely using the wrong processor for the job. It would be better to drop way down to a mega 8,16,32.

I'm not that sure!!! There are a lot of applications where an RTOS is not really mandatory or even a problem. When you talk about ARM you should specifiy which product line: Arm9, Arm8, Arm7, ... Cortex-M0, M3, M4 ????

And all depends on what you are doing. on Cortex-M0 chips, for some applications, using any RTOS would mean having a non acceptable latency, and best solution for a lot of problems is using bare state machines with clever interrupts handling.

All depends upon applications.

[rmteo]

Here's how I see it. Right now, I am using Rowley Crossworks and am happy with it. If mE (or any other company for that matter) were to come up with a product that will better fit my needs (at a price that I would be willing to pay), then I will seriously consider switching to it. If not, then I will stay with RC.

[octal]

@rmteo,
what you say is obvious. No one would like to change his dev tools (and mainly his dev habits) unless he'll find a better and more productive replacement. What I mean is that mikroE is a young company and its compilers are young. Users can influence the development of actual and future version of those compilers. If users continue asking for libs only, they'll got libs for specific compiler, and my tought is that this is not the way to go.

[rmteo]

There 3 principles I follow when designing MCU based systems.

1. NEVER DO IN SOFTWARE WHAT CAN BE DONE IN HARDWARE (IOW, pick the appropriate hardware, no matter which BRAND)
2. NO CODE CAN BETTER THAN ITS DESIGN (IOW, design first and start coding ONLY when you have a complete design)
3. WHEN THE MCU HAS NOTHING TO DO - IT SHOULD DO NOTHING (IOW, it should be in a sleep/low power mode unless it is doing something you WANT it to - no looping delays, blocking commands, etc.)

To me, a wanting better compiler is like a wanting better core (ARM vs MIPS vs AVR etc.). Sure one can be a faster and/or more efficient but as I stated in #1 above, a hardware peripheral will typically perform several orders of magnitude more quickly/efficiently than its software equivalent.

Having/using an RTOS lets one focus on the design (rather than coding) leading to a system that is modular, mantainable, easier to debug and less error prone. I do not start coding until the system is fully designed per its specs. Also, an RTOS makes it very easy to utilise the low power modes of an MCU - most applications use only a small percentage of the total available CPU load.

Bottom line is, more than half the battle is won by selecting the right components (both hardware and software) and having a clear picture of the overall design and function of the system. Beyond that the compiler (and coding) is just a tool to fill in the blanks to complete the system.

[seulater]

And all depends on what you are doing. on Cortex-M0 chips, for some applications, using any RTOS would mean having a non acceptable latency, and best solution for a lot of problems is using bare state machines with clever interrupts handling.

Sure it depends on what your doing which is why i said "most likely". Most RTOS have a way to stop the scheduler to allow you to run certain code without being interrupted.

Read AGAIN my post!!! Instead of asking for additional HIGH level libs, try to spot out the problems when porting code and ask them to modify their compilers accordingly. I personally would prefer 9999999 customers asking MikroC to be 100% ansi compatible or implementing code relocation the way other compilers do, instead of bothering the dev team with standard and high level libs. Such demands will keep mE developers working on what they do best "writing compilers" and would make it easy to other companies or users to do port existing code.

I agree with you 100% on this, i have tried this in the past with them and have been shot down every time. Furthermore, when i have done this other members in the forum started to point the finger at me like i was just silly for mentioning it. So i gave up. The whole point of C/C++ was to make code as portable from one platform/ processor to another.

[seulater]

Having/using an RTOS lets one focus on the design (rather than coding) leading to a system that is modular, mantainable, easier to debug and less error prone. I do not start coding until the system is fully designed per its specs. Also, an RTOS makes it very easy to utilise the low power modes of an MCU - most applications use only a small percentage of the total available CPU load.

well said.

[octal]

Having/using an RTOS lets one focus on the design (rather than coding) leading to a system that is modular, mantainable, easier to debug and less error prone. I do not start coding until the system is fully designed per its specs. Also, an RTOS makes it very easy to utilise the low power modes of an MCU - most applications use only a small percentage of the total available CPU load.

well said.

I agree with that, and I do not question the use of RTOS. This is the main goal of their existance.
What I say is that RTOS usage is not possible for every project. And using a state machine as implementation does not mean continuous consumption or polling!!!! For ARM case, I can use a CORTEX-M0 for pricing and because they offer excellent peripherals (like IRDA support or SPI extended modes) and because of power consumption. I can implement a State machine and keep the processor 90% of its time in an extreme low power mode (MCU stoped and only some peripherals awake to generate interrupts). I can't see myself using an RTOS for extremely time contrained and small application where clever use of power modes and interrupts do the thing. I wont switch to a more expensive chip just because my RTOS induce a high latency.