pimmel

By the way, thank you for posting this. Your code gave me enough information to debug my code so that I could do the initial setting of si570 and make sure that my I2C connections were going to the right place. I can't tell you how pumped I was when I saw my frequency meter jump to 14.2 MHz after reflashing the launchpad!

Hi Jean-Yves, Looking over your code in the ino file, I think you might be writing to the wrong register to freeze the DCO; around line 167 you use register 135 instead of 137. Likewise for unfreezing the DCO. While some sample code I was playing around with didn't seem to matter for the register values I was playing with (jumping from 10 MHz to 14.2 MHz), the way I read the data sheet for the SI570 indicates that for large frequency change you should freeze 0b00010000 (0x10). So maybe use this instead? (untested - I was playing outside of energia): //Freeze DCO err |= SI570_Wr

...and the final post in this series involves success reading and writing via I2C outside of Energia, using a very modest addition to the neat I2C library created by @@V0JT4, found here [1]. When I tried compiling it with mspgcc, it complained about _swap_bytes being undefined, so I just knocked up a real quick implementation for it. It looks like it is used for 16bit addressing, but as I'm only using 8bit addressing at the moment, I haven't had an opportunity for it to fail magnificently! So now I have my starting point for playing around with the si570 I2C-controlled oscillator: makefile,

I downloaded the latest version of Energia, and now I actually got somewhere! Wootwoot.... My ino file #include "Wire.h" void setup() { // put your setup code here, to run once: Wire.begin(); Serial.begin(9600); Serial.print("write some bytes\n"); Wire.beginTransmission(0b10100000); Wire.write(0); Wire.write(0); Wire.write(67); // Capital 'C' Wire.write(65); // Capital 'A' Wire.write(66); // Capital 'B' Wire.endTransmission(); Serial.print("move the read pointer\n"); Wire.beginTransmission(0x50); Wire.write(0); Wire.write(0); Wire.endTransmission

Okay, so I tried to use the TI I2C library found here [1], but again I'm running into a brick wall My main routine code shown below #include <msp430.h> #include "TI_USCI_I2C_master.h" #include "serial.h" void printf(char *, ...); void main(void) { char c; unsigned int dev_address = 0b10100000; unsigned int reg_address = 0x00; unsigned int data[3]; unsigned char array[5] = { 0x0, 0x0, 0x3, 0x2, 0x1}; unsigned char store[3] = { 0x0, 0x0, 0x0}; int i; // Disable watchdog WDTCTL = WDTPW + WDTHOLD; // Use 1 MHz DCO factory calibration DCO

I should mention that I have my SCL line on P1.6 and my SDA line on P1.7...is that even correct? Everything I found (including the data sheet) seemed to indicate that those were the two pins to use, but I couldn't really follow the I2C code and find an explicit declaration of using those pins. One more quick edit; I have 10k pull-up resistors on the SDA and SCL lines and I have the jumpers to the LEDs on the LP removed.

Hey gang, I'm slowly working my way towards supreme greatness and world-overlord status, but before I achieve that I thought I would set up some working tools in my toolbelt. So among the first things I wanted was a Pimmel-proof I2C setup. I'm using an MSP430g2553 chip, and I found some sample code that @@_Murphy_ created found here [1]. Paired with the wonderful serial printf combo found in this thread [2], I thought I had the makings of the awesomeness that is me. I soldered up a simple version of the 3eeprom board found on dangerousprototypes [3], tested it with a bus pirate to ensure i

Okay, so I tried reworking it using C-style structs and msp430-gcc instead of msp430-g++; basically I'm getting the same results if I try use floor and ceil from math.h; if I remove the --nodefaultlibs from my CFLAGS, I then get an error about floor and ceil not being defined. If I get slimy and use my own version of floor and ceil by using casting of ints, it actually compiles. So I know I'm missing something basic in the original problem. Does anyone have any insight as to what I bombed on during my linking and the missing math functions? I think I'm going to try and use nm and see if floor

So I'm trying to to create a simple little program that will interface with an si570 I2C-controlled variable oscillator. The code that I started with as a library was originally for an mbed platform [1]. Opting to keep the class structure from the mbed library, I proceeded to use the included msp430-g++ compiler shipped with Energia. I knocked up a quick Makefile based upon this thread here [2]: OBJECTS = main.o SI570.o CC = msp430-g++ CPPFLAGS =-Os -Wall -g -mmcu=msp430g2553 all : $(OBJECTS) $(CC) $(CPPFLAGS) $(OBJECTS) -o main.elf %.o : %.cpp $(CC) $(CPPFLAGS) -c $< clean:

Hey gang, In addition to trying to adapt some code into an Energia library for the SI570 I2C-controlled oscillator, I also have managed to get ahold of the Adafruit LPC810 mini-kit/programmer [1], with the intent to play around and learn something about working with ARM processors. Sick of using a breadboard, I soldered up on protoboard my own version [2] of NXP's LPC800 mini-board [3] and ran through the tutorials provided by Adafruit [4]. I've also installed the Launchpad generic ARM compiler [5] so that I am not tied to an IDE like LPCXpresso [6] and have a little more insight under th

Hello Jean-Yves, Sorry for going off-topic here, but I have been trying to build a simple Energia library for the si570 (on this board)...When I power it on, I have an initial frequency of ~10MHz...trying to force it to different frequency (both the small offset and large offset) resulted in no change at all. I have pull-up resistors on SDA and SCL. Unfortunately my harddrive crashed and I lost my code (it was based primarily off of an mbed library I found here). Would you be willing to share your si570 code? Thanks, Keith (KI4SAI)

At my job, we had a training class on FPGAs; the project I choose to do was a take on a digital theremin, which ended up using a Launchpad with Energia. If you're suffering from insomnia, feel free to check out the build notes and links to code here: http://underwaterwhistler.blogspot.com/2013/04/fun-with-msp430-launchpad-and-digilent.html

I'm in...self portrait from many moons ago of trying to whistle underwater

Okay, part two of working within cygwin. I now have a post on building up and using a debugging environment with OpenOCD and gdb. If anyone is interested, the write-up can be found at http://underwaterwhistler.blogspot.com/2013/02/stellaris-cygwin-and-openocd-for.html. Again, this is mostly work of others, based heavily off of support from Spen and Mauro. Enjoy!

That worked...I also had to make sure that the tcl package is not installed for Cygwin when building...Thanks for the help, Spen!

Okay, I had to modify some files for jimtcl....I didn't get some defs set, so it didn't find some POSIX-y files jim.c jim-clock.c jim-file.c jim-readdir.c Basically I had manually include unistd.h, sys/time.h, and dirent.h for these files as appropriate.... However, it built now....need to go check to see if it works....

Hmmm....still running into issues here... $ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd;branch=master Cloning into 'openocd'...remote: Counting objects: 42941, done.remote: Compressing objects: 100% (9317/9317), done.remote: Total 42941 (delta 35324), reused 40688 (delta 33498)Receiving objects: 100% (42941/42941), 9.52 MiB | 891 KiB/s, done.Resolving deltas: 100% (35324/35324), done. pimmel@pig ~/tools/tmp$ cd openocd/ pimmel@pig ~/tools/tmp/openocd$ ./bootstrap + aclocal + libtoolize --automake --copy + autoconf + autoheader + automake --gnu --add-missing --c

Continuing from where I left off in building up a development chain, I am trying to get openocd built, running and using gdb to debug in cygwin. I was able to generate an executable and set up a configuration item, based heavily off of a nice tutorial from Mauro Scomparin [1]. It did not appear that the trunk of the git tree of openocd contained the TI ICDI stuff yet, so I ended up using the patch similarly to what Mauro did in his. So I now have an executable...when trying to launch it with an LM4F120XL configuration file like so: pimmel@pig ~/stellaris/openocd-bin $ ./openocd.exe --fil

I was the author of the post you linked...I decided to embrace my love of Unix/Linux and opted to use cygwin; I wrote up a bit more (which can be found here: http://underwaterwhistler.blogspot.com/2013/01/getting-started-with-stellaris-launchpad.htm) and linked it originally here: http://forum.stellarisiti.com/topic/460-gcc-and-cygwin. It works rather well

I didn't see any posts on whether or not cygwin was a usable environment. I figured I would give it the college effort and see if I could build up a toolchain that allows me to compile and flash from within my editor of choice (Vim). The basic groundwork is laid out, and I have to say that I really didn't have to do any original work as it was basically all adapted from linux tutorials. If anyone is interested, I wrote up my experience at http://underwaterwhistler.blogspot.com/2013/01/getting-started-with-stellaris-launchpad.html

c:\pimmel\work\stellaris-launchpad-template-gcc-master>c:\ti\ccsv5\utils\bin\gmake.exe install ECHO is off. Linking... arm-none-eabi-ld -T c:/StellarisWare/boards/ek-lm4f120xl/hello/hello.ld --gc-sections --entry ResetISR -o bin/blink.axf src/main.o c:/StellarisWare/boards/ek-lm4f120xl/hello/startup_gcc.o c:/pimmel/apps/yagarto-20121222/bin/../lib/gcc/arm-none-eabi/4.7.2/../../../../arm-none-eabi/lib/thumb/v7m/libm.a c:/pimmel/apps/yagarto-20121222/bin/../lib/gcc/arm-none-eabi/4.7.2/../../../../arm-none-eabi/lib/thumb/v7m/libc.a c:/pimmel/apps/yagarto-20121222/bin/../lib/gcc/arm-none-eabi/4

I am used to using at my job vim and make together, and so I avoid IDEs when I can. I installed StellarisWare and am trying to modify the template/makefile[1] posted http://forum.stellarisiti.com/topic/328-stellaris-launchpad-gcc-template/?hl=template. I can get it to compile, and manually using the same command that is generated by my make install, I can get it to load, e.g c:\pimmel\work\stellaris-launchpad-template-gcc-master>lmflash -q ek-lm4f120xl -v -r bin/blink.bin Configuring Interface and Device...Failed to load dynamic library: 'ftd2xx.dll' Failed to load dynamic library: '

When did you get out? EE '97 here....

That I do....I'm still deciding between msp430 launchpad and the stellaris as to which to spend a bit more time upfront on....MSP430 seems to have an easier toolchain to set up and examples to go through (I'm a commandline guy), but the enhanced functionality of the stellaris is appealing as well...I also am interested in playing around with the embedded version of Lua (http://eluaproject.net) on the Stellaris.

Since I just did the same over in the 43oh forums, I figured I would do the same here. Greetings from Alabama!