Building without an mbed account

[SimonSapin]

Following the instructions at https://lancaster-university.github.io/microbit-docs/offline-toolchains/, when running yotta build, I get:

info: get versions for bbc-microbit-classic-gcc
info: download [email protected] from the public module registry

You need to log in to do this.
Press enter to continue.
Your browser will open to complete login.

waiting for response...
If you are unable to use a browser on this machine, please copy and paste this URL into a browser:
https://yotta.mbed.com/#login/(…)

I am quite surprised that for something that seems open-source (http://yotta.mbed.com/#/target/bbc-microbit-classic-gcc/0.2.0 says "Licenses: Apache-2.0"), an account is required just to download public code (as opposed to publishing anything).

I would much rather not give identifying information to a private company just to try out a "hello world" program.

Is there a way to obtain a yotta target without an mbed account?

[SimonSapin]

I’ve managed to build something roughly like this:

mkdir yotta_targets
git clone https://github.com/lancaster-university/microbit-targets
cp -a microbit-targets/bbc-microbit-classic-gcc yotta_targets
git clone https://github.com/ARMmbed/target-mbed-gcc yotta_targets/mbed-gcc -b v0.1.3

(Where v0.1.3 is the version number mentioned for mbed-gcc in bbc-microbit-classic/target.json.)

After that, yotta build seems happy with the target it finds, and goes on to download modules. A login doesn’t seem to be required for that.

I understand that Lancaster University is probably not responsible for how mbed and yotta work, but I’m curious what you thoughts are on this unnecessary barrier.

[finneyj]

Thanks @SimonSapin.

You're quite right, this does feel like an unnecessary step to access a public repo. A login make sense if you want to publish via yotta, but seems unnecessary to simply download from the yotta public registry. ARM do indeed own the yotta toolchain, so nothing we can do directly about this, except to flag it to some colleagues from the ARM mbed team...

@jaustin - is auth really considered a requirement for downloading form the yotta public registry? Or is there perhaps something that could be tweaked to help here?

p.s. As you noted, we do also keep copies on guthub... thanks for reporting back the process for others.

[jaustin]

Hi @SimonSapin and @finneyj

I'm looking at what we can do here :)

As an aside, a more 'yotta-esque' way to do what you've done there is yotta link-target:
http://yottadocs.mbed.com/tutorial/targets.html#testing-targets

(This has the advantage that if you want to change things in the target, you keep it under version control)

[finneyj]

Great! Thanks @jaustin. Looking forward to seeing what you guys come up with. ;-)

[SimonSapin]

@jaustin Interesting, thanks!

Updated steps:

# This replaces the /usr/local default which may only be writable by root.
export YOTTA_PREFIX="$HOME/.yotta/prefix"

git clone https://github.com/lancaster-university/microbit-targets
git clone https://github.com/ARMmbed/target-mbed-gcc -b v0.1.3
(cd microbit-targets/bbc-microbit-classic-gcc && yotta link-target)
(cd target-mbed-gcc && yotta link-target)

cd microbit-samples  # Or whatever module
yotta link-target bbc-microbit-classic-gcc   
yotta link-target mbed-gcc    
yotta build

[SimonSapin]

(Mostly unrelated update: my microbit arrived in the mail today and I’ve managed to show "Hello, world!" on the 5x5 display! Although not at first because I was using microbit-samples.hex instead of microbit-samples-combined.hex. Next I’m gonna try to get some Rust code running.)

[SimonSapin]

(Mostly unrelated again: I’ve written about my microbit adventures at https://github.com/SimonSapin/rust-on-bbc-microbit#readme)

[jamesadevine]

@SimonSapin I read that, someone shared it on twitter - Super cool stuff! 😄

Also, if you have a distaste for Source forge, I made a target a while ago that you could use instead of downloading srec:

lancaster-university/microbit-targets@817dee7

[jaustin]

@jamesdevine: None of the mbed OS targets use srec anymore either - is
there a good reason we don't fixup all the targets we're using for
micro:bit to use the same python-only solution?

On 5 August 2016 at 11:37, James Devine [email protected] wrote:

@SimonSapin https://github.com/SimonSapin I read that, someone shared
it on twitter - Super cool stuff! 😄

Also, if you have a distaste for Source forge, I made a target a while ago
that you could use instead of downloading srec:

lancaster-university/microbit-targets@817dee7
lancaster-university/microbit-targets@817dee7

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAI-qVJX1hsopFZStC3ZZGUj33cY3h-Cks5qcxKEgaJpZM4JN28R
.

[jamesadevine]

@jaustin Well, the reason why i haven't moved all targets to a python-only solution, is that the python script hadn't undergone vigorous testing.

I had to tweak it a bit from the more traditional mbed one that other targets use, this was because we had 3 files to concatenate not just two.

It would be useful if others could use it for beta testing, then if it works correctly, we can move it to all of the other targets.

[SimonSapin]

Thanks. My distribution has an srecord package, so I haven’t had to use SourceForge directly.

[davebarkerxyz]

It's been around 8 months since the last update - has anything progressed on this? Has there been any update from ARM or any alternative toolchains or package managers considered?

[finneyj]

@davb5

Thanks for the nudge. This is a very valid issue.

We have got been working on a pure CMake solution for some platforms similar to microbit. We could consider moving that to microbit-dal. Alternatively, I believe ARM is now supporting yotta more actively, so they might well support a request for anonymous access to public repositories.

I'll raise it with the yotta folks.

[davebarkerxyz]

@finneyj Fantastic. Thanks for picking this up.

I think that, for a project like this, it's really important to be able to build and contribute independent of third party accounts (and their Terms of Use.

A pure CMake solution seems like a great solution and would go a long way to ensuring the longevity of the platform. I've had to build toolchains for relatively old platforms in the past, and while it's usually a little tricky it rarely depends on third party services (which as we all know have a tendency to disappear over time). @autopulated suggests that login requirement for yotta was driven from a marketing requirement at ARM. Whether or not this is the case, it's concerning that our ability to build the open source toolchain (using the official instructions) may be subject to such commercial whims, now or in the future.

That said, I'm not currently a contributor to microbit or mbed, so please don't assign too much weight to my comments. I just see some real value in the project and would love for it to be easily buildable far into the future.

Thanks again for resurrecting this.

[autopulated]

I believe ARM is now supporting yotta more actively, so they might well support a request for anonymous access to public

Happily I believe this is going to finally happen!

[jaustin]

Hooray! ARMmbed/yotta#778