Re: Statically allocated build

2021-09-27 Thread Sebastian Huber 

Hello,

On 24/09/2021 20:08, Петр Борисенко wrote:

  Hello everyone!
I am currently creating a aerial robot application upon the arm/stm32f4 bsp
(extending it, possibly will contribute soon)
I have just moved from RTEMS5 to RTEMS6 and have a few questions.
1. I don't understand how to build a system fully statically allocated. For
safety reasons I shouldn't use neither heap for the system objects nor
dynamic loading.


if you don't use the unlimited objects option, then the Classic API 
objects are statically allocated in RTEMS 6. You can construct tasks and 
message queues with user-provided storage:


https://docs.rtems.org/branches/master/c-user/task/directives.html#rtems-task-construct

https://docs.rtems.org/branches/master/c-user/message/directives.html#rtems-message-queue-construct

The POSIX and C++ synchronization objects use user-provided storage.


2. I have just noticed that `__usrenv.c` has been compiled into my
application. I don't understand how to disable it.


I would look at the linker map file. You probably use a file system.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: [EXTERNAL] Re: rtems_semaphore routines on SMP systems

2021-09-27 Thread Sebastian Huber 

Hello Michel,

On 27/09/2021 18:59, Michel, John M wrote:

Could you clarify what you mean by "concurrent use and deletion of a semaphore 
object is undefined behaviour on SMP systems".


sorry for being so unclear. What I meant is using the semaphore (obtain 
or release) in one thread and deleting the semaphore at the same time in 
another thread (you need two processors for this). This is not supported 
on SMP systems. It works most of the time, but not always.




It seems the whole point of semaphores is concurrent use.  Does RTEMS not 
support two threads running on two different cores both accessing a semaphore?  
To me that would mean RTEMS does not support SMP.


Concurrent use (obtain and release) of the semaphore works of course.

The above restriction is not unusual:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_destroy.html

"Attempting to destroy a locked mutex, or a mutex that another thread is 
attempting to lock, or a mutex that is being used in a 
pthread_cond_timedwait() or pthread_cond_wait() call by another thread, 
results in undefined behavior."


This restriction is for performance reasons.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Pleiades Neo and RTEMS?

2021-09-27 Thread Seronie-Vivien, Jacques 
Airbus Amber
Hi All,

Airbus doesn't communicate much about its internal designs but it's no secret 
that we use RTEMS on most of our satellite platforms (earth observation, 
telecommunication, navigation and science) and also on Rosalind Franklin (aka 
Exomars) rover.

We use an old (but stable and well known!) 4.6.6 version on Erc32/Leon2/Leon3 
processors in most of our central computers and in some cases in instrument 
control units.
We have been using RTEMS for two decades and we are very happy of the very 
sound implementation. No in operation problem was ever linked to an RTEMS 
defect!

So Pléiades Neo is no exception and relies on RTEMS for its central software 
(i.e. software in the central computer).


Kind regards
Jacques





THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.

The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Issue Compiling the Tool Suite on Windows 10

2021-09-27 Thread Joel Sherrill 
On Mon, Sep 27, 2021, 9:32 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Hello Luke,
>
> compiling the tool suite on Windows is a bit tricky in my experience and
> it needs ages. I just recently wanted to try a patch that would prefer
> python3 and had quite some problems with it:
>
> https://lists.rtems.org/pipermail/devel/2021-August/069006.html
>
>  From what I can say at the moment, I think your best bet is using msys2
> and not cygwin (if you have the choice). You'll need flex additionally
> to the packets given in the manual here:
>
>  https://docs.rtems.org/branches/master/user/hosts/windows.html#msys2
>
> For my patch that didn't work but I think with the current upstream RSB
> it should work.
>

Piling on, gdb 9 (RTEMS 5) will no longer build on Cygwin. Google finds
plenty of discussion on this and other packages.  I've discussed how to
deal with this with Chris. Looks I will be spending a small patch rather
than upgrading that branch to gdb 10.


> Best regards
>
> Christian
>
> Am 23.09.21 um 18:37 schrieb Luke Halberstadt:
> > Dear Sir/Madam,
> >
> > I am working on compiling the RTEMS toolchain on a Windows machine
> following the instructions provided here:
> > https://docs.rtems.org/branches/master/user/hosts/windows.html#cygwin
> >
> > Both Cygwin and MSYS2 are installed along with most of the recommended
> packages, however, I could not find the gcc4* or python packages. Instead,
> I installed similar gcc* and python2 packages.
> >
> > When I compile using the following command,
> > ../source-builder/sb-set-builder --prefix=/cygdrive/c/opt/rtmes/5.1
> 5/rtems-sparc --jobs=none
> >
> > The build makes it up to building gdb and then fails with a python error.
> > building: sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1
> > error: building sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1
> >
> > I have attached the rsb-report and log files The key issue seems to be
> in the following lines of the report:
> > checking whether to use python... /usr/bin/python2
> > checking for python... no
> > configure: error: no usable python found at /usr/bin/python2
> > make[1]: *** [Makefile:8869: configure-gdb] Error 1
> > make[1]: Leaving directory
> '/cygdrive/c/opt/rtems/5.1/rtems/build/sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1/build'
> > make: *** [Makefile:855: all] Error 2
> > shell cmd failed: sh -ex
> /cygdrive/c/opt/rtems/5.1/rtems/build/sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1/do-build
> > error: building sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1
> >
> > By default, Python is installed at /bin, not /usr/bin, so I tried
> copying the python files from /bin to /usr/bin, but that did not resolve
> the issue. I attached a screenshot showing the contents of /usr/bin when
> this failure occurred.
> >
> > Any ideas how to get around this problem so that gcc recognizes the
> python installation? Thank you for your input.
> >
> > Sincerely,
> >
> > Luke Halberstadt
> > Senior Associate Training Engineer
> > Natick, MA USA
> > (508) 647-0196
> > lhalb...@mathworks.com
> >
> >
> > ___
> > users mailing list
> > users@rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Issue Compiling the Tool Suite on Windows 10

2021-09-27 Thread Christian MAUDERER 

Hello Luke,

compiling the tool suite on Windows is a bit tricky in my experience and 
it needs ages. I just recently wanted to try a patch that would prefer 
python3 and had quite some problems with it:


https://lists.rtems.org/pipermail/devel/2021-August/069006.html

From what I can say at the moment, I think your best bet is using msys2 
and not cygwin (if you have the choice). You'll need flex additionally 
to the packets given in the manual here:


https://docs.rtems.org/branches/master/user/hosts/windows.html#msys2

For my patch that didn't work but I think with the current upstream RSB 
it should work.


Best regards

Christian

Am 23.09.21 um 18:37 schrieb Luke Halberstadt:

Dear Sir/Madam,

I am working on compiling the RTEMS toolchain on a Windows machine following 
the instructions provided here:
https://docs.rtems.org/branches/master/user/hosts/windows.html#cygwin

Both Cygwin and MSYS2 are installed along with most of the recommended 
packages, however, I could not find the gcc4* or python packages. Instead, I 
installed similar gcc* and python2 packages.

When I compile using the following command,
../source-builder/sb-set-builder --prefix=/cygdrive/c/opt/rtmes/5.1 
5/rtems-sparc --jobs=none

The build makes it up to building gdb and then fails with a python error.
building: sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1
error: building sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1

I have attached the rsb-report and log files The key issue seems to be in the 
following lines of the report:
checking whether to use python... /usr/bin/python2
checking for python... no
configure: error: no usable python found at /usr/bin/python2
make[1]: *** [Makefile:8869: configure-gdb] Error 1
make[1]: Leaving directory 
'/cygdrive/c/opt/rtems/5.1/rtems/build/sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1/build'
make: *** [Makefile:855: all] Error 2
shell cmd failed: sh -ex  
/cygdrive/c/opt/rtems/5.1/rtems/build/sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1/do-build
error: building sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1

By default, Python is installed at /bin, not /usr/bin, so I tried copying the 
python files from /bin to /usr/bin, but that did not resolve the issue. I 
attached a screenshot showing the contents of /usr/bin when this failure 
occurred.

Any ideas how to get around this problem so that gcc recognizes the python 
installation? Thank you for your input.

Sincerely,

Luke Halberstadt
Senior Associate Training Engineer
Natick, MA USA
(508) 647-0196
lhalb...@mathworks.com


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



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Pleiades Neo and RTEMS?

2021-09-27 Thread Joel Sherrill 
On Sat, Sep 25, 2021 at 12:35 AM Pierre FICHEUX  wrote:
>
> Hi Joel,
>
> I work with Airbus (including Defence and Space) so I can ask them about the 
> OS.

Thanks. At one point, there was a PDF of a presentation with Airbus'
history with RTEMS.
I think it came from a presentation in France and you may have been a
part of that. Do
you happen to have a copy of it? Or a link?

>
> I'm quite sure they use RTEMS.

:)

--joel

>
> regards
>
> Le lun. 16 août 2021 à 18:13, Joel Sherrill  a écrit :
>>
>> Hi
>>
>> I noticed that another Pleiades Neo satellite was launching later today.
>>
>> https://directory.eoportal.org/web/eoportal/satellite-missions/p/pleiades-neo
>>
>> My quick search didn't find any indication of the software or hardware
>> internals of the satellites. Given the parties involved, I expect there is
>> a reasonable chance RTEMS is hiding in these somewhere.
>>
>> Does anyone have any insight? I'm happy for an offlist answer.
>>
>> Thanks.
>>
>> --joel
>> ___
>> users mailing list
>> users@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>
>
>
> --
>
> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.fich...@smile.fr
>  http://www.smile.fr
>  https://smile.eu/fr/offres/embarque-iot
> I would love to change the world, but they won't give me the source code
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: rtems_semaphore routines on SMP systems

2021-09-27 Thread Sebastian Huber 

Hello Heinz,

On 25/09/2021 12:23, Heinz Junkes wrote:

Can the rtems_semaphore_*() routines be used on SMP systems?


all the rtems_semaphore_*() routines can be used on SMP systems. 
However, concurrent use and deletion of a semaphore object is undefined 
behaviour on SMP systems.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users