On 01/26/2014 09:16 PM, Wolfgang Grandegger wrote:
> On 01/26/2014 08:29 PM, Gilles Chanteperdrix wrote:
>> On 01/26/2014 08:26 PM, Wolfgang Grandegger wrote:
>>> On 01/22/2014 03:12 PM, Gilles Chanteperdrix wrote:
>>>> On 01/22/2014 03:04 PM, Alexandre COFFIGNAL wrote:
>>>>>
>>>>> Le 22/01/2014 14:30, Gilles Chanteperdrix a écrit :
>>>>>> On 01/22/2014 02:27 PM, Alexandre COFFIGNAL wrote:
>>>>>>>
>>>>>>> Le 22/01/2014 13:00, Gilles Chanteperdrix a écrit :
>>>>>>>> On 01/22/2014 12:36 PM, Alexandre COFFIGNAL wrote:
>>>>>>>>>>> + cf->data[3]=((data0 >> 0) & 0xFF) ;
>>>>>>>>>>> + cf->data[2]=((data0 >> 8) & 0xFF) ;
>>>>>>>>>>> + cf->data[1]=((data0 >> 16) & 0xFF) ;
>>>>>>>>>>> + cf->data[0]=((data0 >> 24) & 0xFF) ;
>>>>>>>>>>> + cf->data[7]=((data1 >> 0) & 0xFF) ;
>>>>>>>>>>> + cf->data[6]=((data1 >> 8) & 0xFF) ;
>>>>>>>>>>> + cf->data[5]=((data1 >> 16) & 0xFF) ;
>>>>>>>>>>> + cf->data[4]=((data1 >> 24) & 0xFF) ;
>>>>>>>>>>>
>>>>>>>>>>> rtcan flexcan works perfectly.
>>>>>>>>>>> is anyone know what is the problem with first instructions ?
>>>>>>>>>> Probably mb->data does not have the right alignment. Could you not
>>>>>>>>>> arrange to get it properly aligned? Failing that, you should use
>>>>>>>>>> put_unaligned instead of open coding it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> here structures used in flexcan driver, it seem to be aligned
>>>>>>>>
>>>>>>>> I am talking about the alignment of cf->data, since obviously, that is
>>>>>>>> the one which is causing problems.
>>>>>>>>
>>>>>>>>
>>>>>>> Thank a lot, put_unaligned fix this issue if you want, i can send a
>>>>>>> path
>>>>>>>
>>>>>>
>>>>>> The other solution (getting cf->data to be properly aligned) would be
>>>>>> more efficient, why is not it possible to get cf->data properly aligned?
>>>>>>
>>>>> I think, i can't get cf->data to be properly aligned because "cf" is
>>>>> receive internal frame representation within the ring buffer
>>>>> of a struct rtcan_socket and struct rtcan_rb_frame is a generic
>>>>> structure used in all rtcan drivers .
>>>>
>>>> Well, if you fix rtcan_rb_frame to be aligned, it will be aligned for
>>>> all drivers, so that looks like a worthwile improvement...
>>>
>>> I had a closer look. The CAN message (frame) queuing is optimized for
>>> size to get as much as possible messages into the queue. Therefore the
>>> CAN data are copied using memcpy, but only the real bytes. Directly
>>> behind the real data is the 64 bit timestamp, if requested, which is
>>> also not aligned. Therefore I suggest to use memcpy or byte accesses in
>>> the flexcan driver as well. If this was a good decision is another question.
>>
>> Aligning the data begining costs 2 bytes by struct rtcan_rb_frame. How
>> many such structures are there for a typical driver?
>
> Any message in the queue will require two bytes more. I did not say that
> optimizing for size is necessary, but that's how it was implemented long
> time ago. And I do not see a need to break that just because of the
> Flexcan driver.
IMO, it is not just for the flexcan driver, it will avoid unaligned
accesses for all drivers which access data 4 bytes at a time. And I do
not think it "breaks" anything. What I do not know is:
- how many struct rtcan_rb_frame are typically in use? If only a few,
then adding 2 bytes should not be a problem.
- do all drivers access data 4 bytes at a time? or only the flexcan driver?
Regards.
--
Gilles.
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
