Circuitpython: nRF52: Remove non-nRF52 board

[arturo182]

As mentioned in #586, let discuss what to do about the nRF51 boards, at the moment they don't build because they lack board.c files (a requirement added in 60a23f0fb65bebe91ab8b6da4a32ed0b012e9313), we could either fix them and keep them, although I'm not sure how well they work and if the ubluepy module even works on them, or we could remove them.

That would mean removing pca10000, pca10001, pca10028, pca10031 and wt51822_s4at. The last one would be somewhat of a shame because it was only added last October, but not sure if there is anyone to maintain it.

We have a lot of s110, s120, s130 ifdefs in the ble driver, getting rid of those would make the code easier to work with for sure.

[arturo182]

Oh no, I just noticed the microbit uses a nRF51 chip, and it was mentioned that we want to keep support for that one, so this whole issue might not be so useful. I guess we can still discuss removing the other DKs, but the driver ifdefs might have to stay. Either that or we separate the driver into two files, one for nRF51 SDs and one for nRF52 SDs.

[microbuilder]

micro:bit is the problem at the moment, yes. It's a popular platform and worth continuing to test against. I think that situation will likely change at some point in the future, but perhaps the suggestion of two interim radio files is the right one to at least keep the more similar nRF52 code clean and easy to update?

[arturo182]

Sounds good to me, and what about the other DKs and the wt51822 board?

[microbuilder]

The key boards in my mind that we should be testing against and considered 'supported' are:

nRF52

• feather52
• pca10056

nRF51

• microbit

With the goal of dropping nRF51 support entirely once micro:bit comes out with an nRF52 option (?), and people can always go back to previous releases for legacy support?

Those are just my personal opinions, though, since I think the nRF52832 is a far more flexible chip for a project like this. Obviously I'm interested to hear other opinions!

[ladyada]

im ok with dropping nrf51 completely and not doing any work to support, its ridiculously small + slow, and customized and nordic is clearly trying to kill it off :) microbit people can stick to micropython which is the official standard for them anyhow

i do want to support both nrf52832 and '840, even tho 840 is way superior, if its feasable

[arturo182]

That would be great! I'd say in some regards nRF51 is keeping us back with the ble driver, so dropping it would be beneficial. I don't see any problems with maintaining both nRF52832 and nRF52840, they are quite similar. We could even look into supporting nRF52810, but AFAIK the chips are not available yet and there is no DK for it, Nordic's SDK says to use the nRF52830 DK with some peripherals turned off to simulate nRF52810, which doesn't make sense for us, cause if someone already has the DK, why would they artificially limit it.

So if we agree on the removal and no one has any objections, I'm ok with this being assigned to me :)

My Feather nRF52 is on the way and should be here tomorrow so I can keep testing on both boards!

[ladyada]

my pleasure! go for it :)

[ladyada]

nRF52810 is maybe not possible - 192KB _and_ you have to include the SD? seems challenging - we can barely fit the SAMD core into 256K and thats without BLE. Either way i think nordic's bitten off quite a bit of work for themselves, i do not expect it before 2019! :) we'll revisit when they're available

[arturo182]

Nordic just recently tweeted that the nRF52810 went into production (https://twitter.com/NordicTweets/status/961197875995824128) but you might be right, that flash amount is not really enough.

And yeah, between 3 BLE chips and the new LTE-M SoC, SiP and DK, they have a lot on their plate :D

I noticed that in the readme for the port the Nordic Thingy52 is mentioned as supported even though there is no board file for it and I don't think it is pin compatible to the nRF52832 DK, so we should remove that refrence. But it got me thinking that it would be cool to get CP working on the Thingy, it has a lot of sensors onboard. I have a Thingy, so if I get some time I could look into adding a board file for it.

[ladyada]

im into the Thingy! its pretty cool. i tried to get them to let us stock it, ill try again too :) either way, a Thingy target would be neat, hopefully can be doe as a variant the way SAMD boards are done

[arturo182]

Hey @microbuilder I'm working on removing nRF51 stuff from the ble driver and I test by building feather52 and pca10056, pca10056 works with SD 6, feather works with SD 2 and SD 5 but there is a linker script missing for SD 3, otherwise I think it would work too. So my question is, do we need/want to support all these SDs for the feather? Couldn't we just have support for SD 5 in the feather and 6 for pca10056, they are actually very similar API-wise and very few ifdefs would be needed, otherwise there are still some in the code for SD2 and SD3, so maybe it's time to drop those?

[microbuilder]

We only use s132v2.x, s132v5.x and s140 ... I'm OK with dropping the others.

[microbuilder]

I'd like to continue to support s132v2.0.1 for now for historical reasons since the Arduino nRF52 boards ship with S132v2.0.1 and a bootloader based on that, so that means things will work out of the box there, and people can switch back to Arduino with the same HW and bootloader.

[arturo182]

Oh, does that mean i should leave the arduino_primo board files and support? I thought we discussed only the feather and nRF52 DKs, but it shouldn't be a problem to bring it back and make sure it builds. Just let me know

[microbuilder]

No, sorry ... I mean that the same HW people order (feather52) can be used for programming inside the Arduino IDE as well, which currently supports both S132v2.0.1 (default) and v5.0.0. Not the same as the Primo board!

[arturo182]

Ok then we're good :D