This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: eCosCentric Cortex-M port contribution
Nick Garnett wrote:
"simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes:
Ok, I guess the issues you're talking about are not related to the
silicon errata just release by STMicroelectronics, concerning some
compilers generating incompatible code with all but the latest
revisions of the STM32 processors?
No they are not. ST is annoyingly vague about exactly what the
problems are in that erratum, but the description bears no relation to
the issue we have. In any case, that erratum refers to medium-density
devices while the part on the eval board is high-density. Of course I
don't know what density device or revision you are using for your
own hardware, but it is probably worth ensuring you get parts that
avoid this issue.
Yeah, our current designs are only based on high-density parts, so there
should be no problem. What about the just released toolchain of
Codesourcery, does it already fix the issues you're talking about?
It occurred to me, now that I have been digging into the subject more
deeply, that there are some issues concerning the design of the
Cortex-M3 to match with ecos. I think I do understand the design of
how a kernel should work under the Cortex-M3 architecture, but
admittedly I don't quite see yet how to do that efficiently with
ecos. Does your solution come with changes in the generic ecos kernel
code, or did you manage to solve it all in the Cortex-M3 HAL?
It is all solved entirely in the Cortex-M HAL. Like you I initially
thought that eCos would fit quite nicely. However, the priority
mechanism, the strict enforcement of exception nesting and some other
things mean that the obvious approach didn't work. You either ended up
throwing a hard fault exception, or ended up with all interrupts
masked. I believe my eventual solution is quite elegant, but it was
won at the expense of some false starts.
Yeah, my current implementation suffers from hard faults too :) and I
guess this has to do exactly with what you told, enforcement of
exception nesting. Anyway, would you give me some advice into what
direction I have to go to fix the problems? I would really like to get
this working, even if it's just for learning purposes.
Of course, it might make more sense to just wait for you to release
the port, but this puts us on hold for an uncertain amount of time, as
you don't make a clear statement of when the release will be. So I
think it would be great to start working with your port, as I guess
it's pretty sure that even if I continue developing and get a working
solution myself, it will be your port that ends up in the official
ecos community repository. So my past and future work will be quite
obsolete, despite the learning I did :(
The exact release date depends on whether any serious problems are
thrown up in testing and how quickly we can deal with the remaining
toolchain issues.
I see, this of course is a very vague statement.
Everything you have learned so far will still be useful, so nothing
has been wasted :-)
That of course is true, I have learned a lot already. Anyway, I would
have rather spend my time collaborating with you, working on a common
solution instead of doing my own.
Simon
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss