This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Recommodation for start of new chip-family support


Hi again,

first of all thanks jerzy for your quick answer (did your message arrive
at the list?)

I'm replying to myself to refine my thoughts a bit in reaction to
jerzy's answer.

Am Donnerstag, den 22.04.2010, 15:33 +0200 schrieb Manuel Borchers:
> Hilscher (located in Hattersheim) is designen products / software in the
> automation area. They have a lot of different boards for each of the
> processors in the portfolio which differ in what is placed (amount of
> SDRAM, type of flash, used UART channels, etc).
> 
> I'd like to support as much as possible or better said, I'd like to
> establish a starting point to add many boards without doing too much
> coding and sharing the same codebase.
> 
> I started with the HAL port for one of the boards. I chose to do a
> board-level port to use the ARM9 variant infrastructure. But I'm getting
> the feeling, that this isn't the right way to go, because the UART
> (code) for example is the same on all the boards for all the processors.

What I wanted to stress here is the hugh amount of boards that are
available. I'll tyr to show a small hierarchy:

netX-Family
-> netX500 -> NXHX500-RE
           -> NXHX500-FB
           -> NXHX500-ETM
           -> NXSB100
           -> NDSB
           -> NXBB-HMI
           -> ...
-> netX50  -> NXHX50-RE
           -> NXHX50-ETM
           -> ...
-> netX10  -> NXHX10-RE
           -> ...

I guess you get the point.
So, why don't I want to make board-level ports? Because there is much
common board-level init stuff (configuring multiplex options for IOs,
the simple polles UART code most ARM ports are using, ...) that
sometimes depends on the chip type, sometimes it's even common to all
chips (i.e. UART). Often it only depends on things like how many UARTs
are there on the board.

When I would do board-level ports, I would have to have the board-init
stuff (that is mostly common) for each of these boards. When something
needs to be corrected/added, I would have to do this for ALL boards.

That's the reason, why I'm asking the list. Wouldn't be a variant port
be better in this scenario? I.e. I would implement the init stuff,
polled serial driver in the common variant port and just use defines by
the board selection to do the specifics in the variant code?

Or are there other/better aproaches to my problem?


Cheers,
Manuel

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]