Re: [PATCH rtems-littelvgl] lv_conf.h: Enable user data.
Just a reminder. If no one objects in the next few days, I'll push that patch. On 04/12/2019 12:47, Christian Mauderer wrote: > This is usefull for passing driver objects arround and it doesn't add > too much overhad for drivers that don't need it. Therefore enabling it > by default seems like the better choice. > --- > lv_conf.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lv_conf.h b/lv_conf.h > index 5a0ea26..7453905 100644 > --- a/lv_conf.h > +++ b/lv_conf.h > @@ -152,7 +152,7 @@ typedef void * lv_fs_drv_user_data_t; > #endif > > /*1: Add a `user_data` to drivers and objects*/ > -#define LV_USE_USER_DATA0 > +#define LV_USE_USER_DATA1 > > /* > * Image decoder and cache > -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Requirement Document generator tool
On 10/1/20 4:45 am, Gedare Bloom wrote: > On Wed, Jan 8, 2020 at 11:51 PM Sebastian Huber > wrote: >> >> On 08/01/2020 19:31, Gedare Bloom wrote: I agree completely on the proposed approach with Python tools. >>> Yes. Reading it I'm actually reminded about Google's approach toward >>> Python which includes many of the elements mentioned. Although their >>> guide is probably more comprehensive and verbose that what we need, it >>> might be a useful reference for developing a set of guidelines >>> suitable for Python code in RTEMS (mainly, rtems-tools). Here is a >>> link: >>> http://google.github.io/styleguide/pyguide.html >>> >>> I think most of the existing style has been determined and driving by >>> Chris Johns. So I would also give him some credit to develop/approve >>> how we plan to use Python at a project level. (**Hands Chris an "RTEMS >>> Python Maintainer" hat**);) >> >> I think the Google guide would be a good start. We can always add >> project-specific exceptions/clarifications if necessary. My aim is to >> use it for new code, e.g. code produced for the pre-qualification >> activity. For the code format I strongly want to use a tool for this. I >> don't want to spend review time on code formatting issues. >> >> Using standard guidelines makes the RTEMS Project more attractive for >> new contributors and GSoC students. I think it increases your job >> opportunities if you can refer to a successful GSoC project and it shows >> that you used standard engineering practices in the project. This is >> usually not something a university education includes. >> > OK, both points make sense. I'd be happy with the Google guide, I hope > Chris will comment when he can. Sorry about the erratic access. I have been knee deep in painting and flooring this summer as I avoid any smoke from the fires we are having. I am fine with using a standard guide however we need to review it and to make sure it fits. As an example the C++ guide from Google had some good points as well as some parts I did not think offered any value but did create a certain level of pain. We should also consider capturing the guide as a public one belonging to someone else can and will change and that effects us. I am not sure how we could do this. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Requirement Document generator tool
On Wed, Jan 8, 2020 at 11:51 PM Sebastian Huber wrote: > > On 08/01/2020 19:31, Gedare Bloom wrote: > >> > >> I agree completely on the proposed approach with Python tools. > >> > > Yes. Reading it I'm actually reminded about Google's approach toward > > Python which includes many of the elements mentioned. Although their > > guide is probably more comprehensive and verbose that what we need, it > > might be a useful reference for developing a set of guidelines > > suitable for Python code in RTEMS (mainly, rtems-tools). Here is a > > link: > > http://google.github.io/styleguide/pyguide.html > > > > I think most of the existing style has been determined and driving by > > Chris Johns. So I would also give him some credit to develop/approve > > how we plan to use Python at a project level. (**Hands Chris an "RTEMS > > Python Maintainer" hat**);) > > I think the Google guide would be a good start. We can always add > project-specific exceptions/clarifications if necessary. My aim is to > use it for new code, e.g. code produced for the pre-qualification > activity. For the code format I strongly want to use a tool for this. I > don't want to spend review time on code formatting issues. > > Using standard guidelines makes the RTEMS Project more attractive for > new contributors and GSoC students. I think it increases your job > opportunities if you can refer to a successful GSoC project and it shows > that you used standard engineering practices in the project. This is > usually not something a university education includes. > OK, both points make sense. I'd be happy with the Google guide, I hope Chris will comment when he can. > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: .rtemsstack location on ARM
Hi Sebastian, The relocated vector table is also present in REGION_VECTOR as long as bsp_vector_table_in_start_section is not defined in the linker script. It sounds like this is expected behavior, though, so I'll adjust accordingly. Thanks, William On Wed, Jan 8, 2020 at 11:58 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > the region name REGION_VECTOR is a bit misleading. For ARMv-7M the > vector table is in the .bsp_start_text section, see > "bsps/arm/shared/start/start.S". In the REGION_VECTOR there is only the > interrupt stack. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] c-user: Rework glossary
Define exactly one term per definition. Use references for alternative terms. Add :term: text roles to acronym definitions of glossary defined terms. Update #3853. --- c-user/glossary.rst | 32 +++- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/c-user/glossary.rst b/c-user/glossary.rst index 5a2e6db..fe6749c 100644 --- a/c-user/glossary.rst +++ b/c-user/glossary.rst @@ -61,13 +61,15 @@ Glossary To simultaneously send a message to a logical set of destinations. Board Support Package - BSP A collection of device initialization and control routines specific to a particular type of board or collection of boards. buffer A fixed length block of memory allocated from a partition. + BSP + An acronym for :term:`Board Support Package`. + C11 The standard ISO/IEC 9899:2011. @@ -119,7 +121,7 @@ Glossary of the executive should not be used directly by applications. CPU - An acronym for Central Processing Unit. + An acronym for :term:`Central Processing Unit`. critical section A section of code which must be executed indivisibly. @@ -277,7 +279,7 @@ Glossary An acronym for Input/Output. ISR - An acronym for Interrupt Service Routine. + An acronym for :term:`Interrupt Service Routine`. kernel In this document, this term is used as a synonym for executive. @@ -346,7 +348,7 @@ Glossary disable level used by the task. MPCI - An acronym for Multiprocessor Communications Interface Layer. + An acronym for :term:`Multiprocessor Communications Interface Layer`. multiprocessing The simultaneous execution of two or more processes by a multiple @@ -489,10 +491,10 @@ Glossary proxy. PTCB - An acronym for Partition Control Block. + An acronym for :term:`Partition Control Block`. PXCB - An acronym for Proxy Control Block. + An acronym for :term:`Proxy Control Block`. quantum The application defined unit of time in which the processor is allocated. @@ -501,7 +503,7 @@ Glossary Alternate term for message queue. QCB - An acronym for Message Queue Control Block. + An acronym for :term:`Message Queue Control Block`. ready task A task occupies this state when it is available to be given control of a @@ -554,7 +556,7 @@ Glossary the directive. RNCB - An acronym for Region Control Block. + An acronym for :term:`Region Control Block`. round-robin A task scheduling discipline in which tasks of equal priority are @@ -619,7 +621,7 @@ Glossary pending signals and the signals sent to a task. SMCB - An acronym for Semaphore Control Block. + An acronym for :term:`Semaphore Control Block`. SMP An acronym for Symmetric Multiprocessing. @@ -670,7 +672,6 @@ Glossary An acronym for Test-And-Set. task - thread A logically complete thread of execution. It consists normally of a set of registers and a stack. The scheduler assigns processors to a subset of the ready tasks. The terms task and thread are synonym in RTEMS. The @@ -694,7 +695,10 @@ Glossary processor from one task and given to another. TCB - An acronym for Task Control Block. + An acronym for :term:`Task Control Block`. + + thread + This term has the same meaning as :term:`task`. thread dispatch The thread dispatch transfers control of the processor from the currently @@ -735,7 +739,7 @@ Glossary on the CPU port :cite:`RTEMS:CPU`. TMCB - An acronym for Timer Control Block. + An acronym for :term:`Timer Control Block`. transient overload A temporary rise in system activity which may cause deadlines to be @@ -757,10 +761,12 @@ Glossary the user initialization tasks. user-provided - user-supplied These terms are used to designate any software routines which must be written by the application designer. + user-supplied + This term has the same meaning as :term:`user-provided`. + vector Memory pointers used by the processor to fetch the address of routines which will handle various exceptions and interrupts. -- 2.16.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
