Utilization of non-original code within Espruino?

Posted on
  • What should our policy and practices be on using non-original code within Espruino? For example, there appears to be an excellent candidate source code library that provides hardware SPI for ESP8266 ... see:

    https://github.com/MetalPhreak/ESP8266_S­PI_Driver

    What should we do if Espruino would like to include that within a board? Do we have precedent for using other libraries? Should we contact the authors and ask for permission? Do we have a "credits" page associated with Espruino where these authors can get the notifications that their licenses may require?

  • Sadly it depends on legality - whether the MIT licence can be distributed inside MPLv2. With MIT it's slightly less restrictive, so yes - I think you can.

    BUT generally I try and keep the libraries that get pulled in to a minimum - and in this case it doesn't seem worth it - the code is actually not that complex, so I'd be tempted to just use it as a reference and put what you need straight into jshardware.c.

  • Can we do that? Can we just take the source code from other libraries and merge them into our own files and no longer need attributions and licenses? That doesn't sound right.

  • Well, hopefully you wouldn't just copy it verbatim.

    For a lot of code, I end up googling and finding many sources to see how things are done - documentation, forums, examples and fragments of other code on GitHub.

    I should stress that I don't just copy/paste from proprietary code - but if I see they've had to call functions in a certain order to get something to work then I use that information. I think that's fair enough.

  • Lets take for example the library mentioned in the first post of this thread. It is comprised of one source file and two headers. Can we include that as-is in the Espruino project? If not, what should we do?

  • Well, if you absolutely had to I would contact the author and see if he'd be happy for it to use the MPLv2 license (he probably would be), then you can include it under MPLv2.

    BUT the library is just a collection of register poking code that's also available elsewhere it seems (if you google bits of it). That code should really go in jshardware.c, not a separate library - especially as the library would need quite a lot of modification to work efficiently with Espruino's jsSPISend command. You're basically going to end up rewriting it anyway.

  • I am not seeing any obvious modification needed to the library as is .... here is my thinking. SPI hardware support is indeed a lot of register poking. Quite a bit of it in fact. The complexity of decoding the registers and making the correct sequence of register pokes is complex. This library has done the hard work of that. It exposes "high level" APIs for driving hardware SPI. For example, it has an API to set the clock speed, it has an API to send/receive bits and to specify the bit length ... and it has an API to determine if an SPI request is currently in progress.

    By treating these capabilities as "black box" then the jsSPISend and related Espruino interfaces become controllers for the black-box capability of the MetalPhreak library.

    If my thinking is sound, then the ESP8266 SPI hardware library would be leveraged "as-is" without any modification upon it. So ... there will be jshardware changes needed ... but these will drive MetalPhreak without ever having to "look inside" the register poking complexities.

    Is this your thinking too?

  • Oh well, I see you've done it regardless of my answer so I won't waste any more of my time on this.

    Did you ask if he'd let it be licensed as MPLv2?

    I'd be pretty certain that the library code will in fact be too slow to handle WS2811. In fact it might well be slower than software SPI.

  • We got permission from the author of MetalPhreak for inclusion of the code in Espruino ... in fact he is happy to change the license in any way ... see the following:

    https://github.com/MetalPhreak/ESP8266_S­PI_Driver/issues/7

    He is a good chap and happy to accommodate as needed.

    As for the integration of hardware SPI. The first pass is understanding the architecture of Espruino as it relates to hardware SPI ... we made some notes on this here ... https://github.com/espruino/Espruino/wik­i/SPI-Architecture

    Then we implemented these architected functions using MetalPhreak that worked out just great.

    I don't think anyone is saying that this is the best solution or couldn't be dramatically improved. However it does now gives us a functional base line to start with. I am super keen that we all collaborate with each other ... I'd be delighted to devote time to changing the implementation and design ... but it will be best served by community involvement with you as the leader.

  • ...let's get ESRs going... like JSRs... ;-)

  • @allObjects For each change to Espruino, there is usually a Github "Issue" created where folks can freely chime in with their comments, questions, suggestions and notions ... see for example:

    https://github.com/espruino/Espruino/iss­ues/606

    Do you think these are useful?

  • I think so, they can become the document(s) for ESRs. Everything moves towards begin stored in github... and that's just another case. My (positive) comment was triggered by your paragraph in general and its concluding phrase in particular:

    I don't think anyone is saying that Xyz is the best solution or couldn't be dramatically improved. However it does now gives us a functional base line to start with. I am super keen that we all collaborate with each other ... I'd be delighted to devote time to changing the implementation and design ... but it will be best served by community involvement with you as the leader.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Utilization of non-original code within Espruino?

Posted by Avatar for Kolban @Kolban

Actions