How will user's compile with Makefiles? Was: Re: large bss size for sample applications
The comment below, made in the users ml, caught me off guard. How will user's applications build when RTEMS is built with Waf? If there is a complex answer, then this conversation belongs here on the devel ml until we can sort it out. Gedare On Sat, Sep 26, 2015 at 2:36 AM, Chris Johns wrote: > On 25/09/2015 11:04 pm, Jeff Webb wrote: >> On 09/25/2015 07:59 AM, Gedare Bloom wrote: The next task for me will be to set up a simple out-of tree C or C++ POSIX application. Thanks again for all the help! -Jeff >>> >>> Simple examples for out-of-tree builds exist in the examples-v2.git >>> repository with the "RTEMS Application Makefile" approach using custom >>> Makefiles, and with the "RTEMS Application Waf" approach using >>> wscripts and a git-submodule for waf support. The former is an older, >>> established way to build applications linking to an 'installed' RTEMS, >>> and the latter is a newer way to do it. >> >> Perfect! This is just what I need. Thanks for the pointer. >> > > The Makefile approach will not be supported with the waf build of RTEMS > when it lands. > > Chris > ___ > users mailing list > us...@rtems.org > http://lists.rtems.org/mailman/listinfo/users ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] RTEMS CAN Rough Draft Implementation
On Thu, Aug 27, 2015 at 2:45 PM, Isaac Gutekunst wrote: > 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. > I found some time this morning, and took a look at the version on vecna's github and made comments there, mostly related to minor (style) issues. Instead of going straight into cpukit, I might prefer to see something grow organically within libbsp, where the API is malleable. Then, the below concerns can be dealt with incrementally, until we all are happy with the interface and it's default implementation. > > Concerns > > > * Usage of return codes. > * General higher level error handling. Yes, the asserts need to change to something more graceful. > * Changing can bit rate. Yes, even just adding a stub for functionality to add down-the-road will be good. Same goes for the data length. > * 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? > I didn't see the TX task being used. RX task looks normal enough to me. You may want to look at what is done with the termios/uart drivers. > 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? > This kind of quirk needs to be accommodated for in the driver/BSP level and not creep into cpukit API design/implementation. Gedare > 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 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: How will user's compile with Makefiles? Was: Re: large bss size for sample applications
I don’t like this requirement. I think it’s fine for development but want to be able to deliver a package that will integrate into a client’s Makefile based build system where they can make changes and re-build. In other words, I don’t mind if building a BSP or updating RTEMS requires waf, but want to be able to deploy and make minor changes without it. Up to now I’ve been able to get the existing Makefile fragments to work at multiple sites with a little work. > On Sep 26, 2015, at 09:04 , Gedare Bloom wrote: > > The comment below, made in the users ml, caught me off guard. How will > user's applications build when RTEMS is built with Waf? > > If there is a complex answer, then this conversation belongs here on > the devel ml until we can sort it out. > > Gedare > > On Sat, Sep 26, 2015 at 2:36 AM, Chris Johns wrote: >> On 25/09/2015 11:04 pm, Jeff Webb wrote: >>> On 09/25/2015 07:59 AM, Gedare Bloom wrote: > The next task for me will be to set up a simple out-of tree C or C++ > POSIX > application. > > Thanks again for all the help! > > -Jeff > Simple examples for out-of-tree builds exist in the examples-v2.git repository with the "RTEMS Application Makefile" approach using custom Makefiles, and with the "RTEMS Application Waf" approach using wscripts and a git-submodule for waf support. The former is an older, established way to build applications linking to an 'installed' RTEMS, and the latter is a newer way to do it. >>> >>> Perfect! This is just what I need. Thanks for the pointer. >>> >> >> The Makefile approach will not be supported with the waf build of RTEMS >> when it lands. >> >> Chris >> ___ >> users mailing list >> us...@rtems.org >> http://lists.rtems.org/mailman/listinfo/users > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Peter - Peter Dufault HD Associates, Inc. Software and System Engineering This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
AW: Re: How will user's compile with Makefiles? Was: Re: large bss size for sample applications
Peter's statement gets a +1 for me. Makefile integration IMHO makes using RTEMS in many development systems rather easy. Forcing Waf for user development is a drawback. How can we avoid this? Wkr Thomas. Ursprüngliche Nachricht Von: Peter Dufault Datum: An: Gedare Bloom Cc: Amar Takhar ,"rtems-de...@rtems.org" Betreff: Re: How will user's compile with Makefiles? Was: Re: large bss size for sample applications I don’t like this requirement. I think it’s fine for development but want to be able to deliver a package that will integrate into a client’s Makefile based build system where they can make changes and re-build. In other words, I don’t mind if building a BSP or updating RTEMS requires waf, but want to be able to deploy and make minor changes without it. Up to now I’ve been able to get the existing Makefile fragments to work at multiple sites with a little work. > On Sep 26, 2015, at 09:04 , Gedare Bloom wrote: > > The comment below, made in the users ml, caught me off guard. How will > user's applications build when RTEMS is built with Waf? > > If there is a complex answer, then this conversation belongs here on > the devel ml until we can sort it out. > > Gedare > > On Sat, Sep 26, 2015 at 2:36 AM, Chris Johns wrote: >> On 25/09/2015 11:04 pm, Jeff Webb wrote: >>> On 09/25/2015 07:59 AM, Gedare Bloom wrote: > The next task for me will be to set up a simple out-of tree C or C++ > POSIX > application. > > Thanks again for all the help! > > -Jeff > Simple examples for out-of-tree builds exist in the examples-v2.git repository with the "RTEMS Application Makefile" approach using custom Makefiles, and with the "RTEMS Application Waf" approach using wscripts and a git-submodule for waf support. The former is an older, established way to build applications linking to an 'installed' RTEMS, and the latter is a newer way to do it. >>> >>> Perfect! This is just what I need. Thanks for the pointer. >>> >> >> The Makefile approach will not be supported with the waf build of RTEMS >> when it lands. >> >> Chris >> ___ >> users mailing list >> us...@rtems.org >> http://lists.rtems.org/mailman/listinfo/users > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Peter - Peter Dufault HD Associates, Inc. Software and System Engineering This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: How will user's compile with Makefiles? Was: Re: large bss size for sample applications
On September 26, 2015 9:52:37 AM CDT, "Thomas Dörfler" wrote: >Peter's statement gets a +1 for me. Makefile integration IMHO makes >using RTEMS in many development systems rather easy. Forcing Waf for >user development is a drawback. > > >How can we avoid this? > There are two pieces here. + a file with the list of tools, flags, etc. + the existing application Makefile structure. The application Makefile infrastructure is so old it predates automake. Long ago, I had a shell script called automake to generate them. This is before even releases on tape were shipped. Yes, pre-ftp. The first piece captures basic information required to integrate into any big system. The second is obsoleting an application Makefile system that has been present since before RTEMS was on ftp. I have no idea how widely it is used. But we don't have a formal decision on it that has been through user community review. I think all the core developers wouldn't mind removing it but we have no idea of the impact. If there is a high impact, we may be able to capture it as something not used inside RTEMS but as a kit for users. It rarely changes and depends on the first piece which I think we still need to publish with a BSP. A hard requirement is that we can't force a build system on users. We can provide guidance for popular options we may not personally use but that's about it. Instructions for Eclipse or Visual Studio integration for example. >Wkr Thomas. > > > > > Ursprüngliche Nachricht >Von: Peter Dufault >Datum: >An: Gedare Bloom >Cc: Amar Takhar ,"rtems-de...@rtems.org" > >Betreff: Re: How will user's compile with Makefiles? Was: Re: large bss >size for sample applications > > > >I don’t like this requirement. I think it’s fine for development but >want to be able to deliver a package that will integrate into a >client’s Makefile based build system where they can make changes and >re-build. In other words, I don’t mind if building a BSP or updating >RTEMS requires waf, but want to be able to deploy and make minor >changes without it. > >Up to now I’ve been able to get the existing Makefile fragments to work >at multiple sites with a little work. > >> On Sep 26, 2015, at 09:04 , Gedare Bloom wrote: >> >> The comment below, made in the users ml, caught me off guard. How >will >> user's applications build when RTEMS is built with Waf? >> >> If there is a complex answer, then this conversation belongs here on >> the devel ml until we can sort it out. >> >> Gedare >> >> On Sat, Sep 26, 2015 at 2:36 AM, Chris Johns >wrote: >>> On 25/09/2015 11:04 pm, Jeff Webb wrote: On 09/25/2015 07:59 AM, Gedare Bloom wrote: >> The next task for me will be to set up a simple out-of tree C or >C++ >> POSIX >> application. >> >> Thanks again for all the help! >> >> -Jeff >> > > Simple examples for out-of-tree builds exist in the >examples-v2.git > repository with the "RTEMS Application Makefile" approach using >custom > Makefiles, and with the "RTEMS Application Waf" approach using > wscripts and a git-submodule for waf support. The former is an >older, > established way to build applications linking to an 'installed' >RTEMS, > and the latter is a newer way to do it. Perfect! This is just what I need. Thanks for the pointer. >>> >>> The Makefile approach will not be supported with the waf build of >RTEMS >>> when it lands. >>> >>> Chris >>> ___ >>> users mailing list >>> us...@rtems.org >>> http://lists.rtems.org/mailman/listinfo/users >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > >Peter >- >Peter Dufault >HD Associates, Inc. Software and System Engineering > >This email, like most email, is delivered unencrypted via internet >email protocols subject to interception and tampering. Contact HDA to >discuss methods we can use that ensure secure communication. > >___ >devel mailing list >devel@rtems.org >http://lists.rtems.org/mailman/listinfo/devel --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] score: Fix atomic compare exchange
Hello Gedare, this part of the compare exchange operation is not used in 4.11. There are a couple of other issues with the low level SMP code that turned up after a review and this is a preparation patch. - Am 25. Sep 2015 um 22:38 schrieb Gedare Bloom ged...@rtems.org: > Sebastian, > Does this need to go on 4.11 / ticket filed? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
FWIW intptr_t and uintptr_t
Hi I was doing some investigation this week and noticed that both these types are optional in C99 and POSIX. We know gcc and llvm have them and checked on two (non Microsoft) closed source compilers. All supported it. I had always taken then for granted as part of C99. I think they are universally supported or nearly so. So no problem to use. Just a warning to keep squirrelled away. I don't think we should change anything. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: FWIW intptr_t and uintptr_t
The fixed size 8-bit, 16-bit, 32-bit and 64-bit integer types are optional too. I don't think this is a compiler issue. Some architectures may have problems to support such types. - Am 26. Sep 2015 um 21:30 schrieb Joel Sherrill joel.sherr...@oarcorp.com: > Hi > > I was doing some investigation this week and noticed that both these types are > optional in C99 and POSIX. We know gcc and llvm have them and checked on two > (non Microsoft) closed source compilers. All supported it. > > I had always taken then for granted as part of C99. I think they are > universally > supported or nearly so. So no problem to use. > > Just a warning to keep squirrelled away. I don't think we should change > anything. > --joel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: How will user's compile with Makefiles? Was: Re: large bss size for sample applications
I think there should be a requirement that you can deploy an RTEMS release at a site strictly using Makefiles. Not develop RTEMS or build RTEMS, but deploy RTEMS. I would prefer, but won’t go so far as to say it is a requirement, that one should be able rebuild a deployed BSP with changes via Makefiles. The barriers to using RTEMS in a subsystem at a company not committed to RTEMS must be kept as low as possible, and the additional work to someone suggesting RTEMS (me) must be kept as low as possible. > On Sep 26, 2015, at 11:13 , Joel Sherrill wrote: > > > > On September 26, 2015 9:52:37 AM CDT, "Thomas Dörfler" > wrote: >> Peter's statement gets a +1 for me. Makefile integration IMHO makes >> using RTEMS in many development systems rather easy. Forcing Waf for >> user development is a drawback. >> >> >> How can we avoid this? >> > > There are two pieces here. > > + a file with the list of tools, flags, etc. > + the existing application Makefile structure. > > The application Makefile infrastructure is so old it predates automake. Long > ago, I had a shell script called automake to generate them. This is before > even releases on tape were shipped. Yes, pre-ftp. > > The first piece captures basic information required to integrate into any big > system. > > The second is obsoleting an application Makefile system that has been present > since before RTEMS was on ftp. I have no idea how widely it is used. But we > don't have a formal decision on it that has been through user community > review. I think all the core developers wouldn't mind removing it but we have > no idea of the impact. > > If there is a high impact, we may be able to capture it as something not used > inside RTEMS but as a kit for users. It rarely changes and depends on the > first piece which I think we still need to publish with a BSP. > > A hard requirement is that we can't force a build system on users. We can > provide guidance for popular options we may not personally use but that's > about it. Instructions for Eclipse or Visual Studio integration for example. > >> Wkr Thomas. >> >> >> >> >> Ursprüngliche Nachricht >> Von: Peter Dufault >> Datum: >> An: Gedare Bloom >> Cc: Amar Takhar ,"rtems-de...@rtems.org" >> >> Betreff: Re: How will user's compile with Makefiles? Was: Re: large bss >> size for sample applications >> >> >> >> I don’t like this requirement. I think it’s fine for development but >> want to be able to deliver a package that will integrate into a >> client’s Makefile based build system where they can make changes and >> re-build. In other words, I don’t mind if building a BSP or updating >> RTEMS requires waf, but want to be able to deploy and make minor >> changes without it. >> >> Up to now I’ve been able to get the existing Makefile fragments to work >> at multiple sites with a little work. >> >>> On Sep 26, 2015, at 09:04 , Gedare Bloom wrote: >>> >>> The comment below, made in the users ml, caught me off guard. How >> will >>> user's applications build when RTEMS is built with Waf? >>> >>> If there is a complex answer, then this conversation belongs here on >>> the devel ml until we can sort it out. >>> >>> Gedare >>> >>> On Sat, Sep 26, 2015 at 2:36 AM, Chris Johns >> wrote: On 25/09/2015 11:04 pm, Jeff Webb wrote: > On 09/25/2015 07:59 AM, Gedare Bloom wrote: >>> The next task for me will be to set up a simple out-of tree C or >> C++ >>> POSIX >>> application. >>> >>> Thanks again for all the help! >>> >>> -Jeff >>> >> >> Simple examples for out-of-tree builds exist in the >> examples-v2.git >> repository with the "RTEMS Application Makefile" approach using >> custom >> Makefiles, and with the "RTEMS Application Waf" approach using >> wscripts and a git-submodule for waf support. The former is an >> older, >> established way to build applications linking to an 'installed' >> RTEMS, >> and the latter is a newer way to do it. > > Perfect! This is just what I need. Thanks for the pointer. > The Makefile approach will not be supported with the waf build of >> RTEMS when it lands. Chris ___ users mailing list us...@rtems.org http://lists.rtems.org/mailman/listinfo/users >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> Peter >> - >> Peter Dufault >> HD Associates, Inc. Software and System Engineering >> >> This email, like most email, is delivered unencrypted via internet >> email protocols subject to interception and tampering. Contact HDA to >> discuss methods we can use that ensure secure communication. >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/l
