Hello Sebastian, On Thursday 14 of August 2014 07:39:19 Sebastian Huber wrote: > Hello, > > its nice that you use the new Termios device API. I would be happy to > receive comments if you found something odd about it. > > Contains the current GCC 4.8 or 4.9 branch HEAD all what is necessary for > your BSP?
I have rebuild x86_64 -> arm-rtems4.11 toolchain after you have redone Cortex-R patch and all Premek's works is done by that. Even newlib has been updated after official single liner correction. > I recently committed a patch for the Cortex-M floating point unit. There > are probably now some conflicts with your Cortex-R floating point code. As for floating-point, we use softfloat for Cortex-R still, sorry. Premek has been busy enough with other stuff till now. But I expect that after your change it should be quite straightforward to test with VFP-D16. We do that. As for registers and fields names, the initial fragments are generated by Ti manual Python parser and then adjusted by hand. https://github.com/AoLaD/rtems-tms570-utils/tree/master/parser Again, parser has not been updated after Premek's initial version too much because focus was to have something running first. Comments and alignments are easy. I think that registers structures per module are OK either. As for fields, I am not sure what to select. One option is to use unions in structures union { uint32_t v; struct { unsigned xxx : 10; unsigned yy : 5; } } This is roughly what original Ti headers use. But problem is that BSP should be reusable for more TMS570 chips and in future even for RM48 and RM57. The last two are used in industrial area may be even more than TMS570 (automotive/safety) and are little endian. Ti has all blocks of bitfields twice with endian ifdef. I would prefer more Linux kernel MIPS approach if bitfields are used 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 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. As for formating, the LPC BSP uses mixing of defines and structure fields declarations. Quite readable but on the other hand overview of compact structure is little lost. So may it be that compact structure and then list of macros with comment about field or even offset macros would be more readabble TMS570_SCI_SCICLEARINT_o The alone at beginning would be easier for Premek now than inserting fields between already defined fields. Anyway, I expect that the parser enhancement is the right way and only manageable way for us if we consider all periferals which we already have running on Ti provided headers in our other projects and which we want to move to RTEMS when it we have solid support (SPI, CAN, FlexRay, N2HET etc.) http://rtime.felk.cvut.cz/rpp-tms570/ Because we have no resources to prepare all headers manually and Premek does not look at Ti headers for unclear license reasons. Best wishes, Pavel PS: I have not get to promissed testing of Cortex-M4F yesterday and I have only LPC1788 based board at hand now. I have struck mostly on consultation a helping move motion control to some FPGA based Profinet stack which is diploma thesis of our other student. I have testing Cortex-M4F on my list but I get to it probably only next week. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
