[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001550

--- Comment #15 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-03 13:53:57 BST ---
(In reply to comment #14)
> > But yes, since an ethernet driver is not included in this contribution, 
>  (...)
> @Jonathan Larmour
> Before I'm starting work I think that status of eCosCentric ethernet driver
> have to be clarify.
> 1. If I can ask - why the ethernet driver isn't provided in this contribution?

Our ethernet driver is specific to our own port of the lwIP stack. Our lwIP
stack has modifications to make it "single-copy", but these changes have not
been released, and would not apply to public eCos's completely different lwIP
port. As a result of this, it provides a wholly different interface between
ethernet drivers and the lwIP stack. As such it is not usable with the BSD
stack - that was a deliberate choice for us due to the STM's focus on low
memory targets which makes use of the BSD stack unlikely, in which case having
a single-copy interface is also a useful memory saver compared to the standard
ethernet driver model.

> 2. Is it any plan to push ethernet driver in near future?

There isn't. You wouldn't be able to use it in any case, and to understand it
properly, you would need information on our single-copy driver interface which
is something which is being kept in-house for the foreseeable future. If you're
having specific problems with, say, driver initialisation, I could cut'n'paste
some snippets, but it wouldn't be the whole driver.

> > And he will probably find the majority
> > correspond exactly to what he's already got anyway since both the names and
> > values essentially come from ST anyway.
> Exactly - looking on  var_io_eth.h macros are very similar :)
> Diffs are:
> 1. Instead of macros like that CYGHWR_HAL_STM32_ETH_MACCR I tend to "increase
> readability"
> by separating ethernet module e.g. MAC from its register e.g. CR i.e.
> CYGHWR_HAL_STM32_ETH_MAC_CR

We just used the names exactly as ST document them, which doesn't have the
underscore, so you can search for the definition based on the exact documented
register name. It's not a big thing, but that was the reason it is like it is.


> 2. Tx/Rx DMA descriptors definitions are moved to ethernet driver

We just wanted to keep definitions laid down in the hardware documentation all
in one place. If there were two ethernet drivers (say, BSD and lwIP-specific,
like we sometimes have in eCosCentric), then you would want them to share these
definitions rather than duplicate them, so they are better off being in a
common place since they never change. Even if you don't use our definitions, I
would recommend you follow the same principle.


> 3. Pins mapping is moved to plf_io.h header according to Ilija hint :
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001219#c19

If you look more closely, you will see that only _some_ of the pins are defined
there. These are the pins that cannot be remapped, even on F2/F4, and thus do
not change so they should be common.

For the pins which can be remapped, they are indeed to be defined in plf_io.h.


> Summarizing:
> I open to modify driver and if anyone is still interesting in my implementation
> of ethernet driver for STM32 I can do that.

I'm sure people are. Don't underestimate the many people who will use stuff if
it's there and if it isn't just walk away :).

> IMO The fastest and simplest way to push driver is using contributing eval
> board STM322/40G but I don't have any possibility to achieve it.

I'm afraid we have no spare hardware. We only have one of each board and they
are needed for customer support. Once you're confident it /ought/ to work, I
could try out code on one though. But be warned I have a very high workload at
the moment.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.