Firmware source code?
-
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.
-
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.
-
Hi schuschu,
I understand your disappointment. We are working as fast as we can to bring the firmware and the docs to level of quality that is needed. We are also considering several options around the open source matter. Hopefully your impression will be better soon.
Cheers,
Daniel
-
Don't get me wrong here I appreciate all you hard work, but I have little to no use for the IDE or the Android App. I would however like to try the quite impressive peripherals in the ESP32 especially with their internal pin mux this could be awesome. But as long as I cannot develop in C i'm basically locked to the features you care to implement and one day, maybe even care to document (I sill cant even get working LoRa connection as the defines for the spreading factor are just not there, whatever 7 is its the only one that appears to work). If we have to wait for you to built a firmware with support for say ethernet or I2S (which you never promised so of course you have no obligation to even develop such a module) this could take quite some time.
I know by now that nothing we say here will change your business strategy, even though so far you have the only viable development board for the ESP32 out there (saying nothing about the LoPy and SiPy which offer features that no other board will add anyway) which should ensure sales (for a time). As far as I remember micropython supports inline assembler which could be leveraged to cross compile C (using the esp32 sdk) to something we could run. It just bums me out that I have to boards which is essentially capped to what the esp8266 provides, with some more RAM and two cores.
-
@daniel I have to say that I too feel very misled and disappointed. If this is not an open source project then I hope you guys are going to get your act together with fixing all of the issues - as it is currently not fit for purpose. I thought your excuse was going to be that we were "all in it together" and needed help fix things, but if it isn't open source we don't have that option so there is much more responsibility for you to provide a working product.
So far the experience of LoPy has been awful - given the hardware delays you've had even longer than originally expected to get the documentation, examples and firmware up to scratch. Even the few examples you've provided frequently don't work suggesting you haven't even taken the time to try them out on the LoPy.
-
Wait, what? This is some shocking and upsetting news. I feel completely deceived here.
I backed this project, and also ordered additional LoPys on top of that, based on your (well-earned) reputation as skilled, open-source friendly engineers. This I gathered from previously having closely followed and interacted with the ESP8266 and MicroPython communities, including backing several of the previous WiPy and MicroPython related Kickstarter campaigns. Moreover, for the last weeks -- now that LoPy is on its way out to customers, I've been waiting for an "esp32" or "lopy" directory to be merged into the MicroPython code base, or to see a (firmware) code dump show up in a repo on one of your GitHub organizations.
You've consistently marketed your goals and products as open-source this and open-source that. Pointing out how much you love open-source, how it's a key concept to you, how this LoRa protocol is open (despite being of a different kind of "open"), etc. Pretty much every Kickstarter update has been sure to mention the word "open" and/or "open-source" a few times. Combine this with the fact that several popular SoCs among the electronics hobbist communities are well supported with open-source components such as Arduino, MicroPython, FreeRTOS, compiler suites or drivers for various things. They're hackable, fun and invite creativity.
And now you're pretty much out-of-the-blue telling everybody that LoPy was never meant to be an open-source product!? I'm sorry, but had you made this clear from the beginning, that you would produce yet another SoC with a blackbox firmware, something many of us are all too familiar with from the Linux WiFi world, I would personally have thought twice about backing this project. I mean, a module with LoRa, WiFi and BLE which runs MicroPython is cool and all, but with a 100% closed source firmware it's not so awesome any more. Why would I choose LoPy over something similar from a different vendor?
(Btw, ,it's irritating that the latest blog post, the very one that is supposed to explain this misconception that the LoPy is in fact NOT an open-source product, has a headline with the postive words "Open-source" -- I assume you're not doing this intentionally?)
I'm all for "buy quality, cry once". For me, a big slice of "good quality" is open-source components, hackable software and strong community support. Like others, I've come to appreciate open-source stuff because that means I don't necessarily need to live with consumer electronics and hardware that contains firmware that is neither well-maintained nor hackable. I can make a choice that doesn't involve throwing the thing out. Commonly this includes TVs, CPEs (broadband routers), many (ironically) Android-based devices and now IoT-like devices. Regressions and security vulnerabilities are a real issue, too. And with new hardware, the fact that it is sold as having support for X, Y and Z despite not actually being delivered with software support for those features from day one, or even for several months to come. With open-source and a strong community, that can be taken care of even if the vendor drops supports for the product (EOL), goes bust or even goes "rogue" like, say, 3D-printer vendor Makerbot infamously did when it sold out. For the consumer, another benefit of open-source is that you can alleviate the dreadful vendor lock-in.
While I'm not happy that you've (IMHO) effectively done a bait-and-switch with your open-source talk (and street creds in the community) for the LoPy firmware, I don't want to come off as some overly negative and complaining customer.
Hands-down, I'm very impressed with what you've achieved so far. I can't imagine how much hard work you've been through to make this happen. I hope your roadmap includes a healthy vacation to the tune what China recently had with the Golden Week.
-
Hello schuschu,
I'm sorry to disappoint you. I see that the statement we made during the Kickstarter campaign was not completely clear. We do give back to the open source community as part of the MicroPython core, so saying the we build on top of the work of others and we don't give anything back is a bit unfair.
We'll make a public announcement to clarify what we said during the Kickstarter campaign.
Cheers,
Daniel
-
So in other words were are stuck with whatever firmware you guys come up with and that's it? You guys even handed out the source for the WiPy which was the sole reason I bought the 2.0 version and a LoPy.
Kinda disappointing news. Building on the work of others and not giving back is just a d*** move, I thought you guys were better than that.
-
I'd say the "We believe in open source" is quite misleading. It would be better better to say "We use and contribute to open source".
Of course, I still appreciate that the threading feature was contributed back, so thanks for that.
It just means that I won't be personally buying any LoPy/WiPys until I can build my own source for it,since the espressif SDK is still under such heavy development. I definitely don't wanna be tied down from using new features as they come available.
-
That claim was about the threading features, e.g.:
https://github.com/micropython/micropython/blob/master/py/modthread.c
which Pycom funded and are open source.
Cheers,
Daniel
-
Guess I misunderstood this banner on the Kickstarter campaign...
-
The LoPy was never meant to be an open source product.
