Firmware source code?


  • Global Moderator

    I have asked this in various topics now but never got a response.

    Where can I find the firmware source code? Can't find anything under https://github.com/wipy

    Edit: I did find this GitHub account: https://github.com/pycom/

    Is this your new official corporate account? Should we expect the LoPy firmware sources to be published here?


  • Pybytes Beta

    @Xykon said in Firmware source code?:

    Well the good news is that I managed to dump the Lopy firmware so I can erase the flash, experiment with the ESP32 SDK and come back to the MicroPython firmware at any moment.

    If you don't want to release the schematics then at least a block diagram would be nice to see how everything inside is connected and which pins are what on the header.

    Kinda curious what you installed to play with the esp32 sdk with. Did you just use esp-idf like you would a regular esp32 module?



  • @jeremy said in Firmware source code?:

    Any thoughts on this?

    Yes I agree with you. Perhaps MPL could be considered? GPLv3 does not seem to offer any additional protection against hardware cloners who don't really want to modify the software anyway. So unless there are different terms for running on official pycom hardware or an available commercial license version then not sure of the advantage. Being able to use some proprietary C application code is quite important.



  • While I of course applaud the announcement to open source the firmware, I see two problems with the use of GPLv3:

    If I use the LoPy in a commercial product for a client, it means that they must also release the encryption keys, etc for their product. Which for a lot of them is a non-starter. From the GNU page: https://www.gnu.org/licenses/quick-guide-gplv3.en.html

    Tivoization is a dangerous attempt to curtail users' freedom: the right to modify your software will become meaningless if none of your computers let you do it. GPLv3 stops tivoization by requiring the distributor to provide you with whatever information or data is necessary to install modified software on the device. This may be as simple as a set of instructions, or it may include special data such as cryptographic keys or information about how to bypass an integrity check in the hardware. It will depend on how the hardware was designed—but no matter what information you need, you must be able to get it.
    

    On top of this, if there need to be any customisations to micropython (such as custom C modules for peripherals, etc), they would be forced to license their code under GPLv3 as well. Which again, is a basically a non-starter.

    It's also unlikely to be upstreamed (maybe?) into the micropython source code, given that micropython is MIT. Maybe Damien would be amenable to this, but it would be very confusing to have different ports with different licenses and a compiled version would be forced to license via GPLv3.

    Any thoughts on this? I'm guessing you are trying to protect your revenue stream (which is presumably hardware modules at this point), so how about something like MIT license for people who use the LoPy/WiPy board, and GPLv3 otherwise? But I daresay that someone (maybe even me!) is still going to port micropython to ESP32 with an MIT license once the ecosystem (and supply) stabilizes.


  • administrators

    Alberto Piganti (pighixxx) is busy designing some beautiful pin-outs for for the LoPy, the WiPy 2.0 and the Expansion Board, which will look similar to this:

    http://www.pighixxx.com/test/wp-content/uploads/2016/07/Metro_pinout_final.png

    They will be detailed enough to provide all the info about the internals of the hardware :-)



  • A blockdiagram like this is also really helpfull (and i think even required) to use this piece of wonderfull hardware with the arduino IDE later.


  • Global Moderator

    @daniel said in Firmware source code?:

    A lot of open source discussion here and there with my Pycom team. I think we have now exciting news for all the open source enthusiasts. We are just getting the details sorted and we'll announce everything next week. Please be patient and sit tight people.

    Cheers,
    Daniel

    Consider me excited :)

    I do hope this covers not only the firmware but also the hardware. I'm not interested in the value of every resistor and capacitor on the LoPy, or even the exact schematics. As I said before a block diagram showing the internal and external connections would be enough for me. I do like to experiment with the ESP-IDF SDK without having to invest in yet another prototype board, and that is not possible without understanding how the LoPy is wired internally... or at the very least it would be a lot of work to figure out on your own.

    That being said I do appreciate you giving this a second thought and I'm looking forward to next week.


  • administrators

    A lot of open source discussion here and there with my Pycom team. I think we have now exciting news for all the open source enthusiasts. We are just getting the details sorted and we'll announce everything next week. Please be patient and sit tight people.

    Cheers,
    Daniel


  • Global Moderator

    In case anyone else wants to give this a try I did this enough times now to be comfortable this is working properly. Download this tool which contains esptool.py and connect a cable jumper between GND and P2 (G23 on the expansion board). Replace COM24 with your COM port number (check device manager).

    To backup the LoPy Micropython firmware run:

    esptool.py --chip esp32 --port COM24 --baud 115200 read_flash 0 4194304 lopy_firmware.bin

    To restore the LoPy Micropython firmware run:

    esptool.py --chip esp32 --port COM24 --baud 1115200 write_flash 0 lopy_firmware.bin -ff 80m -fs 4MB -z

    Under Linux replace COM24 with /dev/ttyUSBx (x=your serial usb com port number, usually 0 if it's the only USB serial device).

    There is an error message at the end of the restore process:

    A fatal error occurred: Timed out waiting for packet content

    You can ignore this error.

    I'm not taking any responsibility if you brick your LoPy or loose your MAC address which is stored in flash. It's a good idea to write down the MAC address of your LoPy in case something goes wrong.

    P.S. One thing I noticed is that when I use the ESP32 SDK directly I can't get a Wifi signal unless I connect an external antenna. I'm guessing I need to set a pin on the esp32 to either choose internal or external antenna. But without any schematics that's hard to guess.


  • Global Moderator

    Well the good news is that I managed to dump the Lopy firmware so I can erase the flash, experiment with the ESP32 SDK and come back to the MicroPython firmware at any moment.

    If you don't want to release the schematics then at least a block diagram would be nice to see how everything inside is connected and which pins are what on the header.



  • That's no issue at all. Just introduce every feature I need quickly and 100% working straight away. ;-)



  • Sigh - I wish I knew that before. I never would have backed it.

    I haven't received mine yet, but I now have no intention of even opening the package.



  • @throwaway yes, that is what I meant. The lora and iot stuff could get hidden in a blob, and the micropython bits could be open.



  • Personally I'd be happy if Pycom could just stuff away the secret sauce in a Pycom SDK library, much like Espressif does with the ESP8266 or what TI does with the CC3200, and then release the rest, preferably as a MicroPython port. I don't care much about the hardware (design) itself and being open or not.

    What is so special with this product that warranted a fully closed firmware anyway?



  • I also find this quite disappointing. I was under the impression that the firmware source would be available just like the wipy, it's why I bought 11 lopys! I'm not sure the idea of a closed source development board is congruent with the "maker/hacker" ideas in my head, especially because the micropython (and python!) code base is expressly designed as hackable and easy to change/patch. I think I will be recommending to colleagues and friends that they stick with the wipy instead.



  • @daniel Thanks, and apologies for my impatience. I found the roadmap at https://www.kickstarter.com/projects/1795343078/lopy-the-lora-wifi-and-bluetooth-iot-development-p/posts/1709739 yesterday, which inspires more confidence but still has some minor gaps; for instance I'd like to add some of the crypto blocks for SSL, SSH and similar. I'm going to start looking at peripherals through uctypes, but naturally there are some risks of collisions that way and I can't easily do interrupt handling.


  • administrators

    The pull up/down stuff it's fixed already, as well as the reset_reason() function, those will be on the Friday release. The threading functionality will come later, please see this:
    https://github.com/espressif/esp-idf/pull/21



  • I for one would much appreciate source access, which would let me fix things like how pullups don't work in the GPIO interface, reset reason isn't readable (and the values are missing), timer is absent, SD card appears to be as well.. and yes, I can probably do most of that without requiring the ESP32 SDK to catch up. The reference manual covers most of it. Some things are purely micropython bugs. Looking forward to if the Friday update fixes things. Also, any timeframe on when the Pycom-sponsored threading appears on these boards?



  • @daniel I too am hoping for better - I realise it is early days but I thought there would be far better documentation and samples. I see people asking rudeimentary questions about things like which pins are used for I2C,SPI, Uart etc. and can't find anything. Hopefully, this is all in the pipeline but is such basic stuff that it should have been available some time ago.

    There are a lot of Noobs with no LoRa experience who need a helping hand. What may be obvious to some, needs explaining step by step for others.

    Here's hoping!



  • To be fair most of the blame for the current functionality or lack thereof goes to the esp32 SDK for not being feature complete yet, to put it mildly. There will be a way to run custom arduino or C apps and I would be surprised if there is not another open source port of micropython to esp32 within the next 6 months. Some people will still feel duped that they thought they were buying into an open source ecosystem.


Log in to reply
 

Looks like your connection to Pycom Forum was lost, please wait while we try to reconnect.