robert-burger/libethercat

Idea: hw_device_send() with pool_type

Closed this issue · 5 comments

marcfir commented

Passing down a pool type enables to distinguish between rt and no-rt traffic in the send function of a device.
Example for a potential sock_sotxtime which uses internally two sockets. One for rt and one for nrt.

//! Flag to distinguish the pool types during processing
typedef enum pooltype {
    POOL_HIGH,
    POOL_LOW,
} pooltype_t; //!< \brief pool type struct type. 

int hw_device_sock_sotxtime_send(hw_t *phw, ec_frame_t *pframe, pooltype_t pool_type)
{
    assert(phw != NULL);
    assert(pframe != NULL);
    if(pool_type == POOL_HIGH){
        return sotxtime_send(phw, pframe);
    }else{
        return sock_raw_send(phw,pframe);
    }
}

I can add a PR for this.

robert-burger commented

Hi Marc,

i understand your point why this is necessary for you. We could add this now in the current state of the hw layer.

i also thought about reworking the nic hardware access layer.

please take a look at my (not finished yet) proposal here:
https://github.com/robert-burger/libethercat/tree/feat/hw_rework

Pros:

  • clearly separates hw layers from each other and ethercat code
  • support for external hw layers

Currently i'm not sure how to decide which hw layer to use during runtime here without dynamic mem allocation. But i think if it's a project specific solution the user usually should know how he wants to send/recv frames here.

I'm not sure if the current state of the branch is actually working. But you could give this a try and if fit's for you than feel free to modify the 'send' call.

marcfir commented

Hi Robert,
nice, I didn't see the branch. This rework looks quite nice. In fact, this would solve the problem I described with #11 ec_open(), and something like a pooltype_t could also be easily added.

I have already implemented the SO_TXTIME socket with the current HW abstraction and try to figure out how to merge it. But it breaks the current API in some places. So I think it makes more sense to integrate it when your rework is done. But I can clean up the implementation and at least push out a branch so you can see the changes.

I ran the feat/hw_rework against some EtherCAT devices, but I think it does not work properly yet.

robert-burger commented

the feat/hw_rework now works on my side at least for 'sock-raw:eth0' and 'file:/dev/ecat0' hardware layer. maybe you have time to test this on your side.

i think i will do a merge of this into master soon. then we could do the modifications you need.

robert-burger commented

take a look at example_with_dc.c to see how it is meant to be used.