date:20140814

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

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

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

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

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)))

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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

Hello Joel,

On Thursday 14 of August 2014 00:40:49 Joel Sherrill wrote:
> On 8/13/2014 2:48 PM, Premysl Houdek wrote:

> > --- /dev/null
> > +++ b/c/src/lib/libbsp/arm/tms570/README
> > @@ -0,0 +1,64 @@
> > +Development Board: TMS570LS31x Hercules Development Kit from TI
...
> > +Execution
> > +
> > +  There is not used any generic bootloader. Initial complex CPU and
> > peripherals +  initialization and self test are not implemented and
> > included in RTEMS BSP +  right now. For testing and debuging purposes is
> > used simple Ti's HalCoGen +  generated application to setup board and
> > then download RTEMS image over +  OpenOCD to internal EEC SRAM or
> > external SDRAM.
>
> This is rough from an English viewpoint.  How about:
>
> Currently, a bootloader is not used. For test and debug purposes, TI's
> HalCoGen generated
> application is used to set up the board and then the RTEMS application
> image is loaded
> using OpenOCD to internal EEC SRAM or external DRAM. The following
> features are
> not implemented in the BSP:
>
>   + Initial complex CPU and peripheral initialization
>   + Self-test
>
> Can you be more specific about what that first bullet covers?
>
> Is the generated setup code available? What's the license on it?

The generated setup is available, see link below

> > +  Setup application code is available there:
> > +  https://github.com/hornmich/tms570ls3137-hdk-sdram
> > +
> > +Howto setup TMDS570LS31HDK?
> > +
> > +   o Unpack board.
> > +   o Verify that demo application runs.
> > +  o Upload bootloader specified above
> > +  o write BSP aplication either to sdram or intram and jump to RTEMS
> > start code
>
> application not aplication
> Internal RAM?

Yes, thanks for checking, English is neither Premek nor my
specialty and Pemek.

There would be happy even to provide build binary to everybody who cares.

But generally the hardware needs more work to be done.
Unfortuantelly, flashing to the MCU is quite complicated due
un-documented algorithm. We have used Ti tools to Flash setup
code. But we know other working solution, it is possible to
setup MCU over JTAG and the download flasher code into internal
RAM. The library with flash algorithm is available from Ti
in binary form for Cortex-R4F. So our plan is to have small
loader to allow flash application over CAN or ETHERNET.

But it is still longer term goal.

Best wishes,

 Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems_termios_puts: Copy and write more than one char at once

Beside copying more than one char at once, rtems_termios_refill_transmitter()
and rtems_termios_puts() now use a common helper that (after checking ORCVXOF)
calls write() with as much chars as are available consecutively in rawOutBuf.
Integer types used in new rtems_termios_start_xmit might not be ideal but
resemble what is used in existing rtems_refill_transmitter code.

---
 cpukit/libcsupport/src/termios.c | 133 ---
 1 file changed, 83 insertions(+), 50 deletions(-)

diff --git a/cpukit/libcsupport/src/termios.c b/cpukit/libcsupport/src/termios.c
index 2448ea1..f14f138 100644
--- a/cpukit/libcsupport/src/termios.c
+++ b/cpukit/libcsupport/src/termios.c
@@ -974,6 +974,47 @@ rtems_termios_ioctl (void *arg)
 }
 
 /*
+ * Send as many chars at once as possible to device-specific code.
+ * If stopXmit==true then explicitly write(0) to stop transmitter.
+ */
+static int
+rtems_termios_start_xmit (
+  struct rtems_termios_tty *tty, unsigned int newTail, bool stopXmit)
+{
+  int nToSend;
+
+  /* if XOFF was received, do not start output resp. stop */
+  if ((tty->flow_ctrl & (FL_MDXON | FL_ORCVXOF))
+  ==(FL_MDXON | FL_ORCVXOF)) {
+/* Buffer not empty, but output stops due to XOFF */
+/* set flag, that output has been stopped */
+tty->flow_ctrl |= FL_OSTOP;
+nToSend = 0;
+tty->rawOutBufState = rob_busy;
+if (stopXmit) {
+  (*tty->handler.write) (tty, NULL, 0);
+}
+  } else {
+if (newTail > tty->rawOutBuf.Head)
+  nToSend = tty->rawOutBuf.Size - newTail;
+else
+  nToSend = tty->rawOutBuf.Head - newTail;
+/* when flow control XON or XOF, don't send blocks of data */
+/* to allow fast reaction on incoming flow ctrl and low latency*/
+/* for outgoing flow control   */
+if (tty->flow_ctrl & (FL_MDXON | FL_MDXOF)) {
+  nToSend = 1;
+}
+
+tty->rawOutBufState = rob_busy;
+(*tty->handler.write)(
+tty, &tty->rawOutBuf.theBuf[newTail], nToSend);
+  }
+
+  return nToSend;
+}
+
+/*
  * Send characters to device-specific code
  */
 void
@@ -989,21 +1030,16 @@ rtems_termios_puts (
 (*tty->handler.write)(tty, buf, len);
 return;
   }
-  newHead = tty->rawOutBuf.Head;
+
   while (len) {
-/*
- * Performance improvement could be made here.
- * Copy multiple bytes to raw buffer:
- * if (len > 1) && (space to buffer end, or tail > 1)
- *  ncopy = MIN (len, space to buffer end or tail)
- *  memcpy (raw buffer, buf, ncopy)
- *  buf += ncopy
- *  len -= ncopy
- *
- * To minimize latency, the memcpy should be done
- * with interrupts enabled.
- */
-newHead = (newHead + 1) % tty->rawOutBuf.Size;
+size_t nToCopy;
+size_t nAvail;
+
+/* Check space for at least one char */
+newHead = tty->rawOutBuf.Head + 1;
+if (newHead >= tty->rawOutBuf.Size)
+  newHead -= tty->rawOutBuf.Size;
+
 rtems_termios_interrupt_lock_acquire (tty, &lock_context);
 while (newHead == tty->rawOutBuf.Tail) {
   tty->rawOutBufState = rob_wait;
@@ -1014,21 +1050,41 @@ rtems_termios_puts (
 rtems_fatal_error_occurred (sc);
   rtems_termios_interrupt_lock_acquire (tty, &lock_context);
 }
-tty->rawOutBuf.theBuf[tty->rawOutBuf.Head] = *buf++;
+
+/* Determine free space up to current tail or end of ring buffer */
+nToCopy = len;
+if (tty->rawOutBuf.Tail > tty->rawOutBuf.Head) {
+  /* Available space is contiguous from Head to Tail */
+  nAvail = tty->rawOutBuf.Tail - tty->rawOutBuf.Head - 1;
+} else {
+  /* Available space wraps at buffer end. To keep code simple, utilize
+ only the part from Head to end during this iteration */
+  nAvail = tty->rawOutBuf.Size - tty->rawOutBuf.Head;
+  /* Head may not touch Tail after wraparound */
+  if (tty->rawOutBuf.Tail == 0)
+nAvail--;
+}
+if (nToCopy > nAvail)
+  nToCopy = nAvail;
+
+/* To minimize latency, the memcpy could be done
+ * with interrupts enabled or with limit on nToCopy (TBD)
+ */
+memcpy(&tty->rawOutBuf.theBuf[tty->rawOutBuf.Head], buf, nToCopy);
+
+newHead = tty->rawOutBuf.Head + nToCopy;
+if (newHead >= tty->rawOutBuf.Size)
+  newHead -= tty->rawOutBuf.Size;
 tty->rawOutBuf.Head = newHead;
+
 if (tty->rawOutBufState == rob_idle) {
-  /* check, whether XOFF has been received */
-  if (!(tty->flow_ctrl & FL_ORCVXOF)) {
-(*tty->handler.write)(
-  tty, &tty->rawOutBuf.theBuf[tty->rawOutBuf.Tail],1);
-  } else {
-/* remember that output has been stopped due to flow ctrl*/
-tty->flow_ctrl |= FL_OSTOP;
-  }
-  tty->rawOutBufState = rob_busy;
+  (void)rtems_termios_start_xmit (tty, tty->rawOutBuf.Tail, false);
 }
+
 rtems_termios_interrupt_lock_release (tty, &lock_context);
-len--;
+
+buf += nToCopy;
+len -= nToCopy;
   }
 }
 
@@ -1678,35 +1734,12 @@ rtems_te

Re: Using rtl-host in covor - some questions

On Wed, Aug 13, 2014 at 11:17 PM, Chris Johns  wrote:
> On 14/08/2014 6:58 am, Gedare Bloom wrote:
>>
>> We need to decide if we want 1 repo per "tool" or a consolidated tools
>> repo. My opinion is to add the rtl-host and rtems-coverage as
>> git-submodules within another repo the project manages as project
>> tools. My $.02
>>
>> Otherwise, you should add rtl-host as a git-submodule within
>> rtems-coverage so you can build and link against rtl-host. The
>> consumer (coverage) should be dependent on the producer.
>
>
> I am happy with a single rtems-tools.git repo and we move the tools in to
> here.
>
> Chris

That works for me. It simplifies things. -Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems_termios_puts: Copy and write more than one char at once


Hello Kolja,

looks good, but I have some minor stuff.

On 14/08/14 13:10, Kolja Waschk wrote:

Beside copying more than one char at once, rtems_termios_refill_transmitter()
and rtems_termios_puts() now use a common helper that (after checking ORCVXOF)
calls write() with as much chars as are available consecutively in rawOutBuf.
Integer types used in new rtems_termios_start_xmit might not be ideal but
resemble what is used in existing rtems_refill_transmitter code.

---
  cpukit/libcsupport/src/termios.c | 133 ---
  1 file changed, 83 insertions(+), 50 deletions(-)

diff --git a/cpukit/libcsupport/src/termios.c b/cpukit/libcsupport/src/termios.c
index 2448ea1..f14f138 100644
--- a/cpukit/libcsupport/src/termios.c
+++ b/cpukit/libcsupport/src/termios.c
@@ -974,6 +974,47 @@ rtems_termios_ioctl (void *arg)
  }

  /*
+ * Send as many chars at once as possible to device-specific code.
+ * If stopXmit==true then explicitly write(0) to stop transmitter.
+ */
+static int
+rtems_termios_start_xmit (


The internal functions use normally CamelCase in this file.


+  struct rtems_termios_tty *tty, unsigned int newTail, bool stopXmit)
+{
+  int nToSend;


Integer type is wrong.


+
+  /* if XOFF was received, do not start output resp. stop */
+  if ((tty->flow_ctrl & (FL_MDXON | FL_ORCVXOF))
+  ==(FL_MDXON | FL_ORCVXOF)) {


Previously we had this and

if (!(tty->flow_ctrl & FL_ORCVXOF)) {

I would use this, since FL_ORCVXOF is only set if FL_MDXON is set.


+/* Buffer not empty, but output stops due to XOFF */
+/* set flag, that output has been stopped */
+tty->flow_ctrl |= FL_OSTOP;
+nToSend = 0;
+tty->rawOutBufState = rob_busy;
+if (stopXmit) {
+  (*tty->handler.write) (tty, NULL, 0);
+}
+  } else {
+if (newTail > tty->rawOutBuf.Head)
+  nToSend = tty->rawOutBuf.Size - newTail;
+else
+  nToSend = tty->rawOutBuf.Head - newTail;
+/* when flow control XON or XOF, don't send blocks of data */
+/* to allow fast reaction on incoming flow ctrl and low latency*/
+/* for outgoing flow control   */
+if (tty->flow_ctrl & (FL_MDXON | FL_MDXOF)) {
+  nToSend = 1;
+}


Yes, the this is the original code, but I think it is a bit odd to discard a 
value computed directly above.  I would rather do the buffer nToSend 
computation in an else block.



+
+tty->rawOutBufState = rob_busy;
+(*tty->handler.write)(
+tty, &tty->rawOutBuf.theBuf[newTail], nToSend);
+  }
+
+  return nToSend;
+}
+
+/*
   * Send characters to device-specific code
   */
  void
@@ -989,21 +1030,16 @@ rtems_termios_puts (
  (*tty->handler.write)(tty, buf, len);
  return;
}
-  newHead = tty->rawOutBuf.Head;
+
while (len) {
-/*
- * Performance improvement could be made here.
- * Copy multiple bytes to raw buffer:
- * if (len > 1) && (space to buffer end, or tail > 1)
- *  ncopy = MIN (len, space to buffer end or tail)
- *  memcpy (raw buffer, buf, ncopy)
- *  buf += ncopy
- *  len -= ncopy
- *
- * To minimize latency, the memcpy should be done
- * with interrupts enabled.
- */
-newHead = (newHead + 1) % tty->rawOutBuf.Size;
+size_t nToCopy;
+size_t nAvail;
+
+/* Check space for at least one char */
+newHead = tty->rawOutBuf.Head + 1;
+if (newHead >= tty->rawOutBuf.Size)
+  newHead -= tty->rawOutBuf.Size;
+
  rtems_termios_interrupt_lock_acquire (tty, &lock_context);
  while (newHead == tty->rawOutBuf.Tail) {
tty->rawOutBufState = rob_wait;
@@ -1014,21 +1050,41 @@ rtems_termios_puts (
  rtems_fatal_error_occurred (sc);
rtems_termios_interrupt_lock_acquire (tty, &lock_context);
  }
-tty->rawOutBuf.theBuf[tty->rawOutBuf.Head] = *buf++;
+
+/* Determine free space up to current tail or end of ring buffer */
+nToCopy = len;
+if (tty->rawOutBuf.Tail > tty->rawOutBuf.Head) {
+  /* Available space is contiguous from Head to Tail */
+  nAvail = tty->rawOutBuf.Tail - tty->rawOutBuf.Head - 1;
+} else {
+  /* Available space wraps at buffer end. To keep code simple, utilize
+ only the part from Head to end during this iteration */
+  nAvail = tty->rawOutBuf.Size - tty->rawOutBuf.Head;
+  /* Head may not touch Tail after wraparound */
+  if (tty->rawOutBuf.Tail == 0)
+nAvail--;
+}
+if (nToCopy > nAvail)
+  nToCopy = nAvail;
+
+/* To minimize latency, the memcpy could be done
+ * with interrupts enabled or with limit on nToCopy (TBD)
+ */
+memcpy(&tty->rawOutBuf.theBuf[tty->rawOutBuf.Head], buf, nToCopy);
+
+newHead = tty->rawOutBuf.Head + nToCopy;
+if (newHead >= tty->rawOutBuf.Size)
+  newHead -= tty->rawOutBuf.Size;
  tty->rawOutBuf.Head = newHead;
+
  if (tty->rawOutBufState == rob_idle) {
-  /* check, whether XOFF has been received */
-  if (!(tty->flow_ctrl

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

On Thu, Aug 14, 2014 at 4:53 AM, Pavel Pisa  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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Using rtl-host in covor - some questions


On 8/13/2014 10:13 PM, Chris Johns wrote:
> On 14/08/2014 7:34 am, Joel Sherrill wrote:
>> On 8/13/2014 3:49 PM, Krzysztof Mięsowicz wrote:
>>> Hi,
>>>
>>> Thanks for your replies :-) I didn't see librld.a because I had old
>>> version of repo and after updating it appears :-)
>>>
>>> I think for now it would be better to get everything integrated with
>>> old "nm-based" approach. I had it working as a separate module, now I
>>> will integrate it into covoar. I think that one of next steps may be
>>> generating symbols without nm.
>>>
>> There are two uses of symbols in covoar.
>>
>> The first is external and it is generating the "symbols of interest" for
>> the run. That
>> is currently a process that runs over the set of libraries of interest
>> and lists all the
>> text symbols in those libraries. Doing that with the Python based code
>> should be a
>> snap.
>>
> What does "run over a set of libraries" mean ?
This is the user defining the set of symbols that they want to generate
coverage
reports on. For RTEMS, this is just looking at the set of libXXX.a in
the build
tree for each directory we analyze and extracting the symbols.

This is completely external to covoar. How a project generates its
symbol list
is project dependent. covoar only knows that it is to generate reports based
on that set of symbols, the .exe files, and the coverage files.

This is currently done using nm in the script that invokes covoar.
> We have a really good way to get at the symbols via C++ now with 0 
> parsing code or external tools.
OK.

>> The other part is in covoar itself. As it processes each exe and builds
>> the internal
>> database of information, it needs the physical address of each method of
>> interest
>> in that particular exe. That is done by an invocation of nm with some
>> magic processing
>> afterwards. This could be done with libelf I think.
> The rtl-host is a wrapper to libelf which is included in the rtl-host 
> code we are not dependent on host specifics or versions.
Currently covoar uses system() to invoke nm (maybe with a sed) and then
process it
using regular file operations.

Personally, I don't see much difference between invoking nm and
rtl-host. Either
will require a system and then loading the symbol set from a file. On a
large set
of executables, this may be a large time consumer. It would be better to
directly
use libelf to read the symbols. It should simplify and speed things up.
>>> But I also wonder if it would not be better to focus on changing flow
>>> of covoar - to avoid multiple runs (one for each symbol set as it
>>> would be now), because it takes quite long. I think it should be done
>>> in such way, that covoar reads symbol sets configuration file, runs
>>> analysis and takes data for all desired symbols from all sets and
>>> finally performs multiple reporting part, generating simple, generic
>>> output for each symbols set.
>>>
>> Then covoar knows what purpose and scope of the reports are.  As it
>> stands now, covoar knows NOTHING
>> about RTEMS. Let's keep it that way.
> Out of interest what is config file format for covoar ? I have added INI 
> file support to the rtl-host repo and it seems stable and flexible.
I think it is just name=value without sections. I honestly don't recall
but it is not fancy.
It could easily be switched to .ini.
>> covoar gets slower as the set of symbols and tests grows. The standard
>> run now already does at
>> least two covoar runs. Once for "all" and one for "core". The build and
>> test execution time dominates.
> Where is bottleneck ? The RTL code uses an STL map for symbol look up.
See above. I think executing nm on each exe with whatever filter
commands and
then reading them. Using libelf directly will help a lot.

I don't recall any other hot spots but that there are places where you
have to
cycle over all exe's for all symbols of interest. That is obviously
O( num exes * num syms) but I don't think it is the big issue. I think
the first
issue is just like make vs waf. Avoid doing system() and parsing output
files
500 times (# tests) and just read the symbol table directly. That has to
be a
huge time saver
>> As we process smaller sets of symbols, covoar will be faster anyway.
>> Besides, if it is slow enough,
>> eventually we will profile and fix it. :)
>>> Another job I am thinking about doing next is adding more bsps support
>>> for coverage and getting things working on more bsps. This should be
>>> quite simple.
>>>
>> This requires the simulator support. But you should be able to do arm
>> and x86 with qemu.
>>> There is still one problem waiting for decision :-) What with rtems
>>> grub boot img for qemu? How should we integrate it into rtems-tools?
>>>
>> Chris?
> Ah yes. I think we should download an image from a know spot but I have 
> not looked into how to do this with the RSB.
>
> Maybe building grub from source is possible but that can be something 
> for another day.
>
> Chris

-- 
Joel Sherrill, Ph.D. Directo

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


On 8/14/2014 3:53 AM, Pavel Pisa 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.
I don't think RTEMS has a formal coding convention (yet) for this but I
don't
trust them for any compiler. Ignoring breakages, you don't have as much
control
over the width of the generated accesses. 

I recall ages ago helping someone debug a broken driver where gcc had
generated
a bit set or clear instruction and the device didn't like that.
>>> 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)))
>
> 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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

Thanks.

I am just worried about reproducibility or the BSP and test results
combined with licensing and redistribution of the TI support
code. As long as everyone is comfortable with that, I am as well.

On 8/14/2014 4:04 AM, Pavel Pisa wrote:
> Hello Joel,
>
> On Thursday 14 of August 2014 00:40:49 Joel Sherrill wrote:
>> On 8/13/2014 2:48 PM, Premysl Houdek wrote:
>>> --- /dev/null
>>> +++ b/c/src/lib/libbsp/arm/tms570/README
>>> @@ -0,0 +1,64 @@
>>> +Development Board: TMS570LS31x Hercules Development Kit from TI
> ...
>>> +Execution
>>> +
>>> +  There is not used any generic bootloader. Initial complex CPU and
>>> peripherals +  initialization and self test are not implemented and
>>> included in RTEMS BSP +  right now. For testing and debuging purposes is
>>> used simple Ti's HalCoGen +  generated application to setup board and
>>> then download RTEMS image over +  OpenOCD to internal EEC SRAM or
>>> external SDRAM.
>> This is rough from an English viewpoint.  How about:
>>
>> Currently, a bootloader is not used. For test and debug purposes, TI's
>> HalCoGen generated
>> application is used to set up the board and then the RTEMS application
>> image is loaded
>> using OpenOCD to internal EEC SRAM or external DRAM. The following
>> features are
>> not implemented in the BSP:
>>
>>   + Initial complex CPU and peripheral initialization
>>   + Self-test
>>
>> Can you be more specific about what that first bullet covers?
>>
>> Is the generated setup code available? What's the license on it?
> The generated setup is available, see link below
>
>>> +  Setup application code is available there:
>>> +  https://github.com/hornmich/tms570ls3137-hdk-sdram
>>> +
>>> +Howto setup TMDS570LS31HDK?
>>> +
>>> +   o Unpack board.
>>> +   o Verify that demo application runs.
>>> +  o Upload bootloader specified above
>>> +  o write BSP aplication either to sdram or intram and jump to RTEMS
>>> start code
>> application not aplication
>> Internal RAM?
> Yes, thanks for checking, English is neither Premek nor my
> specialty and Pemek.
>
> There would be happy even to provide build binary to everybody who cares.
>
> But generally the hardware needs more work to be done.
> Unfortuantelly, flashing to the MCU is quite complicated due
> un-documented algorithm. We have used Ti tools to Flash setup
> code. But we know other working solution, it is possible to
> setup MCU over JTAG and the download flasher code into internal
> RAM. The library with flash algorithm is available from Ti
> in binary form for Cortex-R4F. So our plan is to have small
> loader to allow flash application over CAN or ETHERNET.
>
> But it is still longer term goal.
>
> Best wishes,
>
>  Pavel

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

Hello Gedare,

On Thursday 14 of August 2014 15:12:44 Gedare Bloom wrote:
> On Thu, Aug 14, 2014 at 4:53 AM, Pavel Pisa  wrote:
 > 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#n
>68

You get exactly same code if mask is constant and contains only
single continuous region of one bits. The main advantage is,
that you can define everything required to describe field
by single plain define

#define MODULEx_REGy_FIELDx_m 0x0f00

or in BSP utility language more readable

#define MODULEx_REGy_FIELDx_m BSP_MSK32(8, 11)

Then to access filed in register (if struct is used for registers
placement in memory) you get


value = __mfld2val(MODULEx_REGy_FIELDx_m, MODULEx->REGy);

to setup register by values for more fields

  MODULEx->REGy = __val2mfld(MODULEx_REGy_FIELD1_m, val1) |
  __val2mfld(MODULEx_REGy_FIELD2_m, val2);


To replace field value

  MODULEx->REGy = (MODULEx->REGy & ~MODULEx_REGy_FIELDz_m) |
  __val2mfld(MODULEx_REGy_FIELDz_m, val1);

I see significant advantage in defining of plain masks without get/set
that they suggest to be used directly in more situations.
I.e. used in atomic clear mask or other special instructions.

In the fact, real mask can be retrieved from set/get pair by little
(or bigger) hack


   MODULEx_REGy_FIELDx_SET(~1)

You can get the first bit position still too

   __builtin_ffs(MODULEx_REGy_FIELDx_SET(~1))

and bit count similar way from get or by more ops from SET.
But seems to be hacky to me.

Anyway all these is compiled to constants by GCC.
So no overhead only final and and shift if value
put into field is not constant.

I have used __val2mfld/__mfld2val names with two underscores
to be outside of clash with POSIX when masks are used
in generic headerfiles which can be included by third party
libraries.

But if you accept these in BSP_ space for RTEMS, I would be happy
with any other descriptive name

#define BSP_TOFLD(mask,val) (((mask)&~((mask)<<1))*(val)&(mask))
#define BSP_FROMFLD(mask,val) (((val)&(mask))/((mask)&~((mask)<<1)))

or under some other name BSP_MF2V  BSP_V2MF  in

  http://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/include/utility.h

> > 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/def
> >ines/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_lpcss
> >p.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-lpc17x
> >x/libs/hal/hal_gpio.c#l32

Best wishes,

  Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

Since Joel commented on style issues, I'll try to stick to technical questions.

On Wed, Aug 13, 2014 at 3:48 PM, Premysl Houdek  wrote:
> Included variants:
>   tms570ls3137_hdk_intram - place code and data into internal SRAM
>   tms570ls3137_hdk_sdram - place code into external SDRAM and data to SRAM
>   tms570ls3137_hdk - variant prepared for stand-alone RTEMS aplication
>   stored and running directly from flash. Not working yet.
>
> Chip initialization code not included in BSP.
> External startup generated by TI's HalCoGen was usedfor
> testing and debugging.
>
> More information about TMS570 BSP can be found at
>   http://www.rtems.org/wiki/index.php/Tms570
> ---
>  c/src/lib/libbsp/arm/tms570/Makefile.am|  148 ++
>  c/src/lib/libbsp/arm/tms570/README |   64 +++
>  c/src/lib/libbsp/arm/tms570/bsp_specs  |   13 +
>  c/src/lib/libbsp/arm/tms570/clock/tms570-rti.c |  205 
>  c/src/lib/libbsp/arm/tms570/configure.ac   |   45 ++
>  .../lib/libbsp/arm/tms570/console/printk-support.c |   68 +++
>  c/src/lib/libbsp/arm/tms570/console/tms570-sci.c   |  546 
> 
>  c/src/lib/libbsp/arm/tms570/include/bsp.h  |  101 
>  c/src/lib/libbsp/arm/tms570/include/irq.h  |  134 +
>  c/src/lib/libbsp/arm/tms570/include/tms570-pom.h   |  101 
>  c/src/lib/libbsp/arm/tms570/include/tms570-rti.h   |   95 
>  .../libbsp/arm/tms570/include/tms570-sci-driver.h  |   39 ++
>  c/src/lib/libbsp/arm/tms570/include/tms570-sci.h   |   75 +++
>  c/src/lib/libbsp/arm/tms570/include/tms570-vim.h   |   74 +++
>  c/src/lib/libbsp/arm/tms570/include/tms570.h   |   29 ++
>  c/src/lib/libbsp/arm/tms570/irq/irq.c  |  182 +++
>  .../make/custom/tms570ls3137_hdk-testsuite.tcfg|   19 +
>  .../arm/tms570/make/custom/tms570ls3137_hdk.cfg|   19 +
>  .../tms570/make/custom/tms570ls3137_hdk_intram.cfg |   20 +
>  .../tms570/make/custom/tms570ls3137_hdk_sdram.cfg  |   19 +
>  c/src/lib/libbsp/arm/tms570/pom/tms570-pom.c   |  100 
>  c/src/lib/libbsp/arm/tms570/startup/bspreset.c |   37 ++
>  c/src/lib/libbsp/arm/tms570/startup/bspstart.c |   46 ++
>  .../lib/libbsp/arm/tms570/startup/bspstarthooks.c  |   42 ++
>  .../arm/tms570/startup/linkcmds.tms570ls3137_hdk   |   27 +
>  .../startup/linkcmds.tms570ls3137_hdk_intram   |   28 +
>  .../tms570/startup/linkcmds.tms570ls3137_hdk_sdram |   27 +
>  27 files changed, 2303 insertions(+)
>  create mode 100644 c/src/lib/libbsp/arm/tms570/Makefile.am
>  create mode 100644 c/src/lib/libbsp/arm/tms570/README
>  create mode 100644 c/src/lib/libbsp/arm/tms570/bsp_specs
>  create mode 100644 c/src/lib/libbsp/arm/tms570/clock/tms570-rti.c
>  create mode 100644 c/src/lib/libbsp/arm/tms570/configure.ac
>  create mode 100644 c/src/lib/libbsp/arm/tms570/console/printk-support.c
>  create mode 100644 c/src/lib/libbsp/arm/tms570/console/tms570-sci.c
>  create mode 100644 c/src/lib/libbsp/arm/tms570/include/bsp.h
>  create mode 100644 c/src/lib/libbsp/arm/tms570/include/irq.h
>  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-pom.h
>  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-rti.h
>  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-sci-driver.h
>  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-sci.h
>  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-vim.h
>  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570.h
>  create mode 100644 c/src/lib/libbsp/arm/tms570/irq/irq.c
>  create mode 100644 
> c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk-testsuite.tcfg
>  create mode 100644 
> c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg
>  create mode 100644 
> c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_intram.cfg
>  create mode 100644 
> c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_sdram.cfg
>  create mode 100644 c/src/lib/libbsp/arm/tms570/network/tms570-ethernet.c
>  create mode 100644 c/src/lib/libbsp/arm/tms570/network/tms570-ethernet.h
>  create mode 100644 c/src/lib/libbsp/arm/tms570/pom/tms570-pom.c
>  create mode 100644 c/src/lib/libbsp/arm/tms570/startup/bspreset.c
>  create mode 100644 c/src/lib/libbsp/arm/tms570/startup/bspstart.c
>  create mode 100644 c/src/lib/libbsp/arm/tms570/startup/bspstarthooks.c
>  create mode 100644 
> c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk
>  create mode 100644 
> c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk_intram
>  create mode 100644 
> c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk_sdram

> diff --git a/c/src/lib/libbsp/arm/tms570/clock/tms570-rti.c 
> b/c/src/lib/libbsp/arm/tms570/clock/tms570-rti.c
> new file mode 100644
> index 000..3f8278c
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/tms570/clock/tms570-rti.c
Usually this file is called clock.c

> @@ -0,0 +1,205 @@
> +/**
> + * @file tms570-rti.c
> + *
> + * @ing

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


On 8/14/2014 8:46 AM, Pavel Pisa wrote:
> Hello Gedare,
>
> On Thursday 14 of August 2014 15:12:44 Gedare Bloom wrote:
>> On Thu, Aug 14, 2014 at 4:53 AM, Pavel Pisa  wrote:
>  > 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#n
>> 68
> You get exactly same code if mask is constant and contains only
> single continuous region of one bits. The main advantage is,
> that you can define everything required to describe field
> by single plain define
>
> #define MODULEx_REGy_FIELDx_m 0x0f00
>
> or in BSP utility language more readable
>
> #define MODULEx_REGy_FIELDx_m BSP_MSK32(8, 11)
>
> Then to access filed in register (if struct is used for registers
> placement in memory) you get
>
>
> value = __mfld2val(MODULEx_REGy_FIELDx_m, MODULEx->REGy);
>
> to setup register by values for more fields
>
>   MODULEx->REGy = __val2mfld(MODULEx_REGy_FIELD1_m, val1) |
>   __val2mfld(MODULEx_REGy_FIELD2_m, val2);
>
>
> To replace field value
>
>   MODULEx->REGy = (MODULEx->REGy & ~MODULEx_REGy_FIELDz_m) |
>   __val2mfld(MODULEx_REGy_FIELDz_m, val1);
>
> I see significant advantage in defining of plain masks without get/set
> that they suggest to be used directly in more situations.
> I.e. used in atomic clear mask or other special instructions.
I personally like using pointers with structures that represent device
layout.
Then just using the pointers appropriately. The get/set macros tend to
end up
with casts which can cover up type issues.
> In the fact, real mask can be retrieved from set/get pair by little
> (or bigger) hack
>
>
>MODULEx_REGy_FIELDx_SET(~1)
>
> You can get the first bit position still too
>
>__builtin_ffs(MODULEx_REGy_FIELDx_SET(~1))
>
> and bit count similar way from get or by more ops from SET.
> But seems to be hacky to me.
>
> Anyway all these is compiled to constants by GCC.
> So no overhead only final and and shift if value
> put into field is not constant.
>
> I have used __val2mfld/__mfld2val names with two underscores
> to be outside of clash with POSIX when masks are used
> in generic headerfiles which can be included by third party
> libraries.
>
> But if you accept these in BSP_ space for RTEMS, I would be happy
> with any other descriptive name
>
> #define BSP_TOFLD(mask,val) (((mask)&~((mask)<<1))*(val)&(mask))
> #define BSP_FROMFLD(mask,val) (((val)&(mask))/((mask)&~((mask)<<1)))
>
> or under some other name BSP_MF2V  BSP_V2MF  in
>
>   http://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/include/utility.h
>
>>> 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/def
>>> ines/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_lpcss
>>> p.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-lpc17x
>>> x/libs/hal/hal_gpio.c#l32
> Best wishes,
>
>   Pavel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems_termios_puts: Copy and write more than one char at once


Hi Sebastian,


+  int nToSend;

Integer type is wrong.


Yes, just what the original refill_transmitter uses and expects: nToSend 
is passed as return value to rtems_refill_transmitter, which also 
returns it to its caller as an int...



+ (void)rtems_termios_start_xmit (tty, tty->rawOutBuf.Tail, false);

Please don't use this (void).


Only one of the two callers (rtems_refill_transmitter) is interested in 
that information. Is it preferred to omit the "(void)" in the other or 
rather do not pass the info as a return value, but e.g. into a variable 
pointed to by a further argument?


http://stackoverflow.com/questions/11888594/ignoring-return-values-in-c

Thanks,
Kolja

--
mr.k.waschk - ixo.de - hamburg, germany

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

Hello Joel,

I fully understand.

On Thursday 14 of August 2014 15:44:54 Joel Sherrill wrote:
> Thanks.
>
> I am just worried about reproducibility or the BSP and test results
> combined with licensing and redistribution of the TI support
> code. As long as everyone is comfortable with that, I am as well.

I am not so confortable with that, but license is not problem.
There is no restriction on code to be used in commercial
applications etc. It is intended to be a such support from Ti.
I am not aware/cannot imagine that there is restriction to write
boot loader which jumps to other code for this case.

But it is uncomfortable.

I have information that Google in  their proprietary/closed project
based on same MCU only GCC toolchain and achieved linking with
Ti flashing library. So it is possible to write all needed
infrastructure with GCC and OpenOCD and that Ti blob. Cannot put
blob to RTEMS mainline but even RTEMS applications can use it
thanks linking exception. As for Google project, they have not
solved clean separation of bootloader and loaded application
ARM exception/interrupt vectors. We have done that on HW basis
by use of POM module and I have even suggested them and have
in reserve standard jump over secondary vectors table in SRAM.

I hope we can move BSP a little forward. End even if not
I think that it is valuable base to continue on it.

As for reproducibility, we try to gain board for you and preflash
it with setup by Ti tools, if you have interrest.
Then only OpenOCD/HW based debugger and common ARM JTAG
are required to run tests.

Best wishes,

  Pavel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Console driver that needs extra TIMER


Hi,

I'm developing a DMA-based UART driver for Blackfin. It requires an 
extra timer to trigger data processing after a transmission ended. This 
increases the amount of timers required by every application that uses 
it for the console.


E.g. most of the tests won't even start without modifications. So 
effectively I have to fall back to a polling driver for console if I 
want to run the tests unmodified, or is there any mechanism to generally 
increment the amount of timers for all tests?


Thanks,
Kolja





___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Console driver that needs extra TIMER


On 8/14/2014 9:11 AM, Kolja Waschk wrote:
> Hi,
>
> I'm developing a DMA-based UART driver for Blackfin. It requires an 
> extra timer to trigger data processing after a transmission ended. This 
> increases the amount of timers required by every application that uses 
> it for the console.
Don't you get an end of DMA TX interrupt?
> E.g. most of the tests won't even start without modifications. So 
> effectively I have to fall back to a polling driver for console if I 
> want to run the tests unmodified, or is there any mechanism to generally 
> increment the amount of timers for all tests?
I don't think so. There are some BSP hooks for various features and
default number
of termios ports. But nothing specific to an object.

I suppose one could be added but for orthogonality, it would make me wonder
why we wouldn't also let you add a BSP factor on every Classic API object.
Just thinking out load.
> Thanks,
> Kolja
>
>
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Console driver that needs extra TIMER

On Thu, Aug 14, 2014 at 10:15 AM, Joel Sherrill
 wrote:
>
> On 8/14/2014 9:11 AM, Kolja Waschk wrote:
>> Hi,
>>
>> I'm developing a DMA-based UART driver for Blackfin. It requires an
>> extra timer to trigger data processing after a transmission ended. This
>> increases the amount of timers required by every application that uses
>> it for the console.
> Don't you get an end of DMA TX interrupt?
>> E.g. most of the tests won't even start without modifications. So
>> effectively I have to fall back to a polling driver for console if I
>> want to run the tests unmodified, or is there any mechanism to generally
>> increment the amount of timers for all tests?
> I don't think so. There are some BSP hooks for various features and
> default number
> of termios ports. But nothing specific to an object.
>
If you are working with rtems.git, you could probably just add another
BSP setting in confdefs.h for this and push the patch out for
inclusion in RTEMS. Something like CONFIGURE_BSP_TIMERS() that gets
added into CONFIGURE_MAXIMUM_TIMERS(). If you need more guidance how
to do this just ask.

> I suppose one could be added but for orthogonality, it would make me wonder
> why we wouldn't also let you add a BSP factor on every Classic API object.
> Just thinking out load.
Joel, what kind of load?

There are probably only a few object-types that a BSP might need to
reserve for use, but it may be worth considering.

-Gedare
>> Thanks,
>> Kolja
>>
>>
>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available(256) 722-9985
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Console driver that needs extra TIMER

On 14/08/14 16:15, Joel Sherrill wrote:

E.g. most of the tests won't even start without modifications. So
>effectively I have to fall back to a polling driver for console if I
>want to run the tests unmodified, or is there any mechanism to generally
>increment the amount of timers for all tests?

I don't think so. There are some BSP hooks for various features and
default number
of termios ports. But nothing specific to an object.

I suppose one could be added but for orthogonality, it would make me wonder
why we wouldn't also let you add a BSP factor on every Classic API object.
Just thinking out load.

Its not only a BSP factor.  It is also a per driver factor.  Since the console 
and clock drivers are optional if you make it only BSP specific, then you have 
to overestimate.

--
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

Re: [PATCH] rtems_termios_puts: Copy and write more than one char at once


On 14/08/14 15:58, Kolja Waschk wrote:

Hi Sebastian,


+  int nToSend;

Integer type is wrong.


Yes, just what the original refill_transmitter uses and expects: nToSend is
passed as return value to rtems_refill_transmitter, which also returns it to
its caller as an int...


Ok, rtems_termios_refill_transmitter() and rtems_termios_dequeue_characters() 
use the wrong types as well.  This termios.c is a real mess.  Originally only 
ints where used, but someone introduced size_t and ssize_t to match the POSIX 
API.  Apparently this was done a bit sloppy.


In this function nToSend is computed from unsigned ints, so its type should be 
unsigned int.





+ (void)rtems_termios_start_xmit (tty, tty->rawOutBuf.Tail, false);

Please don't use this (void).


Only one of the two callers (rtems_refill_transmitter) is interested in that
information. Is it preferred to omit the "(void)" in the other or rather do not
pass the info as a return value, but e.g. into a variable pointed to by a
further argument?

http://stackoverflow.com/questions/11888594/ignoring-return-values-in-c


If you use this warning, then it makes sense to use this cast, but its not done 
in many places in RTEMS and not in termios.c in particular.




Thanks,
Kolja

--
mr.k.waschk - ixo.de - hamburg, germany




--
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

Re: Console driver that needs extra TIMER


On 8/14/2014 9:20 AM, Gedare Bloom wrote:
> On Thu, Aug 14, 2014 at 10:15 AM, Joel Sherrill
>  wrote:
>> On 8/14/2014 9:11 AM, Kolja Waschk wrote:
>>> Hi,
>>>
>>> I'm developing a DMA-based UART driver for Blackfin. It requires an
>>> extra timer to trigger data processing after a transmission ended. This
>>> increases the amount of timers required by every application that uses
>>> it for the console.
>> Don't you get an end of DMA TX interrupt?
>>> E.g. most of the tests won't even start without modifications. So
>>> effectively I have to fall back to a polling driver for console if I
>>> want to run the tests unmodified, or is there any mechanism to generally
>>> increment the amount of timers for all tests?
>> I don't think so. There are some BSP hooks for various features and
>> default number
>> of termios ports. But nothing specific to an object.
>>
> If you are working with rtems.git, you could probably just add another
> BSP setting in confdefs.h for this and push the patch out for
> inclusion in RTEMS. Something like CONFIGURE_BSP_TIMERS() that gets
> added into CONFIGURE_MAXIMUM_TIMERS(). If you need more guidance how
> to do this just ask.
>
>> I suppose one could be added but for orthogonality, it would make me wonder
>> why we wouldn't also let you add a BSP factor on every Classic API object.
>> Just thinking out load.
> Joel, what kind of load?
out loud. :)
> There are probably only a few object-types that a BSP might need to
> reserve for use, but it may be worth considering.
Task, semaphore, message queue come to mind. Obviously he needs a timer
but that makes sense, I always use the example of timeouts in communications
protocols.

Hmm.. if we add message queue, we need to remember the buffer side of that.
> -Gedare
>>> Thanks,
>>> Kolja
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>> --
>> Joel Sherrill, Ph.D. Director of Research & Development
>> joel.sherr...@oarcorp.comOn-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available(256) 722-9985
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Console driver that needs extra TIMER

On Thu, Aug 14, 2014 at 10:21 AM, Sebastian Huber
 wrote:
> On 14/08/14 16:15, Joel Sherrill wrote:
>>>
>>> E.g. most of the tests won't even start without modifications. So
>>> >effectively I have to fall back to a polling driver for console if I
>>> >want to run the tests unmodified, or is there any mechanism to generally
>>> >increment the amount of timers for all tests?
>>
>> I don't think so. There are some BSP hooks for various features and
>> default number
>> of termios ports. But nothing specific to an object.
>>
>> I suppose one could be added but for orthogonality, it would make me
>> wonder
>> why we wouldn't also let you add a BSP factor on every Classic API object.
>> Just thinking out load.
>
>
> Its not only a BSP factor.  It is also a per driver factor.  Since the
> console and clock drivers are optional if you make it only BSP specific,
> then you have to overestimate.
>
Ah, that is a good point. The drivers that get used by the application
should be determining the configuration requirements?
-Gedare

> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Console driver that needs extra TIMER


On 8/14/2014 9:21 AM, Sebastian Huber wrote:
> On 14/08/14 16:15, Joel Sherrill wrote:
>>> E.g. most of the tests won't even start without modifications. So
 effectively I have to fall back to a polling driver for console if I
 want to run the tests unmodified, or is there any mechanism to generally
 increment the amount of timers for all tests?
>> I don't think so. There are some BSP hooks for various features and
>> default number
>> of termios ports. But nothing specific to an object.
>>
>> I suppose one could be added but for orthogonality, it would make me wonder
>> why we wouldn't also let you add a BSP factor on every Classic API object.
>> Just thinking out load.
> Its not only a BSP factor.  It is also a per driver factor.  Since the 
> console 
> and clock drivers are optional if you make it only BSP specific, then you 
> have 
> to overestimate.
>
That has been the problem with the number of termios ports. When set
above 1 needed for
the tests, it tends to cover up resource under allocation issues.

If the "needs driver" is not defined, the constant could be undef'ed and
redef'ed to 0.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems_termios_puts: Copy and write more than one char at once

Renamed startXmit(), nToSend is unsigned, just check FL_ORCVXOF, no (void) cast 
anymore, compute nToSend in single if/else if/else.


---
 cpukit/libcsupport/src/termios.c | 135 ---
 1 file changed, 85 insertions(+), 50 deletions(-)

diff --git a/cpukit/libcsupport/src/termios.c b/cpukit/libcsupport/src/termios.c
index 2448ea1..216834c 100644
--- a/cpukit/libcsupport/src/termios.c
+++ b/cpukit/libcsupport/src/termios.c
@@ -974,6 +974,49 @@ rtems_termios_ioctl (void *arg)
 }
 
 /*
+ * Send as many chars at once as possible to device-specific code.
+ * If transmitting==true then assume transmission is already running and
+ * an explicit write(0) is needed if output has to stop for flow control.
+ */
+static unsigned int
+startXmit (
+  struct rtems_termios_tty *tty,
+  unsigned int newTail,
+  bool transmitting
+)
+{
+  unsigned int nToSend;
+
+  tty->rawOutBufState = rob_busy;
+
+  /* if XOFF was received, do not (re)start output */
+  if (tty->flow_ctrl & FL_ORCVXOF) {
+/* set flag, that output has been stopped */
+tty->flow_ctrl |= FL_OSTOP;
+nToSend = 0;
+/* stop transmitter */
+if (transmitting) {
+  (*tty->handler.write) (tty, NULL, 0);
+}
+  } else {
+/* when flow control XON or XOF, don't send blocks of data */
+/* to allow fast reaction on incoming flow ctrl and low latency*/
+/* for outgoing flow control   */
+if (tty->flow_ctrl & (FL_MDXON | FL_MDXOF))
+  nToSend = 1;
+else if (newTail > tty->rawOutBuf.Head)
+  nToSend = tty->rawOutBuf.Size - newTail;
+else
+  nToSend = tty->rawOutBuf.Head - newTail;
+
+(*tty->handler.write)(
+tty, &tty->rawOutBuf.theBuf[newTail], nToSend);
+  }
+
+  return nToSend;
+}
+
+/*
  * Send characters to device-specific code
  */
 void
@@ -989,21 +1032,16 @@ rtems_termios_puts (
 (*tty->handler.write)(tty, buf, len);
 return;
   }
-  newHead = tty->rawOutBuf.Head;
+
   while (len) {
-/*
- * Performance improvement could be made here.
- * Copy multiple bytes to raw buffer:
- * if (len > 1) && (space to buffer end, or tail > 1)
- *  ncopy = MIN (len, space to buffer end or tail)
- *  memcpy (raw buffer, buf, ncopy)
- *  buf += ncopy
- *  len -= ncopy
- *
- * To minimize latency, the memcpy should be done
- * with interrupts enabled.
- */
-newHead = (newHead + 1) % tty->rawOutBuf.Size;
+size_t nToCopy;
+size_t nAvail;
+
+/* Check space for at least one char */
+newHead = tty->rawOutBuf.Head + 1;
+if (newHead >= tty->rawOutBuf.Size)
+  newHead -= tty->rawOutBuf.Size;
+
 rtems_termios_interrupt_lock_acquire (tty, &lock_context);
 while (newHead == tty->rawOutBuf.Tail) {
   tty->rawOutBufState = rob_wait;
@@ -1014,21 +1052,41 @@ rtems_termios_puts (
 rtems_fatal_error_occurred (sc);
   rtems_termios_interrupt_lock_acquire (tty, &lock_context);
 }
-tty->rawOutBuf.theBuf[tty->rawOutBuf.Head] = *buf++;
+
+/* Determine free space up to current tail or end of ring buffer */
+nToCopy = len;
+if (tty->rawOutBuf.Tail > tty->rawOutBuf.Head) {
+  /* Available space is contiguous from Head to Tail */
+  nAvail = tty->rawOutBuf.Tail - tty->rawOutBuf.Head - 1;
+} else {
+  /* Available space wraps at buffer end. To keep it simple, utilize
+ only the free space from Head to end during this iteration */
+  nAvail = tty->rawOutBuf.Size - tty->rawOutBuf.Head;
+  /* Head may not touch Tail after wraparound */
+  if (tty->rawOutBuf.Tail == 0)
+nAvail--;
+}
+if (nToCopy > nAvail)
+  nToCopy = nAvail;
+
+/* To minimize latency, the memcpy could be done
+ * with interrupts enabled or with limit on nToCopy (TBD)
+ */
+memcpy(&tty->rawOutBuf.theBuf[tty->rawOutBuf.Head], buf, nToCopy);
+
+newHead = tty->rawOutBuf.Head + nToCopy;
+if (newHead >= tty->rawOutBuf.Size)
+  newHead -= tty->rawOutBuf.Size;
 tty->rawOutBuf.Head = newHead;
+
 if (tty->rawOutBufState == rob_idle) {
-  /* check, whether XOFF has been received */
-  if (!(tty->flow_ctrl & FL_ORCVXOF)) {
-(*tty->handler.write)(
-  tty, &tty->rawOutBuf.theBuf[tty->rawOutBuf.Tail],1);
-  } else {
-/* remember that output has been stopped due to flow ctrl*/
-tty->flow_ctrl |= FL_OSTOP;
-  }
-  tty->rawOutBufState = rob_busy;
+  startXmit (tty, tty->rawOutBuf.Tail, false);
 }
+
 rtems_termios_interrupt_lock_release (tty, &lock_context);
-len--;
+
+buf += nToCopy;
+len -= nToCopy;
   }
 }
 
@@ -1678,35 +1736,12 @@ rtems_termios_refill_transmitter (struct 
rtems_termios_tty *tty)
   if ( tty->tty_snd.sw_pfn != NULL) {
 (*tty->tty_snd.sw_pfn)(&tty->termios, tty->tty_snd.sw_arg);
   }
-}
-/* check, whether output should stop due to received XOFF */
-else if ((tty->flow_ctrl & (FL_MDXON | FL_

Re: Console driver that needs extra TIMER


[...] DMA-based UART driver for Blackfin. It requires an
extra timer to trigger data processing after a transmission ended. [...]



Don't you get an end of DMA TX interrupt?


No, it's about RX - the driver doesn't know beforehand how many bytes are 
expected
and thus can configure DMA only to continously receive into a ring buffer.
There are buffer-complete interrupts after every so many bytes, but not related
to the actual received data content.

As an alternative to the timer, to avoid the latency it introduces, the driver
can generate/interpret RTS/CTS signals as frame sync signals with interrupts,
but these aren't always connected and usually not supported by the communication
partner.

Kolja



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Console driver that needs extra TIMER


If you are working with rtems.git, you could probably just add another
BSP setting in confdefs.h for this and push the patch out for


Thanks for that hint. There already seems to be such mechanism in place for 
SHARED_MEMORY_DRIVER:

confdefs.h
...
rtems_api_configuration_table Configuration_RTEMS_API = {
  CONFIGURE_TASKS,
  CONFIGURE_NOTEPADS_ENABLED,
  CONFIGURE_MAXIMUM_TIMERS + CONFIGURE_TIMER_FOR_SHARED_MEMORY_DRIVER,
  CONFIGURE_SEMAPHORES,
...

At least confdefs allows to add something to CONFIGURE_MAXIMUM_TIMERS so I can
patch it for running the tests, and soon make it properly dependent on some
BSP setting.

Thanks,
Kolja



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Console driver that needs extra TIMER


On 8/14/2014 12:02 PM, Kolja Waschk wrote:
>>> If you are working with rtems.git, you could probably just add another
>>> BSP setting in confdefs.h for this and push the patch out for
> Thanks for that hint. There already seems to be such mechanism in place for 
> SHARED_MEMORY_DRIVER:
Glad  you have a temporary solution. I think the permanent solution may
unfortunately be
something that feels it like this (which could grow by drivers * object
classes):

bsp.h: 

  #define CONFIGURE_BSP_TIMERS_FOR_CONSOLE_DRIVER 1

confdefs.h:
  default it in the "no bsp section"
 
  later in a section for standard driver  resources

  #ifndef CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
  #undef CONFIGURE_BSP_TIMERS_FOR_CONSOLE_DRIVER
  #define CONFIGURE_BSP_TIMERS_FOR_CONSOLE_DRIVER 0
  #endif

  and then use it in the timer configuration line.
> confdefs.h
> ...
> rtems_api_configuration_table Configuration_RTEMS_API = {
>CONFIGURE_TASKS,
>CONFIGURE_NOTEPADS_ENABLED,
>CONFIGURE_MAXIMUM_TIMERS + CONFIGURE_TIMER_FOR_SHARED_MEMORY_DRIVER,
>CONFIGURE_SEMAPHORES,
> ...
>
> At least confdefs allows to add something to CONFIGURE_MAXIMUM_TIMERS so I can
> patch it for running the tests, and soon make it properly dependent on some
> BSP setting.
>
> Thanks,
> Kolja
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Console driver that needs extra TIMER

Joel,

A problem with the approach you outlined is as Sebastian said, you
still end up overestimating if for example the application does not
use the DMA-based console but uses a different console within the same
bsp.

-Gedare

On Thu, Aug 14, 2014 at 1:08 PM, Joel Sherrill
 wrote:
>
> On 8/14/2014 12:02 PM, Kolja Waschk wrote:
 If you are working with rtems.git, you could probably just add another
 BSP setting in confdefs.h for this and push the patch out for
>> Thanks for that hint. There already seems to be such mechanism in place for 
>> SHARED_MEMORY_DRIVER:
> Glad  you have a temporary solution. I think the permanent solution may
> unfortunately be
> something that feels it like this (which could grow by drivers * object
> classes):
>
> bsp.h:
>
>   #define CONFIGURE_BSP_TIMERS_FOR_CONSOLE_DRIVER 1
>
> confdefs.h:
>   default it in the "no bsp section"
>
>   later in a section for standard driver  resources
>
>   #ifndef CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
>   #undef CONFIGURE_BSP_TIMERS_FOR_CONSOLE_DRIVER
>   #define CONFIGURE_BSP_TIMERS_FOR_CONSOLE_DRIVER 0
>   #endif
>
>   and then use it in the timer configuration line.
>> confdefs.h
>> ...
>> rtems_api_configuration_table Configuration_RTEMS_API = {
>>CONFIGURE_TASKS,
>>CONFIGURE_NOTEPADS_ENABLED,
>>CONFIGURE_MAXIMUM_TIMERS + CONFIGURE_TIMER_FOR_SHARED_MEMORY_DRIVER,
>>CONFIGURE_SEMAPHORES,
>> ...
>>
>> At least confdefs allows to add something to CONFIGURE_MAXIMUM_TIMERS so I 
>> can
>> patch it for running the tests, and soon make it properly dependent on some
>> BSP setting.
>>
>> Thanks,
>> Kolja
>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available(256) 722-9985
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Console driver that needs extra TIMER