On 14/08/14 09:48, Pavel Pisa wrote:
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.
Ok, good.
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
My experience with bitfields at this level is that GCC is regularly broken in
this area.
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-pl011-regs.h
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.
I only tested it with the spfatal26 and spcontext01 tests so far. These two
tests are quite handy and may help you with the Cortex-R floating point
support. My next step is to figure out if the LPC4088 works better with Google
Skia which uses 32-bit floats for the anti-aliasing calculations etc.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
