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

[bugzilla-daemon@bugs.ecos.sourceware.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 #14 from Jerzy Dyrda <jerzdy@gmail.com> 2012-04-03 12:44:58 BST ---
Hello all,

I think that it's high time to add my remarks.

(In reply to comment #13)
> (In reply to comment #10)
> > Hi Jifl, can you integrate this contribution with the existing STM32
> > contribution in bug #1001219 ? It seems that the Jerzy's contribution should
> > really have been checked in first to avoid conflicts.
> 
(...)
> However looking at Jerzy's contribution, the STM32 variant changes in the eCosCentric contribution
> completely subsume and obsolete what Jerzy did, given this needs to provide
> both connectivity line *and* F2/F4 processor support, which changes clocking
> and pin mapping properties significantly, so the result would still have been
> something that looks identical or near-identical to this contribution.
That's right the eCosCentric contribution provide much more and this work
should have 
priority against my. I don't see any problem to modify ethernet driver to
comply to the eCosCentric contribution.

> 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?
2. Is it any plan to push ethernet driver in near future?

> As for the Ethernet, it's up to Jerzy if he wants to use the definitions
> provided, or provide his own alternative in var_io_eth.h - at least a separate
> file keeps it all self-contained (var_io.h was getting too big to be
> navigable). All I would say is that eCosCentric's driver has undergone
> extensive testing using these definitions, so they are "known good", and has
> been used on multiple boards, and include necessary changed definitions for the
> F2/F4 which Jerzy's obviously wouldn't. 

> 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
2. Tx/Rx DMA descriptors definitions are moved to ethernet driver
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
> "> Regarding pins, some addition to my statement in Comment #11. Since pins are
> > being provided by HAL, they should be defined in HAL (unlike other Ethernet
> > definitions such as registers, etc.). Preferable place is plf_io.h rather than
> > var_io.h. because other chips (present or future) may have different pin
> > mapping.
> Yes you are right. Despite of promised pin compatibility by ST pins assignment
> between F105/7 CL and F2xx family differs."

Summarizing:
I open to modify driver and if anyone is still interesting in my implementation
of ethernet driver for STM32 I can do that.
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.


Best regards,
jerzy

-- 
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.