This is the mail archive of the
mailing list for the eCos project.
Re: Assignment query & tree organization
Andrea Michelotti wrote:
Jonathan Larmour wrote:
I don't know much about the Diopsis, but from what I see it contains an
ARM7 with a DSP. If eCos is running on the DSP itself that would want its
own HAL, but I would surmise that it's running on the ARM but prodding the
DSP and providing access to it. It's not clear to me why this would
a separate architecture HAL, rather than providing a way for variant
processor HALs to extend the architecture HAL in the way you would want.
The advantage is that the ARM HAL gets a lot more attention and so the
Diopsis will get any improvements and fixes that come for the ARM HAL if
uses it. If the Diopsis has its own architecture tree, it would not get
those benefits, and so would lose out on those improvements unless someone
notices. So it would be beneficial to keep them together if it is sensible
to do so.
Thank you very much for your interest.
As I said the modifications to arm architecture at the moment are restricted
to vectors.S to enhance interrupt handling (use of Advanced Interrupt
Controller to call interrupt handlers) and just an init procedure that
install two interrupt handlers for the DSP.
Then it sounds like we should be able to do something to support this. As
per Gary's other mail, the diff/patch of the arch hal changes would be good.
I don't like very much the duplication of code that I did at the moment. But
I would like to be free to optimize and specialize some piece of ARM7 code
without affecting other platforms. I'll have to modify also some part of the
stub to support debugging of diopsis (single step, stop during break...,
intercept particular addresses..). The idea will be to see diopsis not as an
ARM7 + a memory mapped DSP, but as a single processor.
I think you would have some significant hurdles with GDB to achieve that.
Is it what developers would want anyway? Since they are entirely separate
but parallel execution threads, running different code, it's difficult to
perceive the benefit.
Is there a clean way to modify interrupt handling and stub calls doing a
Roughly how does the AIC work? It may be something we've already dealt with
in a different way before. I had a quick search but only found
http://www.atmel.com/dyn/resources/prod_documents/6075S.pdf which only says
it optimises ISR branch and execution without saying how. If it means that
it will return the address of the ISR to use then there's only a relatively
small part of vectors.S that would need to be ifdeffed.
But if not, it can all be done, if nothing else by just ifdeffing entire
functions, or even files, based on some CDL option that the
variant/platform HAL defines.
Do you think is acceptable a solution where I modify some arm/arch files via
I think we want to keep generic code as generic. Instead the approach to
take is to take a step back and figure out what it is you are wanting to
allow being overridden and why. It's possible you might still have an
ifdef, but on some generic capability like:
which would be a macro the platform HAL defines. So if other similar
systems come along later, they would also make the same define.
Note that we haven't said that putting this in its own architecture tree is
the wrong thing to do - it may be right, in which case that's what we'll
do. But it is to be avoided if it can be.
Were you using eCos v2.0 or more recent CVS? The AT91 HALs had some
substantial work and improvements done to them since eCos v2.
I used the standard v2.0 distribution.
I'll check CVS version ASAP. thank you.
Since obviously this contribution would be checked in to CVS, it would be a
good idea to do that.
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine