Re: IoT Protocol in RTEMS
OK. For a time being we can create tickets for these protocol. We can figure it out from where we can port. :) On Tue, Mar 14, 2017 at 10:13 PM, Gedare Bloom wrote: > On Tue, Mar 14, 2017 at 12:08 PM, Joel Sherrill wrote: >> >> >> On Tue, Mar 14, 2017 at 10:22 AM, punit vara wrote: >>> >>> Can I port MQTT from here ? >>> >>> >>> https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/net/lib/mqtt >>> >>> It has Apache licence. Where do I possibly need to add files ? Any >>> suggestion ? >>> >> Why would Zephyr want their code to support multiple RTOSes? Would >> we end up with something that has long-term life as an RTEMS option? >> > Apache License is a bit of a pain to use if we need to modify the > upstream source, especially if the upstream will not accept changes. > I, like Joel, am more concerned about the latter in case we need to > adapt the upstream for easier porting and maintenance. > >>> >>> -- PV >>> >>> On Tue, Mar 14, 2017 at 7:50 PM, Joel Sherrill wrote: >>> > >>> > >>> > On Tue, Mar 14, 2017 at 8:56 AM, Gedare Bloom wrote: >>> >> >>> >> On Tue, Mar 14, 2017 at 1:26 AM, punit vara >>> >> wrote: >>> >> > Hi >>> >> > >>> >> > I think RTEMS don't have any IoT protocol so I propose we should >>> >> > implement at least two important IoT protocols >>> >> > >>> >> > 1. MQTT >>> >> > (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html) >>> >> > 2. CoAP (http://coap.technology/) >>> >> > >>> >> Why are these 2 important? >>> >> >>> >> The problem to avoid is adopting a network protocol too early, because >>> >> there is always a bunch of competing ones, and in the end only a >>> >> handful will survive in the long term. >>> > >>> > >>> > MQTT is an OASIS standard which is a good sign. It also has multiple >>> > implementations >>> > already with this one from the Eclipse Foundation looking very promising >>> > and >>> > appropriate for RTEMS. >>> > >>> > https://www.eclipse.org/paho/clients/c/embedded/ >>> > >>> > CoAP also looks promising since it has an RFC. And promising >>> > implementations >>> > to investigate. >>> > >>> > http://coap.technology/impls.html >>> > >>> > https://github.com/obgm/libcoap is dual licensed as GPL and BSD (why?). >>> > >>> >> >>> >> >>> >> > >>> >> > What's your opinion on this ? :) >>> >> > >>> >> This may be a good idea. What is the state of industry and of >>> >> standardization in this space? Are there open-source reference >>> >> implementations with a useful (BSD/MIT) license? >>> >> >>> > >>> > I think those two are worth porting. There are already other ports to >>> > embedded >>> > environments so RTEMS should join the list. >>> > >>> > The effort would have to get the RTEMS specific configuration and >>> > adaptation >>> > code upstream, add RSB recipes, and examples with documentation. I would >>> > honestly expect the ports to be easy enough where more work needs to be >>> > identified. :) >>> > >>> > --joel >>> > >>> >> >>> >> Gedare >>> >> >>> >> > >>> >> > Regards >>> >> > Punit Vara >>> > >>> > >> >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Coverity Scan Issues
Hi I have been running Coverity Scan on RTEMS, newlib, and RTEMS Tools. If anyone in the community (including GSoC students), wants to take a stab at analysing issues and addressing them, you are more than welcome. The links are: https://scan.coverity.com/projects/rtems https://scan.coverity.com/projects/rtems-newlib https://scan.coverity.com/projects/rtems-tools A few words of caution. + First some of the issues are in code that originates outside RTEMS. The solution path here is to get the issue addressed upstream and bring it back to RTEMS. This effects at least libdl and libcrypt. + Second, I have filed tickets on some of the issues. Be sure to check so work gets tracked correctly. + Third, Don't immediately assume an issue is a false positive. The tools don't like something and even if the code is right, it is often coded in a less than clear manner. If a program can't figure the code out, a random person isn't going to understand it either. See if it can be improved for clarity, simplicity, and readability. The scripts for building and submitting jobs to Coverity is in rtems-testing/coverity. Not the prettiest but functional. Help is definitely appreciated. Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] psxstrsignal01: New test
---
testsuites/psxtests/Makefile.am| 2 +-
testsuites/psxtests/configure.ac | 1 +
testsuites/psxtests/psxstrsignal01/Makefile.am | 24 +
testsuites/psxtests/psxstrsignal01/init.c | 115 +
.../psxtests/psxstrsignal01/psxstrsignal01.doc | 19
.../psxtests/psxstrsignal01/psxstrsignal01.scn | 38 +++
6 files changed, 198 insertions(+), 1 deletion(-)
create mode 100644 testsuites/psxtests/psxstrsignal01/Makefile.am
create mode 100644 testsuites/psxtests/psxstrsignal01/init.c
create mode 100644 testsuites/psxtests/psxstrsignal01/psxstrsignal01.doc
create mode 100644 testsuites/psxtests/psxstrsignal01/psxstrsignal01.scn
diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index 2bea8ab..a00aea4 100644
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -12,7 +12,7 @@ _SUBDIRS += psxhdrs psx01 psx02 psx03 psx04 psx05 psx06 psx07
psx08 psx09 \
psxitimer psxmsgq01 psxmsgq02 psxmsgq03 psxmsgq04 \
psxmutexattr01 psxobj01 psxrwlock01 psxsem01 psxshm01 psxshm02 \
psxsignal01 psxsignal02 psxsignal03 psxsignal04 psxsignal05 psxsignal06 \
-psxspin01 psxsysconf \
+psxspin01 psxstrsignal01 psxsysconf \
psxtime psxtimer01 psxtimer02 psxualarm psxusleep psxfatal01 psxfatal02 \
psxintrcritical01 psxstack01 psxstack02 \
psxeintr_join psxgetattrnp01 psxclock01
diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac
index 77af14e..3211a8d 100644
--- a/testsuites/psxtests/configure.ac
+++ b/testsuites/psxtests/configure.ac
@@ -200,6 +200,7 @@ psxspin01/Makefile
psxstack01/Makefile
psxstack02/Makefile
psxstat/Makefile
+psxstrsignal01/Makefile
psxsysconf/Makefile
psxtime/Makefile
psxtimer01/Makefile
diff --git a/testsuites/psxtests/psxstrsignal01/Makefile.am
b/testsuites/psxtests/psxstrsignal01/Makefile.am
new file mode 100644
index 000..f353999
--- /dev/null
+++ b/testsuites/psxtests/psxstrsignal01/Makefile.am
@@ -0,0 +1,24 @@
+
+rtems_tests_PROGRAMS = psxstrsignal01
+psxstrsignal01_SOURCES = init.c ../include/pmacros.h
+
+dist_rtems_tests_DATA = psxstrsignal01.scn
+dist_rtems_tests_DATA += psxstrsignal01.doc
+
+include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
+include $(top_srcdir)/../automake/compile.am
+include $(top_srcdir)/../automake/leaf.am
+
+
+AM_CPPFLAGS += -I$(top_srcdir)/include
+AM_CPPFLAGS += -I$(top_srcdir)/../support/include
+
+LINK_OBJS = $(psxstrsignal01_OBJECTS)
+LINK_LIBS = $(psxstrsignal01_LDLIBS)
+
+psxstrsignal01$(EXEEXT): $(psxstrsignal01_OBJECTS) \
+$(psxstrsignal01_DEPENDENCIES)
+ @rm -f psxstrsignal01$(EXEEXT)
+ $(make-exe)
+
+include $(top_srcdir)/../automake/local.am
diff --git a/testsuites/psxtests/psxstrsignal01/init.c
b/testsuites/psxtests/psxstrsignal01/init.c
new file mode 100644
index 000..82b517f
--- /dev/null
+++ b/testsuites/psxtests/psxstrsignal01/init.c
@@ -0,0 +1,115 @@
+/*
+ * COPYRIGHT (c) 2017.
+ * On-Line Applications Research Corporation (OAR).
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "tmacros.h"
+#include
+#include
+#include
+
+const char rtems_test_name[] = "PSXSTRSIGNAL 1";
+typedef struct {
+ char *sigstr;
+ int signal;
+} Signals_t;
+
+Signals_t Signals[] = {
+ { "SIGHUP", SIGHUP },
+ { "SIGINT", SIGINT },
+ { "SIGQUIT", SIGQUIT },
+ { "SIGILL", SIGILL },
+ { "SIGTRAP", SIGTRAP },
+ { "SIGIOT", SIGIOT },
+ { "SIGABRT", SIGABRT },
+#ifdef SIGEMT
+ { "SIGEMT", SIGEMT },
+#endif
+ { "SIGFPE", SIGFPE },
+ { "SIGKILL", SIGKILL },
+ { "SIGBUS", SIGBUS },
+ { "SIGSEGV", SIGSEGV },
+ { "SIGSYS", SIGSYS },
+ { "SIGPIPE", SIGPIPE },
+ { "SIGALRM", SIGALRM },
+ { "SIGTERM", SIGTERM },
+ { "SIGURG", SIGURG },
+ { "SIGSTOP", SIGSTOP },
+ { "SIGTSTP", SIGTSTP },
+ { "SIGCONT", SIGCONT },
+ { "SIGCHLD", SIGCHLD },
+ { "SIGCLD", SIGCLD },
+ { "SIGTTIN", SIGTTIN },
+ { "SIGTTOU", SIGTTOU },
+ { "SIGIO",SIGIO },
+ { "SIGPOLL", SIGPOLL },
+ { "SIGWINCH", SIGWINCH },
+ { "SIGUSR1", SIGUSR1 },
+ { "SIGUSR2", SIGUSR2 },
+ { NULL, -1 },
+};
+
+void do_test(void)
+{
+ int i;
+
+ puts( "=== Normal Signals" );
+ for (i=0 ; Signals[i].sigstr ; i++) {
+printf(
+ "signal=%s => %s\n",
+ Signals[i].sigstr,
+ strsignal(Signals[i].signal)
+);
+ }
+}
+
+void do_test_rt(void)
+{
+ int sig;
+
+ puts( "=== Real-Time Signals" );
+ for (sig=SIGRTMIN ; sig <= SIGRTMAX ; sig++) {
+printf(
+ "signal=SIGRTMIN+%d => %s\n",
+ sig-SIGRTMIN,
+ strsignal(sig)
+);
+ }
+}
+
+void *POSIX_Init(
+ void *unused
+)
+{
+ TEST_BEGIN();
+
+ do_test();
+ puts("");
+ do_test_rt();
+
+ TEST_END();
+ rtems_test_exit( 0 );
+
+ return NULL; /* just so the co
Re: [GSoC] RTEMS Tester Improvements
Hello Chris, Gedare, Joel, Thank you for answering my questions. Sorry for the late reply, it took me time to go through the tasks suggested. > > What platforms have you run tester on? I was searching for a way to compile and execute a single test and the community suggetsed rtems-tester. So I ran the tester on sparc/erc32 (and no simulator). I am unable to find a relevant doc on how to run rtems-tester on qemu. Though there is this rtems-tools.git/tester/rtems/testing/qemu.cfg so I know that it is supported. Also I couldn't find any other hint in the rtems-tools repository as to which simulators (except for qemu) are supported. rtems-testing/sim-scripts support gdbsim, skyeye and tsim (other than qemu). So we can add support for these and gem5 (as Gedare suggested). Please correct me if I am wrong. Furthermore, if you could please point me to a doc that explains using rtems-tester on qemu? I have tested qemu for running an application, the steps for which I have documented here (http://tokencolour.github.io/2017/03/16/how-to-run-applications-on-qemu-rtems.html). I can play with visualizing aggregated testing results with plotting techniques (like matplotlib or maybe something that the devs recommend) :). Also, where can I find more about "expected fail" state? Is it for those tests that fail nevertheless and need to be skipped? Can you please point me to an example? Also, what kind of regression will one need to perform? Do the final states of the test need to maintain an overall state of the system so as to recommend/predict the state of affairs next time the tests are run (i.e. a predictor (which has memory) kind of thing)? I also think that converting macro files to yaml won't be very difficult. I might be very myopic here and it would be great if I get a heads up. What will be the challenge here? For the generic serial console, will pySerial do the trick, on Windows? Do you have some other package in mind? I have a problem here, though. I don't own a Zedboard and can't afford one. I can check with my department at college once I reach there, but I don't have my hopes too high. Will this pose a problem in the course of the project? I am yet to build for xilinx_zynq_zc706, so I'll ask more questions on the configuration control once I am done with it. Also, I'm trying out the old and new approach for Coverage reporting. I'll ask questions on it, once I try it. Thank you, Tanu Hari Dixit. On Wed, Mar 15, 2017 at 2:37 AM, Chris Johns wrote: > On 15/3/17 1:02 am, Gedare Bloom wrote: >> On Tue, Mar 14, 2017 at 9:58 AM, Gedare Bloom wrote: >>> On Tue, Mar 14, 2017 at 1:50 AM, Chris Johns wrote: On 14/3/17 9:18 am, Chris Johns wrote: > > The follow is the work I see needing to be done. > I have created a ticket for this project. Please update and add BSP/Simulator section to track those tasks. https://devel.rtems.org/ticket/2927 >>> Does this supersede https://devel.rtems.org/ticket/2919 >>> >> >> Note: I classify Testing Tool Improvements as part of improving our >> Developer Ecosystem rather than as a Testing project. A subtle >> distinction perhaps, but I feel it is important to understand where we >> draw these kinds of lines. >> > > I agree, one side is what a test is and how to create a test executable > and as you say this project is about the ecosystem used to execute these > tests and manage the results. > > Chris > ___ > 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: [GSoC] RTEMS Tester Improvements
On 16/03/2017 08:44, Tanu Hari Dixit wrote:
> Hello Chris, Gedare, Joel,
> Thank you for answering my questions. Sorry for the late reply, it
> took me time to go through the tasks suggested.
>>
>> What platforms have you run tester on?
>
> I was searching for a way to compile and execute a single test and the
> community suggetsed rtems-tester. So I ran the tester on sparc/erc32
> (and no simulator).
Great, this is what the tool is for.
> I am unable to find a relevant doc on how to run rtems-tester on qemu.
> Though there is this rtems-tools.git/tester/rtems/testing/qemu.cfg so
> I know that it is supported.
The `--list-bsps` gives some hints however not all BSPs that use qemu have this
in the test BSP name. After a waf configure and build try:
ruru rtems-tools.git $ pwd
/opt/work/chris/rtems/tools/rtems-tools.git
ruru rtems-tools.git $ ./tester/rtems-test --list-bsps | grep qemu
realview_pbx_a9_qemu
xilinx_zynq_a9_qemu
xilinx_zynq_a9_qemu_smp
xilinx_zynq_zc706_qemu
The low level and simplest way to currently see is:
ruru rtems-tools.git $ grep -r qemu.cfg tester/rtems
tester/rtems/testing/bsps/xilinx_zynq_a9_qemu.mc:xilinx_zynq_a9_qemu:
none,none, '%{_rtscripts}/qemu.cfg'
tester/rtems/testing/bsps/generic_or1k.mc:generic_or1k: none,none,
'%{_rtscripts}/qemu.cfg'
tester/rtems/testing/bsps/xilinx_zynq_zc706_qemu.mc:xilinx_zynq_zc706:
none,none, '%{_rtscripts}/qemu.cfg'
tester/rtems/testing/bsps/xilinx_zynq_a9_qemu_smp.mc:xilinx_zynq_a9_qemu:
none,none, '%{_rtscripts}/qemu.cfg'
tester/rtems/testing/bsps/realview_pbx_a9_qemu.mc:realview_pbx_a9_qemu:
none,none, '%{_rtscripts}/qemu.cfg'
It is not the best way but it does work :)
> Also I couldn't find any other hint in
> the rtems-tools repository as to which simulators (except for qemu)
> are supported. rtems-testing/sim-scripts support gdbsim, skyeye and
> tsim (other than qemu). So we can add support for these and gem5 (as
> Gedare suggested). Please correct me if I am wrong.
You will need to review each .cfg file we have and see what there is. I see
tsim is there.
> Furthermore, if you could please point me to a doc that explains using
> rtems-tester on qemu? I have tested qemu for running an application,
> the steps for which I have documented here
> (http://tokencolour.github.io/2017/03/16/how-to-run-applications-on-qemu-rtems.html).
I am not sure there is any doco. If you have built the RSB qemu which runs the
zynq and you have built the xilinx_zynq_a9_qemu BSP you should be able to do:
ruru xilinx_zynq_a9_qemu $ pwd
/opt/work/chris/rtems/kernel/bsps/xilinx_zynq_a9_qemu
ruru xilinx_zynq_a9_qemu $ rtems-test --report-mode=all
--rtems-bsp=xilinx_zynq_a9_qemu `find . -name hello.exe`
RTEMS Testing - Tester, 4.12.not_released
Command Line: /opt/work/rtems/4.12/bin/rtems-test --report-mode=all
--rtems-bsp=xilinx_zynq_a9_qemu
./arm-rtems4.12/c/xilinx_zynq_a9_qemu/testsuites/samples/hello/hello.exe
Python: 2.7.13 (default, Jan 12 2017, 01:19:30) [GCC 4.2.1 Compatible FreeBSD
Clang 3.8.0 (tags/RELEASE_380/final 262564)]
[1/1] p:0 f:0 t:0 i:0 | arm/xilinx_zynq_a9_qemu: hello.exe
[1/1] p:0 f:0 t:0 i:0 | arm/xilinx_zynq_a9_qemu: hello.exe
> run: qemu-system-arm -no-reboot -serial null -serial mon:stdio -nographic
> -net none -M xilinx-zynq-a9 -m 256M -kernel
> ./arm-rtems4.12/c/xilinx_zynq_a9_qemu/testsuites/samples/hello/hello.exe
] Warning: nic cadence_gem.0 has no peer
] Warning: nic cadence_gem.1 has no peer
]
]
] *** BEGIN OF TEST HELLO WORLD ***
] Hello World
] *** END OF TEST HELLO WORLD ***
Result: passed Time: 0:00:01.069137 hello.exe
Passed: 1
Failed: 0
Timeouts: 0
Invalid: 0
---
Total:1
Average test time: 0:00:01.526334
Testing time : 0:00:01.526334
> I can play with visualizing aggregated testing results with plotting
> techniques (like matplotlib or maybe something that the devs
> recommend) :).
I would prefer this not be part of rtems-test. I am happy to have rtems-test
generate report data in XML that can be used by other tools to generate visual
data. I also happy to see these other tools being developed as part of this
project if there is time and added to the RTEMS Tools Project if suitable, just
not part of the rtems-test tool.
A couple of points ...
The separation is done to avoid extra dependencies being added to the
rtems-test tool. Separating this type of functionality this way means the way
this data is used is up to the user and not the rtems-test tool. It also brings
the tool inline with the RSB which also exports XML reports.
Second, any tool to do this and added to the RTEMS Tool Project has to be fully
cross platform, which means FreeBSD, OSX, Windows and even Linux. If the tool
can be based on just standard Python libraries it will be cross platform and
preferred.
> Also, where can I find more about "expected fail" state? Is it for
> those tests that fail nevertheless and need to be skipped? Can you
> plea
