Black Lives Matter - Action and Equality. ... Adafruit is part of the Stop Hate for Profit campaign. Adafruit is open and shipping.
0

CP roadmap for 2020 (or 5.3+/6.x/7.x) ?
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by ericwertz on Tue Apr 14, 2020 2:33 am

Is there a roadmap for what's likely to go on (software-wise) with CircuitPython over the next 9-12 months? I know that a call went out somewhat recently for feature/tools suggestions, but even independently of that, I haven't found anything that suggests what the priority development issues are for, say, the rest of the year.

thanks!
-e

ericwertz
 
Posts: 73
Joined: Sun Jun 01, 2008 4:18 am

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by tannewt on Tue Apr 14, 2020 4:31 pm

Hi Eric! Dan and I were just chatting about this yesterday!

5.3 is likely going to be a big minor version bump. I'm wrapping up the initial lower power work. Jeff is wrapping up RGB matrix support. Lucian is wrapping up initial STM32 F7/H7 support. They'll all land around the same time (hopefully this week) so they'll all be part of 5.3.

After that, my thinking is that we'll largely be focused on the iMX RT and the ESP32-S2 ports. There is foundational work to do there before we get to new APIs that would cause a major version bump like 6.x. I think one candidate is rethinking the low level networking API to better match our co-processor inspired APIs. Another is rethinking our USB descriptor API so it can be changed in boot.py. That would solve our oldest bug for having two CDC connections, allow us to support high speed protocols such as audio and video over USB and let us make decisions how to use the 4 endpoints we have on the ESP32-S2.

Dan may also pick up my lower power work to start getting a feel for handling sleep and wake up sources in addition to time.

We've got lots we can work on. :-) Hope that helps given an idea where the core Adafruit folks are going with CircuitPython.

Other work is happening by FPGA folks so keep an eye out for that too.

tannewt
 
Posts: 1685
Joined: Thu Oct 06, 2016 8:48 pm

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by bjfurman3 on Tue Apr 14, 2020 8:10 pm

Any thoughts/plans to include interrupt support in CP? That would really be great... :)

bjfurman3
 
Posts: 3
Joined: Fri Aug 22, 2014 1:16 am

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by wminarik on Wed Apr 15, 2020 11:00 am

A second for the request: extending interrupts on CircuitPython would allow porting of the LittlevGL GUI library to CP.

wminarik
 
Posts: 14
Joined: Tue Jan 17, 2017 1:30 pm

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by ericwertz on Wed Apr 15, 2020 2:02 pm

Great, that definitely helps.

My original question was intended to be about software features rather than (relatively) sideways moves to new platforms. So for example, Bluetooth Classic support, multi-threading, user-level direct access to hardware registers (like PEEK and POKE from BASIC), user-level GPIO interrupt handlers, explicit user-level data allocations from battery-backed memory (or tightly-coupled fast memory), finer control of timer-peripheral resource allocation, etc. I don't necessarily care if any of these already exist or not, I'm just using them of examples of what (I think that) I'm curious about.

I suppose that rework of network and USB APIs/stacks and low-power are probably the best examples of the types of things that I was getting at. Clearly a lot changes get made as random people show interest and ability to make contributions in whatever areas they're interested in (new graphics APIs, new drivers for the CCCCnnnn from SiliconVendorX, etc) that are totally unplanned/opportunistic. So, a lot of work is "unplanned" as far as any given release is concerned, and that's realistic and fine.

I also suspect that some functionality makes more sense to be done in MicroPython rather than just CircuitPython, which confuses the matter of what's part of an MP roadmap vs. a CP roadmap. Classic examples would be shared memory, semaphores, priority control, etc -- core OS/runtime kind of stuff.

What's the best way of tracking how the development priorities change? Would this all get discussed in the weekly development meetings. Is there a planned-feature list vs. targeted release doc that pulls this together? I'd idealize something like:

5.3 (target MM/YY)
FeatureA
FeatureB
PortP

5.3 or 6.0
FeatureC
FeatureD
PortQ
PortR

6.0 (target MM/YY)
FeatureE
FeatureF

6.1 (target MM/YY)
PortS
PortT

I'll try hard to carve out some time to follow the weekly dev meetings. It may very well be that much of this is wrangled there and I just don't know it, in which case I'll readily plead "guilty as charged".

Thanks again. Keep up the good work.

-e
Last edited by ericwertz on Wed Apr 15, 2020 2:42 pm, edited 3 times in total.

ericwertz
 
Posts: 73
Joined: Sun Jun 01, 2008 4:18 am

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by ericwertz on Wed Apr 15, 2020 2:28 pm

Separately, I'll (again) chime-in on interrupt support. Not being able to take an interrupt from an external device on a GPIO in a user-program is killing us in the classroom.
We really don't want to go back to C/C++/Arduino, but switching to MicroPython just for this is a real consideration, unfortunately, in spite of everything else that we'd have to give up.

ericwertz
 
Posts: 73
Joined: Sun Jun 01, 2008 4:18 am

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by tannewt on Wed Apr 15, 2020 4:12 pm

bjfurman3 wrote:Any thoughts/plans to include interrupt support in CP? That would really be great... :)


No, we don't have any immediate plans. Concurrency and interrupts are much more complex and most projects can be done without it. We need numerous concrete uses for them to design an API in the future. See the long discussion here: https://github.com/adafruit/circuitpython/issues/1380

wminarik wrote:A second for the request: extending interrupts on CircuitPython would allow porting of the LittlevGL GUI library to CP.


wminarik, I'd love to know more about why LittleVGL is tied to interrupts. We use interrupts internally as needed.

ericwertz wrote:Separately, I'll (again) chime-in on interrupt support. Not being able to take an interrupt from an external device on a GPIO in a user-program is killing us in the classroom.


Why do you need it in the classroom? Our goal with CircuitPython isn't to teach underlying embedded principles. It is to enable easy project creation for folks new to programming.

ericwertz wrote:Great, that definitely helps.


Awesome!

ericwertz wrote:My original question was intended to be about software features rather than (relatively) sideways moves to new platforms. So for example, Bluetooth Classic support, multi-threading, user-level direct access to hardware registers (like PEEK and POKE from BASIC), user-level GPIO interrupt handlers, explicit user-level data allocations from battery-backed memory (or tightly-coupled fast memory), finer control of timer-peripheral resource allocation, etc. I don't necessarily care if any of these already exist or not, I'm just using them of examples of what (I think that) I'm curious about.


Moving to a new platform is a lot of software work. :-)

We're adding new platforms because they allow Adafruit customers to build projects they couldn't build cheaply or easily before. The features we implement are driven by the projects we want to highlight. As much as we can, we avoid adding features for features sake because it greatly increases the likelihood of wasted work. Project motivated hardware and software ensures there is a use.

So, it's most helpful to propose features within the context of a project. For example, hardware register level access could be very useful on an FPGA to allow pure Python drivers for dynamic peripherals.

ericwertz wrote:What's the best way of tracking how the development priorities change? Would this all get discussed in the weekly development meetings. Is there a planned-feature list vs. targeted release doc that pulls this together?


We do try to use GitHub milestones for these things but our use varies depending on where we are in the release cycle. Lurking on the meeting notes is the best way to follow along.

ericwertz wrote:I'll try hard to carve out some time to follow the weekly dev meetings. It may very well be that much of this is wrangled there and I just don't know it, in which case I'll readily plead "guilty as charged".

Thanks again. Keep up the good work.

-e


The meetings themselves are pretty long but we do take notes. Skimming the notes doc is the most efficient way to stay up to date. Time codes are included so you can skip through the video to the relevant section. They are here: https://github.com/adafruit/adafruit-ci ... aster/2020

Thanks for the thoughts folks. Remember that these are largely the priorities of those of us funded by Adafruit. We're always happy to help someone else add things to CircuitPython that may not be a priority for us.

tannewt
 
Posts: 1685
Joined: Thu Oct 06, 2016 8:48 pm

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by wminarik on Wed Apr 15, 2020 5:40 pm

Thanks Scott for your detailed replies.

I'm writing mostly from ignorance, but a superficial reading of the LittlevGL doc suggest that Micropython callbacks and ISRs are part of the API for the Python port of LittlevGL as well as for the underlying C code:
https://blog.littlevgl.com/2019-08-05/micropython-pure-display-driver
https://docs.littlevgl.com/en/html/porting/index.html

wminarik
 
Posts: 14
Joined: Tue Jan 17, 2017 1:30 pm

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by tannewt on Thu Apr 16, 2020 12:40 pm

Thanks! I think LittleVGL could fit into CircuitPython without it. When I glanced at it the Python API seemed very C-like. That's a common problem for C code ported into Python. I'd prefer to take a bit higher look at the API if it's brought into CircuitPython to ensure it uses common Python patterns such as properties.

tannewt
 
Posts: 1685
Joined: Thu Oct 06, 2016 8:48 pm

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by esquagga on Sat May 02, 2020 11:48 am

Here's my vote for working on lower-power, especially with respect to nRF52.

I built a sensor using ItsyBitsy nRF52840 and BLE advertisements using CircuitPython. It was fairly easy to do (making sense out of BLE advertisements was 99% of it), but I was disappointed that the battery life was miserable. Some posts I found said that the DotStar uses a lot of energy (even when off) so I tried the SparkFun Pro nRF52840 Mini, which doesn't have a DotStar. The result was not measurably better. Then I tried switching from CP to Arduino. Woah! Current went from several mA down to less than 1mA (I don't have measuring equipment to say more precisely).

I don't enjoy working in Arduino. It would be great to have CP power utilization down to the level possible with Arduino.

esquagga
 
Posts: 14
Joined: Sat Apr 08, 2017 5:17 pm

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by tannewt on Sun May 03, 2020 9:17 pm

esquagga, please try the latest version of CircuitPython from master. It should improve the power consumption when you call time.sleep. It may not match Arduino yet though because it's still the lightest form of sleep.

tannewt
 
Posts: 1685
Joined: Thu Oct 06, 2016 8:48 pm

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by esquagga on Sun May 03, 2020 9:52 pm

Hi tannewt, that made a big difference! Like you wrote, it isn't down to the Arduino level; the current's around 1 mA now while it's sleeping. That's a big difference from about 6 I was seeing before.

I have been struggling to use the Adafruit Arduino BLE library to do the same thing that was straightforward using adafruit_ble_broadcastnet in CircuitPython. I was debating giving up and just wiring up my sensor to power. Now, at 1 mA while sleeping, I might get a week between battery recharges with a 150 mAh LiPo; I can live with that. Still, any further improvements will be welcome!

Thanks!

esquagga
 
Posts: 14
Joined: Sat Apr 08, 2017 5:17 pm

Re: CP roadmap for 2020 (or 5.3+/6.x/7.x) ?

by tannewt on Mon May 04, 2020 5:05 pm

esquagga wrote:Hi tannewt, that made a big difference! Like you wrote, it isn't down to the Arduino level; the current's around 1 mA now while it's sleeping. That's a big difference from about 6 I was seeing before.

I have been struggling to use the Adafruit Arduino BLE library to do the same thing that was straightforward using adafruit_ble_broadcastnet in CircuitPython. I was debating giving up and just wiring up my sensor to power. Now, at 1 mA while sleeping, I might get a week between battery recharges with a 150 mAh LiPo; I can live with that. Still, any further improvements will be welcome!

Thanks!


Awesome! Thanks for reporting back! There is definitely more room for improvement. This first PR was mainly getting our time keeping setup to allow sleep.

tannewt
 
Posts: 1685
Joined: Thu Oct 06, 2016 8:48 pm

Please be positive and constructive with your questions and comments.