New firmware release 1.5.0.b1 and SiPy Sigfox certification completed
-
Hello everyone,
Firmware version 1.5.0.b1 is out. Here's the change log:
- Enable AP+STA mode.
- Add parameter to BLE services to specify the number of characteristics.
- Increase available FreeRTOS heap to make SSL work again.
- Increase the MicroPython heap size to 64K.
- Allocate memory for Bluetooth structures at runtime.
- Allocate memory for PWM at runtime.
- Remove unused Pin elements, reordered them in bit fields, save 8 bytes per pin.
- Change time.time() back to integer because mp_float_t is not a double.
The most notable improvement here is that SSL works again and that the MicroPython heap size has been increased to 64K (and there will be more increments next week).
If you don't have the latest updater tool, please go ahead and get it here:
https://www.pycom.io/support/supportdownloads#firmwareAnother good news is that today we achieved Sigfox certification for the SiPy in RCZ1, RCZ2 and RCZ4. We are busy completing all the details so that early next week we can release an new updater tool that will allow to upgrade the SiPy firmware and flash it with the ID, the PAC and the Keys so that it can be activated on the Sigfox network.
Cheers,
Daniel -
Hello
Thanks for your great work!
Is the hardware I2C support part of this release as well like anounced two weeks ago?Kind regards,
Markus -
Awesome! And thanks for also updating the Github repo even on a Friday night, you know your users well 😉
-
still not enough for my needs
MemoryError: memory allocation failed, allocating 136 bytesbut nice progress :)
(sysname='WiPy', nodename='WiPy', release='1.5.0.b1', version='v1.8.6-409-gc86bfcc on 2017-01-27', machine='WiPy with ESP32') >>> micropython.mem_info() stack: 752 out of 7168 GC: total: 64000, used: 14608, free: 49392 No. of 1-blocks: 307, 2-blocks: 16, max blk sz: 256, max free sz: 2692gc.collect()>>> micropython.mem_info() stack: 752 out of 7168 GC: total: 64000, used: 12048, free: 51952 No. of 1-blocks: 134, 2-blocks: 23, max blk sz: 256, max free sz: 2692 -
Very nice version. I also notice the the primary interest is BT. What is the plan for sleep and deepSleep?
Thanks!
-
After upgrading to the latest firmware,suddenly
if not wlan.isconnected():Eventhough the WLAN connection is connected,it reinitates the WLAN connection everytime.
And one more stuff that i noticed was,after syncing few of my python files are getting synced properly and when i open it,i see some lines of code are missing which is present locally in my system(I am using FireFTP plugin to view the files).For Example the lopy_lcd.py module i am getting the error asTraceback (most recent call last):
File "<stdin>", line 32, in <module>
File "<stdin>", line 25, in displayMsg
File "lopy_lcd.py", line 306, in addString
NameError: name 'ofd' is not definedThese were working before :(
Thanks & regards,
MK HB -
Thanks so much, the extra space is much appreciated.
But coincidentally, I2C seems to have stopped working, the exact same code that ran on 1.4 now just throws a bus error with every device I try.
Can someone elsse verify that I2c is working for them ?
Update
@daniel - OK, confirmed, I just downgraded to 1.4 and I2C works again, seems to be broken in 1.5
-
@constantinos said in New firmware release 1.5.0.b1 and SiPy Sigfox certification completed:
Very nice version. I also notice the the primary interest is BT. What is the plan for sleep and deepSleep?
Thanks!
I would also like to know about deep sleep
-
machine.idle() is btw not working. The MCU continues with execution of code, even though the function is called.
-
@daniel
Thanks for the update.
GATT Server's Notify functionality (core to proper functionality of GATT Servers), promised for the last week's update, is STILL missing, which is a very very bad news for us. :( -
I2C has stopped working.
-
We will investigate the I2C problem and provide a fix today or tomorrow.
machine.idle() only stops the CPU until an interrupt occurs (and there are several internal interrupts, including the system tick every 1ms). The machine.idle() function is mean to be called inside a loop when you are waiting for a callback to fire.
-
This release was more focused on memory improvements.
@mohpor pleasd give me more details around the way you need the notify functionality to work on the GATT server. Thanks
Cheers,
Daniel -
Here is what we need:
-
Being able to actually
Subscribeto a Characteristic defined in a GATTS: Currently, when you try to subscribe to characteristics defined in service in GATTS, the subscription would simply fail and will report to the subscriber that it has not been subscribed. -
Get notifications from a GATTS Characteristic when the
Valueis updated, even if the notification could be sent manually. Other device's BLE Stack like Curie, Nordic, ATMEL, ... they all send the notification, if: There is a subscription on a characteristic and the value gets updated by device.
More Technically:
Service Changed characteristic present on the server
In this case, a client needs to subscribe to the server-initiated updates by writing into the corresponding CCCD enclosed within the Service Changed characteristic (see Characteristic Descriptors). This will allow the server to alert the client of any structural changes. If the client and the server are bonded as described in Security Modes and Procedures, the client can cache attribute handles across connections and expect them to remain identical. If the devices are not bonded, the client will need to perform discovery every time it reconnects to the server.from: https://www.safaribooksonline.com/library/view/getting-started-with/9781491900550/ch04.html
-
-
@daniel or @abilio
On the I2C issue:I2C is open drain and uses the GPIO_MODE_INPUT_OUTPUT_OD mode flag. This includes one bit to set open drain
#define GPIO_MODE_DEF_OD (BIT2)which is 4 (or b100)I noticed in the latest bitfield changes mode became a 2 bit field in pin_obj_t (set in esp32/mods/machpin.h)
unsigned int mode : 2;so to me it appears mode doesn't have enough bits to hold the _OD open drain bit. It should be 3 bits:
unsigned int mode : 3;I tested this change on my fork and I2C - which was behaving very erratically - is now working well again. So it could well be a very simple fix :-)
-
@jmarcelino thanks for investigating the issue. You are right. I'll apply the fix now and release a new version in a few minutes.
Cheers,
Daniel -
@daniel said in New firmware release 1.5.0.b1 and SiPy Sigfox certification completed:
We will investigate the I2C problem and provide a fix today or tomorrow.
machine.idle() only stops the CPU until an interrupt occurs (and there are several internal interrupts, including the system tick every 1ms). The machine.idle() function is mean to be called inside a loop when you are waiting for a callback to fire.
Right, then I misunderstood it completly.
-
I tested this change on my fork and I2C - which was behaving very erratically - is now working well again. So it could well be a very simple fix :-)
I wish you could make a PR to somehow break this open-source barrier we've set ahead of us and maybe encourage others to do the same!
Cheers,
M. -
@mohpor anyone can open a PR on the repo: https://github.com/pycom/pycom-micropython
and propose changes.
Anyway, this will be much easier once we merge our port with the official MicroPython repository.
Cheers,
Daniel -
@daniel
I know they can, I meant I wish he would've!Cheers,
M.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login