El 9/4/2016 12:24, "Joel Sherrill" escribió:
>
>
>
> On Sat, Apr 9, 2016 at 10:17 AM, Daniel Gutson <
daniel.gut...@tallertechnologies.com> wrote:
>>
>>
>> El 9/4/2016 12:15, "Joel Sherrill" escribió:
>> >
>> > Hi
>>
El 21/1/2016 10:08, "Sebastian Huber"
escribió:
>
> On 21/01/16 14:04, Marcos Díaz wrote:
>>
>> Just a question, isn't this hardware counter used for debugging? This
won't cause us any problem for debugging?
>
>
> Why should it cause problems?
Beside any problem, how this affects debugging since
On Mon, Jan 4, 2016 at 2:04 PM, Joel Sherrill wrote:
>
>
> On Mon, Jan 4, 2016 at 3:48 AM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>>
>>
>> On 23/12/15 22:22, Marcos Díaz wrote:
>>
>>> That patch didn't work,
>>> one reason is that it has a mistake:
>>> in kern_tc.c you d
Hi folks,
I'm confused about the latest patches: does newlib contain a (full)
network stack which we don't use?
Thanks,
Daniel.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On Sun, Dec 6, 2015 at 11:36 PM, Joel Sherrill wrote:
>
> On Dec 6, 2015 8:06 PM, "Daniel Gutson"
> wrote:
>>
>> In the f2fs/jffs2 thread a point about licensing arose.
>> Martin mentioned that the original code is part of Linux, assuming
>> that i
In the f2fs/jffs2 thread a point about licensing arose.
Martin mentioned that the original code is part of Linux, assuming
that it is GPLv2 (we'll check).
However, Chris asked for a dual licensing scheme in order to include
it in RTEMS.
I read in https://www.rtems.org/license/LICENSE "...GNU Genera
On Sun, Dec 6, 2015 at 10:42 PM, Chris Johns wrote:
> On 12/05/15 06:49, Martin Galvan wrote:
>>
>> Certainly! This filesystem has been so far implemented in Linux, so
>> I'd assume it's GPLv2.
>
>
> Would it be worth contacting the developer/maintainer and ask about a dual
> license or something
Hi Sebastian,
sorry for top-posting. How does the lack of this function affect
current RTEMS behavior? What's the impact of not having this? We lived
without this till now, how mandatory is this update?
Thanks!
Daniel.
On Wed, Nov 25, 2015 at 4:35 AM, Sebastian Huber
wrote:
> This functio
El 17/11/2015 8:51, "Thomas Dörfler"
escribió:
>
> Hello Daniel,
>
> Expo and conference are in the same building complex. And we will be part
of the expo.
Ah ok, thanks. See you there.
Daniel.
>
> wkr,
>
> Thomas.
>
>
>
> Am 17.11.2015 um
ch the critical mass of people interested for this.
Please note that I will attend the Expo, not the Conference.
>
> Looking forward to seeing you all,
>
> Thomas.
>
>
>
> Am 16.11.2015 um 21:23 schrieb Daniel Gutson:
>>
>> Sorry the off-topic email.
>>
&
Sorry the off-topic email.
Who is planning to attend the expo at EW, so we could meet?
Thanks,
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://a
Hi Ketul,
we are experiencing a deadlock that seems to be caused by
+#define OBTAIN_LOCK(s) assert( rtems_semaphore_obtain(s,\
+ RTEMS_WAIT, \
+ RTEMS_NO_TIMEOUT \
+
On Thu, Nov 5, 2015 at 11:52 AM, Sebastian Huber
wrote:
>
>
> On 05/11/15 15:50, Daniel Gutson wrote:
>>
>> On Thu, Nov 5, 2015 at 11:41 AM, Sebastian Huber
>> wrote:
>>>
>>> >Hello,
>>> >
>>> >I would like to add the
On Thu, Nov 5, 2015 at 11:41 AM, Sebastian Huber
wrote:
> Hello,
>
> I would like to add the tools for RTEMS 4.12 to the RSB. The question is
> which GCC version should we use? Since our release process is so slow I tend
> to use GCC 6 since it includes support for OpenMP and C++11 threads out of
On Wed, Oct 21, 2015 at 6:02 PM, Joel Sherrill
wrote:
>
>
> On 10/21/2015 3:52 PM, Daniel Gutson wrote:
>>
>> On Wed, Oct 21, 2015 at 3:41 PM, Joel Sherrill
>> wrote:
>>>
>>> Hi
>>>
>>> lm32, moxie, and nios2 all have generic is
On Wed, Oct 21, 2015 at 3:41 PM, Joel Sherrill
wrote:
> Hi
>
> lm32, moxie, and nios2 all have generic issues with C++ applications
> which indicate C++ is not really supported by gcc for these targets.
Could you please provide more information/details about the error and messages?
What does "C++
On Wed, Oct 7, 2015 at 8:22 PM, Chris Johns wrote:
> On 7/10/2015 11:00 pm, Daniel Gutson wrote:
>>
>> FWIW no need from feedback from us.
>>
>
> Can we assume this is an ok from you?
Yes.
>
> Chris
--
Daniel F. Gutson
Chief Engineering Officer, SPD
Sa
On Wed, Oct 7, 2015 at 4:05 AM, Sebastian Huber
wrote:
>
>
> On 07/10/15 09:04, Chris Johns wrote:
>>
>> On 7/10/2015 4:33 pm, Sebastian Huber wrote:
>>>
>>> >
>>> >
>>> >On 07/10/15 05:13, Chris Johns wrote:
>>On 23/09/2015 11:33 am, Gedare Bloom wrote:
>>
>> >>> >ping. i will t
El 25/9/2015 13:17, "sudarshan.rajagopalan"
escribió:
>
> On 2015-09-25 11:06, Daniel Gutson wrote:
>>
>> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan
>> wrote:
>>>
>>> Hey all,
>>>
>>> We are developing a new BSP th
On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan
wrote:
> Hey all,
>
> We are developing a new BSP that uses math.h in few of the BSP files. I do
May I ask why do you need floating point operations in a kernel? At
least, what sort of operations and why not move them upwards.
> understand t
towards 2 and 5. I will get consensus with other gcc
maintainers and see what comes out and will let you know.
Daniel.
>
> On 17/09/15 21:39, Daniel Gutson wrote:
>>
>> Hi,
>>
>>we are working towards compiling RTEMS for gcc 5.2 (since we are
>> worki
Hi,
we are working towards compiling RTEMS for gcc 5.2 (since we are
working in a fork of the latter).
We found a bug that Sebastian previously found, which I reported here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Not only it causes calloc() to call itself (recursively), but the
(arg
Update:
fix sent https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01184.html
Waiting for review.
Daniel.
On Thu, Aug 13, 2015 at 7:02 PM, Daniel Gutson
wrote:
> I have been desperately busy to fix this, though we are indeed
> interested in the fix since we'll use C++14 soon.
>
El 9/9/2015 16:14, "Gedare Bloom" escribió:
>
> On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber
> wrote:
> > Hello Martin,
> >
> > - Martin Galvan schrieb:
> >> Hi there! We were looking at the RTEMS SMP support, and wondered what
> >> would it take for the system to support some form of mem
On Thu, Sep 3, 2015 at 5:44 PM, Joel Sherrill wrote:
> Should be committed now.
>
> I guess one of us should have compiled it. :)
Don't worry, Martin will buy some beers because of this.
Cheers.
Daniel.
>
> --joel
>
> On 9/3/2015 3:25 PM, Martin Galvan wrote:
>>
>> Apparently 'free' is define
On Thu, Sep 3, 2015 at 1:21 PM, Joel Sherrill wrote:
>
>
> On 9/2/2015 4:54 PM, Martin Galvan wrote:
>>
>> I also used the 'n' versions of the string functions, #define'd magic
>> numbers
>> and added a few comments.
>
>
> Great on the 'n' versions!
>
> One comment. Why is the output buffer now st
El 2/9/2015 11:58, "Martin Galvan"
escribió:
>
> On 02/09/2015 15:00, Sebastian Huber wrote:
> > I deleted the test tree. It will take a couple of days before I create a
> > new one. I think it makes more sense if you run the tests yourself, so
> > that you can debug them. I use the realview_pbx_a
El 2/9/2015 11:14, "Joel Sherrill" escribió:
>
>
>
> On 8/31/2015 5:47 AM, Cudmore, Alan P. (GSFC-5820) wrote:
>>
>> Having a floating point configuration of the BSP makes sense. I was able
>> to rebuild the BSP with the hardware floating point compiler option and
it
>> works.
>>
>> I did get a fl
El 2/9/2015 5:28, "Sebastian Huber"
escribió:
>
>
>
> On 02/09/15 02:50, Chris Johns wrote:
>>
>> On 1/09/2015 8:52 pm, Daniel Gutson wrote:
>>>
>>> >
>>> >El 31/7/2015 3:28, "Chris Johns" >> ><mailto:chr.
El 2/9/2015 5:17, "Sebastian Huber"
escribió:
>
>
>
> On 01/09/15 13:05, Sebastian Huber wrote:
>>
>> On 01/09/15 12:10, Sebastian Huber wrote:
>>>
>>> Shared mutexes are not implemented in general.
>>
>>
>> This works now also:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00027.html
>>
>
>
El 1/9/2015 23:10, "Joel Sherrill" escribió:
>
>
>
> On September 1, 2015 8:33:54 PM CDT, Daniel Gutson <
daniel.gut...@tallertechnologies.com> wrote:
> >Is there any reason to not declare these variables as unsigned (int)?
> >IIUC strlen returns an uns
Is there any reason to not declare these variables as unsigned (int)? IIUC
strlen returns an unsigned integral. Sign-correctnesd doesn't hurt and I
saw many bugs caused by the lack of it (the last one being pushed few says
ago in the Chromium beowser).
El 1/9/2015 18:41, "Joel Sherrill" escribió:
El 31/7/2015 3:28, "Chris Johns" escribió:
>
> On 31/07/2015 4:11 pm, Sebastian Huber wrote:
> > For synchronization objects use the self-contained objects available via
> > Newlib .
> >
> >
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f3998
On Mon, Aug 31, 2015 at 2:34 PM, Gedare Bloom wrote:
> I'd approve 2 patches in case you want to give credit. First patch
> with Sudarshan's fix, and Martin's improvement second.
+1
>
> On Mon, Aug 31, 2015 at 1:28 PM, Daniel Gutson
> wrote:
>> Side questio
Side question to Joel and others: is this enough to credit Sudarshan?
He did an amazing job for finding the bug and proposing an initial
solution.
On Mon, Aug 31, 2015 at 11:37 AM, Martin Galvan
wrote:
> On exception entry, _ARMV7M_Exception_default stores the previous Stack
> Pointer
> in a CPU
On Fri, Aug 28, 2015 at 2:31 PM, sudarshan.rajagopalan
wrote:
> On 2015-08-28 12:18, sudarshan.rajagopalan wrote:
>>
>> On 2015-08-28 11:30, Daniel Gutson wrote:
>>>
>>> On Fri, Aug 28, 2015 at 12:20 PM, Gedare Bloom wrote:
>>>>
>>>> C
On Fri, Aug 28, 2015 at 12:33 PM, sudarshan.rajagopalan
wrote:
> On 2015-08-27 17:06, Joel Sherrill wrote:
>>
>> On 8/27/2015 3:58 PM, Daniel Gutson wrote:
>>>
>>> On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan
>>> wrote:
>>>>
&
On Fri, Aug 28, 2015 at 12:20 PM, Gedare Bloom wrote:
> Could you please open a ticket on our trac to describe the problem
> this fixes, and add "closes #." to your patch commit message?
Additionally, please clarify which architecture this applies to. I
suspect this is for cortex-m4.
In any c
On Thu, Aug 27, 2015 at 6:38 PM, Joel Sherrill
wrote:
>
>
> 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?
>&
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. K
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,
>> >
>>
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 f
On Wed, Aug 19, 2015 at 1:51 PM, Isaac Gutekunst
wrote:
> Hi
>
> I'm thinking about porting CANFestival to RTEMS. I think it should be
> relatively doable do to the posix support, and because the core files don't
> have any platform specific code as far as I can tell.
>
> Has anyone had any experi
El 13/8/2015 19:35, "Joel Sherrill" escribió:
>
>
>
> On August 13, 2015 3:34:12 PM CDT, Daniel Gutson <
daniel.gut...@tallertechnologies.com> wrote:
> >I'd recommend a gcc plugin that generates your annotations; otherwise,
> >dig into gcov in or
I have been desperately busy to fix this, though we are indeed
interested in the fix since we'll use C++14 soon.
That's why I will address this a bit later. Sorry the delay.
Daniel.
On Wed, Aug 5, 2015 at 7:36 PM, Daniel Gutson
wrote:
> On Fri, Jul 31, 2015 at 9:56 AM, Se
ap branches from execution traces to conditions
> within the source code. With this information it will be possible to analyze
> source coverage metrics as decision coverage or MCDC.
>
>
> Daniel Gutson schrieb am Do., 13.
> Aug. 2015 um 21:50 Uhr:
>>
>> 1) Are you lookin
1) Are you looking for something statically processed (i.e. at compile
time) or at runtime? (such as gcov)
2) Are you looking for a way to add _your_ annotations, or a way to
_extract_ information?
In any case, the best way I can think of is with a gcc plugin.
Have you seen gcc's -ftest-coverage
ou 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.
>
> Gedare
>
> On Thu, Aug 13, 2015 at 11:18 AM,
fore
> 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 num
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: +5
some fixes.
>
> I am not aware of the issue with POSIX API. Once we get this working,
> I am ready to implement with native api in the future.
>
>
> Thanks,
> Ragunath
>
>
> On Mon, Aug 10, 2015 at 9:50 PM, Daniel Gutson
> wrote:
> > On Mon, Aug 10, 2015 at
Are you intending to make RTEMS use an existing linux driver via
Xtratum? Otherwise, which is the relationship with RTEMS?
On Sun, Aug 9, 2015 at 11:26 AM, Shabnam Engineer
wrote:
> Hello,
> I have a question about porting Linux drivers into Xtratum.
> Can I port Linux drivers into Xtratum? or is
On Mon, Aug 10, 2015 at 10:48 AM, Joel Sherrill
wrote:
>
>
> On 8/9/2015 4:57 AM, ragu nath wrote:
>>
>> Hi All,
>>
>> I have sent the patches for building lwIP from RSB. First patch
>> contains changes for RTEMS Resource Builder. The second patch is RTEMS
>> specific changes that will be applied
On Fri, Jul 31, 2015 at 9:56 AM, Sebastian Huber
wrote:
>
>
> On 31/07/15 14:51, Daniel Gutson wrote:
>>
>>
>> > Is it possible to construct objects without an address via plain C++?
>>
>> Sorry I don't understand the question. Rephrase please?
>
El 31/7/2015 2:37, "Sebastian Huber"
escribió:
>
> Hello Daniel,
Hello Sebastian.
>
>
> On 30/07/15 17:26, Daniel Gutson wrote:
>>
>> On Thu, Jul 30, 2015 at 11:31 AM, Daniel Gutson
>> wrote:
>>>
>>> >
>>> >El 30/7/20
Update: confirmed bug. I'll address it during next week.
On Thu, Jul 30, 2015 at 12:26 PM, Daniel Gutson
wrote:
> On Thu, Jul 30, 2015 at 11:31 AM, Daniel Gutson
> wrote:
>>
>> El 30/7/2015 11:27, "Joel Sherrill" escribió:
>>>
>>>
On Thu, Jul 30, 2015 at 11:31 AM, Daniel Gutson
wrote:
>
> El 30/7/2015 11:27, "Joel Sherrill" escribió:
>>
>>
>>
>> On 7/30/2015 9:08 AM, Daniel Gutson wrote:
>>>
>>> IOW, I think that the double parens is only for decltype.
>>
&g
El 30/7/2015 11:27, "Joel Sherrill" escribió:
>
>
>
> On 7/30/2015 9:08 AM, Daniel Gutson wrote:
>>
>> IOW, I think that the double parens is only for decltype.
>
>
> Historical convention is to put parens around variable names
> in macros. What type
IOW, I think that the double parens is only for decltype.
El 30/7/2015 11:06, escribió:
> I don't it's a language issue: https://ideone.com/k1vz5d
> El 30/7/2015 10:51, "Gedare Bloom" escribió:
>
>> OK, I guess this makes the convention "minimize parentheses" mandatory
>> if we want C++11. I gue
I don't it's a language issue: https://ideone.com/k1vz5d
El 30/7/2015 10:51, "Gedare Bloom" escribió:
> OK, I guess this makes the convention "minimize parentheses" mandatory
> if we want C++11. I guess the basic problem is that constructions
> where a single atom is in parens may produce differ
Hi guys,
I just got a student who likes this project and wants to provide a
CMSIS API to RTEMS as her career final project.
I will be her director.
Besides telling her to read stuff, documentation, and the github
source files, any initial advice about how to implement this
on top of RTEMS? I.e.
On Wed, Jul 15, 2015 at 8:46 AM, Premysl Houdek wrote:
> Signed-off-by: Premysl Houdek
> ---
> c/src/lib/libbsp/arm/tms570/clock/clock.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/c/src/lib/libbsp/arm/tms570/clock/clock.c
> b/c/src/lib/libbsp/arm/tms570/cl
Ragu,
Please ensure that you are getting cache coherence right. That is, there
are no packets crossing the cache lines.
FWIW, in a life ago, i got a problem with an eth driver where the
descriptors ring was not properly sized (ie no modulus cache line).
El 29/6/2015 17:23, "ragu nath" escribió
On Tue, Feb 17, 2015 at 10:53 AM, Daniel Gutson
wrote:
>
> El 14/02/2015 10:29, "Sebastian Huber"
> escribió:
>>
>> On 14/02/15 14:27, Sebastian Huber wrote:
>>>
>>> On 14/02/15 12:48, Daniel Gutson wrote:
>>>>
>>>> We
Thanks Sebastian.
We will use it in the BeagleBone Black BSD.
On Tue, Jun 9, 2015 at 4:16 AM, Sebastian Huber
wrote:
> Hello Daniel,
>
> the USB host and MMC/SD card stack is from FreeBSD 9. It works quite well on
> our targets.
>
>
> On 05/06/15 18:27, Daniel Gutson wrot
Hi Sebastian,
is this industrial-grade fully functional, or has known issues? If
it has, we could fix them.
Thanks,
Daniel.
On Mon, May 18, 2015 at 4:01 AM, Sebastian Huber
wrote:
> On 16/05/15 20:53, Afshin Jamaali (Arian) wrote:
>>
>> Hi Sebastian,
>>
>> Sorry, it seems a problem exist
I see things like "unsigned long" in some changes (specially macro
constants) rather than the stdint.h types. Please point me to the generator
tool location and I will contribute a patch to FreeBSD (meanwhile we could
use them).
___
devel mailing list
dev
Hi,
with this (just approved) patch
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00104.html
the toolchain can be built containing an exceptions-free multilib (if
the -fno-exceptions flag is specified
in the target fragment file).
This means that now the same toolchain can generate binary
ld is really ld or gold?
Version?
El 16/4/2015 18:52, "Joel Sherrill" escribió:
> Hi
>
> Has anyone seen this failure?
>
> $ make
> lt LINK vscclient
> /usr/bin/ld: -f may not be used without -shared
> collect2: ld returned 1 exit status
> make: *** [vscclient] Error 1
>
> --
> Joel Sherrill, Ph
El 29/03/2015 20:52, "Chris Johns" escribió:
>
> On 30/03/2015 8:23 am, Daniel Gutson wrote:
> >
> >We are waiting for the (hopefully) last round of comments for our gdb
> > pretty printers of glibc's NPTL.
>
> Do you have a suitable link ?
Hi,
We are waiting for the (hopefully) last round of comments for our gdb
pretty printers of glibc's NPTL.
Is there interest here for an RTEMS version as well?
Daniel.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/d
On Thu, Mar 26, 2015 at 5:16 PM, Martin Galvan
wrote:
> ---
> c/src/lib/libbsp/arm/tms570/include/tms570.h | 19 +++--
> c/src/lib/libbsp/arm/tms570/startup/bspreset.c | 37
> --
> 2 files changed, 34 insertions(+), 22 deletions(-)
>
> diff --git a/c/src/lib/lib
El 25/03/2015 21:41, "Joel Sherrill" escribió:
>
>
>
> On March 24, 2015 8:37:57 AM CDT, Daniel Gutson <
daniel.gut...@tallertechnologies.com> wrote:
> >In order to avoid code duplication and ease future bugfixing, I suggest
> >to have a condition
El 24/03/2015 10:34, "Joel Sherrill" escribió:
>
>
>
> On 3/24/2015 8:29 AM, Daniel Gutson wrote:
>>
>>
>> El 24/03/2015 10:17, "Joel Sherrill"
escribió:
>> >
>> > Hi
>> >
>> > I am pushing all but the
In order to avoid code duplication and ease future bugfixing, I suggest to
have a conditional casting and leave the core code alone, something like
#ifdef __rtems__
#define cast(x) ((unsigned long int)x)
#else
#define cast(x) (x)
#endif
...cast(final[ 0] << 16)...
#undef cast
El 23/03/2015 11:52
El 24/03/2015 10:17, "Joel Sherrill" escribió:
>
> Hi
>
> I am pushing all but the one patch that was commented on.
> I will try the suggested alternative approach to eliminating
> the warning before pushing some solution.
I'm just back from a trip and I am not sure what that remaining patch is o
d. And also see
>the way of submitting it to rtems. It was suggested to upload it in
>rtems source builder and try to make it easier to configure
He is looking at this as part of a gsoc project so could help take a work
in progress and push it to completion.
>El mar 13, 2015 6:52 PM,
Hi Ragu.
We're successfully using it in production code. We had no time to
contribute it yet, AFAIK blocked in the source builder. Marcos,
details please?
Daniel.
On Fri, Mar 13, 2015 at 6:00 PM, ragu nath wrote:
> Hi,
>
> I would like to know what is the status of running lwIP on beaglebone
Hi,
I know this has been asked before.
What's the status of the new C++ threading model implementation? I
barely recall people saying that
there were some features provided in the GNU's STL that uses POSIX
features not currently
implemented in RTEMS.
We are interested in the C++0x/1y concurre
I'm resending my answer since I got a mailman error response.
On Tue, Feb 17, 2015 at 10:53 AM, Daniel Gutson
wrote:
>
> El 14/02/2015 10:29, "Sebastian Huber"
> escribió:
>>
>> On 14/02/15 14:27, Sebastian Huber wrote:
>>>
>>> On 14/02/15
El 13/02/2015 22:59, "Cudmore, Alan P. (GSFC-5820)"
escribió:
>
> A project is looking at using RTEMS on an FPGA based ARM Cortex-M1 like
> the one in the Microsemi ProAsic3L development kit:
>
http://www.microsemi.com/products/fpga-soc/design-resources/dev-kits/proasi
> c3/cortex-m1-enabled-proas
Just to clarify: the ability to provide a new piece of binary
corresponding to a driver and replace the existing one.
Have anybody tried this before?
Thanks!
Daniel.
On Fri, Feb 13, 2015 at 12:27 PM, Daniel Gutson
wrote:
> Hi,
>
>is there any current experience / support
Hi,
is there any current experience / support with hot patching? E.g.
patching a driver while the whole system is running.
Thanks,
Daniel.
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 42182
On Wed, Feb 4, 2015 at 1:27 PM, Gedare Bloom wrote:
>
> On Wed, Feb 4, 2015 at 11:16 AM, Daniel Gutson
> wrote:
> > Hi Sebastian,
> >
> > On Wed, Feb 4, 2015 at 10:46 AM, Sebastian Huber
> > wrote:
> >>
> >> ---
> >> cpukit/libcsuppor
On Wed, Feb 4, 2015 at 1:16 PM, Daniel Gutson <
daniel.gut...@tallertechnologies.com> wrote:
> Hi Sebastian,
>
> On Wed, Feb 4, 2015 at 10:46 AM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> ---
>> cpukit/libcsupport/include/rtems/lib
Hi Sebastian,
On Wed, Feb 4, 2015 at 10:46 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> ---
> cpukit/libcsupport/include/rtems/libio.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/cpukit/libcsupport/include/rtems/libio.h
> b/cpukit/libcsupport/includ
Hi,
We are thinking about a "supervisor" watchdog, which runs in a high
priority task, and
has the following characteristics:
a) tasks that "want" to be supervised are registered in the supervisor watchdog
b) each supervised task is in one of the following mode:
- automatic supervision
Congratulations!
--Mensaje original--
De: Joel Sherrill
Remitente: devel
Para: us...@rtems.org
Para: devel@rtems.org
Asunto: Fwd: Sebastian Huber appointed RTEMS Co-Maintainer
Enviado: 21 de dic de 2014 2:13 PM
Original Message
Subject:Sebastian Huber appointed
w a little more, I suggest that you make a objdump and
> see what global objects are using more RAM and where did they come from.
>
> On Wed, Dec 17, 2014 at 1:36 PM, Daniel Gutson <
> daniel.gut...@tallertechnologies.com> wrote:
>>
>> We were able to downsize R
We were able to downsize RTEMS to about 9k for the LPC1768.
Marcos, could you give a hint?
On Wed, Dec 17, 2014 at 1:34 PM, Joel Sherrill
wrote:
>
>
>
> On December 17, 2014 8:00:50 AM PST, Hesham Moustafa <
> heshamelmat...@gmail.com> wrote:
> >Hi all,
> >
> >I am working on reducing RTEMS size
FWIW, we have a fully functional LWIP eth stack for the Beaglebone Black that
we'll contribute soon.
Maybe exploring/prototyping some dynamic checkers (specially for concurrency)
would be an option for gsoc.
--Mensaje original--
De: Joel Sherrill
Remitente: devel
Para: us...@rtems.org
Pa
On Fri, Oct 24, 2014 at 2:16 PM, Daniel Gutson
wrote:
> On Fri, Oct 24, 2014 at 2:33 AM, Sebastian Huber
> wrote:
>> On 23/10/14 18:12, Daniel Gutson wrote:
>>>
>>> On Thu, Oct 23, 2014 at 5:47 AM, Sebastian Huber
>>> wrote:
>>>>
>>&
On Fri, Oct 24, 2014 at 2:33 AM, Sebastian Huber
wrote:
> On 23/10/14 18:12, Daniel Gutson wrote:
>>
>> On Thu, Oct 23, 2014 at 5:47 AM, Sebastian Huber
>> wrote:
>>>
>>> >Hello Daniel,
>>
>> Hi Sebastian,
>>
>>> >
>
ompletely empty is not the problem I
see since it is
guaranteed by the interrupt. My concern is different: it's whether the
FIFO is filled too fast
for the device.
>
> On 21/10/14 19:32, Daniel Gutson wrote:
>>
>> Hi,
>>
>> in the writing interrupt mode (ns1
Hi,
in the writing interrupt mode (ns16550_write_support_int), we have
for (i = 0; i < out; ++i) {
set( port, NS16550_TRANSMIT_BUFFER, buf [i]);
}
Shouldn't we check, before writing to the register for the iterations
after the first one,
whether the character entered in the FIFO? (oth
On Thu, Oct 2, 2014 at 6:16 AM, Daniel Cederman wrote:
>> I would not put too much time into this. Who needs this stuff?
>
> Thanks for the comment. I thought it would be a quick fix to add support,
> but looking at the code that gcc generates for _Atomic struct's I do not
> really trust it to be
>
>> -Original Message-
>> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Daniel Gutson
>> Sent: Thursday, September 18, 2014 3:02 AM
>> To: RTEMS
>> Subject: dynamic checking tools
>>
>> Hi guys,
>>
>>are there any dynamic check
Hi folks,
could you please give us an update of the shape of this BSP?
There's a project that uses the TMS570, and I'd like to convince some
people to move to RTEMS. How far do you consider the BSP is from the
"industrial" status?
I don't see much progress details in its wiki, such as stabili
Hi guys,
are there any dynamic checking tools (a la
valgrind/helgrind/memcheck/drd and *sanitizer) for RTEMS?
More specifically, I'm interested in memory and concurrency checking,
more specifically for ARM.
Thanks!
Daniel.
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo
Marcos and I will take a look.
On Wed, Sep 17, 2014 at 12:19 PM, Joel Sherrill
wrote:
> Hi
>
> I would really appreciate it if someone could look into this
> warning and see if we can get an explanation. It could be
> a source code issue or something higher in the tools.
> It is reported on 120 B
1 - 100 of 106 matches
Mail list logo
