New firmware release 1.0.0.b1
-
Hello everyone,
Firmware 1.0.0.b1 has just been released. These are the notes from the change log:
- Add bind method to LoRa sockets.
This allows to specify a port number different than the default of 2. - Add the Bluetooth network class with WiFi co-existence.
- Refactor the LoRa module to use event groups.
- Update to the latest IDF from Espressif
- Only try to send via LoRaWAN if the network is joined.
- Avoid glitches when configuring pins.
- Add support for SHA-224
- Allow to pass a manual DEV_EUI during LoRa OTAA join.
The most important feature here is that we have added BLE support, it's very basic for now, but we will now be able to start adding more features in the next releases. For details check the docs:
https://docs.pycom.io/pycom_esp32/library/network.Bluetooth.html
As usual the updater tools for the new firmware can be downloaded from:
https://www.pycom.io/support/supportdownloads/ (Under Firmware Updates)
Cheers,
Daniel
- Add bind method to LoRa sockets.
-
@livius regarding your problem trying to connect 2 WiPy's together, please check my reply in: https://forum.pycom.io/topic/376/interim-update/6
Thanks.
Cheers,
Daniel
-
Hi Mophor, we'll check this issue immediately and if there's a problem when performing a WiFi scan after a BLE scan then we'll fix it. Coexistence is happening for sure, you can check it by enabling BLE and doing the scan from telnet when being connected to the LoPy in AP mode.
The memory being overwritten is OK, that portion of memory is already reserved for BLE usage.
Cheers,
Daniel
-
@robert-hh @daniel If we end using LoPy for a project / class, it'd be great to have students build the whole thing, even if just once. Many had never installed an OS before working with a Pi.
-
@bmarkus
This is a common question with the ESP32 - see the long discussion at http://esp32.com/viewtopic.php?f=2&t=44&start=10ESP32 specs list RAM as one big block (400KB! 540KB!) however that's not really all available to applications - at least not in a simple way.
The ESP-IDF (the "core" SDK of the ESP32) is also not currently optimised for memory. From that thread the "official answer" is:
We indeed will be working on minimizing esp-idf RAM usage at a certain ? point in time; for now, we think it's more important to get all features in first.
Once the ESP-IDF reaches feature stability and they start look into memory improvements I'd expect those savings will translate into *Py environment as well
-
With each firmware update we get less and less free RAM. Now it is only 51k. During KickStarter campaign I got the impression to get much more free RAM. Seems that new features eat up memory. Does it mean that at the end of the road with working LoRa stack, BT and so on there will be no RAM available, or RAM availablity limits the introduction of new or missing features? Hope it is not the case.
Would appreciate an explanation how RAM is used by the system.
-
Hello Daniel, this is a big improvement. Would you mind to update the github repository, such that I can enable support of .mpy files?
Robert
-
@daniel
In this release note you have mentioned WiFi and BLE Coexistence, I have tried a very simple REPL script to check if that's true and I'm sorry to say I have found it's not!
I have tried importing BLE first like this:from network import Bluetooth ble = Bluetooth() # Heartbeat LED turns constant blue. ble.scan() # outputs a few bluetooth devices in 10 secs from network import WLAN wifi = WLAN(mode = WLAN.STA) wifi.scan() # REPL won't give back the control and it never finishes the taskThis is a little different if the order was reversed:
from network import WLAN wifi = WLAN(mode = WLAN.STA) wifi.scan() # Outputs list of WiFi devices very fast from network import Bluetooth ble = Bluetooth() ble.scan() # Outputs a list of BLE devices in 10 seconds. wifi.scan() # Won't return the control in ever.So, in essence, yeah, there is no co existence, even for the simple
scanfunctionality! This means ifBluetoothis imported, WLAN won't work. I have tested the Scan functionality for both but that's bad enough for my scenario.
Any comments?Update:
It seems vital to mention that from the looks of it, instantiating
Bluetoothoverwrites memory like this:from network import Bluetooh() ble = Bluetooth() BTDM CONTROLLER VERSION: 010101 btip start copy .data from 4000d890 to 3ffae6e0, len 00001830 set .bss 0x0 from 3ffb8000 to 3ffbff70, len 00007f70 BTDM ROM VERSION 0101 BD_ADDR: ..:..:..:..:..:..is that a right assessment?
-
@pipomolo I have faced the same issue last week. My problem was related to installed FTDI drivers. Have you tried to install FTDI drivers on your mac? if so, you need to remove one of them and leave just one acting driver live.
You can find more info on related FTDI driver's page info: http://www.ftdichip.com/Drivers/D2XX.htm
-
@daniel Hi Daniel, i have just tried to upgrade my 3 LoPy recently received, with the latest firmware here, and after installing the PyMaker (which works with the actual version of the LoPy) and then trying with the PyCom firmware Updade software, on an iMac, connected with USB cable (and selecting the /dev/cu.Bluetooth-Incoming-Port for Serial), i face the sameproblem. Failed.
It seems there is an issue with the serial / USB driver ?
I have tried with a MacBookPro also, and i face the same issue.
I use the same interface and cable to program my Arduino without issues.
i have tried also to change the speed (9600, 19200) in the .py file related, but no luck.thanks for pointing me to a relevant doc or tool.
-
@brotherdust said in New firmware release 1.0.0.b1:
One thought that occurs to me: what are other MP boards doing for BT (the BBC:micro comes to mind)? Isn't it more pythonic to not reinvent the wheel?
The particular Nordic part used in the micro:bit didn't have enough RAM (16K) to run both MicroPython and the BLE stack so they never implemented it.
They only support wired (!) networking and a simple proprietary radio protocol from Nordic.
So here we have a chance to be true pioneers.
-
One thought that occurs to me: what are other MP boards doing for BT (the BBC:micro comes to mind)? Isn't it more pythonic to not reinvent the wheel?
-
@daniel
The cb (CoreBluetooth) module in Pythonista could give some inspiration as well
-
@jasonriedy
I've been keeping an eye on the implementation status of the ULP coprocesssor functions in the upstream espressif-idf repository. Espressif has been making progress on it, but it doesn't seem like it's ready yet. Pycom did mention they updated their downstream idf repo, which means the ULP functions are present in C; but I didn't see any mention of ULP functions for MicroPython yet. Likely we will see it in them in the near future.For those interested, I'd strongly suggest occasionally reviewing the commit log on the upstream espressif-idf. It's pretty fun to watch!
-
@daniel
I suggest you take a look at CurieBLE's API as well (https://www.arduino.cc/en/Reference/CurieBLE). It's related to Intel's IoT enabled MCU you can find on Arduino/Genuino 101.
I have used it for a BLE project and it did the job quite beautifully.
-
@daniel They're hive sensors from Broodminder. The sensor pipes up every few seconds, but we likely only need the measurements every 10-15 minutes. Assuming that dropping to low power / standby during that time can be made to work... Otherwise might just gather all the data but only send it every longish time. The actual processing is minimal. We just need to re-arrange the bytes into a packet to send of to TTN.
-
@daniel Ah, but the Pi3 sees many devices advertising in the neighborhood.
-
Reinstalling the installer app every time is a bit annoying. Is it possible to have a direct link to a firmware file on the web site? Or at least please make OTA-version, that does not require install.
PS: I've updated the last firmware, machine.freq() is 160MHz now instead of 80. Magic :)
-
@jasonriedy and @jmarcelino I think you both have very good ideas around what the BLE API should look like. I'd love to hear your suggestions around that. We have also been looking and bluepy for inspiration.
Cheers,
Daniel
-
@jasonriedy right now the scan function only provides a list of the devices advertising in the neighborhood, so it makes sense to see only one entry in your tests. The next step (and it's what we will release soon) is to subscribe to a given device and get each of the advertisements messages that it sends.
Cheers,
Daniel
