T3: linking libarm_cortexM3l_math.a

Status
Not open for further replies.
I think I know what is wrong. The CMSIS folder is found in the Arduino 1.5.2 distribution only. So I have to copy it and paste it into my Arduino 1.0.5 distribution.

I thought that's what I said earlier today! I guess it wasn't very clear. Sorry.
 
Sadly, its still not working for me.

This is what I did:

1. Download libarm_cortexM4l_math.a from the internet and copy it to my arduino folder, into a new 'lib' directory located at:
Arduino.app/Contents/Resources/Java/hardware/arduino/lib/

2. Download Arduino 1.5.2. Copy:
Arduino1.5.2/Contents/Resources/Java/hardware/arduino/sam/system/CMSIS/CMSIS/Include/* to
Arduino.app/Contents/Resources/Java/hardware/teensy/cores/teensy3/

3. Goto Arduino.app/Contents/Resources/Java/hardware/tools/arm-none-eabi/bin and rename arm-none-eabi-gcc to arm-none-eabi.gcc.real

4. Download the perl script from https://gist.github.com/TJC/5633484, name it as arm-none-eabi-gcc and put it inside:
Arduino.app/Contents/Resources/Java/hardware/tools/arm-none-eabi/bin

5. Change the path inside arm-none-eabi-gcc:
From:
push @new_args, "-L/home/tobyc/git/arduino/lib", "-larm_cortexM4l_math", "-lm";
To:
push @new_args, "./../../../arduino/lib", "-larm_cortexM4l_math", "-lm";


So now when I try to complile a program that performs FFT, I get the following error:
Cannot run program Arduino.app/Contents/Resources/Java/hardware/tools/arm-none-eabi/bin/arm-none-eabi-gcc": error 13, Permission denied.

Any help?
 
This is what I did:

Wow, that's a lot of complex steps!!!!

Several months ago I added hpyle's patch to Teensyduino, so you should not need to do all that crazy stuff.

First, extract a fresh copy of Arduino 1.0.5 and install Teensyduino 1.14 to it.

Then edit boards.txt. On a Mac, that should be in Arduino.app/Contents/Resources/Java/hardware/teensy/boards.txt. Add just one line:

Code:
teensy3.build.additionalobject1=/full/pathname/to/libarm_cortexM4l_math.a

Of course, replace "/full/pathname/to" with the correct pathname to where your copy of that file is located. It doesn't matter where, just make sure you get the full pathname correct.

Restart Arduino (on a Mac, use cmd-Q to fully quit, since like most Mac programs it stays running after you close the last window). Arduino rereads boards.txt when it starts up, so you must restart for your edit to that file to take hold.

To check if your edit worked, use File > Preferences to turn on verbose info while compiling. Then compile something. The (very long) linker command should have the libarm_cortexM4l_math.a near the end of the huge list of files it builds into your final .elf image.





Edit: if you read hyple's post about the patch, DO NOT copy that .jar file into your Arduino lib directory. It's an old version and is certainly not correct for 1.0.5. I designed the Teensyduino installer to very carefully check for compatibility of the .jar files against known versions. The "Next" button in the installer only enables if *MANY* checks all pass. I put an incredible amount of work into making that installer very safe, it can't result in corrupting a copy of Arduino (or at least the odds of corruption are extremely low). But as soon as you start copying and replacing binary files without extreme attention to versions and platforms, all sorts of subtle problems can occur. It's very easy to end up with a copy of the Arduino IDE which seems to work, but then has unexpected failures. I'd highly recommend you start over with a fresh copy of Arduino+Teensyduino, then only edit boards.txt.
 
Last edited:
Thanks Paul!

I am still facing a problem here. I followed your instructions and deleted my Arduino and Teensy program, doing a fresh install of Arduino and Teensyduino.

I have no errors in the verbose. However, when I try to run my program for FFT, get this error:

fatal error: arm_math.h: No such file or directory


I also have this very weird problem. I have downloaded teensyduino from here (http://www.pjrc.com/teensy/td_download.html)

But when I check the version, its showing up as Teensy Loader 1.07.

teensy.jpg
 
fatal error: arm_math.h: No such file or directory

You'll need to copy that .h file and any others it needs. The simplest approach would be to just put them into your program's folder.

But when I check the version, its showing up as Teensy Loader 1.07.

That's normal. Originally the Teensy Loader was developed separately from Teensyduino, so it has its own independent version number.

I'm considering just bumping it up to 1.15 and keeping it in sync with Teensyduino, which ought to be less confusing?
 
For the include files needed by CMSIS, I copied the contents of this directory:
hardware\arduino\sam\system\CMSIS\CMSIS\Include
from the Arduino 1.0.5 distribution into a new subdirectory under my Teensy libraries subdirectory:
teensy\libraries\arm_math

Pete
 
Wow, that's a lot of complex steps!!!!

Several months ago I added hpyle's patch to Teensyduino, so you should not need to do all that crazy stuff.

Wow, I wish I'd known that before hacking everything up myself! >.<

On another related topic though.. The version of the Cortex M4 library that I found packaged with Arduino IDE 1.5.1 was quite old; it only supports now-deprecated FFT functions. I don't suppose anyone has a newer version available?
 
I'm considering adding the math library and header to Teensyduino 1.15.

Does anyone have any input or ideas about how (or if) I ought to do this?

My inclination is to link the .a file by default as part of the build, and put the header somewhere the compiler can find it, but you'd still need to put a #include "arm_math.h" into your program if you want to use it. How does that sound?
 
I'm considering adding the math library and header to Teensyduino 1.15.

Does anyone have any input or ideas about how (or if) I ought to do this?

My inclination is to link the .a file by default as part of the build, and put the header somewhere the compiler can find it, but you'd still need to put a #include "arm_math.h" into your program if you want to use it. How does that sound?

I think it's a good idea to add this to Teensyduino.
Note that there are some other headers that arm_math.h depends on, such as arm_common_table.h, core_cm4.h, etc.
You probably are aware, but I thought I'd mention it just in case.
 
Wow, timing is everything. I was just starting to look into this for my project to have some more interesting frequency response. (https://www.facebook.com/seagrassProject)

Everything worked up to the link. I'm doing most of my development from a makefile but wanted to try to get this to work through the IDE. I got the lib from https://code.google.com/p/rt-thread...C/libarm_cortexM4l_math.a?spec=svn2124&r=2124

I'm looking at the .ld file but not sure if the problem is there or in the .a Any thoughts?

Thanks again for the great post.

mauricio

/Applications/Development/Arduino/Arduino.app/Contents/Resources/Java/hardware/tools/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/4.7.2/../../../../arm-none-eabi/bin/ld: fftTest.cpp.elf section `.text' will not fit in region `FLASH'
/Applications/Development/Arduino/Arduino.app/Contents/Resources/Java/hardware/tools/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/4.7.2/../../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 47720 bytes
collect2: error: ld returned 1 exit status
 
I wonder how much floating point is being done on Teensy 3.0's, and whether there is enough of a market for Paul to consider using a chip with hardware floating point for Teensy 3.0++. The Cortex M4F has single precision floating point built in (but not double, so you would need to use 'float' as a type, and add 'f' suffixes to constants to keep the calculations in single precision). Some things naturally lend themselves to being done in floating point, but is it a significant share of the market to justify going to a more expensive chip?
 
I wonder how much floating point is being done on Teensy 3.0's, and whether there is enough of a market for Paul to consider using a chip with hardware floating point for Teensy 3.0++. The Cortex M4F has single precision floating point built in (but not double, so you would need to use 'float' as a type, and add 'f' suffixes to constants to keep the calculations in single precision). Some things naturally lend themselves to being done in floating point, but is it a significant share of the market to justify going to a more expensive chip?

The Cortex M4 has a DSP that provides a lot of functions, many of which are available in single-precision floating point. I thought those *were* performed in hardware by the DSP, even though the general CPU doesn't have a hardware floating point system

I note that the chip only has 16kb to play with, so using doubles would be halving the amount you could store and operate upon. (I'm having issues with this myself currently, and that's just with single-precision!)
 
First, I'd like to ask anyone who's actually used this library to post any sketches that use it. I'll use them for testing. So far, the only one I've seen is this one from wintrmute. If anyone has any others, please post them to this thread?

So far, I have not personally used this library, but I intend to work with it soon.

I have spent a LOT of time with the ARM reference manual and other ARM documentation. One thing is pretty clear... the "DSP" feature of the Cortex-M4 is mostly designed for the "q15" variable type, which is a 16 bit fixed point number representing +0.99996 to -1.00000.

@MichaelMeissner - I can't talk about Teensy++ 3.0 at this time, because we're still waiting for a new chip from Freescale. Until they officially release it, all the technical details are under NDA. The best I can say at this moment is that I believe you'll agree (in hindsight) that it was worth the wait.
 
I've attached a ZIP archive of 7 CMSIS sketches that I've got working on Teensy 3.

Pete
[edit] I have two others, one of which runs but fails its test and the other hangs.
 

Attachments

  • CMSIS.zip
    39.8 KB · Views: 217
@MichaelMeissner - I can't talk about Teensy++ 3.0 at this time, because we're still waiting for a new chip from Freescale. Until they officially release it, all the technical details are under NDA. The best I can say at this moment is that I believe you'll agree (in hindsight) that it was worth the wait.
Believe me, I know about NDA's and how frustrating it can be not to talk about them in wider contexts, particularly as people are asking for new and better stuff. I have various war stories over the years, but this probably isn't the forum to elaborate on them.

I was just wondering out loud how many people could benefit by having a chip that does floating point in the chip, rather than software emulation. I'm starting to think as the embedded microprocessors take on more tasks, the need for floating point increases. In terms of hobbyists buying a single chip retail, it is an interesting cross over point of whether it is better to go with a microprocessor like the Teensy 3.0/Due/mbed or a small single board computer like a Raspberry Pi/Beagle Bone Black/pcDuino/etc.

On the other hand, if you only use FP to deal with a temp. sensor once a second, you don't really need hardware floating point.
 
When the clock speeds get very fast (ie GHz), isn't it a harder software problem trying to interoperate with things that operate at much slower frequencies?
At least that's what I'm gathering from following Paul and other's posts lately.

Which makes me wonder if it's not just better to have something like a multi-core teensy 3.0.
Maybe with shared DMA?

One problem would be that it would be less teensy, unless it's in the same chip. Or maybe the 2nd ARM could take the place of the Mini54? I admit that sounds kinda weird, but just wondering.
 
I've attached a ZIP archive of 7 CMSIS sketches that I've got working on Teensy 3.

Thanks!!!


Regarding fast hardware, I believe the supplied software makes the biggest difference. For example, in the recent benchmarks, Arduino Due has the fastest USB hardware, but it's nearly the slowest board when you run measure the actual speed using Arduino sketches.

While I haven't used this ARM math library yet (I certainly intend to do so soon), IAR and others have published some benchmarks that show its extremely optimized. It's also not exactly easy to use, but I do believe it should be possible to build some nice audio processing libraries on top of it. I'm pretty excited about those possibilities.

Of course, faster hardware is pretty enticing too. You know I can't discuss Teensy++ 3.0 yet, but you'd be pretty safe to assume it will be faster. Even then, it's the software that makes the biggest difference, especially for people using Arduino and not looking to dig into low-level programming, so I'm going to keep investing most of my effort into the software side.
 
Thanks!!!



Of course, faster hardware is pretty enticing too. You know I can't discuss Teensy++ 3.0 yet, but you'd be pretty safe to assume it will be faster. Even then, it's the software that makes the biggest difference, especially for people using Arduino and not looking to dig into low-level programming, so I'm going to keep investing most of my effort into the software side.

There are lots of nice audio applications that work well with a fast integer multiplier and a good fixed point library. There are also sound synthesis and audio processing techniques that are really hard to with such constraints. Recursive filters (IIR) like resonators, for example, are problematic for audio applications even with single precision floating point. I am waiting for a bit more infrastructure to be accessible to people (easy codec hookup, DMA audio I/O) before throwing in some of the low hanging fruit (additive synthesis, subtractive synthesis, migrators, singing voice) in the integer DSP space.

The first teensy-like board with a real single-precision floating point will attract a lot of attention from the music/audio hacking community. We would then be able to use some of the high-productivity tools like faust and PD to move a 50 year history of Audio/Music DSP code to it.. Currently the top contenders for this sort of work are the new Beagle bone and the Rasberry PI (see satellite CCRMA) but it is awkward to have to shuttle the gesture between arduinoesque boards and the processor doing sound synthesis. Even though we built a protocol designed to solve that problem (OSC) I would rather do the sound synthesis and gesture I/O on the same chip.
 
Last edited:
OK! Thank you very much. I'm linked and running. The basic sample is passing the initial test. I'm going to start playing around more with real data but am very excited to have gotten over the hump. Makefile conniptions.

As for the market, in the Bay Area artistic community, this kind of audio analysis / visualization is what I'm hearing a lot about. The basic functionality with Arduino is all well and good but people are clamoring for something that can bridge the gap (like adrianfreed talks about) and keep the small footprint.
 
It seems to be missing arm_fft_bin_data.h :(

Oh, sorry about that.
There was nothing special in it, just a huge array of floats that is used as the input to the fft function.
In the original it was 2048 entries, but I had to reduce it to half that in order for everything to fit in memory.
 
Status
Not open for further replies.
Back
Top