Not seeing all of the discussion, I'm not sure what the underlying
problem might be. So just a few remarks that might be helpful, given
what I can recall during Christmas in deepest Yorkshire.
-- Mike
(i) I'm sure the identical USB id's are deliberate; the intention is
that higher-level tools will assemble version-independent binaries that
can be uploaded to either device in the same way. Dima and I are
preparing lower-level programs that will only work on one board or the
other -- actually, if things go according to plan, we will use only the
V1 board this year. You could get in touch with the micro:bit
foundation, but they won't change this.
(ii) I don't believe I've had any difficulty communicating with either
board using recent versions of PyOCD, given an appropriate udev rule --
the same rule for both devices. I think PyOCD probes for the processor
it is talking to -- nRF51 or nRF52 -- or you can tell it on the comand line.
(iii) The micro:bit is what I call a two-chip eval board, with the
target processor running arbitrary code on the bare metal, and a
separate serial/programming/debugging chip that runs firmware that is
usually not changed. That's in contrast to the kind of one-chip board
where the target processor has some kind of USB-based bootloader on it.
The separate chip on the micro:bit is a Freescale KL25, I believe, and a
bit more powerful than the nRF51 target chip on the V1. I believe the
firmware is open source and can be replaced through some kind of
bootstrap ritual -- perhaps involving pressing the reset button while
plugging in the device.
On 25/12/2022 11:08, dima.pasechnik@xxxxxxxxxxx wrote:
On Sat, Dec 24, 2022 at 07:53:54AM +0100, Greg KH wrote:
On Fri, Dec 23, 2022 at 11:51:48PM +0000, dima.pasechnik@xxxxxxxxxxx wrote:
On Fri, Dec 23, 2022 at 03:50:26PM +0100, Greg KH wrote:
On Tue, Dec 20, 2022 at 01:08:59PM +0000, dima.pasechnik@xxxxxxxxxxx wrote:
On Mon, Dec 19, 2022 at 06:36:47PM -0500, Alan Stern wrote:
It might help if you post the output of "lsusb -v" for this device.
Please see attached; I also attached the output for an older version of
this board (V1). The one we talk about is V2. Both versions have the
same VID, and, weirdly, the same PID (internally they aren't binary
compatible, even)
That's horrible, someone should talk to the vendor here and get them to
at least bump the device id.
The vendor is ARM (https://www.arm.com/) - I guess Linux Foundation is a good "someone"
to talk to the vendor in this case.
I do not understand here, are you asking me to talk to someone? If so,
great, who? If not, who are you asking?
Can PID be bumped up by a firmware update?
Depends on how the hardware was designed. Most can, some can not. Is
the hardware design and firmware source available anywhere?
As far I know, firmware comes from
https://tech.microbit.org/software/runtime/
As to why these V1 and V2 happened to get the same product ID, perhaps
my colleague Mike, in CC, who teaches a course using this board, knows more.
Cheers
Dima
