Generating micropython + python code `.hex` file from the command line for the BBC micro:bit - bbc-microbit

Is it possible to generate a .hex file with MicroPython and my own python program code at a Linux command line, rather than in one of the editors?

Looking at the tag in your question, it looks like you want to use MicroPython on the BBC micro:bit, correct?
If that's the case then youu can use this Python command line tool: https://github.com/ntoll/uflash/
Instructions on how to install it and use it can be found in the README at that link.
This works with Python 2 and 3, and your Linux distribution is very likely to have at least one Python version available out-of-the-box.
If you have pip installed you can easily install it with: pip install uflash
But you can also download the source code, using git or downloading a zip file from GitHub (https://github.com/ntoll/uflash/archive/master.zip), and run it without installing anything. In this case you can execute the uFlash script with Python:
python uflash.py path_to_your_code.py
And the current version of uFlash includes the latest version of MicroPython for the micro:bit.

You can write the micropython code for the microbit in any text editor, such as vscode or vim. Save it as a .py file.
To create the .hex file, use the py2exe tool that is installed along with uflash when you install uflash using the command:
pip install uflash
To create a .hex file for a microbit micropython file called hello.py:
py2hex hello.py
This creates a file called hello.hex. This can be dragged and dropped onto your connected microbit through the file explorer. I use Nautilus and the microbit appears as 'MICROBIT'.
You can automate the creation and loading of the .hex file to the microbit using uflash, e.g.
uflash hello.py
This will create the .hex file and then load it onto an attached microbit. The .hex file will not be left on your file system though. The microbit has a habit of no longer being attached to the file system after loading a .hex file and needs to be re-attached in between builds.

Working Ubuntu 22.04 host CLI setup with Carlos Atencio's Docker to build your own firmware
After trying to setup the toolchain for a while, I finally decided to Google for a Docker image with the toolchain, and found https://github.com/carlosperate/docker-microbit-toolchain at this commit from Carlos Atencio, a Micro:Bit foundation employee, and that just absolutely worked:
# Get examples.
git clone https://github.com/bbcmicrobit/micropython
cd micropython
git checkout 7fc33d13b31a915cbe90dc5d515c6337b5fa1660
# Get Docker image.
docker pull ghcr.io/carlosperate/microbit-toolchain:latest
# Build setup to be run once.
docker run -v $(pwd):/home --rm ghcr.io/carlosperate/microbit-toolchain:latest yt target bbc-microbit-classic-gcc-nosd#https://github.com/lancaster-university/yotta-target-bbc-microbit-classic-gcc-nosd
docker run -v $(pwd):/home --rm ghcr.io/carlosperate/microbit-toolchain:latest make all
sudo chmod -R +666 .
# Build one example.
tools/makecombinedhex.py build/firmware.hex examples/counter.py -o build/counter.hex
# Build all examples.
for f in examples/*; do b="$(basename "$f")"; echo $b; tools/makecombinedhex.py build/firmware.hex "$f" -o "build/${b%.py}.hex"; done
And you can then flash the example you want to run with:
cp build/counter.hex "/media/$USER/MICROBIT/"
What uflash does it to ship its own precompiled firmware.hex which is the part that requires the toolchain, and it then just uses that to build the combined hex in Python.
The cool thing is that now that we have the toolchain, we can also create examples directy in C/C++/assembly: How to compile C/C++ code into a .hex file for the BBC micro:bit? which can likely run much faster.
Previous failed attempts at setting it up myself
The Yotta package manager used by BBC Microbit bit rot almost immediately after it got was discontinued, making pip install yota approaches like: https://flames-of-code.netlify.app/blog/microbit-cpp-1/ very difficult.
The GCC gcc-arm-embedded toolchain PPA ppa:team-gcc-arm-embedded/ppa has also been discontinued: https://askubuntu.com/questions/1243252/how-to-install-arm-none-eabi-gdb-on-ubuntu-20-04-lts-focal-fossa and now you would have to download from an arm.com website.
Atencios' Docker setup explains how to do it though: https://github.com/carlosperate/docker-microbit-toolchain/blob/master/Dockerfile , the key is likely using his magically crafted requirements.txt, likely kept back from the day when things really worked, to avoid the infinitely many dependency issues of yotta. He's on Ubuntu 20.04.

Related

SOLVED - Ubuntu 18.04 setting up virtualenvwrapper, python 3.8

Original question:
I am installing virtualenvwrapper on Ubuntu 18.04. Here is what I have tried so far:
From https://virtualenvwrapper.readthedocs.io/en/latest/#:~:text=virtualenvwrapper%20is%20a%20set%20of,introducing%20conflicts%20in%20their%20dependencies:
$ pip install virtualenvwrapper
...
$ export WORKON_HOME=~/Envs
$ mkdir -p $WORKON_HOME
$ source /usr/local/bin/virtualenvwrapper.sh
Error: bash: /usr/local/bin/virtualenvwrapper.sh: No such file or directory
Ok, so I went looking for virtualenvwrapper.sh. Eventually I found it:
joanna#joanna-X441BA:~/.local/bin$ ls
...
virtualenv-clone
virtualenvwrapper_lazy.sh
virtualenvwrapper.sh
...
Tried again with the new path: joanna#joanna-X441BA:/$ source /home/.local/bin/virtualenvwrapper.sh
bash: /home/.local/bin/virtualenvwrapper.sh: No such file or directory
Agh, ok. Searched StackOverflow, followed the instructions in Issue installing Virtualenvwrapper on Ubuntu 18.04?:
export WORKON_HOME=$HOME/.virtualenv
export VIRTUALENVWRAPPER_LOG_DIR="$WORKON_HOME"
export VIRTUALENVWRAPPER_HOOK_DIR="$WORKON_HOME"
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
I checked that this is in fact where my python3 installation lives. Same result though - No such file or directory.
Also tried sudo apt-get update and it successfully updated a bunch of stuff. But still No such file or directory.
Following this article, I also tried
export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python
export VIRTUALENVWRAPPER_VIRTUALENV=/usr/local/bin/virtualenv
(with the paths corrected for my filesystem setup.)
I don't understand why Bash is saying "No such file or directory" when it is in fact there (inexact error message that could be improved?), or more importantly how to fix this problem.
Note: This article warns me not to use sudo with pip because "If you think you need to use sudo, you're probably trying to modify a distribution-owned file", which is apparently Very Bad. I have also seen several articles warning that I should really use python -m pip install (or python3 -m pip install?) instead of plain pip install, because plain pip install can cause unintended side effects. I am not an expert by any means in these matters, but avoiding side effects sounds good to me.
Solution:
I finally got it to work! I kept playing around with it and double-checking that all the paths were correct and I did everything in the right order. I also had a stray installation of Python 3.8 that it seems I had installed in one of my folders that I use for code (my understanding is that Python installations should automatically go into one of the root folders like /usr/bin). On advice from my mentor I used the file manager to delete the stray Python 3.8, which may have helped with the virtualenvwrapper problem. After deleting the stray Python 3.8 I ran these commands and it finally worked!!!!
export WORKON_HOME=$HOME/.virtualenv
export VIRTUALENVWRAPPER_LOG_DIR="$WORKON_HOME"
export VIRTUALENVWRAPPER_HOOK_DIR="$WORKON_HOME"
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
source ~/.local/bin/virtualenvwrapper.sh
My advice to readers of this question who are stumped with similar problems: triple-check the paths you are using by cd-ing into the folders, and also check for spelling errors in what you are typing. Your computer's file system may be set up slightly different from mine so don't blindly copy-paste the file paths I used. This will save you a lot of time and frustration. Also note that the file location of ~ is NOT the same as /home, that's one mistake I made.

Flatpak Intellij Idea - problem with subversion executable

After installing Intellij Idea using flatpak on Clear Linux I'm not able to make it run svn executable.
I added ---filesystem=host to flatpak permissions and tried to set executable path to /run/host/usr/bin/svn but with no luck (path is available/exists, though Intellij keeps complain)
svn command is normally available from system terminal.
When I try to run /run/host/usr/bin/svn command via Intellij Idea built-in terminal, I've got error that library is not available:
sh-5.0$ /run/host/usr/bin/svn
/run/host/usr/bin/svn: error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file: No such file or directory
I also tried set flatpak-spawn. Following command works perfectly fine in Intellij Idea built-in terminal:
/usr/bin/flatpak-spawn --host /usr/bin/svn, though when set as path to svn executable still gives me Intellij Idea error:
"The path to Subversion executable is probably wrong"
Could anybody please help with making it work?
TLDR: You probably need to add the path to svn into your IntelliJ terminal Path.
Details:
It looks like you are having a path issue. I had a similar problem running kubectl running PyCharm installed from a flatpak on Pop_Os.
If I try to run kubectl I see the following:
I have kubectl installed in /usr/local/bin. This is a screenshot from my 'normal' terminal.
In the PyCharm terminal this location is mounting under /run/host/usr/local/bin/.
If I look at my path in the PyCharm terminal, it is not there.
So I'll add the /run/host/usr/local/bin/ to my path and I can then run kubectl:
To make sure this comes up all the time, I need to add the PATH to the Terminal settings:
I can now execute any of the commands in my /usr/local/bin dir.
I found a really ugly solution for dealing with SVN with the JetBrains family, which does actually answer the question. But in a very roundabout way. Unfortunately Alex Nelson's solution didn't work for me.
You would think the Flatpak would come with a valid SVN, since it's actually part of the expected requirements for the program...
When in the terminal, you can run
cd ..
/usr/bin/flatpak-spawn --host vim ./svn
Then press i to go into input mode, then paste the following in the opened text file (Basically what it does is create an executable which passes it to the flatpak-spawn invocation):
#!/bin/bash
/usr/bin/flatpak-spawn --host /usr/bin/svn $#
Save and quit from vim (ESC, then :wq!). Make it executable:
chmod +x svn
Then in IntelliJ's menu, set the "path to svn" to
/home/<yourusername>/IdeaProjects/svn
It's worked for everything I've tried... Hope this helps out anyone else who was struggling with this.
I am using a similar solution to caluga.
#!/bin/sh
cd
exec /usr/bin/env -- flatpak-spawn --host /usr/bin/env -- svn "$#"
exec makes it replace the wrapper script process so the wrapper script process can end.
I'm using /bin/sh instead of /bin/bash as bash features are not needed.
using /usr/bin/env, but maybe not necessary if PATH is set up right.
remember to quote "$#" in case there are spaces in arguments.
I am putting it in ~/.local/bin and referencing it with its absolute path in the IntelliJ settings (Settings -> Version Control -> Subversion -> Path to Subversion executable).
I also was running into problems with IntelliJ saying that /app/idea-IC path does not exist. Figured that something outside the flatpak (i.e. svn or env) was trying to change directory to the working directory from where the wrapper script was invoked (inside the flatpak). Using cd allows the wrapper script to change to a directory that exists both inside the flatpak and on the host.
Fedora Silverblue or toolbox users might want to use dev tools inside their toolbox, in which case you can do:
#!/bin/sh
cd
exec /usr/bin/env -- flatpak-spawn --host toolbox run svn "$#"

Unison fails with "ill-formed message" error, same remote & local versions

I'm trying to get unison working after upgrading to Mac OS X Catalina. Unfortunately, macports installs a more recent version of ocaml (4.08.1), which means that the unison 2.51.2 release won't compile.
Well, that's no problem, I just update to git master on unison, and recompile. Unfortunately, this fails at sync time because the version of ocaml used to compile on the mac (4.08.1) is different from the one used to compile on the other machine (4.07.1). Sigh. Okay, use opam magic to install 4.07.1 on my machine. Everything should be fine, right? No!
Here's the error:
Connected [//zzzmyhost//home/clements/unison-home -> //zzzmyotherhost//Users/clements/clements]
Looking for changes
Uncaught exception Failure("input_value: ill-formed message")
Raised at file "/private/tmp/unison/src/lwt/lwt.ml", line 126, characters 16-23
Called from file "/private/tmp/unison/src/lwt/generic/lwt_unix_impl.ml", line 102, characters 8-23
Called from file "/private/tmp/unison/src/update.ml" (inlined), line 2105, characters 2-69
Called from file "/private/tmp/unison/src/uitext.ml", line 978, characters 16-56
Called from file "/private/tmp/unison/src/uitext.ml", line 1066, characters 6-90
Called from file "/private/tmp/unison/src/uitext.ml", line 1088, characters 19-66
Called from file "/private/tmp/unison/src/uitext.ml", line 1144, characters 21-43
What's going on?
Sigh... the problem here (very non-obvious) is actually with a corrupted/wrong-format syncronization file, created when doing the failed sync in the earlier test.
The solution is just to go into ~/Library/Application Support/Unison (on a UNIX machine this path would presumably live in ~/.unison and delete the archive file that's causing the problem (probably the most recent one). In a pinch, just delete all of the archive files and start over.
I've got the same problem between Windows and Ubuntu 20.04 after upgrading from Ubuntu 18.04. I tried the binary from Ubuntu 18.04 in 20.04, which still fails, so the incompatibility is likely inside one of the dependencies.
As a workaround I created a Docker image based on Ubuntu 18.04:
FROM ubuntu:18.04
RUN apt-get update && apt-get dist-upgrade -y
RUN apt-get install unison -y
RUN useradd martin --home /home/martin
WORKDIR /home/martin
USER martin
Building it with docker build -t unison:18.04 .
And then I added a wrapper to ~/bin/unison-2.48.4-docker:
#!/bin/bash
docker run --rm -i \
-v /home/martin/dirtosync:/home/martin/dirtosync \
-v /home/martin/.unison:/home/martin/.unison \
--hostname $(hostname) \
unison:18.04 unison "$#"
Setting the --hostname is important, since the hostname is part of the archive file.
Inside the profile on my Windows machine I configured:
servercmd = ~/bin/unison-2.48.4-docker
In my setup with two windows clients and one Ubuntu 18.04 server, connected by ssh, the problem startet with a second server running on Ubuntu 20.04. Neither the old server nor the windows clients could sync with the new machine.
My solution: Copying the binary from Ubuntu 18.04 to a new directory in the Ubuntu 20.04 machine. This new file is referenced in the "authorized_keys" file of ssh on the new machine.
So far, everything works great with unison 2.48.4.

Installing fzf fuzzy finder offline

I'm behind a firewall and I have the fzf.tar.gz package which has the content of the git repo. How can I install fzf offline?
The install command ~/.fzf/install is reaching out to github.com. I'm on Redhat with no internet connection.
https://github.com/junegunn/fzf
This is just what I observed, I can't guarantee I didn't miss anything:
First, clone fzf to FZF_DIR on an online PC, then,
I'd suggest you to execute 'install' on an online PC to get necessary files
~/.fzf/bin/fzf this one is downloaded by install script
~/.fzf.bash this one is generated by install script
cp ~/.fzf/bin/fzf $FZF_DIR/bin
copy $FZF_DIR (with fzf binary in it) and .fzf.bash into your offline PC
ln -s $FZF_DIR ~/.fzf
source .fzf.bash in your .bashrc
Entire FZF_DIR is needed because it includes some other useful scripts sourced by .fzf.bash.

How to create a PDF-out-of-Sphinx-documentation-tool

Followed this link to try and generate pdf from Sphinx:
https://www.quora.com/How-to-create-a-PDF-out-of-Sphinx-documentation-tool
$ sphinx-build -b pdf source build/pdf
Error: Cannot find source directory `/Users/seb/mydocs/source'.
$ make all-pdf
make: *** No rule to make target `all-pdf'. Stop.
$ make pdf
make: *** No rule to make target `pdf'. Stop.
Since tried in OSX:
$ conda install -c dfroger rst2pdf=0.93
Fetching package metadata .........
Solving package specifications: .
Error: Package missing in current osx-64 channels:
- rst2pdf 0.93*
You can search for packages on anaconda.org with
anaconda search -t conda rst2pdf
EDIT:
After pip install rst2pdf
install rst2pdf
register rst2pdf in your conf.py Sphinx config
extensions = ['sphinx.ext.autodoc','rst2pdf.pdfbuilder']
But adding 'rst2pdf.pdfbuilder' causes
Extension error:
Config value 'math_number_all' already present
make: *** [html] Error 1
$ sphinx-build -bpdf sourcedir outdir
But what do I specify as sourcedir and outdir? Example please.
EDIT:
Now after make html
and then:
$ rst2pdf index.rst output.pdf
index.rst:14: (ERROR/3) Unknown directive type "toctree".
.. toctree::
:maxdepth: 2
introduction
tutorial
multiple_jobs
deployment
project
index.rst:26: (ERROR/3) Unknown interpreted text role "ref".
index.rst:27: (ERROR/3) Unknown interpreted text role "ref".
index.rst:28: (ERROR/3) Unknown interpreted text role "ref".
Also:
$rst2pdf.py index.rst -o mydocument.pdf
Does produce a mydocument.pdf but completely different from html and toc to all the pages are not even there?
Image of pdf verse HTML same page
This is from the official Sphinx documentation. If you have pdfTex tool installed in your machine, all you need is:
$ make latexpdf
Then, the generated pdf file(s) will be under _build/latex/<PROJECT-NAME>.pdf
So, the complete process from scratch would be as follows:
$ pip install -U sphinx # install the package
$ sphinx-quickstart # create a new project (answer the questions)
$ make latexpdf # compile and generate pdf file
Note that you may also "optionally" install whatever extensions needed by editing the file config.py
NOTE: This answer assumes LaTeX engine is installed on your machine.
I have succeeded in generating a PDF file for the DevStack document by following the configuration changes in this link:
Here are the steps:
Edit your conf.py (edit or append values)
extensions = ['rst2pdf.pdfbuilder']
pdf_documents = [('index', u'rst2pdf', u'Sample rst2pdf doc', u'Your Name'),]
Install the "rst2pdf" if necessary
pip install rst2pdf
Build the PDF file like this:
sphinx-build -b pdf doc/source doc/build
Succeeded in Pdf Generation via Latex (for windows 10)... No need to change existing conf.py file in Sphinx... the best solution is install MiKTeX....install Perl (ActiveState).... after when running sphinx type 'make HTML' type 'make latex' and then make latexPdf... this solved my issue.
You could avoid rst2pdf and use make pdflatex to build pdf output via a latex file.
cf more info:
https://docs.typo3.org/typo3cms/extensions/sphinx/AdvancedUsersManual/RenderingPdf/
Make sure to have a look at http://rst2pdf.ralsina.me/handbook.html#sphinx.
Following applies to Ubuntu 16.
But it is probably less painful to install a full LaTex suite than to try to get this tool running; it is very sensitive to errors, and is difficult to use.
I took a look there (https://tex.stackexchange.com/a/95373) and it looks daunting...
this is more encouraging: https://milq.github.io/install-latex-ubuntu-debian/
And I did it:
sudo apt-get install texlive-full
make clean latexpdf
is worthwhile your patience (and disk space) to install. I got rid of rst2pdf.
Found this related post which discovers that rst2pdf breaks math rendering in Sphinx 1.4.1 because it imports a dummy math module.
In rst2pdf.pdfbuilder:setup(), it calls mathbase.setup() internally to install dummy math module. It causes conflicts and raise errors.
I had this same error when running sphinx-build -b pdf
Extension error:
Config value 'math_number_all' already present
Now looking at latex option, and exporting to pdf as #tfv posted. pdflatex is a larger universe of TeX distribution.
As an alternative to latexpdf: rinohtype
Once rinohtype is installed, sphinx-build -b rinoh . _build
Create a file documentation.md, and open it in Typora software. Navigate to the Sphynx documentation that you need, mark with mouse and copy inside Typora. Then inside typora export as PDF. Done.