headers
Ilija Kocho | 10 Jul 2011 22:38
Picon

Re: Eagle 100 (Stellaris LM3S6918)

Hi  all

I am solving similar problems in a course of porting eCos to Kinetis so
I would discuss / propose some ways for CDL management of a large
controller family.

1. Part naming management

Dealing with big number of (similar) parts can be simplified for both
programmer and user, if device selector menu instead being a single
cdl_option, is broken in a number of cdl_options (grouped in
cdl_component). User will select chip features (or name segments) and
build a part.

2. Memory layout and feature management

2.1 Every option from cdl_component described in 1., if needed, can be
used in either CDL or C code as parameters, switches, etc.

2.2 Some of selected features can be further used to resolve memory
layout issues.
      - file name segments such as MLT files
      - defines for memory size and layout

You can find sources at
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001187
( component CYGHWR_HAL_CORTEXM_KINETIS in hal_cortexm_kinetis.cdl ).

3. Further considerations
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christophe Coutand | 12 Jul 2011 10:53

RE: Eagle 100 (Stellaris LM3S6918)

Hi Ilija,

1. Ideally as a user I prefer to select the device from a menu and get all the characteristics propagated from
the selection. The CDL could have a component 
"Device characteristics" that lists all the peripherals included for the selected device, with internal
memory size etc..). For a family with large number 
of sub-variants it can be a tedious work to write the CDL. To mitigate it in the lm3s HAL, some of the work is
done in .h file (to select the peripherals for instance). 
The drawback is that it is no longer available from the configuration GUI therefore not visible to the users
and also developers at first glance. If a common solution should be approved, I hope it will not add too much
extra effort when developing a new port.

3. If none of the device can have external memory it makes sense to have the layout included in the variant HAL
otherwise I am not sure it is worth the effort.

Regards,
Christophe

> -----Original Message-----
> From: ecos-devel-owner <at> ecos.sourceware.org [mailto:ecos-devel-
> owner <at> ecos.sourceware.org] On Behalf Of Ilija Kocho
> Sent: 10. juli 2011 22:39
> To: ecos-devel <at> ecos.sourceware.org
> Subject: Re: Eagle 100 (Stellaris LM3S6918)
> 
> Hi  all
> 
> I am solving similar problems in a course of porting eCos to Kinetis so
> I would discuss / propose some ways for CDL management of a large
> controller family.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ilija Kocho | 13 Jul 2011 16:51
Picon

Re: Eagle 100 (Stellaris LM3S6918)

HI Christophe

Thank you for comments.

On 12.07.2011 10:53, Christophe Coutand wrote:
> Hi Ilija,
>
> 1. Ideally as a user I prefer to select the device from a menu and get all the characteristics propagated
from the selection.

Menu may get veery big if you have hundreds (or even tens) of devices.
But if there's a system in naming you can use it in order to break the
menu in several small menus. But I saw Stellaris device portfolio and
now I think I understand you better...

>  The CDL could have a component 
> "Device characteristics" that lists all the peripherals included for the selected device, with
internal memory size etc..). For a family with large number 
> of sub-variants it can be a tedious work to write the CDL.

Indeed, it can be challenging, but usually they all have a subset of a
same set of peripherals.
However there may be other reason to break them in several variants. For
instance memory size. Tiny devices (RAM <= 16KiB) like one you have
contributed recently may need different set-up than ones with larger
memory (RAM >= 32KiB). Also address different users.

>  To mitigate it in the lm3s HAL, some of the work is done in .h file (to select the peripherals for instance). 
> The drawback is that it is no longer available from the configuration GUI therefore not visible to the
users and also developers at first glance. If a common solution should be approved, I hope it will not add
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ilija Kocho | 19 Jul 2011 09:24
Picon

Single precision math library, porting to eCos.

Hello colleagues

We are working on a port of Newlib's single precision math library
/float/ type functions/. We are going to contribute the port, so we
would like to know if there is interest to incorporate it into main eCos
tree.

Rartionale: Some recent/upcoming architectures such as Cortex-M4,
Cortex-R, MPC 55xx can execute single precision floating point in
hardware. This is also recognised by GCC, for instance GCC 4.6 can
generate /-mhard-float/ code for Cortex-M4.

Regards

Ilija Kocho, manager
SIvA doo
http://www.siva.mk
Permalink | Reply | 2 comments |
headers
Visar Zejnullahu | 25 Jul 2011 13:29
Picon

Testing newlib

Hi.

As announced here:
http://sourceware.org/ml/ecos-devel/2011-07/msg00003.html we are working
on a port of Newlib's single precision floating point math library
(float vs double...).

I know part of the questions should be addressed to the Newlib's mailing
list (which I have done as well), but I am asking help on the Ecos part
of the problems.

We've reached the testing phase of the single precision functions.
First, I have noticed the tests provided in Ecos are different from
those of Newlib's. Can anyone tell how are the test cases chosen? As one
can notice, the test cases in Ecos are random, but are they randomly
chosen over some interval that is "critical" for some specific function
(i.e. some interval in which the specific function might return some
value that differs from the value it should return, that is, in this
interval the function might be erroneous). On the other hand, the test
cases in Newlib are from the interval [-1.2;1.19] with step 0.01, and
some other test cases that do not exceed the interval [-30;30].

Second, I have noticed, there are no tests provided in the
current/tests/vectors directory (where all tests for the corresponding
functions are) for these functions: acosh, atanh, gamma functions,
hypot, Bessel functions, remainder, scalb, asinh, cbrt, copysign, error
function, expm1, finite, ilogb, isnan, log1p, nextafter, rint, scalbn
and significand (I am talking about the standard
double-receiving-and-returning functions, not their float counterparts
we are working on). From these functions. I could not find tests on the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sergei Gavrikov | 25 Jul 2011 19:44
Picon

Re: Single precision math library, porting to eCos.

On Tue, 19 Jul 2011, Ilija Kocho wrote:

> Hello colleagues

Hello Ilija,

my $0.02.

> We are working on a port of Newlib's single precision math library
> /float/ type functions/. We are going to contribute the port, so we
> would like to know if there is interest to incorporate it into main
> eCos tree.

It's very excited and honour task. But, AFAIK, eCos libm are based on
Free Domain Libm fdlibm 5.X (5.2?). The *fdlibm* is a part of netlib
software collection, the references:

http://www.netlib.org/
http://www.netlib.org/fdlibm/

and it (fdlibm) is labeled as

C math library for machines that support IEEE 754 floating-point

> Rartionale: Some recent/upcoming architectures such as Cortex-M4,
> Cortex-R, MPC 55xx can execute single precision floating point in
> hardware. This is also recognised by GCC, for instance GCC 4.6 can
> generate /-mhard-float/ code for Cortex-M4.

Good point.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sergei Gavrikov | 25 Jul 2011 20:01
Picon

Re: Testing newlib

On Mon, 25 Jul 2011, Visar Zejnullahu wrote:

> Hi.
> 
> As announced here:
> http://sourceware.org/ml/ecos-devel/2011-07/msg00003.html we are working
> on a port of Newlib's single precision floating point math library
> (float vs double...).
> 
> I know part of the questions should be addressed to the Newlib's mailing
> list (which I have done as well), but I am asking help on the Ecos part
> of the problems.

Hi Visar,

[cut set of Q that I do not have the expertise]

> And lastly, about the gamma function - I've used the tests provided
> from Newlib, and when I try to compile the test files about this
> function, I get the error
> ecos/packages/language/c/libm/current/src/double/ieee754-api/w_gamma.c:99:
> undefined reference to `signgam'. Can anyone help on this?

Look, please, at ecos math.h:160

  #ifdef CYGSEM_LIBM_THREAD_SAFE_GAMMA_FUNCTIONS

  // FIXME: these need to be documented and signgam mentioned as non-ISO
  // This returns the address of the signgam variable used by the gamma*() and
  // lgamma*() functions
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ilija Kocho | 25 Jul 2011 21:54
Picon

Re: Single precision math library, porting to eCos.

Hello Sergei

Many thanks for your comments.

On 25.07.2011 19:44, Sergei Gavrikov wrote:
> On Tue, 19 Jul 2011, Ilija Kocho wrote:
>
>> Hello colleagues
>  
> Hello Ilija,
>
> my $0.02.
>
>> We are working on a port of Newlib's single precision math library
>> /float/ type functions/. We are going to contribute the port, so we
>> would like to know if there is interest to incorporate it into main
>> eCos tree.
> It's very excited and honour task. But, AFAIK, eCos libm are based on
> Free Domain Libm fdlibm 5.X (5.2?). The *fdlibm* is a part of netlib
> software collection, the references:

Thanks for the reference. Comparing double precision functions from eCos
and Newlib,  some time ago, (and not having complete history
information) I got impression that eCos library is coming from Newlib.
Now, following your pointers, I have looked at fdlibm, it seems that
both eCos and Newlib stem from fdlibm (or all 3 from same origin).
However both fdlibm and Newlib files have same copyright messages so I
think we can safely use either.
From first view I could see that fdlibm does not have single precision
functions. Newlib does have them, according to file header converted
(Continue reading)

Permalink | Reply | 0 comments |

Gmane