New firmware release 1.5.0.b1 and SiPy Sigfox certification completed


  • administrators

    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#firmware

    Another 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



  • @mohpor
    There was no open issue on Github for this problem and to me changing a 2 to 3 didn't seem to warrant opening a PR so I simply brought it up on the forum, seemed to be most practical way of addressing this.



  • @daniel
    I know they can, I meant I wish he would've!

    Cheers,
    M.


  • administrators

    @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



  • @jmarcelino

    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.



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


  • administrators

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



  • @daniel

    Here is what we need:

    • Being able to actually Subscribe to 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 Value is 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


  • administrators

    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


  • administrators

    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.



  • I2C has stopped working.



  • @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. :(



  • machine.idle() is btw not working. The MCU continues with execution of code, even though the function is called.



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



  • 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



  • 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 as

    Traceback (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 defined

    These were working before :(

    Thanks & regards,
    MK HB



  • Very nice version. I also notice the the primary interest is BT. What is the plan for sleep and deepSleep?

    Thanks!



  • still not enough for my needs
    MemoryError: memory allocation failed, allocating 136 bytes

    but 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: 2692
    

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


  • Awesome! And thanks for also updating the Github repo even on a Friday night, you know your users well 😉


Log in to reply
 

Looks like your connection to Pycom Forum was lost, please wait while we try to reconnect.