Jump to content

uberscientist

Members
  • Content Count

    11
  • Joined

  • Last visited

About uberscientist

  • Rank
    Member

Contact Methods

  • Website URL
    http://mindsforge.com

Profile Information

  • Location
    Phoenix, AZ
  • Interests
    Looking at and making interesting things
  1. It works now, Rick pointed out my silly mistake, I had got a new chip and didn't know TI had changed the VECTOR names in the header file >.<; I tried to edit the title of the OP with [solved] like the Arch forums, but I couldn't Thanks though greeeg
  2. @pabigot: Here's a gist of the makefile I'm using: https://gist.github.com/uberscientist/faba7f2050bf94d8176c I'm using an MSP430G2755. I've also tried both ways of spelling the interrupt constant, I wasn't sure which was better. $ msp430-elf-gcc --version msp430-elf-gcc (GCC) 4.8.0 20130315 (release (msp430-130423-272)) (Red Hat/devo) [trunk revision 196673] I should check if there's a newer version... I haven't . So it looks like you're getting the same error for most of the MCUs? I just pushed my project as it stands (it's terribly messy, sorry) https://bitbucket.org/naked/msp-datalogger/src/b834e8e463d4af6470515bd298010fa6542ad24a/?at=fatfs Thank you very much for looking into this with me
  3. Tried a bunch of different ways, even searched github for "__attribute__((interrupt" to see how others were doing it to no avail. Thanks for your replies! Yeah, it didn't work, but I've left the underscores off for further tests though, I just copy-pasted this from that old post.
  4. I'm getting this error: main.c: In function 'Timer_A': main.c:150:28: error: MSP430 builtin functions only work inside interrupt handlers __bic_SR_register_on_exit(CPUOFF); // Clear CPUOFF bit from 0(SR) ^ makefile:23: recipe for target 'main.o' failed With this code: // TimerA interrupt __attribute__((__interrupt__(TIMERA0_VECTOR))) Timer_A (void) { iflag |= BIT0; // Set BIT0 flag __bic_SR_register_on_exit(CPUOFF); // Clear CPUOFF bit from 0(SR) } For some reason msp430-elf-gcc thinks my ISR isn't an ISR Any ideas? I emailed one of the red hat guys who submitted the GCC patch with the function that checks whether a function is an interrupt handler or not.
  5. I finally got a MSP430G2755 -- and it worked! I guess 1KB RAM is just not enough for the full FatFS, PetitFS seemed to work fine fwiw. I had to remove the -Wl,--gc-sections line from the linker options, but after that it worked.
  6. Thanks for the links and words, I'll just give a progress update... I've been able to mount the FAT32 SD card, but as soon as I try to use the f_open(...) function I get that buggy behaviour I was talking about in my original post: Dim LED if I turn the GPIO pin high before calling f_open, or the LED doesn't even turn on if I place it after f_open. It is flickering on/off very quickly so I figure the MSP430 is cycling on/off very rapidly due to the compiler creating an .elf file that is doing something screwy. Oh well, I might just ditch the FatFS idea and just use the SD card as raw flash memory like I was doing before all these shenanigans.
  7. I was looking to interface FatFS to the MSP430G2744: It has 1KB of ram (may be enough? If not I might look into using the MSP430G2755 with 4KB of ram) I've been hacking away at getting it interfaced after doing Petit FatFS and realizing I needed to have resizable files and file creation (oops).... and that Petit has already been ported (double oops). I've been able to get it to compile with GCC, here's the FatFS branch of the project. But things are not running smoothly anymore, after I upload the code the LEDs are dim and it doesn't seem to execute past my little serial logging solution (in com.c) I've taken a break for about a week and just started looking back into this, I'm feeling sort of lost at the moment, I'm not very good at low level debugging with the open source tools. Thanks for any ideas, Chris
  8. I have the same problem (also on Arch). I ended up just running it with sudo. I read you could just add your user to the "uucp" group and it would work... but not for me
  9. Thanks for the welcome! I'll add it to my sig. right now
  10. Hi I joined today because I felt like I should since I've been using the MSP430 for a few months now. This is the project blog using an MSP430G2744 in a datalogging application. It's a new value line chip that is very similar to the MSP430F2274 it's just lacking the opamp peripheral as far as I can see and is about $3 cheaper at qty. 1. ANYWAY, just posting because I saw I could participate in the raffle for the electronic paper. I've had some ideas for e-paper
×
×
  • Create New...