Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001219
--- Comment #21 from Ilija Kocho <[email protected]> 2011-10-24 16:54:17 BST --- (In reply to comment #20) > > > 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. > Pining, in general is something that can change when new chips introduced. > > On the other hand, the pin functions - once assigned to Ethernet > > (although pins are provided provided by HAL) belong to Ethernet > > so their naming should reflect this Here is a plf_io.h snuppet: > > > > plf_io.h snippet -------------------------------- > > > > #define CYGHWR_IO_ETH_STM32MAC_MII_COL \ > > CYGHWR_HAL_STM32_GPIO(A, 3, IN , FLOATING) > > ... > > ------------------------------------------------- > OK. > > > > Also if_stm32.c > > Could CYGHWR_HAL_STM32_GPIO_SET(CYGHWR_...); lines be replaced by a loop? > Could you explain me what you mean? The idea is that, since there are many pins, a loop might slightly reduce the size, although I might be wrong. > > > And in order to avoid specifying HAL specific macros in a device driver, a > > new > > macro can be defined CYGHWR_IO_ETH_STM32MAC_PIN(...). > > > > Note: In macro names above I arbitrarily put "STM32MAC" segment. > > Probably there is a more appropriate name for this Ethernet controller. > Maybe just CYGHWR_IO_ETH_STM32_MII_(pin_name)? I would like to avoid references to architecture. If this Ethernet controller has some name it would be suitable. > > > CYGNUM_DEVS_ETH_CORTEXM_STM32_RX_BUFS: Is there a range of legal values? > Amount of available RAM ;) You may introduce some reasonable boundaries anyway. Also, usually there is a minimal number of buffers (1 or 2) necessary for the driver to work. > > > BTW other Ethernet devices that I have seen also provide configuration > > option > > for TX_BUFFS.Is this fixed on STM32 Ethernet controller? > Driver based on size of SG list : > #define TDES_NUM (CYGNUM_IO_ETH_DRIVERS_SG_LIST_SIZE >> 1) > > Instead of copying data buffer driver uses it - just attach buffer to TX > descriptor list. Than, is there possibility for configuring the number of TX buffer descriptors? > > > > > TCP/IP Checksum generation and check. > > FYI lwIP is aware of such hardware features > > http://sourceware.org/ml/ecos-discuss/2011-07/msg00017.html > > and it would be good if they are implemented. > I know. Driver provides such functionality : > CYGNUM_DEVS_ETH_CORTEXM_STM32_TX_CHECKSUM_GEN > CYGNUM_DEVS_ETH_CORTEXM_STM32_RX_CHECKSUM_VER > but without splitting it in IP checksum and UDP/TCP/ICMP checksum (MAC can't > calculates checksum only for UDP or TCP). IMO it should be used if possible. The gain is considerable according to: http://sourceware.org/ml/ecos-discuss/2011-06/msg00029.html You can put some CDL that enables checksum by HW if lwIP is included and then HW checksum should be the default. Ilija -- 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.
