Closed Hoel closed 6 years ago
screamerbg
commented
6 years ago Hi Hoel,
I'm suspecting that there's a mix of various python environments installed on your system. Could you please provide us with the output of the following commands:
$ mbed --version$ pip list$ sudo pip list
ciarmcom
commented
6 years ago Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-128
Hoel
commented
6 years ago $ mbed --version
1.2.2
$ pip list
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
mbed-cli (1.8.2)
nose (1.3.7)
numpy (1.15.2)
pip (9.0.3)
scipy (1.1.0)
setuptools (40.4.3)
wheel (0.32.0)
You are using pip version 9.0.3, however version 18.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
$ sudo pip list
Password:
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
mbed-cli (1.8.2)
nose (1.3.7)
numpy (1.15.2)
pip (9.0.3)
scipy (1.1.0)
setuptools (40.4.3)
wheel (0.32.0)
The directory '/Users/hoel/Library/Caches/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
You are using pip version 9.0.3, however version 18.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.N.B. on first attempt i had PIP 18.0 installed, then reverted to 9.0.3
screamerbg
commented
6 years ago You might notice that mbed --version is very different to the mbed-cli version reported in pip listm (1.2.2 vs 1.8.2). This means that you either have 2 versions of python installed, or that you have virtual env enabled and effectively you're called the old mbed-cli version.
Could you try to remove mbed-cli using pip uninstall mbed-cli and see whether running command mbed --version still gives any output? If it does, you might have to chase where is this mbed-cli installed, e.g. this should help you find which python is called:
cat `which mbed`
j3hill
commented
6 years ago There is a GitHub pull request (PR) that has been created to help address this issue. Here is a link: https://github.com/ARMmbed/mbed-os-5-docs/pull/809 Please note that it is not recommended to use 'sudo" when installing on the MacOS. This can create system compatibility issues with components (like Python) that are used by the OS itself. It is better to install the mbed-cli using the '--user' flag. The updated Python components then go into the /User/{username}/Library/Python/2.7/bin folder. You may then be required to add that location to the PATH in order for the compile to work.
Hoel
commented
6 years ago @screamerbg ok i will try to uninstall / reinstall CLI. "you might have to chase where is this mbed-cli installed, e.g. this should help you find which python is called" : well, this doesnt sound very good to be honnest, python is a mess and all this is very fragile to say the least.
@j3hill without sudo the update command was throwing: Cache entry deserialization failed, entry ignored i will try to re-install with the --user flag
Hoel
commented
6 years ago @screamerbg
$ pip uninstall mbed-cli
Uninstalling mbed-cli-1.8.2:
/usr/local/lib/python2.7/site-packages/mbed/__init__.py
/usr/local/lib/python2.7/site-packages/mbed/__init__.pyc
/usr/local/lib/python2.7/site-packages/mbed/__main__.py
/usr/local/lib/python2.7/site-packages/mbed/__main__.pyc
/usr/local/lib/python2.7/site-packages/mbed/mbed.py
/usr/local/lib/python2.7/site-packages/mbed/mbed.pyc
/usr/local/lib/python2.7/site-packages/mbed/mbed_terminal.py
/usr/local/lib/python2.7/site-packages/mbed/mbed_terminal.pyc
/usr/local/lib/python2.7/site-packages/mbed_cli-1.8.2.dist-info/METADATA
/usr/local/lib/python2.7/site-packages/mbed_cli-1.8.2.dist-info/RECORD
/usr/local/lib/python2.7/site-packages/mbed_cli-1.8.2.dist-info/WHEEL
/usr/local/lib/python2.7/site-packages/mbed_cli-1.8.2.dist-info/entry_points.txt
/usr/local/lib/python2.7/site-packages/mbed_cli-1.8.2.dist-info/top_level.txt
Proceed (y/n)? y
Successfully uninstalled mbed-cli-1.8.2
You are using pip version 9.0.3, however version 18.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
$ mbed --version
1.2.2
$ cat `which mbed`
#!/usr/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'mbed-cli==1.2.2','console_scripts','mbed'
__requires__ = 'mbed-cli==1.2.2'
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.exit(
load_entry_point('mbed-cli==1.2.2', 'console_scripts', 'mbed')()
)So its using /usr/local/lib/python2.7, not sure what to deduce of cat which mbed output.
By the way should i update back to pip to 18.1?
$ pip install mbed-cli --user
Collecting mbed-cli
Using cached https://files.pythonhosted.org/packages/95/b9/4634ae13e421873e852ad8dcb4445fab2375376eaf6cb73369dbdf4aeadb/mbed_cli-1.8.2-py2-none-any.whl
Installing collected packages: mbed-cli
The scripts mbed and mbed-cli are installed in '/Users/hoel/Library/Python/2.7/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
I then added /Users/hoel/Library/Python/2.7/bin to path
Hoel
commented
6 years ago reinstalling CLI did not change anything, mbed version is still 1.2.2 and it still fails to compile with the same error:
$ mbed --version
1.2.2
$ cat `which mbed`
#!/usr/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'mbed-cli==1.2.2','console_scripts','mbed'
...
$ mbed compile -m NUCLEO_L432KC -t GCC_ARM
[mbed] ERROR: Unknown Error: 'module' object has no attribute 'get_installed_distributions'
$ pip list
Package Version
---------- -------
mbed-cli 1.8.2
nose 1.3.7
numpy 1.15.2
pip 18.1
scipy 1.1.0
setuptools 40.4.3
wheel 0.32.0
$ which mbed
/usr/local/bin/mbedNo idea what to do next
Hoel
commented
6 years ago $ mbed detect -vv
[mbed] Working path "/Volumes/HD/XXXXX/XXXXXXX/FIRMWARE/L4680_L451CE_MBED_SRC/mbed-os-example-blinky" (program)
Traceback (most recent call last):
File "/Library/Python/2.7/site-packages/mbed/mbed.py", line 2601, in main
status = pargs.command(pargs)
File "/Library/Python/2.7/site-packages/mbed/mbed.py", line 1650, in thunk
return command(**argv)
File "/Library/Python/2.7/site-packages/mbed/mbed.py", line 2447, in detect
program.check_requirements(True)
File "/Library/Python/2.7/site-packages/mbed/mbed.py", line 1322, in check_requirements
installed_packages = [re.sub(r'-', '_', package.project_name.lower()) for package in pip.get_installed_distributions(local_only=True)]
AttributeError: 'module' object has no attribute 'get_installed_distributions'
[mbed] ERROR: Unknown Error: 'module' object has no attribute 'get_installed_distributions'
---i also exported the new python / mbed location to .bash PATH
$ export PATH=/Users/hoel/Library/Python/2.7/bin:$PATH
$ which mbed
/Users/hoel/Library/Python/2.7/bin/mbedI also went to /usr/local/bin/ and deleted mbed and mbed-cli
Hoel
commented
6 years ago Finally, after just 4 hours of struggle and guesswork (what a pain) ...
$ mbed compile -m NUCLEO_L432KC -t GCC_ARM --user
[mbed] Auto-installing missing Python modules...
[mbed] WARNING: Unable to auto-install required Python modules.
$ sudo mbed compile -m NUCLEO_L432KC -t GCC_ARM
[mbed] Auto-installing missing Python modules...
[Warning] @,: Compiler version mismatch: Have 4.8.4; expected version >= 6.0.0 and < 7.0.0
Building project mbed-os-example-blinky (NUCLEO_L432KC, GCC_ARM)
Scan: mbed-os-example-blinky
Scan: env
Compile [ 0.1%]: mbed_tz_context.c
....
Compile [100.0%]: stm_spi_api.c
Link: mbed-os-example-blinky
Elf2Bin: mbed-os-example-blinky
| Module | .text | .data | .bss |
|------------------|---------------|-------------|-------------|
| [fill] | 76(+76) | 8(+8) | 14(+14) |
| [lib]/c.a | 24524(+24524) | 2204(+2204) | 56(+56) |
| [lib]/gcc.a | 3792(+3792) | 0(+0) | 0(+0) |
| [lib]/m.a | 80(+80) | 0(+0) | 0(+0) |
| [lib]/misc | 228(+228) | 16(+16) | 28(+28) |
| main.o | 68(+68) | 4(+4) | 28(+28) |
| mbed-os/drivers | 216(+216) | 4(+4) | 100(+100) |
| mbed-os/hal | 1843(+1843) | 4(+4) | 68(+68) |
| mbed-os/platform | 3188(+3188) | 260(+260) | 197(+197) |
| mbed-os/rtos | 8498(+8498) | 168(+168) | 6053(+6053) |
| mbed-os/targets | 9675(+9675) | 4(+4) | 528(+528) |
| Subtotals | 52188(+52188) | 2672(+2672) | 7072(+7072) |
Total Static RAM memory (data + bss): 9744(+9744) bytes
Total Flash memory (text + data): 54860(+54860) bytes
Image: ./BUILD/NUCLEO_L432KC/GCC_ARM/mbed-os-example-blinky.binNow i will have the pleasure to struggle more hours for porting the custom target and generating a SW4STM32 project with compiled mbed-os folder.
It is really a big problem that we cannot generate the SW4STM32 project using compiled version of mbed-os directory directy from the CLI. The only SW4STM32 project CLI can generate uses the uncompiled version of mbed-os folder, which is not less that +17000 files and +700mo, and compiles in many minutes in SW4STM32 rather than the few seconds it should take. The project is then totally un-usable, it cannot even be shared due to it huge size. It takes no less than 4 to 8 hours (when we manage to fix all problems) to make, by hand, a SW4STM32 project for custom a target with compiled mbed-os folder, here is how its done:
Hoel
commented
6 years ago Hi, It works now but there is still something quite not right, at each compilation it is installing "missing python modules", also mbed is not happy with the compiler version, finally there is a bunch of warnings (both are repeated multiples times, only one occurence copied below).
$ mbed compile -m NUCLEO_L432KC -t GCC_ARM
[mbed] Auto-installing missing Python modules...
[Warning] @,: Compiler version mismatch: Have 4.8.4; expected version >= 6.0.0 and < 7.0.0
....
[Warning] MbedCRC.h@36,32: unknown option after '#pragma GCC diagnostic' kind [-Wpragmas]
....
[Warning] mbed_wait_api_rtos.cpp@45,41: 'static osStatus rtos::Thread::wait(uint32_t)' is deprecated (declared at ./mbed-os/rtos/Thread.h:442): Static methods only affecting current thread cause confusion. Replaced by ThisThread::sleep_for. [since mbed-os-5.10] [-Wdeprecated-declarations]I also have problems with the custom target, new ticket opened for this.
JojoS62
commented
6 years ago just some hints:
edit: I see the NUCLEO_L432KC is a supported target, so custom_targets.json and editing the exporter file is not neccessary. But it is also possible to compile the mbed-os to a library with the --library option.
Hoel
commented
6 years ago Thank you for the hint about .mbedignore however my concern is that the exporter does not take it into account.
use a custom_targets.json, see https://os.mbed.com/docs/v5.10/tools/adding-and-configuring-targets.html add your custom target to https://github.com/ARMmbed/mbed-os/blob/master/tools/export/sw4stm32/__init__.py , then the export for your target to the IDE should be much easier.
Well, i know the process and ported various targets already (however the last one has major issues https://github.com/ARMmbed/mbed-cli/issues/781) i exported SW4STM32 projects from CLI, the problem is : the CLI exporter is not able (or i havent found how yet) to export an SW4STM32 project with compiled mbed-os folder rather than full source mbed-os folder.
your compiler version should be checked,
The probem seems to be : CLI is using the default GCC shipped with OSX when it should be using a more recent version, for example the one embedded in SW4STM32, however at this time it works with the old GCC so rather than spending time on this and risking breaking everything i will deal with it later, once the custom target compilation is ok.
I see the NUCLEO_L432KC is a supported target...
Of course, the goal here was to get the CLI working again, so i used an existing target and blink example.
theotherjimmy
commented
6 years ago however my concern is that the exporter does not take .gitignore into account.
This is true: .gitignore is not understood or used by mbed compile or mbed export
theotherjimmy
commented
6 years ago the CLI exporter is not able (or i havent found how yet) to export an SW4STM32 project with compiled mbed-os folder rather than full source mbed-os folder.
In general the exporters are designed to mimic what mbed compile does. This includes building from source.
so rather than spending time on this and risking breaking everything i will deal with it later, once the custom target compilation is ok.
For what it's worth, using an older (or newer) version of GCC will put you at the same risk with respect to the rest of the code base. Mbed OS is tested with 6 <= GCC version < 7. Using a GCC version outside that range is not tested, so you may be at risk of compile succeeding without warnings and the board not booting (I have seen exactly that scenario with GCC4 before).
Hoel
commented
6 years ago For what it's worth, using an older (or newer) version of GCC will put you at the same risk with respect to the rest of the code base. Mbed OS is tested with 6 <= GCC version < 7. Using a GCC
Yes, i meant breaking the CLI. i will fix that once the custom target compile and the SW4STM32 template is functionnal.
In general the exporters are designed to mimic what mbed compile does. This includes building from source.
I understand, however when the CLI compiles from full source it does it fast, which is not the case of the SW4STM32 project. The SW4STM32 project generated from the CLI is not usable as is. Who would like to spend 5 or 6 minutes re-building each and every source file each time you want to compile the project and who would like to use a project made of 17000 files / 700 mb, i suggest that CLI team members try and see by themselves how un-usable the CLI generated SW4STM32 project is.
What is frustrating is that the online compiler generates the SW4STM32 project just right : it uses the compiled mbed folder (found in mbed-os/BUILD) and then compilation is fast in SW4STM32 and the project weight is only few mb. That mean the python code for exporting the SW4STM32 project correctly has already been written and is used in the online compiler server, that would be very good if someone at mbed had to idea to integrate this into the CLI so that we can get proper SW4STM32 project generated. As a side note, the project generated by the online compile is contained in a folder, that is way better than what the CLI does ( : generating the SW4STM32 project file at the root of the current directory).
theotherjimmy
commented
6 years ago What is frustrating is that the online compiler generates the SW4STM32 project just right : it ues the compiled mbed folder
I think you may be using an Mbed 2 project online then. Mbed OS 5 is built from source online and offline. Perhaps the solution to your troubles is to use an mbed 2 project offline.
(found in mbed-os/BUILD)
Definitely Mbed 2. the directory mbed (generated from mbed.bld) in very different from mbed-os (generated from mbed.lib), and mbed-os/BUILD is not going to contain any library (.a) files.
and then compilation is fast
Compilation is only slow for the first compile and if you explicitly ask it to be slow with the clean flag. All non-clean subsequent compiles will only build what has changed. My recommendation: don't use the clean flag.
in SW4STM32 and the project weight only few mb.
There's a big downside to this: you can't configure anything in the OS. Further, your fixation on project "weight"(size) is something that implies (to me) that you're going to zip it up. I think you could be better served by using mbed import and/or mbed deploy, especially if you plan to collaborate with others as you have already mentioned. Then the size of Mbed OS becomes less of a concern, as the size of your project is not dependent on the size of Mbed OS 5 or Mbed 2
theotherjimmy
commented
6 years ago Yes, i meant breaking the CLI.
Mbed CLI works with GCC 6. We test it with GCC 6 :)
Hoel
commented
6 years ago Compilation is only slow for the first compile and if you explicitly ask it to be slow with the clean flag. All non-clean subsequent compiles will only build what has changed. My recommendation: don't use the clean flag.
no, even after the first time compilation in SW4STM32 is still very slow, way too slow.
I think you could be better served by using mbed import and/or mbed deploy Well, i will check import and deply, not sure it can help with SW4STM32, for us it is out of question to work with CLI. We are 3 to work on the project, for ease we currently work on the online compiler with a wrong target, and now we need to use SW4STM32 because working on the wrong target is not an option anymore.
I dont specially focus on the size, if the project was 700mb and compililng as fast as it should it could be ok, but thats not the case and currently the generated project is really unusable. That said the weight is also a problem when it comes to share the project with others team members.
There's a big downside to this: you can't configure anything in the OS.
We dont need to re-configure mbed on the fly, once mbed is configured as we need (: all the unused services are disabled) i export from CLI / create the SW4STM32 template, and we work on that. If ever we need some disabled feature afterwards, then i generate another SW4STM32 template. Frankly, it matters a lot more that the project is fast to compile and decently lightweigth than being able to reconfigure mbed on the fly.
Hoel
commented
6 years ago I think you may be using an Mbed 2 project online then. Mbed OS 5 is built from source online and offline. Perhaps the solution to your troubles is to use an mbed 2 project offline.
Not sure, anyway the project we work on doesnt need mbed 5.
Definitely Mbed 2. the directory mbed (generated from mbed.bld) in very different from mbed-os (generated from mbed.lib), and mbed-os/BUILD is not going to contain any library (.a) files.
Yes maybe, i checked on the previous cutom target, mbed folder seems to contain only one library, libmbed.a :
JojoS62
commented
6 years ago maybe it works with the following steps:
I'm using also eclipse based IDEs, but I see the VSCode has become a better alternative. I want to avoid now also exporting the project to another location. One major disadvantage is that you loose the .git status. By keeping the project in its original dir, it is also much easier to update or switcch between mbed-os versions.
theotherjimmy
commented
6 years ago no, even after the first time compilation in SW4STM32 is still very slow, way too slow.
I was explaining a property of Mbed CLI. I should have specified.
Hoel
commented
6 years ago @JojoS62 nice, i will try, never thought to do it that way. @theotherjimmy indeed, the CLI is always very fast, even first built from source
Anyway, thanks guys for the extended support and suggestions, looks like everything is almost ready to work now
Hoel
commented
6 years ago Hi, it compiles but i got RTOS MUTEX FAULT https://armmbed.github.io/mbedos-error/?error=0x80010133 Even if the fault occurs when compiled from SW4STM32 (so with a compatible GCC version) I would like to set CLI to use the GCC 6.3.1 and see if the fault occurs here, i added the GCC 6.3.1 path to mbed_settings.py and via command line, but when i compile the CLI continues to complain that GCC version is incompatible as if nothing was done, what could be wrong?
$ mbed config -G ARM_PATH "/Applications/Ac6/SystemWorkbench.app/Contents/Eclipse/plugins/fr.ac6.mcu.externaltools.arm-none.macos64_1.15.0.201708311556/tools/compiler/bin/arm-none-eabi-gcc"
[mbed] /Applications/Ac6/SystemWorkbench.app/Contents/Eclipse/plugins/fr.ac6.mcu.externaltools.arm-none.macos64_1.15.0.201708311556/tools/compiler/bin/arm-none-eabi-gcc now set as global ARM_PATH
$ sudo mbed compile -m L4680_L451 -t GCC_ARM
Password:
[mbed] Auto-installing missing Python modules...
[Warning] @,: Compiler version mismatch: Have 4.8.4; expected version >= 6.0.0 and < 7.0.0
N.B. i tried with and without /arm-none-eabi-gcc and arm-none-eabi-gcc-6.3.1 after bin
EDIT: right, i didnt noticed mbed_config.py line was commented out, after fixing this the correct GCC is use, for some reason mbed config -G ARM_PATH is not taken into accout even when the mbed_config.py line is commented.
theotherjimmy
commented
6 years ago for some reason mbed config -G ARM_PATH is not taken into accout even when the mbed_config.py line is commented.
ARM_PATH is for Arm Compiler 5, you want GCC_ARM_PATH, for GCC Arm embedded.
Hoel
commented
6 years ago Ok that makes sense indeed, anyway the GCC path is set in mbed_settings.py and so the CLI uses GCC 6.3.1 as it should.
Hi, CLI fails to compile, environement is OSX 10.11.6, I tried to update CLI, it did nothing and still fail. Last time i used CLI few month ago it was working.
Reverting to PIP 9.0.3 did not fix the problem: