Weekly update W/C 16th Jan 2017

[Fred]

Dear all,

I hope you have had a great weekend!

Further to Daniel's firmware release last Friday, I wanted to keep you updated as to what you can expect to receive in this week's release and moving forward.

This Thursday we will be making the following firmware enhancements:

• Code maturing
• Sleep modes
• WiFi/ BLE disabling
• Add callbacks for all remaining BLE events.

Next Thursday (26th Jan) we will be releasing an update to include:

• Memory optimizations.
• TLS bug fix and reliabilty improvements.
• Hardware I2C driver with support for 2 buses.
• WiFi STA+AP support.

We have taken notes of all your near term requirements and have started building those into our roadmap. I will be coming back very shortly with a detailed plan. The general objective is to continue making new firmware additions up to mid Feb and to switch thereafter to further maturing of the code for several weeks. We will then resume firmware additions thereafter.

On another point, the addition of BLE, as expected, caused available memory reduction. We had anticipated this and are already working with Espressif to optimise memory usage. I will come back to you as soon as I have an improvement date. We are not looking at more than a couple of weeks but cannot commit to a date yet. Main impact of this is around the TLS functionality so it's a high priority item for us.

A few other points, to give you: SiPy, LoRa certification, OEM modules and GPL licence.

SiPy: All SiPy modules are with Sigfox and certification is expected in the next week or so for all 4 zones. As soon as this process is complete, we will ensure those with SiPy modules get connected to the Sigfox backend!

LoRa Certification: Daniel is at the LoRa certification house today as I write this and will be leaving Tuesday with the process complete. Watch out for an update from him.

OEM modules: We have listened to another great suggestion and have now removed the 500 unit MOQ volume requirements for OEM product orders. As some of you rightfully argued, you want to be able to get a few before making a bigger commitment. I am pleased to say the OEM modules are now available for pre-order with MOQ starting at 10 units. We will prioritise WiPy and LoPy following a few months later with SiPy and GPy. We are looking at making an OEM version of FiPy but need to resolve a few complexiites (as both sides of the board are used).

GPL: We will release a revised FAQ document shortly to ensure there are no misunderstandings on the license and spirit of usage etc. In brief, if you use a Pycom board then you are basically free to do what you want to with your application... e.g. keep it open or closed source. If you simply want to licence the firmware, that's also fine but we need to have a discussion around the license terms. If you have a particular requirement/concern, let's talk!

That's it from me. Have a pleasant Sunday evening.

Best wishes
Fred

[livius]

@Fred
i see that after 26th Jan all main features will be finalized :)

may i ask what this does it mean?
Hardware I2C driver with support for 2 buses.

[Fred]

@livius At present there's a software I2C driver (because it wasn't supported by the IDF beforehand). The hardware driver was added a few days ago by Espressif which means we will now enable the 2 I2C hardware interfaces on the ESP32.
Thanks Fred

[Shaun]

@Fred Thanks,

That explains the....
@Shaun said in I2C Clock Stretching:

The I2C clock frequency setting is not accurate.
baudrate=400000 results in an actual clock of 297kHz
baudrate=100000 results in an actual clock of 87.6kHz
baudrate=40000 results in an actual clock of 39kHz

[livius]

@Fred
Ach i see. It explain me many things.
In that case, personally, do not be rid of it.
We can have 2 hardware pins and if we could use software I2C to any pin, this will be very big extension.

[daniel]

Hello,

That's correct, clock stretching is not properly supported by the software I2C.

@livius, that's a good idea. We will leave the software implementation available after integrating the hardware driver, that way there's a "third" bus available.

Cheers,
Daniel

[bmarkus]

@daniel said in Weekly update W/C 16th Jan 2017:

Hello,

That's correct, clock stretching is not properly supported by the software I2C.

@livius, that's a good idea. We will leave the software implementation available after integrating the hardware driver, that way there's a "third" bus available.

Theoretically it is a good idea. However two I2C buses are enough in most applications and question what is the cost to keep the sw I2C in terms of RAM.

[daniel]

@bmarkus the RAM impact is zero. It would all be part of the same machine.I2C module. Bus with ID #2 would be a software implemented one. The only impact is just a little bit more code size.

[bmarkus]

@daniel said in Weekly update W/C 16th Jan 2017:

@bmarkus the RAM impact is zero. It would all be part of the same machine.I2C module. Bus with ID #2 would be a software implemented one. The only impact is just a little bit more code size.

Hi Daniel

thanks for the clarification. In such case I vote for it :)

Béla

[daniel]

@bmarkus you are welcome :-)

[rskoniec]

@Fred said in Weekly update W/C 16th Jan 2017:

Next Thursday (26th Jan) we will be releasing an update to include:

• Memory optimizations.
• TLS bug fix and reliabilty improvements.
• Hardware I2C driver with support for 2 buses.
• WiFi STA+AP support.

Any news about new f/w release? I'm really waiting for @livius most wanted feature STA+AP. ;o)

[daniel]

@rskoniec the release will be out today at the end of the day. I can confirm that TLS is back and there are lots of memory improvements. WiFi AP+STA is almost ready too.

Cheers,
Daniel

[rskoniec]

@daniel Thank you. Great :o)