is support for cortex M4 based boards possible / planned

[abaumann]

Hi,

I developing my first programs with the oberon - 7 compiler from astrobe (mbed LPC 1768 and LPCXpresso LPC1769 ).
I don't like C based languages so much. It is a pleasure to program in oberon !

I thinking about using oberon in embedded development in my company.
In this context future directions of astrobe based software is very important for me.
One aspect is the support of cortex M4 based boards.

Is there a plan to support cortex M4 based boards ?


Best regards

Andreas

[cfbsoftware]

The Cortex-M4 instruction set is a superset of the Cortex-M3 instruction set so it should not be too difficult to get Oberon code working on the Cortex-M4.

Do you have a particular development board in mind?

Is there anything in particular that you are hoping to do with a Cortex-M4 board that you cannot currently do with a Cortex-M3?

[abaumann]

Hi,

Thank you for your fast response !

Do you have a particular development board in mind?

Not yet.

Is there anything in particular that you are hoping to do with a Cortex-M4 board that you cannot currently do with a Cortex-M3?

I think for hard realtime motion control applications the DSP inside a Cortex-M4 could be an advantage.

I assume that it is possible to develop "hard realtime" applications (for the field of PLC applications) using the oberon-7 compiler ?

Are there some restriction to realtime processing (derived from the runtime system) ?

best regards

Andreas

[cfbsoftware]

Yes - the Oberon compiler used in Astrobe is intended to be used for developing "hard realtime" applications.

There isn't a "runtime system" in the traditional sense of the word. Any processing overhead that does exist is related to features that help debugging. These can be disabled in v4.5 Astrobe or later by using the Array index checks and Assertions compiler options. However, you should not have to do that if you make good use of Astrobe's Leaf Procedures feature when implementing time-critical areas of code.

One other overhead when using a Cortex-M3 that you can't do much about involves floating point operations. Using a Cortex-M4 with an FPU would help with realtime applications that use floating-point operations extensively. We would need to modify the compiler to support an FPU but that should not be too difficult.

[cfbsoftware]

We are now investigating what we need to do to be able to support the Cortex-M4. Initial tests will involve a couple of LPC4088-based boards.

[Dimon]

We are now investigating what we need to do to be able to support the Cortex-M4. Initial tests will involve a couple of LPC4088-based boards.

When your investigations will end in success?

[Dimon]

We are now investigating what we need to do to be able to support the Cortex-M4. Initial tests will involve a couple of LPC4088-based boards.

LPC4357 also interesting device.

[cfbsoftware]

I'll post more information here as and when we make progress with the Cortex-M4.

As you are probably aware, the LPC4357 is a dual-core Cortex-M0/M4 device. Providing support for Cortex-M0 devices would be a much bigger task than the Cortex-M4. Apart from a few exceptions, the Cortex-M0 can only use the 16-bit subset of Thumb-2 instructions whereas we almost exclusively use the 32-bit Thumb-2 instructions. Furthermore, the M0 does not have access to five of the registers (R8 - R12) for most of the time. The M3 Oberon compiler uses these extensively. Consequently, unlike the M4, supporting the M0 in the compiler does not just involve supporting some extra instructions - it would require a complete redesign and rewrite.

I'm assuming anybody who was planning to use a dual-core device would not be satisfied if only one of the cores was used - or am I wrong?

[Dimon]

You are absolutely right.
But there are other considerations.
LPC4357 may be used as a dual-core devices, but also as a device with a clock frequency of 204 MHz and FLASH 1024 KB. LPC4088 has a frequency of 120 and FLASH 512. M0, if necessary, can be programmed by other means.

In addition LPC4357 has SGPIO and SCT.

LPC4088 incomparable with LPC4357, because LPC4088 has ADC, DAC, analog comparators, and LPC4357 has SGPIO and SCT.

LPC4088 and LPC4357 very different SoC. They are intended to solve different problems.

[abaumann]

LPC4357 may be used as a dual-core devices, but also as a device with a clock frequency of 204 MHz and FLASH 1024 KB. LPC4088 has a frequency of 120 and FLASH 512. M0, if necessary, can be programmed by other means.

I agree with that. From my point of view it would be a big deal to support LPC 43xx based MCU's.

Providing support for Cortex-M0 devices would be a much bigger task than the Cortex-M4. Apart from a few exceptions, the Cortex-M0 can only use the 16-bit subset of Thumb-2 instructions whereas we almost exclusively use the 32-bit Thumb-2 instructions. Furthermore, the M0 does not have access to five of the registers (R8 - R12) for most of the time.

This is also true but if it is possible to support the Cortex-M4 part without M0 then it would be OK to support LPC 43xx based MCU's with a useless M0 part. From my point of view the LPC4370 with 80-Msps sampling rate of the 12-bit ADC is very interessting. This device could be suitable for realtime vibration signal processing.

Kind regards,

Andreas