Support for eCos/eCosPro

[RallySmith]

Initial support for eCos run-times.

The work is (apart from the minor references in the existing "RTOS Views" files) self-contained in the new rtos-ecos.ts source. It is an initial, basic, thread list view. If the changeset is acceptable and merged then I do intend to extend the eCos functionality to present more useful "system run-time state" information as opposed to just the thread view.

Apologies in advance for my rudimentary TypeScript skills.

[PhilippHaefele]

Hi @RallySmith

Thanks for contributing the eCOS support.

Is there an easy way to get an eCOS example for an STM32F429 running?

Best regards
Philipp

[haneefdm]

Thank you very much. Could you also fix the lint errors?

[RallySmith]

Is there an easy way to get an eCOS example for an STM32F429 running?

I assume you mean a stm32f429i_disco (rather than the eval board)?

If so: I have placed a simple test ELF on my local web server:
http://www.rallysmith.co.uk/stm32f429i_disco_kmutex4
and the source for that test:
http://www.rallysmith.co.uk/kmutex4.c

Annoyingly it would be quite a few hoops to get a complete source and build world for you, since I only have the eCosPro sources to hand - hence just providing a binary and the source for that test case just now in the hope that it is useful.

At least that way you could at least set some BKPTs on the function names, or system calls and satisfy yourself that the XRTOS display reflects the thread status.

kmutex4 is just one of the standard kernel test suite applications, and just bashes a few mutexes with a few threads.

You can have the Cortex Debug OpenOCD (or whatever) setup halt on cyg_user_start to get past the run-time init and stop on startup at the test code start, and if you want you can also set a BKPT on cyg_test_exit to catch the end of the code (since it just busy loops on termination). Diagnostic output is to the VCP (STLink) 115200 8N1 and it just outputs some status as it barrels along.

[RallySmith]

Thank you very much. Could you also fix the lint errors?

Pushed. Cheers

[haneefdm]

A Nucleo is fine if you can get it. Disco's are pricey arent they...

[RallySmith]

A Nucleo is fine if you can get it. Disco's are pricey arent they...

Sadly I do not have in my collection a NUCLEO-F429ZI and it seems that they are harder to get hold of these days (none of the standard main suppliers have stock; and eBay is asking silly money).

I could provide binaries for the NUCLEO-H723ZG or NUCLEO-L476RG. Mostly the available eCosPro STM32F/H/L targets are for -DISCO or -EVAL boards.

[RallySmith]

A Nucleo is fine if you can get it. Disco's are pricey arent they...

Just wanted to check (since I may have misunderstood the last comment, and I have just been waiting for feedback):

Is this changeset blocked for acceptance until someone else has verified operation by running an eCos/eCosPro application on a target platform that they have? or are the maintainers willing to accept the changeset as-is since it only "affects" eCos/eCosPro targets?

If the former then the NUCLEO-F429ZI is probably a non-starter (no new boards to be bought online it seems, since it was EOL a while ago).

We might have to do some ping/pong of information to understand what targets eCosPro supports (and I can build test executables for) vs what boards the maintainers of rtos-views have in their possesion for testing against.

Cheers,
-- Jamie

[haneefdm]

Not blocked. I usually work on this over the weekend. But, we have to select a new, more modern board to verify stuff. Something not too pricey and simple. An ST board is fine. The board selection matters to me and others because we will be asking them to show an example using that board (which they may have to buy). -EVALs are too pricey

• Not too pricey (in the US$20 range)
• Not too old
• No external probe required
• Preferably a USB-C connector for debug

Opinions?

[RallySmith]

NUCLEO-H723ZG ? Is still available in reasonable numbers; but is "expensive" by your goals at ~USD$40/GBB£28
(only mention that one since I have one to hand and can target it with eCosPro :-)

Looking at the ST website there seem to be a few STM32F4/F7 "NUCLEO" boards around the $18->$40 range marked as ACTIVE.

The NUCLEO-L476RG ? I do not have one yet (and would need a little bit of effort to create an eCosPro conf for it, but since we support the stm32l47_disco board it should not be onerous to do a port to the simpler nucleo board) and it is in your <$20 range; and is a relatively modern STM32 implementation.

[haneefdm]

@PhilippHaefele What do you think about @RallySmith choices?

I am wondering whether there is a QEMU solution we should consider. Last I checked, there is minimal RTOS support for any devices but we don't need that ... since we are doing our own queries with the debugger.

[RallySmith]

For working with GDB and "closer" simulation of specific targets Renode is useable:
https://renode.io/

I have successfully used it to create simulations of customer specific boards where the same binary as shipped on real hardware is executed under Renode; and as "shipped" it has reasonable (CPU+memory+diag-channel) support for a selection of development boards.

My only complaint with Renode is they are very slow (to unresponsive) in having fixes and feature-enhancements fed into the mainline (I have a lot of outstanding STM32F/H controller patches from the other year still pending :-)
The upside is that the overall framework is good enough to allow very low-level debug to be done, and it is easy to extend if you need to add models for specific hardware (in fact the base C# world means you can do a lot with their binary release without having to build anything).

[haneefdm]

I looked at the code and I will merge it in. It may be the simplest RTOS we have.

@RallySmith Please help support this if there are issues

[RallySmith]

Indeed. I will help where I can with any eCos support issues in the extension. Also, as I mention in the comments, there are some feature extensions to improve the eCos information available that I plan on getting around to anyway.

Cheers,
-- Jamie