Firmware source code?

[LoneTech]

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]

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

[LoneTech]

@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.

[jeremy]

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.

[throwaway]

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?

[jeremy]

@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.

[dhylands]

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.

[karl-nl]

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

[Xykon]

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.

[Xykon]

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.

[daniel]

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

[Xykon]

@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.

[remcohn]

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.

[daniel]

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 :-)

[jeremy]

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.

[littlebat]

@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.

[interval]

@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?

[sriram.reddy]

Very disappointing. We were planning to integrate into our commercial IOT solution. Potential of buying up to 100s of lopy modules. With this kind of bad reputation, we are opting a board with a full open-source even though it cost slightly more. Thanks for misleading and wasting our R&D time.

[daniel]

@sriram-reddy Apologies for the misunderstanding, I think this very old thread is confusing you. Everything is open source now and we have many customers using our sources to build their own custom firmware. Please have a look at it here:

https://github.com/pycom/pycom-micropython-sigfox

and in general to all our repos: https://github.com/pycom

Cheers,
Daniel

[jdcrunchman]

@jeremy We were going to purchase about 5 LoPy4 units to get an early start on software development, but alas, just learned that the Python modules supporting it, is not Open Source, so we decided not to order the LoPy boards until we can be sure to get access to the source code.... we have a better battery management hardware circuitry we could just "Add" to the board, but also want Python control over it, but have no example code that offers any clue about how Python touches the hardware.