Jump to content
43oh

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by pabigot

  1. Good grief. And I thought my /22 local subnet with 170+ hosts in internal DNS and three Wi-Fi SSIDs was overkill.
  2. Yes, it is hex: The CC110L data sheet swrs109b also has the value as 0x17. With no indication that it could also legitimately be 0x07 hex, as it was in swrs109a.
  3. How wonderful: looks like you might have gotten bitten by this one. I was wondering if a constant was added to each device, or if it was completely random. And if somebody can provide a rationale for why the VERSION number should change because the packaging changed, I'd be interested in hearing it. [edit: Based on a sample size of 2, I'm using 0x0F as a mask for VERSION when trying to determine which radio is being used.]
  4. I don't actually build from these sources, though I do use the headers as-is. I believe others here have done so and have posted instructions either elsewhere on the forums or on the mspgcc users mailing list. Unless you intend to modify the sources you're probably better off downloading the pre-built ones from TI. In fact, you should be able to update to the latest msp430-elf version automatically from within CCS. Energia should also have support for it, but probably not IAR which is a competing product.
  5. Several people liked this post which I took as interest in the mentioned archive of source and headers for TI's public releases of their msp430 gcc toolchain. I've now made this available on github at: https://github.com/pabigot/msp430-elf There's nothing you get there that isn't from TI, but it can be useful to determine what changed in each release, so you know what to look for in the upstream gcc repository. Updates to this repository will be best-effort on my part: no promises.
  6. @@nathancrum Ok, that's a bit more plausible (well, not the power graph). I suspect it's also pretty highly tuned, and sensitive to what AP was used and possibly whether the responding node was the AP or a third host. There's also the issue of use cases where the node needs to receive data asynchronously. The RN171 data sheet doesn't mention whether it supports IEEE PowerSave mode; if not, you're looking at continuous draw of 40mA which gives you a lifespan of maybe three weeks, or doing transmission scheduling at the application layer. At any rate, I'm not saying there aren't cases whe
  7. Is that 50ms verified personal experience or anecdote? Power-up, associate, transmit, disassociate, and power-down in 50ms for 802.11 is pretty damned fast. I haven't used RN modules for over three years, but with some competitors I've evaluated under contract since then I was seeing on-times closer to a full second best-case, longer if I actually wanted confirmation that the packet had been received. ChipCon was and perhaps still is the RF solution for much of the wireless sensor community; it's the basis of the CC430. The CC line has been around for years (the CC1000 is way obsole
  8. There are still plenty of infelicities, if not bugs, but for the record I intend to use msp430-elf for all my own future development. I do, however, build my own from upstream gcc to which RedHat doesn't always promptly push their updates (e.g. the large memory support in the current TI release hasn't been upstreamed yet). I also have a local git archive that tracks all the TI public releases (source and headers), which I'll put on github next time I'm working MSP430. Makes it easier to figure out what changed with each release (and what's not yet pushed upstream).
  9. For RF daughterboards I'd like to see something using the ChipCon-based sub 1GHz radios. The only way you'd get low-power WiFi is using some proprietary chips (the CC3000 absolutely is not, and I don't think the CC3100 makes it either); my understanding is BT is pretty hungry too. If you use the Anaren modules it could be pretty easy to put together. Both 433MHz and 915MHz would be nice. Have per-unit end-user costs been mentioned anywhere? [addendum: I don't think the Anaren would run off a coin cell either, but even with AAs it'll run much longer than any WiFi solution.]
  10. The image shows you using mspgcc, which has very limited support for floating point. If Energia supports using TI's version of msp430-elf, try using that; newlib should have the function as long as the people building the distribution didn't disable it. In general, though, @@David Bender is correct and you should avoid floating point on MSP430.
  11. You probably can't use two on the TM4C1294: the thing is huge. When one is plugged into the BP1 socket, it overlaps the top half inch of the BP2 headers.
  12. From the binutils used in mspgcc: commit 5a5c7b9cfa1ca229f661e5080f1af7584753c900 Author: Peter A. Bigot <pabigot@users.sourceforge.net> Date: Thu Feb 10 17:01:58 2011 -0600 SF 3177314: undefined reference with too many template parameters This patch eliminates bounds on the length of symbols and instruction operands, and some rather inefficient string processing operations. Storage of the appropriate length for a specific symbol is dynamically allocated, and freed when no longer necessary. And it's a binutils bug, not a gcc bug. Still worth filing, and th
  13. If you can create a standalone reproducer, this is the sort of thing that should be reported to gcc: here for the instructions and here for the bug registry. There's only a low probability that it'll get any attention from a maintainer, but there's always a chance and either way it'll provide a central location for everybody who runs into it to discuss potential workarounds.
  14. Normally one would release a production version that's the last beta with minor fixes. For some reason they've decided to jump from gcc 4.8.0 to gcc 4.9.1 (which improves diagnostics), and add features related to placement of code and data in far memory, without external testers. (At least not public ones. TI doesn't talk to me anymore, but they might have selected some others to give it a quick look-over this time.)
  15. And the answer to that hope is...no. The TI version has added some new directives for code and data placement. It's also based on something close to but not the same as gcc-4.9.1: it's got some changes to other architectures that also aren't upstream yet, and is missing some patches that are in 4.9.1. For what any of that's worth.
  16. Thanks @KatiePier; I've grabbed a copy. Hope Red Hat's already pushed the relevant changes upstream. FWIW, http://www.ti.com/tool/msp430-gcc-opensource still says this is a pre-release beta version.
  17. Great. Now all they have to do is release the source code. (Unless they just decided to rebranch version 371 as non-beta, or that announcement preceded the actual release of the non-beta version. Right now, only the 371 version from May is available for download.)
  18. Heh---looking back, obviously I do get the diagnostic you've shown since it's present in what I quoted. It just shows up after the first one (the warning), which is where I stopped reading because it was obviously the problem. Understandable if 272 doesn't warn about the unrecognized value.
  19. The last TI version I've seen is 371, but I work from the GCC trunk version (backported to the 4.9 branch), which probably doesn't exactly match what's in TI's version but is at least convenient. http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html suggests 371 is TI's version. I get the diagnostic in my post, specifically with the G2755. I have never gotten the diagnostic you've shown. Peter
  20. Using this code: #include <msp430.h> volatile int iflag; // 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) } and my house-built gcc-4.9.1--based version of msp430-elf as: /usr/local/msp430-elf-dev-20140602/bin/msp430-elf-gcc -I/usr/local/gcc-msp430-elf/msp430-elf/include -mmcu=msp430g2211 -c /tmp/q.c it works fine. For most other MCUs I get an error: llc[11]$ /usr/local/msp430-elf-dev-20140602/bin/msp430-elf-gcc -I/usr/local/gcc-msp430-elf/msp430
  21. Just for grins, try specifying a void return type on your function definition, and play around with the order of the return type and attribute declaration and the function declaration. It may be that the attribute is being associated with the implicit int return type, not with the function itself.
  22. The AM335X Sitara on the BeagleBone has an ADC peripheral underlying its touchscreen controller, which can be accessed through the Linux IIO driver. It's not a particularly powerful ADC though (24 MHz 12-bit SAR).
  23. imm11 means an 11 bit immediate value. "immediate" here means the value is encoded into the instruction itself, not read from a register or other memory location.
  24. Apparently not for CCR0; thanks for correcting me. It does need to be manually reset for the other CCRs, unless using the TAIV register in which case the highest priority flag is cleared on read.
  25. You also aren't doing anything like: TA0CCTL0 &= ~CCIFG; in your ISR, so your original diagnosis that it's starving the main loop may be correct.
×
×
  • Create New...