Build kernel module

[sirop]

Hallo.

Did you manage to build the kernel module of ecslave?
My Makefile as for now:

../stack/ec_cmd_lwr.o \
../stack/ec_sii.o \
../stack/ec_regs.o \
../stack/ec_coe.o \
../stack/ec_cmd.o \
../stack/ec_mbox.o \
../stack/ec_process_data.o \
../stack/ecat_timer_common.o

CURRENT=`uname -r`
KDIR = /lib/modules/$(CURRENT)/build/

src = /home/slave/ecslave

obj-m  := $(TARGET).o
$(TARGET)-y := $(TARGET)_if.o $(TARGET)_pci.o $(TARGET)_bin.o
#ccflags-y := -I$(PWD)/../include/ -I$(PWD)/../stack/  -I$(PWD)/../kernel/
ccflags-y := -I$(src)/include/ -I$(src)/stack/  -I$(src)/kernel/
$(TARGET)-objs := $(OBJS)


default:
        make -C $(KDIR) M=$(PWD) SUBDIRS='$(src)/include/ $(src)/stack/  $(src)/kernel/' modules

$(TARGET).o: $(TARGET)-objs
        $(LD) $(LD_RFLAG) -r -o $@ $(OBJS)
clean:
        -rm -rf  ../stack/*.o  *.o .*.o.cmd .*.ko.cmd *.[ch]~ Modules.symvers *.order *.*.ko *.ko *.mod.c .*.c  Module.symvers .tmp_versions/
indent:
        indent -kr -i8 *.[ch]

yields:

make -C /lib/modules/`uname -r`/build/ M=/home/slave/ecslave/kernel SUBDIRS='/home/slave/ecslave/include/ /home/slave/ecslave/stack/  /home/slave/ecslave/kernel/' modules
make[1]: Entering directory `/usr/src/linux-headers-3.8-1-xenomai.x86-amd64'
make[4]: *** No rule to make target `/home/slave/ecslave/kernel/../kernel/ec_slave.o', needed by `/home/slave/ecslave/kernel/ecslave.o'.  Stop.
make[3]: *** [_module_/home/slave/ecslave/kernel] Error 2

[ningfei]

Hi Sirop, sorry for the late reply. I just used ecslave in user space. So you've already made it run as kernel module now?

[sirop]

Hallo @ningfei .

I edited the Makefile in ecslave/kernel and corrected some minor bugs.
See my commits of Commits on Dec 21, 2015 https://github.com/sirop/ecslave/commits/master .
Then you can insmod the kernel module with MAC parameters as the author suggests.

But I do not think that ben Jehuda (the author) fully tested his kernel version
as https://github.com/sirop/ecslave/blob/master/kernel/ecat_netproto.c#L197
static int ecat_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
does not seem to be ready.

So the kernel module runs, but sharing any data with the user space awaits yet some implementation effort.

How was your experience with the pure user space version?
See you made some commits to it...

[ningfei]

Hi @sirop

Cool! I haven't worked on the ethercat project for a while. But back to that time, iirc, I also saw that the kernel version was not ready/easy to use.

The user space version works well (as showed by some preliminary tests, I had the ethercat master on my latop and used raspberrypi as simulated slaves). Here you need a small fix like de8e128. Otherwise, if you connect from the master to slaves, you will get a "topology calculation error" in dmesg. Besides, I'm still not clear about how to create different topologies with ecslave.

[sirop]

@ningfei
I noticed that the command line args of the userspace master branch are not correct
for the "open loop" case, that is when the software slave is not the last slave
in the physical ring.

Is you de8e128 commit about this problem?

Or maybe I do not understand what you mean with "topology"? Any kind of physical ring?
Well, as soon as we prove that the "open loop" case works, you can set up any topology.
And that case should work as "open loop" can be set with the kernel module which I proved these days.
So if it is more than just improper handling of command line args, then just adopt int ec_net_init(ecat_slave * ecs, char *rxmac, char *txmac) of the kernel version for the userspace.

[sirop]

Guess you referred to
https://download.beckhoff.com/download/document/io/ethercat-development-products/ethercat_esc_datasheet_sec2_registers_2i7.pdf
ESC DL Control (0x0100:0x0103)
P. 16
in de8e128 ?

[ningfei]

@sirop

I guess you are right. Connect the slave to the master, start the ethercat master service, start the ecslave simulation, on the master side, you will then get some information about the master/slave link from dmesg. With the esv->registers.dlstat value from the original code, there will be a "topology calculation error" there, I think this arose probably due to the improper registers.dlstat value for open loop slaves as you said.

Yes, by "topology" I mean creating star/tree/ring slaves.

The modification in de8e128 actually refers to P. 31, Section 3.19 ESC DL Status. The ethercat master needs to query the DL status register of each slave to determine the (chnage of) topology of the slaves. So for the above "topology calculation error" in dmesg, we need to change the registers.dlstat value (as a workaround?). I think we also need to change the DL Status Register to create different topologies?

Thank you for the hint about adopting the ec_net_init from kernel version :）I will let my friend know and also ask if they have any news on the project.

[sirop]

Hallo again.

Hope you got well over the holidays.

So applied your patch de8e128 .
This improved something as the error was no longer so severe as before: I still got a topology error,
but there was no longer Application Layer error.

Then I just copied some lines from the Arduino version:
https://github.com/sirop/ecslave/blob/ab397b76c783fe704f53390a709decbe58d74151/stack/ec_regs.c#L21-L43 . This seems to be more generic approach and I have not seen any topology errors since then.

So PDO exchange is possible, but I get strange offset values for the PDOs of the master branch:
https://github.com/sirop/EtherCAT_HAL/blob/master/pdoLIBIX2dc.comp#L203-L205

rtapi_print_msg(RTAPI_MSG_INFO,"Offsets in=%d,%d out=%d,%d\n",
    off_libix_in[0], off_libix_in[1],
    off_libix_out[0], off_libix_out[1]);

yield

Offsets in=6,0 out=0,0

I could live with off_libix_in={6,0} , but off_libix_out={0,0} seems very strange to me
as both TxPDOs would have the same offset then.
Did you or your colleagues manage to do any PDO exchange without offset problems?

P.S. As you see I work with https://github.com/machinekit , but I hope that the code of https://github.com/sirop/EtherCAT_HAL/blob/master/pdoLIBIX2dc.comp is nevetheless readable for you.

[ningfei]

Hi @sirop,

Hope you enjoyed the holidays, too.

In our case, after de8e128, there won't be any topology error. If L21-L43 from ec_regs.c turns out to be a better solution for this as you mentioned, I will then merge it later.

For the PDO exchange, I think we hadn't went that further. I asked my friend. But he's now working on a physical slave rather than the virtual ecslave, unfortunately...I just stared your two ethercat related projects, will try the PDO part when I get time.

[rkojcev]

Hi guys,

I would like to test the kernel version of the EtherCAT slave. @sirop do you still have any hints of the modifications you have made to the Makefile to make the kernel module compile?

[sirop]

@rkojcev

Because of legal reasons I am not allowed to comment on this.

If you are looking for an inexpensive but configurable slave, I'd recommend
https://www.synapticon.com/product/ethercat-development-kit

[rkojcev]

Thank you @sirop for the info. @ningfei any hints for what do I need to change to compile the kernel modules?
Thanks for the help!!