Firmware source code?
-
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?
-
@jeremy I'm considering developing a proof of concept for a possible commercial product, and the LoPy 4 board would be an ideal choice for a POC demo. I'm just concerned with what the LoPy board has for battery management for both our back pack units and relay stations. It's the relay stations that has to be smart on battery management, although we think we can get away with 1 watt solar panels for the relay stations, both initially designed around the LoPy, but who do we talk to to at PyCom to talk about licensing the LoPy for commercial use?
-
@robert-hh said in Firmware source code?:
The starting point for the network module is in:
.../pycom-micropython-sigfox/esp32/mods/modnetwork.c
there is also the file modlora.c. More LoRa related files are in:
../pycom-micropython-sigfox/drivers/sx127x/...
../pycom-micropython-sigfox/lib/lora/...
And yes, almost all of it of it is written in C.GREAT, I had no idea I had to look in the "mods" directory. Thanx a lot. This is just what I'm looking for.
-
@jdcrunchman The starting point for the network module is in:
.../pycom-micropython-sigfox/esp32/mods/modnetwork.c
there is also the file modlora.c. More LoRa related files are in:
../pycom-micropython-sigfox/drivers/sx127x/...
../pycom-micropython-sigfox/lib/lora/...
And yes, almost all of it of it is written in C.
-
@daniel I took a look at those links to GitHub you posted, and looked through each one, but I did not find any references to source code from these URL's. https://github.com/pycom/ and https://github.com/wipy, as well as https://github.com/pycom/pycom-micropython-sigfox.
Although I did glance through the URL just above, and saw such modules as "board.c" and other modules written in C. Is the LoRa module written in C with Python hooks, or in Python in pycom-micropython-sigfox/esp32/lora/
Or am I looking in the wrong place. The import statement...
"from network import LoRa"So would I be be looking for "network"? I went through almost everything in "sigfox" . I could not find the "network" module. I hope this more detailed description is more clear.
In the main pycom list of repo's, which lists a whole bunch of repo's, although I didn't check each repo, I didn't see anything.
So if it's in a specific repo, a more direct path would be appreciated.Thanx
-
@jdcrunchman you should probably read the post just before yours.
-
@jdcrunchman The firmware itself is open source and published, the hardware is not. Many people are asking for more information about the hardware, especially since Pycom is sometimes a little tardy in responding to hardware related issues.
Some code, like the one for the PIC on the expansion boards, was never published, even if Pycom, promised to to so.
-
@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.
-
@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
-
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.
-
@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.
-
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.
-
@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,
DanielConsider 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.
-
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
-
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.
-
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. ;-)