arduino installed files - installed too many board types?

All distros
Post Reply
zmemw16
Posts: 1483
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

arduino installed files - installed too many board types?

Post by zmemw16 » Fri Aug 14, 2015 8:05 pm

i'm now looking at the various tools that i've managed to install somehow/somewhen primarily arm-none-eabi-gcc/gdb

so what would the minimum set of boards i need to install within arduino?

this is a jessie debian installation on my i7 laptop, what i find funny is that the debian package installed are arm-none-eabi-gcc is 4.8.4 and arm-none-eabi-gdb is 7.7.1

additionally i seem to have multiple levels of the arduino arm-none-eabi tools installed, i wonder if this might be the result of installing too many board types.

also i'm curious as to the presence of an CMSIS directory....
CMSIS - Cortex Microcontroller Software Interface Standard - well that makes sense:-)
and also as to the presence of an openocd directory.... and its 0.9, jessie is on 0.8 :-)
so where does arduino use that?
stephen@i7:~/ard165$ /home/stephen/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.3 20140228 (release) [ARM/embedded-4_8-branch revision 208322]
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

stephen@i7:~/ard165$ cd /home/stephen/.arduino15/packages/arduino/tools
stephen@i7:~/.arduino15/packages/arduino/tools$ ls
arm-none-eabi-gcc bossac CMSIS openocd
stephen@i7:~/.arduino15/packages/arduino/tools$ ls arm-none-eabi-gcc/
4.8.3-2014q1
stephen@i7:~/.arduino15/packages/arduino/tools$ ls arm-none-eabi-gcc/4.8.3-2014q1/
arm-none-eabi bin lib share
stephen@i7:~/.arduino15/packages/arduino/tools$ ls arm-none-eabi-gcc/4.8.3-2014q1/bin
arm-none-eabi-addr2line arm-none-eabi-elfedit arm-none-eabi-gcc-ranlib arm-none-eabi-nm arm-none-eabi-strings
arm-none-eabi-ar arm-none-eabi-g++ arm-none-eabi-gcov arm-none-eabi-objcopy arm-none-eabi-strip
arm-none-eabi-as arm-none-eabi-gcc arm-none-eabi-gdb arm-none-eabi-objdump
arm-none-eabi-c++ arm-none-eabi-gcc-4.8.3 arm-none-eabi-gprof arm-none-eabi-ranlib
arm-none-eabi-c++filt arm-none-eabi-gcc-ar arm-none-eabi-ld arm-none-eabi-readelf
arm-none-eabi-cpp arm-none-eabi-gcc-nm arm-none-eabi-ld.bfd arm-none-eabi-size
stephen@i7:~/.arduino15/packages/arduino/tools$ ls arm-none-eabi-gcc/4.8.3-2014q1/arm-none-eabi/
bin/ include/ lib/ share/
stephen@i7:~/.arduino15/packages/arduino/tools$ ls arm-none-eabi-gcc/4.8.3-2014q1/arm-none-eabi/bin/
ar as c++ g++ gcc ld ld.bfd nm objcopy objdump ranlib strip
stephen@i7:~/.arduino15/packages/arduino/tools$ arm-none-eabi-gcc/4.8.3-2014q1/arm-none-eabi/bin/gcc --version
gcc (GNU Tools for ARM Embedded Processors) 4.8.3 20140228 (release) [ARM/embedded-4_8-branch revision 208322]
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

User avatar
RogerClark
Posts: 7418
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: arduino installed files - installed too many board types?

Post by RogerClark » Mon Sep 28, 2015 6:35 pm

The ARM compiler installed by the IDE is for the Due. i.e you have to install the Due now to get the ARM Compiler (Well you can install the Zero as it also uses the ARM Compiler)

If a CMSIS is installed it will be for the Due or the Zero.

I'm not an expert on CMSIS but I thought that the CMSIS is processor specific.

The libmaple core does not use the STM32 CMSIS because at the time it was written (in 2012 / 2013) the license on many of STM files was not compatible with open source.

If you want to use CMSIS take a look at the HALMX core that @sheepdoll started the development of (and which I have a copy of in my GitHub account)

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: arduino installed files - installed too many board types?

Post by stevech » Tue Sep 29, 2015 2:07 am

Arm compilers... in the Arduino world that compiler is always GNU/GCC. The command line to the compiler, generated by an IDE's configuration, tells the compiler what back-end code generator to use, i.e., AVRxxx, ARM Cortex Mxxx w/ or w/o FPU. And so on.

CMSIS is generic to the Cortex cores' DSP support. Adding to CMSIS, each ARM vendor has their own suite of on-chip peripherals (UARTs, SPI, SDIO, DMA, etc.). In my experience, not much of CMSIS is used in a project that's not DSP oriented.

AT has I/O drivers for all their on-chip peripherals in their free Hardware Abstraction Library (HAL). Each peripheral can be used in all of its modes: polled I/O, interrupt driven, and DMA, and some with DMA chaining. And goodies like DMA of capture counter counts, and the like. Etc.
Prior to the HAL, and still today, ST has the SPL = Standard Peripheral Library. The SPL is a subset of the HAL now, and ST wants to phase out the SPL.

The ST pin-mapping graphical tool is called CubeMX. These ARM chips are too complex for most users to do it manually in one's lifetime (!). CubeMX is a tool that takes perhaps several days to learn. But like any other tool, it pays for itself quickly, in terms of reduced time to get or change a mapping and it reduces errors greatly.

The outcome of CubeMX is (a) a file containing all the mapping choices and clock / divider changes, and timer settings, and NVIC / DMA settings and so on; and (b) auto-generated C source code to initialize each peripheral on the chip per the user's choices. This code is a godsend. CubeMX can also generate a Project file for several popular IDEs: IAR, Keil, Attolic (GCC in skins), and Eclipse. I use IAR mostly.. it's so sweet to hit BUILD in CubeMX after choosing or altering the configuration of the pins and/or any of the peripherals... such as Timer settings, interrupts, etc. Then BUILD from CubMX goes right into IAR and there I am, ready to hit compile and download. No hours poring over MCU spec sheets.

None of the above is in the Arduino philosophy of starting with bare metal - as was done in the AVR days.

Post Reply