Re: Porting CANFestival to RTEMS

2015-08-27 Thread Isaac Gutekunst 

Thank you everyone for the information! It was very helpful!

I've gone ahead and made a port based on the AVR and Unix ports.

I adapted unix_timers.c and unix.c to use the RTEMS traditional API. So 
far everything appears to be working. I'll be cleaning it up and 
submitting a patch to CanFestival at some point.


I also created an "rtems" can driver port based on my unreleased RTEMS 
can API. I will be submitting a very rough version of that for review 
within a week or so.


I've also been having some trouble with RSB, but I'll save that for 
another email.



Isaac


On 08/24/2015 07:03 PM, Pavel Pisa wrote:

Hello Gedare,

On Friday 21 of August 2015 16:46:41 Gedare Bloom wrote:

I believe CANFestival comes from Pavel Pisa's group. He is active with
RTEMS and interested in pushing forward CAN improvements, but time is
always a problem. He's on vacation but may get to this thread after he
gets back.



no CANfestival is work of unrelated our university departmen
and my company work. I have only contributed minimal
LinCAN interfacing long time ago. Then even met CANfestival
developers on some conferences and spoken with them.
Some of my colleagues have used CANfestival on master
and slave side to build distributed control system
where code has been generated from Matlab/Simulink.
Some document and archive code of that project can be read
from lintarget site
http://lintarget.sourceforge.net/
but that CANfestival part has not be ported to actual version
of ert_linux Simulink support distribudet from Lintatget project.

So generally, I have some knowledge about CANfestival,
it has advantage that it is relatively simple and easy
to understood but I have not done much with it personally.

Our group CAN/CANopen work can be found in OrtCAN project

   http://ortcan.sourceforge.net/

but it tries to be dynamic and runtime configurable
and because we have contracts and demands in different
areas now - mostly automotive, we do not have resources
to push it much forward now.

But CANfestival is good choice for devices and basic
CANopen SDO communication state automata can be used
even for master which communicate with runtime configurable
structure of slaves. Similar state automata can be found
in OrtCAN VCA library as well and reused, but set is much
more complex.

Best wishes,

 Pavel



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

Trouble creating RSB Package: error copying tree

2015-08-27 Thread Isaac Gutekunst 

Hi Devel,

I've been working on porting CANFestival to RTEMS. I ended up creating 
some changes to CANFestival to allow it to be built against an RTEMS BSP.


All was going well except a strange ldconfig error, when I tried to fix 
it by removing the build directory (rtems_source_builder/rtems/build). 
Now I get the following error:


error: copying tree: 
/other/rtems/rtems-source-builder/rtems/build/tmp/canfestival-8bfe0ac00cdb-arm-rtems4.11-1-root-isaac.gutekunst 
-> 
/other/rtems/rtems-source-builder/rtems/build/tmp/sb-isaac.gutekunst/4.11/net/canfestival: 
[Errno 2] No such file or directory: 
'/other/rtems/rtems-source-builder/rtems/build/tmp/canfestival-8bfe0ac00cdb-arm-rtems4.11-1-root-isaac.gutekunst'


I tried re-building ntp, the package I based my bset and cfg files off 
of, and it doesn't build correctly, but gets much farther along.


Any idea what's going on ?

Thanks,

Isaac

--
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] RTEMS CAN Rough Draft Implementation

2015-08-27 Thread Isaac Gutekunst 

Hi All,

Here is the RTEMS CAN driver framework I've been talking about. Please 
give me feedback, and don't worry about being harsh. I want to commit 
something of value.



Concerns


* Usage of return codes.
* General higher level error handling.
* Changing can bit rate.
* In general, changing CAN parameters at runtime.
* Task model: Should there really be an RX and TX task required by the 
RTEMS driver? Is the method of starting and stopping tasks acceptable?


The motivation for this is that the CAN controller we are using, (STM32 
BxCAN) requires you to re-initialize the device to change parameters. 
This is a bit awkward with first calling open, and then IOCTL to 
configure the bus. Any thoughts?


Thanks,

Isaac


P.S. I'm having trouble with git send-email. Something is not quite 
right with our mail server here. I've attached the patch instead.


--
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com
>From a151795883f68dbff91d3044bbf8d629b4b6996f Mon Sep 17 00:00:00 2001
From: Isaac Gutekunst 
Date: Mon, 24 Aug 2015 09:45:27 -0400
Subject: [PATCH] cpukit: Create CAN Driver framework

---
 cpukit/dev/Makefile.am|   6 +
 cpukit/dev/can/can.c  | 510 ++
 cpukit/dev/include/dev/can/can-internal.h | 208 
 cpukit/dev/include/dev/can/can.h  |  86 +
 cpukit/dev/preinstall.am  |  13 +
 cpukit/score/cpu/arm/rtems/score/cpu.h|   2 +-
 6 files changed, 824 insertions(+), 1 deletion(-)
 create mode 100644 cpukit/dev/can/can.c
 create mode 100644 cpukit/dev/include/dev/can/can-internal.h
 create mode 100644 cpukit/dev/include/dev/can/can.h

diff --git a/cpukit/dev/Makefile.am b/cpukit/dev/Makefile.am
index 47a1585..cffcf25 100644
--- a/cpukit/dev/Makefile.am
+++ b/cpukit/dev/Makefile.am
@@ -11,6 +11,11 @@ include_dev_i2c_HEADERS += include/dev/i2c/gpio-nxp-pca9535.h
 include_dev_i2c_HEADERS += include/dev/i2c/i2c.h
 include_dev_i2c_HEADERS += include/dev/i2c/switch-nxp-pca9548a.h
 
+include_dev_candir = $(includedir)/dev/can
+include_dev_can_HEADERS =
+include_dev_can_HEADERS += include/dev/can/can.h
+include_dev_can_HEADERS += include/dev/can/can-internal.h
+
 include_linuxdir = $(includedir)/linux
 include_linux_HEADERS =
 include_linux_HEADERS += include/linux/i2c.h
@@ -24,6 +29,7 @@ libdev_a_SOURCES += i2c/gpio-nxp-pca9535.c
 libdev_a_SOURCES += i2c/i2c-bus.c
 libdev_a_SOURCES += i2c/i2c-dev.c
 libdev_a_SOURCES += i2c/switch-nxp-pca9548a.c
+libdev_a_SOURCES += can/can.c
 
 include $(srcdir)/preinstall.am
 include $(top_srcdir)/automake/local.am
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
new file mode 100644
index 000..2610498
--- /dev/null
+++ b/cpukit/dev/can/can.c
@@ -0,0 +1,510 @@
+/**
+ * @file can.c
+ *
+ * @ingroup can
+ * @brief Control Area Network  (can) Driver API
+ *
+ * @brief RTEMS can driver. Exposes a posix interface to the can bus
+ * similar to lincan.
+ *
+ */
+
+/*
+ * Copyright (c) 2015 Vecna Technologies, Inc.
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.com/license/LICENSE.
+ */
+
+
+#if HAVE_CONFIG_H
+  #include "config.h"
+#endif
+
+#include 
+
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CAN_QUEUE_LEN 10
+#define CAN_TASK_PRIORITY 70
+
+static bool free_busses[10] = {true};
+
+int get_free_bus_number(
+  void
+)
+{
+  int i;
+  for (i = 1; i < 10; i++) {
+if (true == free_busses[i]) {
+  free_busses[i] = false;
+  return i;
+}
+  }
+  return -1; 
+}
+
+void can_bus_obtain(can_bus *bus)
+{
+  rtems_status_code sc;
+
+  sc = rtems_semaphore_obtain(bus->mutex, RTEMS_WAIT, RTEMS_NO_TIMEOUT);
+  _Assert(sc == RTEMS_SUCCESSFUL);
+  (void) sc;
+}
+
+void can_bus_release(can_bus *bus)
+{
+  rtems_status_code sc;
+
+  sc = rtems_semaphore_release(bus->mutex);
+  _Assert(sc == RTEMS_SUCCESSFUL);
+  (void) sc;
+}
+
+int can_bus_change_baudrate(
+  can_bus * bus, 
+  uint32_t baud
+) 
+{
+  can_bus_obtain(bus);
+  bus->de_init(bus);
+  bus->init(bus, baud);
+  can_bus_release(bus);
+  return 0;
+}
+
+int can_bus_set_filter(
+  can_bus * bus, 
+  can_filter * filter
+) 
+{
+  int err;
+  _Assert(filter);
+  can_bus_obtain(bus);
+  err =  bus->set_filter(bus, filter);
+  can_bus_release(bus);
+  return err;
+}
+
+
+int can_bus_init_default(
+  can_bus * bus,
+  long baud
+)
+{
+  (void) bus;
+  (void) baud;
+  return 0;
+  return -EIO;
+}
+
+int can_bus_de_init_default(
+  can_bus * bus
+)
+{
+  (void) bus;
+  return -EIO;
+}
+
+int can_bus_set_filter_default(  
+  can_bus * bus,
+  can_filter * filter
+)
+{
+  (void) bus;
+  (void) filter;
+  return -EIO;
+}
+int can_bus_get_num_filters_default(  
+  can_bus * bus
+)
+{
+  (void) bus;
+  return -EIO;
+}
+
+int can_bus_transfer(can_bus *bus, can_msg *msgs, uint32_t msg_count)
+{
+  int err;
+
+  _Assert(msg_count > 0);
+  
+  // error c

ARMv7M Exception Handler

2015-08-27 Thread sudarshan.rajagopalan 

Hey guys,

I was working on the exception handler for the CPU hard fault. Managed 
to register the fatal error user extension to RTEMS and call the user 
defined function when an exception occurs. But the pointer to the 
stacked frame didn't have the correct register values(esp. the PC 
register). So I looked into the assembly code in 
/cpukit/score/cpu/arm/armv7m-exception-default.c, where it decides which 
stack pointer was used (MSP or PSP) before the exception occurred 
depending on the error code returned in the Link Register. After 
carefully examining all the assembly instructions, I guess theres a 
little bug in the code.


The instruction "cmn r2, #3\n" in line 31 basically compares the Link 
Register(lr) to value 0xFFFD (negative #3, because CMN negates the 
RHS and compares with LHS) and chooses MSP or PSP in the following IT 
block. This is pretty cool! But, it will not work if you have the 
floating-point unit (FPU) enabled in your processor, which is enabled in 
mine. With FPU enabled, the error code returned is either 0xFFE9 or 
0xFFED, for which the above assembly instruction will not work out 
and MSP will be selected always.


Better way to do is to check the 2nd bit of the error code to determine 
which stack pointer was used before the exception happened - "tst lr, 
#4\n" and change the IT block from "itt ne" to "itt eq" and the "mov" 
and "add" within this IT block.


Have tested this with the above changes and it works. I have sent the 
patch "0001-Fix-exception-handler-for-supporting-FPU.patch" to the devel 
mailing list that fixes this problem. :)


Thanks and Regards,
Sudarshan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Fix exception handler for supporting FPU

2015-08-27 Thread sudarshan.rajagopalan 
 

Patch attached here for ARMv7M Exception Handler. [1] Looks like git
send-email didn't deliver the mail. Something is not quite right with
our mail server here. Avoid this email if patch delivered through git. 

Thanks and Regards, 

Sudarshan 

 

Links:
--
[1] https://lists.rtems.org/pipermail/devel/2015-August/012381.html
From e7674a2c26a3db26e3019f3c6ee94c9ea88d5a3c Mon Sep 17 00:00:00 2001
From: Sudarshan Rajagopalan 
Date: Thu, 27 Aug 2015 14:19:24 -0400
Subject: [PATCH] Fix exception handler for supporting FPU

---
 cpukit/score/cpu/arm/armv7m-exception-default.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/cpukit/score/cpu/arm/armv7m-exception-default.c 
b/cpukit/score/cpu/arm/armv7m-exception-default.c
index e890cdf..2ddc6fc 100644
--- a/cpukit/score/cpu/arm/armv7m-exception-default.c
+++ b/cpukit/score/cpu/arm/armv7m-exception-default.c
@@ -28,10 +28,10 @@ void __attribute__((naked)) _ARMV7M_Exception_default( void 
)
 "mov r2, lr\n"
 "mrs r1, msp\n"
 "mrs r0, psp\n"
-"cmn r2, #3\n"
-"itt ne\n"
-"movne r0, r1\n"
-"addne r0, %[cpufsz]\n"
+"tst lr, #4\n"
+"itt eq\n"
+"moveq r0, r1\n"
+"addeq r0, %[cpufsz]\n"
 "add r2, r0, %[v7mlroff]\n"
 "add r1, sp, %[cpulroff]\n"
 "ldm r2, {r3-r5}\n"
-- 
1.9.1

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

Re: ARMv7M Exception Handler

2015-08-27 Thread Daniel Gutson 
On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan
 wrote:
> Hey guys,
>
> I was working on the exception handler for the CPU hard fault. Managed to
> register the fatal error user extension to RTEMS and call the user defined
> function when an exception occurs. But the pointer to the stacked frame
> didn't have the correct register values(esp. the PC register). So I looked
> into the assembly code in /cpukit/score/cpu/arm/armv7m-exception-default.c,
> where it decides which stack pointer was used (MSP or PSP) before the
> exception occurred depending on the error code returned in the Link
> Register. After carefully examining all the assembly instructions, I guess
> theres a little bug in the code.
>
> The instruction "cmn r2, #3\n" in line 31 basically compares the Link
> Register(lr) to value 0xFFFD (negative #3, because CMN negates the RHS
> and compares with LHS) and chooses MSP or PSP in the following IT block.
> This is pretty cool! But, it will not work if you have the floating-point
> unit (FPU) enabled in your processor, which is enabled in mine. With FPU
> enabled, the error code returned is either 0xFFE9 or 0xFFED, for
> which the above assembly instruction will not work out and MSP will be
> selected always.
>
> Better way to do is to check the 2nd bit of the error code to determine
> which stack pointer was used before the exception happened - "tst lr, #4\n"
> and change the IT block from "itt ne" to "itt eq" and the "mov" and "add"
> within this IT block.
>
> Have tested this with the above changes and it works. I have sent the patch
> "0001-Fix-exception-handler-for-supporting-FPU.patch" to the devel mailing
> list that fixes this problem. :)

Nice. Have you tested this without FPU support too?

>
> Thanks and Regards,
> Sudarshan
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: ARMv7M Exception Handler

2015-08-27 Thread Joel Sherrill 



On 8/27/2015 3:58 PM, Daniel Gutson wrote:

On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan
 wrote:

Hey guys,

I was working on the exception handler for the CPU hard fault. Managed to
register the fatal error user extension to RTEMS and call the user defined
function when an exception occurs. But the pointer to the stacked frame
didn't have the correct register values(esp. the PC register). So I looked
into the assembly code in /cpukit/score/cpu/arm/armv7m-exception-default.c,
where it decides which stack pointer was used (MSP or PSP) before the
exception occurred depending on the error code returned in the Link
Register. After carefully examining all the assembly instructions, I guess
theres a little bug in the code.

The instruction "cmn r2, #3\n" in line 31 basically compares the Link
Register(lr) to value 0xFFFD (negative #3, because CMN negates the RHS
and compares with LHS) and chooses MSP or PSP in the following IT block.
This is pretty cool! But, it will not work if you have the floating-point
unit (FPU) enabled in your processor, which is enabled in mine. With FPU
enabled, the error code returned is either 0xFFE9 or 0xFFED, for
which the above assembly instruction will not work out and MSP will be
selected always.

Better way to do is to check the 2nd bit of the error code to determine
which stack pointer was used before the exception happened - "tst lr, #4\n"
and change the IT block from "itt ne" to "itt eq" and the "mov" and "add"
within this IT block.

Have tested this with the above changes and it works. I have sent the patch
"0001-Fix-exception-handler-for-supporting-FPU.patch" to the devel mailing
list that fixes this problem. :)


Nice. Have you tested this without FPU support too?


Daniel .. when you are happy, we can push it.

Should this go on the 4.11 branch and master? If so, it needs a ticket.


Thanks and Regards,
Sudarshan
___
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: cppcheck errors

2015-08-27 Thread Joel Sherrill 



On 8/13/2015 10:52 AM, Daniel Gutson wrote:


El 13/8/2015 12:49, "Gedare Bloom" mailto:ged...@gwu.edu>> 
escribió:
 >
 > Daniel,
 >
 > Unknown deadline right now. Probably whenever Joel can get around to
 > it! Realistically, we can create a bugfix "dot release" anytime after
 > the release subject to user demand. So, even if you miss the 4.11.0
 > release with your patches, we can cut a 4.11.1 after applying the
 > patches if you need an official release to work from.

Ok. Yes, we do.

Thanks. Anyway we're making a ranking for a timebox of 2 weeks.


Any updates?


 > Gedare
 >
 > On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson
 > mailto:daniel.gut...@tallertechnologies.com>> wrote:
 > > Hi Gedare,
 > >
 > > What's the deadline for the official release, if any?
 > >
 > > El 13/8/2015 7:15, "Gedare Bloom" mailto:ged...@gwu.edu>> 
escribió:
 > >>
 > >> Daniel,
 > >>
 > >> The release has (unofficially) happened on rtems.git/4.11 branch, from
 > >> which master is slowly diverging. Any patches you want applied before
 > >> the official release need to be (1) associated with a ticket on Trac,
 > >> and (2) apply to both the 4.11 and master branches.
 > >>
 > >> Gedare
 > >>
 > >> On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson
 > >> mailto:daniel.gut...@tallertechnologies.com>> wrote:
 > >> > Hi guys,
 > >> >
 > >> >   we will be posting patches for a number of errors reported by
 > >> > cppcheck (errors that we can confirm are not false positives).
 > >> > Please hold on any release.
 > >> >
 > >> >Daniel.
 > >> >
 > >> > --
 > >> >
 > >> > Daniel F. Gutson
 > >> > Chief Engineering Officer, SPD
 > >> >
 > >> > San Lorenzo 47, 3rd Floor, Office 5
 > >> > Córdoba, Argentina
 > >> >
 > >> > Phone:   +54 351 4217888 / +54 351 4218211
 > >> > Skype:dgutson
 > >> > LinkedIn: http://ar.linkedin.com/in/danielgutson
 > >> > ___
 > >> > 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: cppcheck errors

2015-08-27 Thread Daniel Gutson 
On Thu, Aug 27, 2015 at 6:06 PM, Joel Sherrill
 wrote:
>
>
> On 8/13/2015 10:52 AM, Daniel Gutson wrote:
>>
>>
>> El 13/8/2015 12:49, "Gedare Bloom" > > escribió:
>>  >
>>  > Daniel,
>>  >
>>  > Unknown deadline right now. Probably whenever Joel can get around to
>>  > it! Realistically, we can create a bugfix "dot release" anytime after
>>  > the release subject to user demand. So, even if you miss the 4.11.0
>>  > release with your patches, we can cut a 4.11.1 after applying the
>>  > patches if you need an official release to work from.
>>
>> Ok. Yes, we do.
>>
>> Thanks. Anyway we're making a ranking for a timebox of 2 weeks.
>
>
> Any updates?

Sorry guys, we have a release tomorrow (which contains some of the top
fixes) but didn't have the time
to send a patch. We will send it early next week.
FWIW, nios had memory leaks but since we are not using that arch we skipped it.
Maybe we can just provide the list until we provide the fixes? Martín?

>
>>  > Gedare
>>  >
>>  > On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson
>>  > > > wrote:
>>  > > Hi Gedare,
>>  > >
>>  > > What's the deadline for the official release, if any?
>>  > >
>>  > > El 13/8/2015 7:15, "Gedare Bloom" > > escribió:
>>  > >>
>>  > >> Daniel,
>>  > >>
>>  > >> The release has (unofficially) happened on rtems.git/4.11 branch,
>> from
>>  > >> which master is slowly diverging. Any patches you want applied
>> before
>>  > >> the official release need to be (1) associated with a ticket on
>> Trac,
>>  > >> and (2) apply to both the 4.11 and master branches.
>>  > >>
>>  > >> Gedare
>>  > >>
>>  > >> On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson
>>  > >> > > wrote:
>>  > >> > Hi guys,
>>  > >> >
>>  > >> >   we will be posting patches for a number of errors reported by
>>  > >> > cppcheck (errors that we can confirm are not false positives).
>>  > >> > Please hold on any release.
>>  > >> >
>>  > >> >Daniel.
>>  > >> >
>>  > >> > --
>>  > >> >
>>  > >> > Daniel F. Gutson
>>  > >> > Chief Engineering Officer, SPD
>>  > >> >
>>  > >> > San Lorenzo 47, 3rd Floor, Office 5
>>  > >> > Córdoba, Argentina
>>  > >> >
>>  > >> > Phone:   +54 351 4217888 / +54 351 4218211
>>  > >> > Skype:dgutson
>>  > >> > LinkedIn: http://ar.linkedin.com/in/danielgutson
>>  > >> > ___
>>  > >> > 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



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: cppcheck errors

2015-08-27 Thread Martin Galvan 
On Thu, Aug 27, 2015 at 6:10 PM, Daniel Gutson
 wrote:
> Maybe we can just provide the list until we provide the fixes? Martín?

Gladly. Keep in mind we ran cppcheck only on the modules we use
(though some things may've slipped in, like nios):

[c/src/lib/libbsp/shared/umon/umon.h:21]: (error) Invalid number of
character ({) when these macros are defined: '__cplusplus'.
[cpukit/libmisc/dumpbuf/dumpbuf.c:69]: (error) Undefined behavior:
Variable 'line_buffer' is used as parameter and destination in
s[n]printf().
[cpukit/libmisc/dumpbuf/dumpbuf.c:76]: (error) Undefined behavior:
Variable 'line_buffer' is used as parameter and destination in
s[n]printf().
[cpukit/libmisc/stackchk/check.c:285] ->
[cpukit/libmisc/stackchk/check.c:294]: (performance) Variable
'pattern_ok' is reassigned a value before the old one has been used.
[cpukit/libmisc/stackchk/check.c:255]: (portability) 'pattern_area' is
of type 'void *'. When using void pointers in calculations, the
behaviour is undefined.
[cpukit/libnetworking/kern/kern_subr.c:93]: (portability) 'cp' is of
type 'void *'. When using void pointers in calculations, the behaviour
is undefined.
[cpukit/libnetworking/kern/uipc_socket2.c:616]: (error) Uninitialized
variable: o
[cpukit/libnetworking/lib/ftpfs.c:704] ->
[cpukit/libnetworking/lib/ftpfs.c:709]: (performance) Variable
'port_socket' is reassigned a value before the old one has been used.
[cpukit/libnetworking/lib/tftpDriver.c:503]: (error) Common realloc
mistake: 'current' nulled but not freed upon failure
[cpukit/libnetworking/libc/ether_addr.c:72]: (portability) scanf
without field width limits can crash with huge input data on some
versions of libc.
[cpukit/libnetworking/libc/ether_addr.c:94]: (portability) scanf
without field width limits can crash with huge input data on some
versions of libc.
[cpukit/libnetworking/libc/gethostbyht.c:233]: (error) Common realloc
mistake: 'hostmap' nulled but not freed upon failure
[cpukit/libnetworking/libc/ns_addr.c:112]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:120]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:128]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:137]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/rtems/rtems_dhcp.c:401]: (error) Common realloc
mistake: 'dhcp_hostname' nulled but not freed upon failure
[cpukit/librpc/src/rpc/netnamer.c:331]: (error) Resource leak: fd
[cpukit/posix/include/rtems/posix/ptimer.h:33]: (error) Invalid number
of character ({) when these macros are defined: '__cplusplus'.
[cpukit/rtems/include/rtems/rtems/dpmemimpl.h:116]: (error) Invalid
number of character ({) when these macros are defined: '__cplusplus'.
[cpukit/score/cpu/h8300/cpu.c:54]: (error) Uninitialized variable:
_ccr (si no se inicializa, se hace un #warning pero igual existe el
problema)
[cpukit/zlib/gzwrite.c:80]: (error) Uninitialized variable: got
[tools/build/binpatch.c:104]: (error) Resource leak: ifp
[tools/build/binpatch.c:63]: (error) Uninitialized variable: off
[tools/build/unhex.c:238]: (error) Resource leak: outfp
[tools/cpu/nios2/memory.c:99]: (error) Uninitialized variable: memory
[tools/cpu/nios2/ptf.c:542]: (error) fprintf format string has 1
parameters but only 0 are given.
[tools/cpu/nios2/ptf.c:580]: (error) Memory leak: new_prefix
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: cppcheck errors

2015-08-27 Thread Daniel Gutson 
Please note too that there are some false positives, like the realloc one.

On Thu, Aug 27, 2015 at 6:15 PM, Martin Galvan
 wrote:
> On Thu, Aug 27, 2015 at 6:10 PM, Daniel Gutson
>  wrote:
>> Maybe we can just provide the list until we provide the fixes? Martín?
>
> Gladly. Keep in mind we ran cppcheck only on the modules we use
> (though some things may've slipped in, like nios):
>
> [c/src/lib/libbsp/shared/umon/umon.h:21]: (error) Invalid number of
> character ({) when these macros are defined: '__cplusplus'.
> [cpukit/libmisc/dumpbuf/dumpbuf.c:69]: (error) Undefined behavior:
> Variable 'line_buffer' is used as parameter and destination in
> s[n]printf().
> [cpukit/libmisc/dumpbuf/dumpbuf.c:76]: (error) Undefined behavior:
> Variable 'line_buffer' is used as parameter and destination in
> s[n]printf().
> [cpukit/libmisc/stackchk/check.c:285] ->
> [cpukit/libmisc/stackchk/check.c:294]: (performance) Variable
> 'pattern_ok' is reassigned a value before the old one has been used.
> [cpukit/libmisc/stackchk/check.c:255]: (portability) 'pattern_area' is
> of type 'void *'. When using void pointers in calculations, the
> behaviour is undefined.
> [cpukit/libnetworking/kern/kern_subr.c:93]: (portability) 'cp' is of
> type 'void *'. When using void pointers in calculations, the behaviour
> is undefined.
> [cpukit/libnetworking/kern/uipc_socket2.c:616]: (error) Uninitialized
> variable: o
> [cpukit/libnetworking/lib/ftpfs.c:704] ->
> [cpukit/libnetworking/lib/ftpfs.c:709]: (performance) Variable
> 'port_socket' is reassigned a value before the old one has been used.
> [cpukit/libnetworking/lib/tftpDriver.c:503]: (error) Common realloc
> mistake: 'current' nulled but not freed upon failure
> [cpukit/libnetworking/libc/ether_addr.c:72]: (portability) scanf
> without field width limits can crash with huge input data on some
> versions of libc.
> [cpukit/libnetworking/libc/ether_addr.c:94]: (portability) scanf
> without field width limits can crash with huge input data on some
> versions of libc.
> [cpukit/libnetworking/libc/gethostbyht.c:233]: (error) Common realloc
> mistake: 'hostmap' nulled but not freed upon failure
> [cpukit/libnetworking/libc/ns_addr.c:112]: (portability) scanf without
> field width limits can crash with huge input data on some versions of
> libc.
> [cpukit/libnetworking/libc/ns_addr.c:120]: (portability) scanf without
> field width limits can crash with huge input data on some versions of
> libc.
> [cpukit/libnetworking/libc/ns_addr.c:128]: (portability) scanf without
> field width limits can crash with huge input data on some versions of
> libc.
> [cpukit/libnetworking/libc/ns_addr.c:137]: (portability) scanf without
> field width limits can crash with huge input data on some versions of
> libc.
> [cpukit/libnetworking/rtems/rtems_dhcp.c:401]: (error) Common realloc
> mistake: 'dhcp_hostname' nulled but not freed upon failure
> [cpukit/librpc/src/rpc/netnamer.c:331]: (error) Resource leak: fd
> [cpukit/posix/include/rtems/posix/ptimer.h:33]: (error) Invalid number
> of character ({) when these macros are defined: '__cplusplus'.
> [cpukit/rtems/include/rtems/rtems/dpmemimpl.h:116]: (error) Invalid
> number of character ({) when these macros are defined: '__cplusplus'.
> [cpukit/score/cpu/h8300/cpu.c:54]: (error) Uninitialized variable:
> _ccr (si no se inicializa, se hace un #warning pero igual existe el
> problema)
> [cpukit/zlib/gzwrite.c:80]: (error) Uninitialized variable: got
> [tools/build/binpatch.c:104]: (error) Resource leak: ifp
> [tools/build/binpatch.c:63]: (error) Uninitialized variable: off
> [tools/build/unhex.c:238]: (error) Resource leak: outfp
> [tools/cpu/nios2/memory.c:99]: (error) Uninitialized variable: memory
> [tools/cpu/nios2/ptf.c:542]: (error) fprintf format string has 1
> parameters but only 0 are given.
> [tools/cpu/nios2/ptf.c:580]: (error) Memory leak: new_prefix



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: cppcheck errors

2015-08-27 Thread Martin Galvan 
On Thu, Aug 27, 2015 at 6:19 PM, Daniel Gutson
 wrote:
> Please note too that there are some false positives, like the realloc one.

Actually, we ruled out most false positives. IIRC that one is an actual bug.

Btw, sorry for the Spanish comment there. It means that if we don't
initialize _ccr we just get a #warning, but the actual problem
remains.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: cppcheck errors

2015-08-27 Thread Joel Sherrill 



On 8/27/2015 4:10 PM, Daniel Gutson wrote:

On Thu, Aug 27, 2015 at 6:06 PM, Joel Sherrill
 wrote:



On 8/13/2015 10:52 AM, Daniel Gutson wrote:



El 13/8/2015 12:49, "Gedare Bloom" mailto:ged...@gwu.edu>> escribió:
  >
  > Daniel,
  >
  > Unknown deadline right now. Probably whenever Joel can get around to
  > it! Realistically, we can create a bugfix "dot release" anytime after
  > the release subject to user demand. So, even if you miss the 4.11.0
  > release with your patches, we can cut a 4.11.1 after applying the
  > patches if you need an official release to work from.

Ok. Yes, we do.

Thanks. Anyway we're making a ranking for a timebox of 2 weeks.



Any updates?


Sorry guys, we have a release tomorrow (which contains some of the top
fixes) but didn't have the time
to send a patch. We will send it early next week.
FWIW, nios had memory leaks but since we are not using that arch we skipped it.
Maybe we can just provide the list until we provide the fixes? Martín?


Both Sebastian and Chris are on holiday this week so there is no
reason to rush. Posting a list of issues would be good but it may
have to be pinged when they are back on line.

I know Chris has experience with the NIOS so he will want to review
those.

--joel


  > Gedare
  >
  > On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson
  > mailto:daniel.gut...@tallertechnologies.com>> wrote:
  > > Hi Gedare,
  > >
  > > What's the deadline for the official release, if any?
  > >
  > > El 13/8/2015 7:15, "Gedare Bloom" mailto:ged...@gwu.edu>> escribió:
  > >>
  > >> Daniel,
  > >>
  > >> The release has (unofficially) happened on rtems.git/4.11 branch,
from
  > >> which master is slowly diverging. Any patches you want applied
before
  > >> the official release need to be (1) associated with a ticket on
Trac,
  > >> and (2) apply to both the 4.11 and master branches.
  > >>
  > >> Gedare
  > >>
  > >> On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson
  > >> mailto:daniel.gut...@tallertechnologies.com>> wrote:
  > >> > Hi guys,
  > >> >
  > >> >   we will be posting patches for a number of errors reported by
  > >> > cppcheck (errors that we can confirm are not false positives).
  > >> > Please hold on any release.
  > >> >
  > >> >Daniel.
  > >> >
  > >> > --
  > >> >
  > >> > Daniel F. Gutson
  > >> > Chief Engineering Officer, SPD
  > >> >
  > >> > San Lorenzo 47, 3rd Floor, Office 5
  > >> > Córdoba, Argentina
  > >> >
  > >> > Phone:   +54 351 4217888 / +54 351 4218211
  > >> > Skype:dgutson
  > >> > LinkedIn: http://ar.linkedin.com/in/danielgutson
  > >> > ___
  > >> > 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






--
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: cppcheck errors

2015-08-27 Thread Joel Sherrill 



On 8/27/2015 4:15 PM, Martin Galvan wrote:

On Thu, Aug 27, 2015 at 6:10 PM, Daniel Gutson
 wrote:

Maybe we can just provide the list until we provide the fixes? Martín?


Gladly. Keep in mind we ran cppcheck only on the modules we use
(though some things may've slipped in, like nios):


Most of these are worth looking at. Honestly, the ones on the tcp/ip
stack and other directly imported code aren't going to get touched.


[c/src/lib/libbsp/shared/umon/umon.h:21]: (error) Invalid number of
character ({) when these macros are defined: '__cplusplus'.


Spot check shows this is missing the closing magic for extern "C".
I see a couple more of these below and we should fix though.


[cpukit/libmisc/dumpbuf/dumpbuf.c:69]: (error) Undefined behavior:
Variable 'line_buffer' is used as parameter and destination in
s[n]printf().
[cpukit/libmisc/dumpbuf/dumpbuf.c:76]: (error) Undefined behavior:
Variable 'line_buffer' is used as parameter and destination in
s[n]printf().


This should be looked at.


[cpukit/libmisc/stackchk/check.c:285] ->
[cpukit/libmisc/stackchk/check.c:294]: (performance) Variable
'pattern_ok' is reassigned a value before the old one has been used.


This should be looked at.


[cpukit/libmisc/stackchk/check.c:255]: (portability) 'pattern_area' is
of type 'void *'. When using void pointers in calculations, the
behaviour is undefined.


Not sure what to do about this. I think this is defined behavior
for at least GCC.


[cpukit/libnetworking/kern/kern_subr.c:93]: (portability) 'cp' is of
type 'void *'. When using void pointers in calculations, the behaviour
is undefined.
[cpukit/libnetworking/kern/uipc_socket2.c:616]: (error) Uninitialized
variable: o


Imported code.


[cpukit/libnetworking/lib/ftpfs.c:704] ->
[cpukit/libnetworking/lib/ftpfs.c:709]: (performance) Variable
'port_socket' is reassigned a value before the old one has been used.
[cpukit/libnetworking/lib/tftpDriver.c:503]: (error) Common realloc
mistake: 'current' nulled but not freed upon failure


Need to be looked at.


[cpukit/libnetworking/libc/ether_addr.c:72]: (portability) scanf
without field width limits can crash with huge input data on some
versions of libc.
[cpukit/libnetworking/libc/ether_addr.c:94]: (portability) scanf
without field width limits can crash with huge input data on some
versions of libc.
[cpukit/libnetworking/libc/gethostbyht.c:233]: (error) Common realloc
mistake: 'hostmap' nulled but not freed upon failure
[cpukit/libnetworking/libc/ns_addr.c:112]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:120]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:128]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:137]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.


All imported code. maybe the realloc() is worth addressing.


[cpukit/libnetworking/rtems/rtems_dhcp.c:401]: (error) Common realloc
mistake: 'dhcp_hostname' nulled but not freed upon failure


This is the only one in our code.


[cpukit/librpc/src/rpc/netnamer.c:331]: (error) Resource leak: fd


Probably should be looked at.


[cpukit/posix/include/rtems/posix/ptimer.h:33]: (error) Invalid number
of character ({) when these macros are defined: '__cplusplus'.
[cpukit/rtems/include/rtems/rtems/dpmemimpl.h:116]: (error) Invalid
number of character ({) when these macros are defined: '__cplusplus'.


Easy.


[cpukit/score/cpu/h8300/cpu.c:54]: (error) Uninitialized variable:
_ccr (si no se inicializa, se hace un #warning pero igual existe el
problema)


Appears to be confused by conditional or inline asm.


[cpukit/zlib/gzwrite.c:80]: (error) Uninitialized variable: got


Hmm.. but third party code.


[tools/build/binpatch.c:104]: (error) Resource leak: ifp
[tools/build/binpatch.c:63]: (error) Uninitialized variable: off
[tools/build/unhex.c:238]: (error) Resource leak: outfp


Need to be looked at but these are host side utilities. There is likely
no resource leak since it is a process. The unitialized variable needs
looking at. We fixed a number of issues flagged by CodeSonar in these
last year.


[tools/cpu/nios2/memory.c:99]: (error) Uninitialized variable: memory
[tools/cpu/nios2/ptf.c:542]: (error) fprintf format string has 1
parameters but only 0 are given.
[tools/cpu/nios2/ptf.c:580]: (error) Memory leak: new_prefix



Those worth a look. But again a host-side utility.

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

obsolete h8300 was Re: cppcheck errors

2015-08-27 Thread Joel Sherrill 



On 8/27/2015 4:22 PM, Martin Galvan wrote:

On Thu, Aug 27, 2015 at 6:19 PM, Daniel Gutson
 wrote:

Please note too that there are some false positives, like the realloc one.


Actually, we ruled out most false positives. IIRC that one is an actual bug.

Btw, sorry for the Spanish comment there. It means that if we don't
initialize _ccr we just get a #warning, but the actual problem
remains.



The h8 port is up for discussion to be deprecated. As best I can
tell most, if not all, of the models we support are not recommended
for new designs. I think the entire h8300 family is in that situation.

The h8sx and h8s are the only viable parts of the family left.

I wanted to start deprecation discussions now that we are past
branching 4.11. :)

My intention would be to announce ports and BSPs as deprecated in
4.11 and remove them from the master to reduce our work going
forward.

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

obsolete m32r port

2015-08-27 Thread Joel Sherrill 

Hi

Another one on my chopping block. I don't see the official
not recommended for new designs language but I also don't
seen much hinting an update in five years either.

http://am.renesas.com/products/mpumcu/m32r/index.jsp

Anyone got any thoughts about it being a part that is still
being sold and we should support it?

Again, mark it as deprecated in the 4.11 notes and remove it
on master if no one objects.

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