Jump to content

pimmel

Members
  • Content Count

    26
  • Joined

  • Last visited

About pimmel

  • Rank
    Member

Contact Methods

  • Website URL
    http://underwaterwhistler.blogspot.com/

Profile Information

  • Gender
    Male
  • Location
    Madison, Alabama
  • Github
    https://github.com/kpimmel
  1. 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!
  2. 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_WriteRegister(137, 16); Wire.beginTransmission(SI570); // ... // Unfreeze DCO err |= SI570_WriteRegister(137, 0);
  3. ...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, mspgcc, i2c library, serial debugging capability. If anyone is interested in the code, I've attached it to this final post... test3.zip [1] - http://forum.43oh.com/topic/1772-universal-ripple-control-receiver/?p=16781 And if you're really bored, I blogged about it here.
  4. 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(); Serial.print("read some bytes\n"); Wire.requestFrom(0x50,3); while(Wire.available()) { char c = Wire.read(); Serial.print(c); } } void loop() { // put your main code here, to run repeatedly: } Output in a serial terminal: write some bytes move the read pointer read some bytes CAB Real sexy, huh? So now I know that the coms and the wiring work, I need to figure out what is going on in the other I2C attempts above.
  5. 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 DCOCTL = 0; BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; // Setup the serial port // Serial out: P1.1 (BIT1) // Serial in: P1.2 (BIT2) // Bit rate: 9600 (CPU freq / bit rate) serial_setup (BIT1, BIT2, 1000000 / 9600); printf("Can we write to serial???\r\n"); // Send a string TI_USCI_I2C_transmitinit(dev_address,0xa); printf("1\r\n"); while ( TI_USCI_I2C_notready() ); // wait for bus to be free printf("2\r\n"); //if ( TI_USCI_I2C_slave_present(dev_address) ) // slave address may differ from //{ // initialization printf("Write some bytes...\r\n"); while ( TI_USCI_I2C_notready() ); // wait for bus to be free printf("3\r\n"); TI_USCI_I2C_transmit(5,array); // start transmitting printf("4\r\n"); while ( TI_USCI_I2C_notready() ); // wait for bus to be free printf("Move read pointer...\r\n"); TI_USCI_I2C_transmitinit(dev_address,0xa); printf("6\r\n"); while ( TI_USCI_I2C_notready() ); // wait for bus to be free printf("7\r\n"); TI_USCI_I2C_transmit(2,array); // start transmitting printf("8\r\n"); while ( TI_USCI_I2C_notready() ); // wait for bus to be free printf("Read some bytes...\r\n"); TI_USCI_I2C_receiveinit(dev_address, 0xa); // init receiving with USCI while ( TI_USCI_I2C_notready() ); // wait for bus to be free TI_USCI_I2C_receive(3,store); while ( TI_USCI_I2C_notready() ); // wait for bus to be free //} printf("%i %i %i \r\n", store[0], store[1], data[2]); for (; { // Do forever c = serial_getc (); // Get a char serial_putc (c); // Echo it back } } With my serial console spitting out the following Can we write to serial??? 1 2 Write some bytes... 3 4 Move read pointer... 6 7 8 Read some bytes... 0 0 -8454 I know I'm missing something obvious, as folks are using I2C regularly Does anyone spot the error of my ways? [1] - http://www.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa382
  6. 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.
  7. 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 it works and set about to conquer the world with my g2553 chip. Below is my simple little test program that aims to replicate the test case of the DP 3EEPROM. #include <msp430.h> #include "I2C_MSP430.h" #include "serial.h" void printf(char *, ...); void main(void) { char c; //uint8_t dev_address = 0xa0; uint8_t dev_address = 0b10100000; uint8_t reg_address = 0x00; uint8_t data[3]; int i; // Disable watchdog WDTCTL = WDTPW + WDTHOLD; // Use 1 MHz DCO factory calibration DCOCTL = 0; BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; // Setup the serial port // Serial out: P1.1 (BIT1) // Serial in: P1.2 (BIT2) // Bit rate: 9600 (CPU freq / bit rate) serial_setup (BIT1, BIT2, 1000000 / 9600); // Send a string printf("Write some bytes...\r\n"); I2CbeginTransmission(dev_address); I2Cwrite(0); I2Cwrite(0); I2Cwrite(3); I2Cwrite(2); I2Cwrite(1); I2CendTransmission(); printf("Move read pointer...\r\n"); I2CbeginTransmission(dev_address); I2Cwrite(0x0); I2Cwrite(0x0); I2CendTransmission(); printf("Read some bytes...\r\n"); dev_address = 0b10100001; I2CrequestFrom(dev_address, 3); for (i = 0; i < 3; i++) { data[i] = I2Cread(); } printf("%i %i %i \r\n", data[0], data[1], data[2]); for (; { // Do forever c = serial_getc (); // Get a char serial_putc (c); // Echo it back } } The first issue I ran into was that it seemed to hang in the I2CendTransmission function whenever it tried to put the chip into low power. I commented out those lines and the program moved on, but I am not getting the results I expected Sample output in my serial console: Write some bytes... Move read pointer... Read some bytes... 0 0 0 Does anyone with kung-fu prowess have any idea what I'm doing wrong? I admit to being fairly new to actually trying to use I2C. I've tried my device address with the read/write bit set to one and zero, and it didn't seem to change the result. Here is my setup; Windows 7, using commandline compilation with msp430-gcc compiler shipped with Energia. ***EDIT - REMOVED THIS CODE SINCE IT IS SUPERCEDED IN LATER POST*** I've attached my simple little project with a Makefile in case you're morbidly interested... Many thanks, Keith [1] - http://forum.43oh.com/topic/3216-need-help-with-i2c-using-msp430g2553/?p=33924 [2] - http://forum.43oh.com/topic/1289-tiny-printf-c-version/ [3] - http://dangerousprototypes.com/docs/3EEPROM_explorer_board#24AA_I2C_EEPROM
  8. 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 and ceil actually are defined somewhere....
  9. 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: rm -fr $(OBJECTS) main.elf flash: mspdebug tilib -d USB --force-reset "prog main.elf" size: msp430-size main.elf So when I exercise make, I get the error of the linker not finding -lstdc++ If I add -nodefaultlibs to my CFLAGS, I got a metric crap ton of math library functions not being c:\pimmel\workspace\msp430i2c>make msp430-g++ -Os -Wall -g -mmcu=msp430g2553 -nodefaultlibs -lm -lc -lgcc -c main.cpp msp430-g++ -Os -Wall -g -mmcu=msp430g2553 -nodefaultlibs -lm -lc -lgcc -c SI570.cpp SI570.cpp: In member function 'void SI570::get_registers()': SI570.cpp:76:24: warning: suggest parentheses around comparison in operand of '& ' [-Wparentheses] SI570.cpp:53:7: warning: unused variable 'i' [-Wunused-variable] msp430-g++ -Os -Wall -g -mmcu=msp430g2553 -nodefaultlibs -lm -lc -lgcc main.o SI570.o -o main.elf SI570.o: In function `SI570::get_registers()': SI570.cpp:(.text+0x26e): undefined reference to `__floatsisf' SI570.cpp:(.text+0x278): undefined reference to `__mulsf3' SI570.cpp:(.text+0x27c): undefined reference to `__fixunssfsi' SI570.cpp:(.text+0x280): undefined reference to `__floatunsisf' SI570.cpp:(.text+0x296): undefined reference to `__floatsisf' SI570.cpp:(.text+0x2a0): undefined reference to `__mulsf3' SI570.cpp:(.text+0x2ac): undefined reference to `__addsf3' SI570.cpp:(.text+0x2b0): undefined reference to `__fixunssfsi' SI570.cpp:(.text+0x2c0): undefined reference to `__floatunsisf' SI570.cpp:(.text+0x2ca): undefined reference to `__mulsf3' SI570.cpp:(.text+0x2fc): undefined reference to `__floatsisf' SI570.cpp:(.text+0x308): undefined reference to `__addsf3' (etc...) I've tried differing combinations of the combination of -lm -lc -lgcc per a couple of stackoverflow posts [3], but nothing really seemed to change. Does anyone have any pointers for me on how to link this feller? As an aside, I dropped the following bat file into the bin directory and when launched, it automatically adds the path for the compiler and msp430-debug. I found it convenient: gccvar.bat @echo off rem This file is the script to set path for mspgcc tool chain. set TL_PATH=%~dp0 set PATH=%TL_PATH%;%PATH%;%TL_PATH%\..\mspdebug cmd /K cd %CD% [1] - http://mbed.org/users/soldeerridder/code/SI570/ [2] - http://forum.43oh.com/topic/835-makefile-for-mspgcc/ [3] - http://stackoverflow.com/questions/6534191/undefined-reference-to-only-some-math-h-functions
  10. 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 the hood of what is going on in the compilation/build/linking process. I found a nifty little simple blinky example that included an easy-to-modify makefile [7] and I was able to build and flash that on to the chip. So my question is, where do I go from here in the world of ARM? I don't really have a good understanding of the linker script, how/if you need to modify it, and I also really want to try and understand how to access the libraries that are included in the ROM on the die. Does anyone have any insight into that? All the LPC8xx examples I have found some to rely heavily on third party libraries that I can't follow or find, or (like in the example of the midibel stuff) are so arcane that I have a hard time trying to understand the code. I do have the data sheet and the programming manual, but they really seem to be geared for someone who has a bit of experience working with ARMs already, if not specific experience with LPC parts. All I seem to read on the googletubes is how easy it is to work with the NXP parts, not where you learn to use them So my embedded masters, do you have any hints or pointers? Thanks, Keith [1] http://www.adafruit.com/products/1336 [2] http://underwaterwhistler.blogspot.com/2013/08/lpc810-arm-processor-board.html [3] http://lpcware.com/lpc800-mini-kit [4] http://learn.adafruit.com/getting-started-with-the-lpc810/introduction [5] https://launchpad.net/gcc-arm-embedded [6] http://lpcxpresso.code-red-tech.com/LPCXpresso/ [7] http://www.midibel.com/
  11. 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)
  12. 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
  13. I'm in...self portrait from many moons ago of trying to whistle underwater
  14. 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!
  15. That worked...I also had to make sure that the tcl package is not installed for Cygwin when building...Thanks for the help, Spen!
×
×
  • Create New...