Jump to content
43oh

fughilli

Members
  • Content Count

    11
  • Joined

  • Last visited

About fughilli

  • Rank
    Member

Profile Information

  • Sparkfun
    IOIO, Bus Pirate, GPS Module(s), Arduino Mega
  1. They are both using the same toolchain. I actually have Code::Blocks pointing to the /bin directory under Energia/hardware/tools/lm4f. As for include directories, I originally had added Energia/hardware/tools/lm4f/arm-none-eabi/include and Energia/hardware/tools/lm4f/arm-none-eabi/include/c++/4.7.1 to the build search paths in Code::Blocks, but I removed them later; that didn't seem to change anything... I tried fixing the warnings about initializer lists by populating the arrays manually, but that didn't fix it; I also tried compiling with the C++11 option, but that didn't fix it either.
  2. Hello all, A year or two ago I attempted to setup Code::Blocks with the arm-none-eabi toolchain so that I could compile and run my Energia projects without dealing with the idiosyncrasies of the Processing-based IDE. I did not much understand command-line tools or GCC and so my efforts were somewhat frustrated. I have picked it up again, and almost have it working. I have analyzed the verbose output from Energia to determine which compiler/linker flags are used, and set up Code::Blocks to do the exact same things as Energia during compilation (excepting one thing, which I will get to later
  3. Hello again, I've been busy thinking about how to restructure this library, and also about how to fix some issues I discovered with it. First: The modified linker script I originally posted is--in fact--flawed. Seriously so. I added in a section in the RAM for the ARM exception unwinding table (bounded by the __exidx_start and __exidx_end symbols) to allow me to use the GCC library functions that trigger errors (inverse trig, sqrt, etc...). Unfortunately, I did not have a very strong understanding of how linker scripts actually worked, and so I ended up placing that section in such
  4. Hmm. That's an interesting issue. I will investigate as well, but I personally haven't had any issues between delayMicroseconds() and the servo library. I wrote these three libraries and the Chronos library for a quadcopter project I am working on, and they all play nicely with one another, including delays and the other built-in library functions. Thanks for bringing my attention to the problem! -K/Fughilli
  5. Hello all! I've been on a sort of coding binge lately... and so a new library has been born! This one will come with basically no manual and no explanation, other than: It lets you schedule things to happen at specific times. It is timer interrupt-driven. It works with the StellarPad. It requires that you make some modifications to startup_gcc.c and (at least, in my case) to Energia.h, main.c, and lm4fcpp.ld. All the files are attached below. Be warned that this is an early prototype, and that though it works (as far as I can tell) now, it will probably undergo some pretty
  6. Hello all! I've got three new libraries to share with you! They are: An Arduino "Servo" library clone (StellarPad): Duplicates all of the functionality of the Arduino "Servo" library. Fully compatible with all existing sketches that use the Arduino "Servo" library. Based upon the Eigendreams servo library posted here a while back. Supports 8 servos as-is. Can be modified to do a heck of a lot more, but that is up to you to incorporate (at least for now -- update to come soon). An ultrasonic rangefinder library (StellarPad, easily modifiable to work with other Energia device
  7. Okay, so I've changed the code a bit to remove any ambiguity that may have been presented by the use of Random. The new code is as follows: #include <math.h> float test_arg = 1.0f; void setup () { Serial.begin(9600); delay(100); for(int i = 0; i < 10; i++) { Serial.println(sqrt(test_arg)); test_arg += 0.1f; } } void loop () { } It still doesn't compile and spits out the same error: D:\ENERGIA\HARDWARE\TOOLS\LM4F\BIN\arm-none-eabi-g++ -c -g -Os -Wall -fno-rtti -fno-exceptions -ffunction-sections -fdata-sections -mthumb -mcpu=cortex-m4 -mfloat-abi=h
  8. Hi, I'm having an issue with the sqrt() function. The following code compiles and runs: #include <math.h> void setup() { Serial.begin(9600); delay(100); Serial.println(sqrt(1.5f)); } void loop() { } It gives the following output on the serial console: 1.22 The following code, however, does not compile: #include <math.h> void setup() { Serial.begin(9600); randomSeed(analogRead(A0)); delay(100); Serial.println(sqrt(random(0.0, 1.0f))); } void loop() { } Energia spits out the following: D:\ENERGIA\HARDWARE\TOOLS\LM4F\BIN\arm-none-eabi-g++ -c -g
  9. Well, after much deliberation and a while reading through documentation on C++ templates, I've (more or less) fixed my own problem. Instead of allocating memory dynamically, I've opted for a statically allocated Smoother instance using a template argument. The new library is attached below. Any further suggestions would be greatly appreciated! Smoother.zip
  10. Hey Rickysinho! I had the same question about two days ago, and I found a couple on this forum available for download. However, I didn't spot one that matched the layout of the official Arduino servo library, so I've modified one that I got from here (eigendreams' library, github here: https://github.com/eigendreams/stellaris_energia_libs) to be a drop-in substitute. Go ahead and use that one for now; it works well as-is. I'm gonna keep tinkering with my library and see if I can't release it here sometime soon.
  11. Hello everyone, I've written a small library for smoothing raw data by averaging collected values over a set history, and to accomplish this in a portable way I made the "Smoother" class a template. There is an array of the generic T type that starts as a private pointer and is then allocated as an array using the "new" keyword of a size specified by the user. Everything works fine and dandy on codepad.org, so I assumed I could just plop it down verbatim onto the Stellaris Launchpad. Unfortunately, the sample program I've written does not work as expected; instead, the analogRead() fun
×
×
  • Create New...