Corrected STM eth driver flagging, memory allocation and thread init

[mikaleppanen]

Description

Changed STM EMAC ethernet driver RX memory allocation back to pool allocation. It was changed to heap during early phases of EMAC development when pool buffers were not yet implemented. Changed LWIP ethernet enabled flag to DEVICE_EMAC used in feature branch. Added check to RX callback function to check if RX thread has already been created.

Pull request type

• Fix
• Refactor
• New Target
• Feature

[mikaleppanen]

@kjbracey-arm Please review.

[mikaleppanen]

Updated cliapp tests which are now passing.

[0xc0170]

/morph build

[mbed-ci]

Build : FAILURE

Build number : 1331
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6241/

[kjbracey]

Hmm, mbed-os-example-sockets removes DEVICE_EMAC from the Odin W2 board, which is the previously-necessary hack to deactivate the Wi-Fi interface so it could test the Ethernet interface.

With the feature-emac branch and this commit, that actually kills the Ethernet interface, which is now EMAC-based.

Make a feature-emac branch for that socket example and modify CI to test that? Possible/easy @tommikas ?

[kjbracey]

Okay, this is a bit of a mess. Basic problem stems from re-using DEVICE_EMAC as "target provides EMAC::get_default_instance()" flag.

That doesn't scale anyway - we want something similar for other factories - see #6108, and that covers factories not provided by the target.

In this particular case, as the driver for the target, we are specifically relying on the "targetness", so couldn't use any proposed "system has default EMAC" flag - someone providing that via a plug-in module and defining it would then trip up STM builds.

I think target drivers should be looking at something target-specific - in this case it could be #ifdef ETH_BASE. That should make sure we can test if the driver compiles.

The remaining point is "does the STM driver provide weak EMAC::get_default_instance()"? That would need separate target-specific flagging anyway to cover the case where a target had a separate off-chip EMAC and didn't want to use the STM driver. Neither #ifdef DEVICE_EMAC nor #ifdef ETH_BASE would cover that. They'd need a separate "use STM driver as default EMAC" config flag that an STM-derived target could turn off.

In short - change #if DEVICE_EMAC to #ifdef ETH_BASE here, and then find out what's wrong with that.

[kjbracey]

K64F driver works the same way, but doesn't suffer from apps undefining its DEVICE_EMAC. I think that could be switched to using #ifdef ENET_BASE.

[kjbracey]

As @mikaleppanen is away this week, added a change to not use DEVICE_EMAC in a replacement PR #6266.