Request VID/PID for AramCon Badges

[bmeisels]

HI,
I would like to request PIDs for the conference badge we are working on and for the previous one (2 total).
AramCon Badge 2019
AramCon Badge 2020

We are planning to upstream later this year.
our circuit python fork https://github.com/urish/circuitpython
the badge repo https://github.com/urish/aramcon-badge

Thanks for all the great work on circuitpython!

[ladyada]

@bmeisels cool! is there a reason you cannot submit a PR for the changes/support for the two boards?

[bmeisels]

Hi @ladyada,
We have not completed development of this years firmware and the hardware is not finalized. I think it would be better for our port to be more stable before we start upstreaming.

[ladyada]

what about for the 2019 board definition? we like to give the USB PID as an incentive for people to open PR's for their hardware definitions ;)

[bmeisels]

we can push the 2019 board definition but a change in circuitpython 5 breaks I2C for us.
right now our fork handles this by reverting this change but i don't think that would be suitable for upstream. We are thinking of a better solution which would work with upstream but it is still WIP.

If you prefer to give us a PID when the PR is ready we have no problem to wait.

More details about the issue:
We don't have pullups on the board and 85a6482 breaks I2C on the 2019 board with SAO addons that don't have pullups.
We are adding pullups on this years badge and are thinking of a solution for the 2019 badge.

[ladyada]

hiya what do you mean by 'breaks' - it should throw an exception, does it not throw an exception?

[bmeisels]

It does but this means that the board doesn't work with many addons which don't have pullups.

[ladyada]

it shouldn't - pullups are required for I2C to work!

[bmeisels]

Of course. I had a discussion on the circuitpython discord channel with @dhalbert on the topic. This used to work for us on circuitpython 4 as the underlying nordic driver (twim) uses internal weak pullups. Apparently #2253 required checking for strong external pullups.

[ladyada]

hmm @dhalbert should we allow internal weak pulls if its allowed - samd21/51 does not have that ability (but avr allows it in arduino)?

[dhalbert]

The nrf I2C drivers turn on internal 13K pullups (typical, range is 11k-16k). We don't turn these off, but they are not on when we first test for pullups , using GPIO operations.

The code is testing for powered pullups. The original problem was that an Arduino Nano 33 BLE has one set of 4.7K pullups for all of its on-board peripherals. The peripherals can be switched off, and when they are, the pullups are unpowered. So that puts the equivalent of a 9.4k resistor between SCL and SDA in the unpowered case. That caused I2C and CircuitPython to hang, even with the internal pullups enabled by the driver. I guess the internal pullups were too weak to overcome that. See #2253.

So any I2C peripheral with fairly strong unpowered pullups could cause this problem. Maybe it would even happen with 20k (2 10k pullups); I haven't tested that.

So the check is testing both for pullups present and that the pullups are powered. If it didn't check, there's the possibility of a hang, when there are strong unpowered pullups.

[ladyada]

ooof - i suppose we should fix the hang before we disable the pullup check. dan, what do you think we should do?

[dhalbert]

This hanging problem is not confined to nRF; it also shows up in atmel, and we added the pullup checks originally to the atmel port to catch it. #719.

[dhalbert]

We could add a conditional compilation flag that suppresses the pull-up check on nrf, and @bmeisels, you could turn it on for the current board. Is that enough of a solution?

[bmeisels]

@dhalbert sure that would be great.
I have prepared a branch with the board definition. Once this issue is solved I will rebase and open a PR.