[PATCH] BSP for TMS570LS31x Hercules Development Kit from TI (TMS570LS3137)

Gedare Bloom gedare at rtems.org
Thu Aug 14 13:12:44 UTC 2014


On Thu, Aug 14, 2014 at 4:53 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> Hello Sebastian,
>
> On Thursday 14 of August 2014 10:07:06 Sebastian Huber wrote:
>> On 14/08/14 09:48, Pavel Pisa wrote:
>> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch
>> >/mips/include/uapi/asm/inst.h?id=refs/tags/v3.15#n486
>>
>> My experience with bitfields at this level is that GCC is regularly broken
>> in this area.
>
> Aligned with my feeling that it is dangerous and combined with required
> volatile for regs can lead even to worse code.
>
>> > But I generally prefer more only defines used for such fields.
>> >
>> > Then it would look something like
>> >
>> >    TMS570_SCI_SCICLEARINT_XXX
>> >
>> > My notation is to add suffix "_m" for mask, "_b" for starting bit
>> > position if used and where are offset from base "_o". The "_m" and "_b"
>> > quite usesfull because C dosenit warn you when starting bit or mask is
>> > mixed and results of mixing are quite damaging.
>> >
>> > But use of macros leads to quite complex/long lines in the code.
>>
>> Yes, I prefer this too.  You may have a look at
>>
>> http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/include/arm-pl0
>>11-regs.h
>
> I am OK with single bit masks - BSP_BIT32(7), but I prefer only single
> define per multi bit field. So my own approach is to use macros to find
> field start bit from maks
>
> /*masked fields macros*/
> #define __val2mfld(mask,val) (((mask)&~((mask)<<1))*(val)&(mask))
> #define __mfld2val(mask,val) (((val)&(mask))/((mask)&~((mask)<<1)))
>
Do you get the similar effect from BSP_FLD32?
http://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/include/utility.h#n68

> for constant masks they compile optimal way and for variable
> they are usable too if CPU has ffs/clz support.
>
> http://sourceforge.net/p/ulan/sysless/ci/master/tree/arch/arm/generic/defines/cpu_def.h
>
> This is how I use it in our bare HW/system-less code
>
> http://sourceforge.net/p/ulan/sysless/ci/master/tree/libs4c/spi/spi_lpcssp.c#l200
>
>  lpcssp_drv->ssp_regs->CR0 =
>      __val2mfld(SSP_CR0_DSS_m, lpcssp_drv->data16_fl? 16 - 1 : 8 - 1) |
>      __val2mfld(SSP_CR0_FRF_m, 0) |
>      (msg->size_mode & SPI_MODE_CPOL? SSP_CR0_CPOL_m: 0) |
>      (msg->size_mode & SPI_MODE_CPHA? SSP_CR0_CPHA_m: 0) |
>      __val2mfld(SSP_CR0_SCR_m, 15);
>
> http://sourceforge.net/p/ulan/sysless/ci/master/tree/arch/arm/mach-lpc17xx/libs/hal/hal_gpio.c#l32
>
> So I would prefer something like that. But I agree that it can hurt
> someone else eyeballs as well.
>
> I have seen similar solution in Nvidia driver sources with even
> really interresting (ab)use of ternary C operator.
>
> But if RTEMS preference is to define all fields twice with SET and GET
> then I would suggest that to Premek.
>
> Best wishes,
>
>               Pavel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list