PS: can you send a link to your PR? I couldn't find it. Cheers, Ludwig
Am 26. Februar 2015 07:23:52 MEZ, schrieb Ludwig Ortmann <ludwig.ortm...@fu-berlin.de>: >Hi Murat, > >Under what license are the generated files? >And also, how do you think your port is related to the discussion in >this thread? > >I can try to talk about this topic with a cypress representative today. >We are currently at the "embedded world" and they are too. They seemed >interested in RIOT in an initial chat. >BTW: As far as I understood it, their software can create object files >with library code for the psoc. Therefore I guess it should be possible >to link the generated psoc library with RIOT in our make system as >well. > >So, whatever it looks like today, please don't close your pull request >yet. > >Cheers, Ludwig > >Am 25. Februar 2015 21:46:45 MEZ, schrieb Murat CAKMAK ><m...@muratcakmak.net>: >>Hi All, >> >> >> >>I was (still) busy to read mails about LGPL compliance so sorry for >>slience. >> >> >>As you know, I have initially ported RIOT to PsoC 5LP processor by >>creating >>a PsoC Creator IDE Projects. >> >> >> >>In my case: >> >>1. This port not using the default RIOT build environment and >>PsoC >>Creator IDE hides linking and other details. >> >>2. PsoC Creator IDE also creates automatically some source >codes. >>I >>have created an empty project with a small HW design under >>dist/PsoCCreator >>directory. But when you build project in PsoC Creator IDE, It is going >>to >>create a lot of files; system initialization, APIs for HW blocks which >>created for RIOT etc. I was not planning to commit those files to GIT >>repository because they are already created automatically by IDE. >> >>3. Auto-generated files may be changed (e.g bug fixing) by the >>version >>of PSOC Creator IDE. So, md5 sums may be different for different >>versions of >>PsoC Creator IDE. >> >> >> >>On the other hand, I can also implemented required files instead of >>auto-generated PsoC Creator files, and use RIOT build system. But HEX >>files >>of PsoC processors also includes HW desing code (verilog) addition to >>firmware output(elf, hex etc.). I dont know how PsoC Creator IDE >merges >>Firmware code and HW design code into a single HEX file and I am not >>sure >>about PSOC Creator team share this information with me. >> >>It is the hard way and also I dont prefer to use this way. Because, in >>this >>way, we can not use advantages(ARM Core + Programmable Digital&Analog >>Blocks) of PsoC processors which only available by PsoC Creator IDE. >> >> >> >>So, What is the latest decision? >> >>Should I withdraw my "pull request" for PsoC 5LP port? >> >> >> >>Regards. >> >> >> >>Murat. >> >> >> >> >> >>-----Original Message----- >>From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Matthias >>Waehlisch >>Sent: Saturday, February 21, 2015 5:09 PM >>To: RIOT OS kernel developers >>Subject: Re: [riot-devel] LGPL compliance testing >> >> >> >>Hi Kaspar, >> >> >> >>On Fri, 20 Feb 2015, Kaspar Schleiser wrote: >> >> >> >>> Let me correct myself. >> >>> >> >>> There are no technical reasons against using LGPLed RIOT to develop >> >>> proprietary applications. >> >>> >> >> it depends on how you define "technical reasons". Yes, it is not >>impossible to create separate object files. But you maybe don't want >to >>do >>this for technical optimization (see for example >><http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL >>.pdf> >>http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL. >>pdf). >> >> >> >>> Using a "weird compiler" that cannot output the required object >files >> >> >>> because it is closed source and proprietary is purely political. >That >> >> >>> compiler could be changed trivially *if it would be open source* or >> >>> the vendor was inclined to do so. This doesn't count as technical >> >>> reason. >> >>> >> >> I agree with Oleg's comment on this. >> >> >> >> And btw, if a compiler can "be changed trivially" depends on details >I >>suppose. >> >> >> >>> > For me the sentence "RIOT allows LGPL + proprietary source code > >> >>> > at the same level of comfort compared to Linux" sounds like a >cheap >> >> >>> > marketing slogan making clear that the persons are not aware of >the >> >> >>> > IoT diversity. >> >>> Saying otherwise makes clear that the persons are not aware of the >> >>> troubles embedded linux companies go through when developing >> >>> proprietary devices using (L)GPLed linux + libraries. >> >>> >> >> Both systems address different types of devices. >> >> >> >>> > From a professional point of view, I would not base strategic >> >>> > decisions on the discussed PR/idea. >> >>> What profession would that be? >> >>> >> >> Having an almost complete picture of the landscape. >> >> >> >> >> >>Cheers >> >> matthias >> >> >> >>-- >> >>Matthias Waehlisch >> >>. Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . >Takustr. >>9, >>D-14195 Berlin, Germany .. <mailto:waehli...@ieee.org> >>mailto:waehli...@ieee.org .. <http://www.inf.fu-berlin.de/~waehl> >>http://www.inf.fu-berlin.de/~waehl >> >>:. Also: <http://inet.cpt.haw-hamburg.de> >>http://inet.cpt.haw-hamburg.de .. >><http://www.link-lab.net> http://www.link-lab.net >>_______________________________________________ >> >>devel mailing list >> >> <mailto:devel@riot-os.org> devel@riot-os.org >> >> <http://lists.riot-os.org/mailman/listinfo/devel> >>http://lists.riot-os.org/mailman/listinfo/devel >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>devel mailing list >>devel@riot-os.org >>http://lists.riot-os.org/mailman/listinfo/devel > >_______________________________________________ >devel mailing list >devel@riot-os.org >http://lists.riot-os.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
