[etherlab-dev] Large PDOs

[Jeroen Van den Keybus]

>
> I’m not sure how the former would help you, since you’re still constrained
> by the wire delays of the large data block.
>
>
I could, in the slower thread, upload the SDO in smaller parts (e.g. 64
bytes each) and use linear addressing for that.



>
> And the second just sounds like “I want non-standard CoE”... so why not
> just use CoE?  It uses zero extra FPGA resources (assuming you already have
> a general-purpose CPU) and not all that much software – probably little
> more than you’d need to write something custom.  (Though if you want
> something even more slimmed down, you can use VoE – but then it might be
> more of a hassle to use from the master side.)
>

The issue is: I don't have a CPU. And the mailbox protocol (whatever oE) is
fairly complicated to implement in hardware. It is best to use a softcore
CPU in that case, bur I'm lacking the memory resources for that.

I did find two solutions:

1) In the application

Before activation of the master:
   domain1_reg = ecrt_slave_config_create_reg_request(sc, 64);

Then, in the cyclic task:
   if (ecrt_reg_request_state(domain1_reg) != EC_REQUEST_BUSY) {
      memcpy(ecrt_reg_request_data(domain1_reg), Some_uint32_t_Array, 64);
/* Write a full array ... */
      EC_WRITE_U32(ecrt_reg_request_data(domain1_reg), Some_uint32_t_Data);
/* ... or do individual writes */
      ecrt_reg_request_write(domain1_reg, 0x2000, 64); /* Schedule the
write */
   }

which is very similar to an SDO request.


2) From the command line

   ethercat reg_write 0x2000 File_with_Array


Of course, the SM has to be set as well. In our case, the PDI does this and
we don't even mention the SM nor the PDO to the master.

Currently I'm testing this config.


J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20131212/35ec128a/attachment-0003.htm>