Re: [PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

[Christian Mauderer]

On 03/09/2019 01:46, Chris Johns wrote:
> On 2/9/19 5:42 pm, Vijay Kumar Banerjee wrote:
>> On Mon, Sep 2, 2019 at 4:34 AM Chris Johns > > wrote:
>> > +     puts("\nRTEMS I2C TEST\n");
>> > +     exit_code = bbb_register_i2c_0();
>> > +     assert(exit_code == 0);
>>
>> Is this needed for the display to work?
>>
>> Yes. We need to register the rtems i2c device in order to work with the TDA 
>> driver
>> as libbsd uses rtems i2c driver. The bbb_register_* is making it bbb 
>> specific, what
>> do you suggest to make it more generic? 
> 
> Should the I2C be registered during the BSP initalisation? This would remove 
> the
> need for this type of call being spread across all applications on the BBB. 
> The
> BBB has a lot of resources and the I2C is part of the SoC and so always 
> present.
> 
> I cannot think of a way to have a sysinit entry that installs the driver when
> the I2C bus used.
> 
> Chris

Hello Chris,

I would also prefer that the I2C is initialized during BSP init. But
note that this opens the same discussion we had with Joel when I
suggested the FDT support as a project: It links in the Support for
every BSP. I don't really think it hurts for a small driver like I2C on
a big target like BBB but we should make sure that everyone is OK with that.

What might could be a problem: Is there something in the initialization
that might is application specific? The still bad solution for pin
config for example? (@Vijay: Bad because it's hard coded in I2C driver
and not due to the double init.)

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

[Vijay Kumar Banerjee]

On Tue, Sep 3, 2019 at 5:15 AM Chris Johns  wrote:

> On 3/9/19 4:56 am, Vijay Kumar Banerjee wrote:
> > > +void
> > > +libbsdhelper_start_shell(rtems_task_priority prio)
> > > +{
> > > + rtems_status_code sc = rtems_shell_init(
> > > + "SHLL",
> > > + STACK_SIZE_SHELL,
> > > + prio,
> > > + CONSOLE_DEVICE_NAME,
> > > + false,
> > > + true,
> > > + NULL
> > > + );
> > > + assert(sc == RTEMS_SUCCESSFUL);
> > > +}
> > > +
> > > +static void
> > > +Init(rtems_task_argument arg)
> > > +{
> > > + rtems_status_code sc;
> > > + int exit_code;
> > > + (void)arg;
> > > + static lv_color_t buf[LV_HOR_RES_MAX*10];
> > > + static lv_disp_buf_t disp_buf;
> > > +
> > > + puts("\nRTEMS I2C TEST\n");
> > > + exit_code = bbb_register_i2c_0();
> > > + assert(exit_code == 0);
> >
> > Is this needed for the display to work?
> >
> > Yes. We need to register the rtems i2c device in order to work with
> the TDA
> > driver
> > as libbsd uses rtems i2c driver. The bbb_register_* is making it bbb
> > specific, what
> > do you suggest to make it more generic?
> >
> > A good reference I could find is in:
> > https://git.rtems.org/rtems/tree/testsuites/libtests/i2c01/init.c#n534
> >
> > Should I do something like this in the lvgl example?
>
> I am sorry, I do not understand what you are asking with the link to that
> test.
>
> Sorry for not being clear in the question.
In the i2c01 test that the link points to, i2c_bus_register API has been
used
and the transfer, set_clock and destroy functions are defined as static in
the
program itself.
I was asking if I can add the transfer, set_clock functions in my example
and
make an i2c_bus_register call.

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

[PATCH] Add a parallel bootstrap command.

[chrisj]

From: Chris Johns 

---
 rtems-bootstrap | 270 
 1 file changed, 270 insertions(+)
 create mode 100755 rtems-bootstrap

diff --git a/rtems-bootstrap b/rtems-bootstrap
new file mode 100755
index 00..9db039aada
--- /dev/null
+++ b/rtems-bootstrap
@@ -0,0 +1,270 @@
+#! /usr/bin/env python
+
+#
+# SPDX-License-Identifier: BSD-2-Clause
+#
+# Copyright (C) 2013-2019 Chris Johns (chr...@rtems.org)
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#notice, this list of conditions and the following disclaimer in the
+#documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+#
+
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+#
+
+from __future__ import print_function
+
+import argparse
+import datetime
+import multiprocessing
+import os
+import re
+import sys
+import threading
+import time
+
+version = "1.0"
+
+class error(Exception):
+"""Base class for Builder exceptions."""
+def set_output(self, msg):
+self.msg = msg
+def __str__(self):
+return self.msg
+
+class general_error(error):
+"""Raise for a general error."""
+def __init__(self, what):
+self.set_output('error: ' + str(what))
+
+def _collect(path_, file):
+confs = []
+for root, dirs, files in os.walk(path_, topdown = True):
+for f in files:
+if f == file:
+confs += [os.path.join(root, f)]
+return confs
+
+def _grep(file, pattern):
+rege = re.compile(pattern)
+try:
+f = open(file, 'r')
+matches = [rege.match(l) != None for l in f.readlines()]
+f.close()
+except IOError as err:
+raise general_error('reading: %s' % (file))
+return True in matches
+
+class command:
+
+def __init__(self, cmd, cwd):
+self.exit_code = 0
+self.thread = None
+self.output = None
+self.cmd = cmd
+self.cwd = cwd
+self.result = None
+
+def runner(self):
+
+import subprocess
+
+#
+# Support Python 2.6
+#
+if "check_output" not in dir(subprocess):
+def f(*popenargs, **kwargs):
+if 'stdout' in kwargs:
+raise ValueError('stdout argument not allowed, it will be 
overridden.')
+process = subprocess.Popen(stdout=subprocess.PIPE, *popenargs, 
**kwargs)
+output, unused_err = process.communicate()
+retcode = process.poll()
+if retcode:
+cmd = kwargs.get("args")
+if cmd is None:
+cmd = popenargs[0]
+raise subprocess.CalledProcessError(retcode, cmd)
+return output
+subprocess.check_output = f
+
+self.start_time = datetime.datetime.now()
+self.exit_code = 0
+try:
+try:
+if os.name == 'nt':
+cmd = ['sh', '-c'] + self.cmd
+else:
+cmd = self.cmd
+self.output = subprocess.check_output(cmd, cwd = self.cwd)
+except subprocess.CalledProcessError as cpe:
+self.exit_code = cpe.returncode
+self.output = cpe.output
+except OSError as ose:
+raise general_error('bootstrap failed: %s in %s: %s' % \
+(' '.join(cmd), self.cwd, (str(ose
+except KeyboardInterrupt:
+pass
+except:
+raise
+except:
+self.result = sys.exc_info()
+self.end_time = datetime.datetime.now()
+
+def run(self):
+self.thread = threading.Thread(target = self.runner)
+self.thread.start()
+
+def is_alive(self):
+return self.thread and self.thread.is_alive()
+
+  

Re: devel.rtems.org down?

[groups]

Thanks Chris and Amar.

Andrei

> On 2019-September-02, at 19:04, Chris Johns  wrote:
> 
> On 3/9/19 10:48 am, Mr. Andrei Chichak wrote:
>> Poking around, I find that devel.rtems.org  isn’t
>> answering.
> 
> We are suffering a sustained load on Trac that is overloading the server. Amar
> is looking into but it is a long weekend and there is only so much time he has
> to sort it out. We hope it will be back and running soon.
> 
> Thank you for your patience and understanding.
> 
> Chris

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

Re: [PATCH] Address several issues from compiling examples

[Martin Erik Werner]

On Tue, 2019-09-03 at 01:48 +0200, Martin Erik Werner wrote:
> Compiling the code from examples "code-block:: c" along with public
> includes and a bsp exposed a few issues amongst a lot of false
> positives. Address some of these:
(...)

As per the sent patch, I've had some "fun" trying to run through code
examples in the documentation and looking at compile warnings.

Amongst the large amount of false positives there were quite a few more
or less significant fixes that came out of it, hopefully.

I used a *very rough* bash+awk script to do filtering and compilation,
I've attached it below if anyone dares to look.

I wonder if it might be interesting to mark a select few (or even
majority?) of the documentation examples as explicitly compilable in
isolation and adding the required include statements to them? It might
make compile-validation significantly easier in the future...

As a side effect of this I've also noticed some things which I'm really
unsure about:

The filesystem section seems very out of date, especially the
filesystem implementation part, where it seems to match the current
rtems state very poorly, I've skipped doing any updates in this section
since there seemed like major changes in both text and examples would
be needed.

With reference to ticket #3254, commit 3f575da2f2 - "Remove obsolete
network header files" removed cpukit/libnetworking/include/net/if.h.
This removed, amongst other things, the definitions for "struct ifreq"
and "struct ifaliasreq". These two are referenced and used both in
rtems-docs and in current code in rtems.

I'm wondering if I'm missing something here? Are they provided through
some other means? Are these supposed to be completely removed and all
use of them removed eventually? Do they need to be re-added for the
current code to work as it should?

-- 
Martin Erik Werner 

compile-examples
Description: Perl program
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Address several issues from compiling examples

[Chris Johns]

On 3/9/19 9:48 am, Martin Erik Werner wrote:
> Compiling the code from examples "code-block:: c" along with public
> includes and a bsp exposed a few issues amongst a lot of false
> positives. Address some of these:

Pushed. Thank you.

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

[PATCH] Address several issues from compiling examples

[Martin Erik Werner]

Compiling the code from examples "code-block:: c" along with public
includes and a bsp exposed a few issues amongst a lot of false
positives. Address some of these:

* Terminate struct declarations with ';'. Mainly for pedantic
  correctness.

* Show ptrdiff_t instead of size_t for the sbrk() prototype, matching
  the current argument type in rtems.

* Replace some occurrences of unsigned16 with uint16_t.

* Fix odd type declaration, "uint8_t char*" -> "char*".

* Use appropriate helper to get chain head instead of invalid access to
  nonexistent struct member.

* Remove several excess '\' escapes.

* Use RTEMS_SELF instead of undefined SELF.

* Use rtems_task instead of void for task functions.

* Add missing stack size parameter in task creation.

* Use rtems_interrupt_level instead of undefined rtems_interrupt.

* Correct return value format for rtems_object_id_get_api()
  rtems_object_id_get_index() (enum and uint16_t) and also fix
  corresponding print formatting.

* Correct return value documentation for rtems_object_id_get_class(),
  rtems_object_id_get_node() and rtems_object_id_get_index()
  int -> uint32_t.

* Use RTEMS_SUCCESSFUL instead of undefined RTEMS_STATUS_SUCCESSFUL and
  fix return value variable name in rate monotonic examples.

* Use RTEMS_TIMEOUT instead of undefined TIMEOUT and RTEMS_PERIOD_STATUS
  instead of undefined STATUS.

* Add missing fields to ftpd configuration.

* Correct parameter types in ftpd hook prototype,
  unsigned char * -> void *.

* Fix various code-block:: attributes, c -> makefile and c -> shell.

* Add missing parenthesis in socket buffer memory calculation example.

* Remove typedef in declaration of mq_attr since it is defiend without
  typedef in reality.

* Update siginfo_t declaration to match current reality.

* Update shell user command definition example to include mode, uid and
  gid.
---
 bsp-howto/console.rst |  2 +-
 bsp-howto/miscellanous_support.rst|  2 +-
 bsp-howto/real_time_clock.rst |  4 ++--
 c-user/chains.rst |  4 ++--
 c-user/configuring_a_system.rst   |  2 +-
 c-user/constant_bandwidth_server.rst  |  6 +++---
 c-user/fatal_error.rst|  7 ---
 c-user/interrupt_manager.rst  |  8 
 c-user/key_concepts.rst   |  4 ++--
 c-user/object_services.rst| 19 ++-
 c-user/rate_monotonic_manager.rst | 19 +--
 c-user/task_manager.rst   |  2 +-
 networking/network_servers.rst| 10 --
 networking/networking_driver.rst  |  4 ++--
 networking/using_networking_rtems_app.rst |  6 +++---
 posix-users/message_passing.rst   |  2 +-
 posix-users/signal.rst| 16 
 shell/configuration_and_init.rst  | 15 +--
 shell/file_and_directory.rst  |  6 +++---
 shell/general_commands.rst|  2 +-
 20 files changed, 71 insertions(+), 69 deletions(-)

diff --git a/bsp-howto/console.rst b/bsp-howto/console.rst
index 83b10b4..aef13a8 100644
--- a/bsp-howto/console.rst
+++ b/bsp-howto/console.rst
@@ -168,7 +168,7 @@ The handler table for the polled mode should look like the 
following.
   .set_attributes = my_driver_set_attributes,
   .ioctl = my_driver_ioctl, /* optional, may be NULL */
   .mode = TERMIOS_POLLED
-}
+};
 
 The :c:func:`my_driver_poll_write()` routine is responsible for writing ``n``
 characters from ``buf`` to the serial device specified by ``base``.
diff --git a/bsp-howto/miscellanous_support.rst 
b/bsp-howto/miscellanous_support.rst
index cea744d..77b7194 100644
--- a/bsp-howto/miscellanous_support.rst
+++ b/bsp-howto/miscellanous_support.rst
@@ -138,7 +138,7 @@ prototype for this routine:
 
 .. code-block:: c
 
-void * sbrk(size_t increment)
+void * sbrk(ptrdiff_t increment)
 
 The ``increment`` amount is based upon the ``sbrk_amount`` parameter passed to
 the ``bsp_libc_init`` during system initialization.
diff --git a/bsp-howto/real_time_clock.rst b/bsp-howto/real_time_clock.rst
index ee40a6c..62ec09e 100644
--- a/bsp-howto/real_time_clock.rst
+++ b/bsp-howto/real_time_clock.rst
@@ -67,8 +67,8 @@ table is below:
 
 bool dmv177_icm7170_probe(int minor)
 {
-  volatile unsigned16 *card_resource_reg;
-  card_resource_reg = (volatile unsigned16 *) DMV170_CARD_RESORCE_REG;
+  volatile uint16_t *card_resource_reg;
+  card_resource_reg = (volatile uint16_t *) DMV170_CARD_RESORCE_REG;
   if ( (*card_resource_reg & DMV170_RTC_INST_MASK) == DMV170_RTC_INSTALLED 
)
 return TRUE;
   return FALSE;
diff --git a/c-user/chains.rst b/c-user/chains.rst
index c47d318..0dce1d9 100644
--- a/c-user/chains.rst
+++ b/c-user/chains.rst
@@ -149,7 +149,7 @@ to the control. Consider a user structure and chain control:
 typedef struct foo
 {
 rtems_chain_node node;
-uint8_t char*   

Re: [PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

[Chris Johns]

On 3/9/19 4:56 am, Vijay Kumar Banerjee wrote:
> > +void
> > +libbsdhelper_start_shell(rtems_task_priority prio)
> > +{
> > +     rtems_status_code sc = rtems_shell_init(
> > +             "SHLL",
> > +             STACK_SIZE_SHELL,
> > +             prio,
> > +             CONSOLE_DEVICE_NAME,
> > +             false,
> > +             true,
> > +             NULL
> > +     );
> > +     assert(sc == RTEMS_SUCCESSFUL);
> > +}
> > +
> > +static void
> > +Init(rtems_task_argument arg)
> > +{
> > +     rtems_status_code sc;
> > +     int exit_code;
> > +     (void)arg;
> > +     static lv_color_t buf[LV_HOR_RES_MAX*10];
> > +     static lv_disp_buf_t disp_buf;
> > +
> > +     puts("\nRTEMS I2C TEST\n");
> > +     exit_code = bbb_register_i2c_0();
> > +     assert(exit_code == 0);
> 
> Is this needed for the display to work?
> 
> Yes. We need to register the rtems i2c device in order to work with the 
> TDA
> driver
> as libbsd uses rtems i2c driver. The bbb_register_* is making it bbb
> specific, what
> do you suggest to make it more generic? 
> 
> A good reference I could find is in:
> https://git.rtems.org/rtems/tree/testsuites/libtests/i2c01/init.c#n534
> 
> Should I do something like this in the lvgl example? 

I am sorry, I do not understand what you are asking with the link to that test.

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

Re: [PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

[Chris Johns]

On 2/9/19 5:42 pm, Vijay Kumar Banerjee wrote:
> On Mon, Sep 2, 2019 at 4:34 AM Chris Johns  > wrote:
> > +     puts("\nRTEMS I2C TEST\n");
> > +     exit_code = bbb_register_i2c_0();
> > +     assert(exit_code == 0);
> 
> Is this needed for the display to work?
> 
> Yes. We need to register the rtems i2c device in order to work with the TDA 
> driver
> as libbsd uses rtems i2c driver. The bbb_register_* is making it bbb 
> specific, what
> do you suggest to make it more generic? 

Should the I2C be registered during the BSP initalisation? This would remove the
need for this type of call being spread across all applications on the BBB. The
BBB has a lot of resources and the I2C is part of the SoC and so always present.

I cannot think of a way to have a sysinit entry that installs the driver when
the I2C bus used.

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

Re: [PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

[Vijay Kumar Banerjee]

>
> > +void
>> > +libbsdhelper_start_shell(rtems_task_priority prio)
>> > +{
>> > + rtems_status_code sc = rtems_shell_init(
>> > + "SHLL",
>> > + STACK_SIZE_SHELL,
>> > + prio,
>> > + CONSOLE_DEVICE_NAME,
>> > + false,
>> > + true,
>> > + NULL
>> > + );
>> > + assert(sc == RTEMS_SUCCESSFUL);
>> > +}
>> > +
>> > +static void
>> > +Init(rtems_task_argument arg)
>> > +{
>> > + rtems_status_code sc;
>> > + int exit_code;
>> > + (void)arg;
>> > + static lv_color_t buf[LV_HOR_RES_MAX*10];
>> > + static lv_disp_buf_t disp_buf;
>> > +
>> > + puts("\nRTEMS I2C TEST\n");
>> > + exit_code = bbb_register_i2c_0();
>> > + assert(exit_code == 0);
>>
>> Is this needed for the display to work?
>>
>> Yes. We need to register the rtems i2c device in order to work with the
> TDA driver
> as libbsd uses rtems i2c driver. The bbb_register_* is making it bbb
> specific, what
> do you suggest to make it more generic?
>
A good reference I could find is in:
https://git.rtems.org/rtems/tree/testsuites/libtests/i2c01/init.c#n534

Should I do something like this in the lvgl example?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

[Vijay Kumar Banerjee]

On Mon, Sep 2, 2019 at 4:34 AM Chris Johns  wrote:

> Hi,
>
>
> Thank you for the patch.
>
> Can this please be moved as lvgl/hello? It would allow for other examples
> to be
> added.
>
> We need a test for liblvgl.a. Maybe lvgl/wscript can check and not build
> if not
> found.
>
> OK. Understood.

> On 31/8/19 4:23 am, Vijay Kumar Banerjee wrote:
> > ---
> >  README |   2 +-
> >  lvgl_hello/README  |   6 ++
> >  lvgl_hello/test.c  | 180 +
> >  lvgl_hello/wscript |  25 +++
> >  wscript|   1 +
> >  5 files changed, 213 insertions(+), 1 deletion(-)
> >  create mode 100644 lvgl_hello/README
> >  create mode 100644 lvgl_hello/test.c
> >  create mode 100644 lvgl_hello/wscript
> >
> > diff --git a/README b/README
> > index 99ca787..f1e127c 100644
> > --- a/README
> > +++ b/README
> > @@ -15,4 +15,4 @@ posix_api- POSIX API examples (no led)
> >  schedsim - RTEMS Scheduler Simulator examples
> >  ticker   - Ticker Variations
> >  uboot- U-Boot interaction examples
> > -
> > +lvgl_hello   - LittleVGL graphics app example using libbsd framebuffer
> driver
> > diff --git a/lvgl_hello/README b/lvgl_hello/README
> > new file mode 100644
> > index 000..866d0cd
> > --- /dev/null
> > +++ b/lvgl_hello/README
> > @@ -0,0 +1,6 @@
> > +This folder contains a sample graphics app using littleVGL library and
> libbsd
> > +The generated exe file can be directly run using a JTAG debugger on a
> target
> > +with the right device tree or this can be converted into an image.
> > +
> > +For instructions on how to build the image or how to run the exe,
> please refer
> > +to the BSP documentation in https://docs.rtems.org
> > diff --git a/lvgl_hello/test.c b/lvgl_hello/test.c
> > new file mode 100644
> > index 000..6e0c030
> > --- /dev/null
> > +++ b/lvgl_hello/test.c
> > @@ -0,0 +1,180 @@
> > +/*
> > + * Copyright (c) 2019 Vijay Kumar Banerjee .
> > + * All rights reserved.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + *notice, this list of conditions and the following disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + *notice, this list of conditions and the following disclaimer in
> the
> > + *documentation and/or other materials provided with the
> distribution.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS''
> AND
> > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> > + * ARE DISCLAIMED.   IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE
> LIABLE
> > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> CONSEQUENTIAL
> > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
> GOODS
> > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
> STRICT
> > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
> ANY WAY
> > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
> OF
> > + * SUCH DAMAGE.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
>
> Needed?
>
> > +#include 
> > +#include 
>
> This ...
>
> > +#include 
>
>  [ Needed? ]
>
> Not all these headers are needed, they seeped in from the experimental
app that I made. I'll remove the ones that are unnecessary.

> > +#include 
> > +#include 
>
> .. and this header make the example BBB specific. Is there a way this can
> be
> moved into the BBB BSP or libbsd?
>
> I think bbb-gpio.h isn't needed anymore, so it can just be removed. I'll
have a look
and report.

> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include 
> > +
> > +#define PRIO_SHELL   150
> > +#define STACK_SIZE_SHELL (64 * 1024)
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>
> Which headers are needed in this list?
>
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +void
> > +libbsdhelper_start_shell(rtems_task_priority prio)
> > +{
> > + rtems_status_code sc = rtems_shell_init(
> > + "SHLL",
> > + STACK_SIZE_SHELL,
> > + prio,
> > + CONSOLE_DEVICE_NAME,
> > + false,
> > + true,
> > + NULL
> > + );
> > + assert(sc == RTEMS_SUCCESSFUL);
> > +}
> > +
> > +static void
> > +Init(rtems_task_argument arg)
> > +{
> > + rtems_status_code sc;
> > + int exit_code;
> > + (void)arg;
> > + static lv_color_t buf[LV_HOR_RES_MAX*10];

Re: [PATCH] record: Add wrappers for malloc() functions

[Sebastian Huber]

On 02/09/2019 09:00, Chris Johns wrote:

Why not generate the call to `rtems_record_produce_2`? You should be able to
determine this give you will know there in a single item plus the return address
to record. In fact there is little need for `rtems_record_produce_n` if you have
[1..n] already defined.


The rtems_record_produce_2() is just an optimization since most 
architectures accept up to four arguments via registers. The particular 
rtems_record_produce*() function is not the issue here.


--
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] record: Add wrappers for malloc() functions

[Chris Johns]

On 2/9/19 4:11 pm, Sebastian Huber wrote:
> On 02/09/2019 08:00, Chris Johns wrote:
 I do not see any upside adding this library or wrapping specific functions
 this way.
>>> The benefits are:
>>>
>>> * Slightly more compact (the event indicates the function and the data can 
>>> be
>>> used for the caller address instead, the generic function entry/exit needs 
>>> two
>>> events for this).
>> Could you please explain this, sorry I am not sure what this means? If the 
>> code
>> is what needs to be generated then why not generate?
> 
> The record items is defined like this:
> 
> /**
>  * @brief The record data integer type.
>  *
>  * It is big enough to store 32-bit integers and pointers.
>  */
> typedef unsigned long rtems_record_data;
> 
> /**
>  * @brief The native record item.
>  */
> typedef struct __attribute__((__packed__)) {
>   uint32_t  event;
>   rtems_record_data data;
> } rtems_record_item;
> 
> The event member contains a 22-bit time stamp and a 10-bit event number.
> 
> The malloc entry/exit wrapper with a special event number looks like this:
> 
> void *__wrap_malloc( size_t size )
> {
>   void *ptr;
> 
>   rtems_record_produce_2(
>     RTEMS_RECORD_MALLOC_ENTRY,
>     (rtems_record_data) RTEMS_RETURN_ADDRESS(),
>     RTEMS_RECORD_ARG_0,
>     size
>   )
>   ptr = __real_malloc( size );
>     rtems_record_produce_2(
>     RTEMS_RECORD_MALLOC_EXIT,
>     (rtems_record_data) RTEMS_RETURN_ADDRESS(),
>     RTEMS_RECORD_RETURN_0,
>     (rtems_record_data) ptr
>   )
>   return ptr;
> }
> 
> If you have to encode the function in the event data, then you need two extra
> items:
> 
> void *__wrap_malloc( size_t size )
> {
>   rtems_record_item items[ 3 ];
>   void *ptr;
> 
>   items[ 0 ].event = RTEMS_RECORD_FUNCTION_ENTRY;
>   items[ 1 ].data = (rtems_record_data) __real_malloc;
>   items[ 1 ].event = RTEMS_RECORD_CALLER;
>   items[ 1 ].data = (rtems_record_data) RTEMS_RETURN_ADDRESS();
>   items[ 2 ].event = RTEMS_RECORD_ARG_0;
>   items[ 2 ].data = size;
>   rtems_record_produce_n( items, RTEMS_ARRAY_SIZE( items ) );
>   ptr = __real_malloc( size );
>   items[ 0 ].event = RTEMS_RECORD_FUNCTION_EXIT;
>   items[ 1 ].data = (rtems_record_data) __real_malloc;
>   items[ 1 ].event = RTEMS_RECORD_CALLER;
>   items[ 1 ].data = (rtems_record_data) RTEMS_RETURN_ADDRESS();
>   items[ 2 ].event = RTEMS_RECORD_RETURN_0;
>   items[ 2 ].data = (rtems_record_data) ptr;
>   rtems_record_produce_n( items, RTEMS_ARRAY_SIZE( items ) );
>   return ptr;
> }
> 
> For this simple one argument function, this is a 50% increase.
> 

Why not generate the call to `rtems_record_produce_2`? You should be able to
determine this give you will know there in a single item plus the return address
to record. In fact there is little need for `rtems_record_produce_n` if you have
[1..n] already defined.

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

Re: rtems_version_control_key() may return NULL

[Sebastian Huber]

On 02/09/2019 08:04, Chris Johns wrote:

On 2/9/19 3:58 pm, Sebastian Huber wrote:

Hello,

the

const char *rtems_version_control_key( void )
{
#ifdef RTEMS_VERSION_VC_KEY
   return RTEMS_VERSION_VC_KEY;
#else
   return NULL;
#endif
}

returns NULL, if no RTEMS_VERSION_VC_KEY is defined, e.g. the RTEMS sources are
not managed by Git. Naive users like me may produce a NULL pointer if they use
it like this printf("version: %s", rtems_version_control_key()). Should we
change this function to return "" instead of NULL?


"NO-VERSION-VC-KEY" ?


I would keep it simple, e.g. strlen(rtems_version_control_key()) == 0 
means, no version control key.


--
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] record: Add wrappers for malloc() functions

[Sebastian Huber]

On 02/09/2019 08:00, Chris Johns wrote:

I do not see any upside adding this library or wrapping specific functions
this way.

The benefits are:

* Slightly more compact (the event indicates the function and the data can be
used for the caller address instead, the generic function entry/exit needs two
events for this).

Could you please explain this, sorry I am not sure what this means? If the code
is what needs to be generated then why not generate?


The record items is defined like this:

/**
 * @brief The record data integer type.
 *
 * It is big enough to store 32-bit integers and pointers.
 */
typedef unsigned long rtems_record_data;

/**
 * @brief The native record item.
 */
typedef struct __attribute__((__packed__)) {
  uint32_t  event;
  rtems_record_data data;
} rtems_record_item;

The event member contains a 22-bit time stamp and a 10-bit event number.

The malloc entry/exit wrapper with a special event number looks like this:

void *__wrap_malloc( size_t size )
{
  void *ptr;

  rtems_record_produce_2(
RTEMS_RECORD_MALLOC_ENTRY,
(rtems_record_data) RTEMS_RETURN_ADDRESS(),
RTEMS_RECORD_ARG_0,
size
  )
  ptr = __real_malloc( size );
rtems_record_produce_2(
RTEMS_RECORD_MALLOC_EXIT,
(rtems_record_data) RTEMS_RETURN_ADDRESS(),
RTEMS_RECORD_RETURN_0,
(rtems_record_data) ptr
  )
  return ptr;
}

If you have to encode the function in the event data, then you need two 
extra items:


void *__wrap_malloc( size_t size )
{
  rtems_record_item items[ 3 ];
  void *ptr;

  items[ 0 ].event = RTEMS_RECORD_FUNCTION_ENTRY;
  items[ 1 ].data = (rtems_record_data) __real_malloc;
  items[ 1 ].event = RTEMS_RECORD_CALLER;
  items[ 1 ].data = (rtems_record_data) RTEMS_RETURN_ADDRESS();
  items[ 2 ].event = RTEMS_RECORD_ARG_0;
  items[ 2 ].data = size;
  rtems_record_produce_n( items, RTEMS_ARRAY_SIZE( items ) );
  ptr = __real_malloc( size );
  items[ 0 ].event = RTEMS_RECORD_FUNCTION_EXIT;
  items[ 1 ].data = (rtems_record_data) __real_malloc;
  items[ 1 ].event = RTEMS_RECORD_CALLER;
  items[ 1 ].data = (rtems_record_data) RTEMS_RETURN_ADDRESS();
  items[ 2 ].event = RTEMS_RECORD_RETURN_0;
  items[ 2 ].data = (rtems_record_data) ptr;
  rtems_record_produce_n( items, RTEMS_ARRAY_SIZE( items ) );
  return ptr;
}

For this simple one argument function, this is a 50% increase.

--
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: rtems_version_control_key() may return NULL

[Chris Johns]

On 2/9/19 3:58 pm, Sebastian Huber wrote:
> Hello,
> 
> the
> 
> const char *rtems_version_control_key( void )
> {
> #ifdef RTEMS_VERSION_VC_KEY
>   return RTEMS_VERSION_VC_KEY;
> #else
>   return NULL;
> #endif
> }
> 
> returns NULL, if no RTEMS_VERSION_VC_KEY is defined, e.g. the RTEMS sources 
> are
> not managed by Git. Naive users like me may produce a NULL pointer if they use
> it like this printf("version: %s", rtems_version_control_key()). Should we
> change this function to return "" instead of NULL?
> 

"NO-VERSION-VC-KEY" ?

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