pabigot

I'm using the nRF51 for Bluetooth IOT work, but the new sensortag product line looks interesting. The debug devpack page suggests it works only with CCS and IAR; is there reason to believe it might work on Linux (gcc+openocd)? On the other hand, it looks like TI's still using their own HWREG-based API instead of CMSIS mapped structs on the CC2650. So it's probably not worth wasting time. I guess TI is uninterested in trying to take market share away from other ARM vendors by making it easy to try out their solution.

You're welcome. I don't check in here regularly anymore as I'm not doing anything with TI hardware now, but yes the bulk of the bloat is probably due to newlib. If you use newlib nano things get a lot better. I don't use mspgcc anymore (won't build on Ubuntu 14.04 without more effort than I care to make), and made the switch to upstream msp430-elf-gcc late last year, in part because newlib nano was finally usable. Check out BSP430 for some suggestions. You'd have to clone the repo and look at what's in the makefile to get the necessary flags for nano access.

Silicon Labs (the Energy Micro line) and Nordic (the nRF51 line) are two I have personal experience with. There are "right" ones for Tiva out on github, which I think somebody generated from CMSIS-SVD files using ARM tools, but for some reason TI isn't providing them directly. It's frustrating because TI appears to be doing more work to generate headers that aren't consistent with what other Cortex-M vendors produce. Maybe they think their approach is better somehow.

Normally I'd say it's an ARM device so I'd use CMSIS structures and the standard PERIPH_REG_FIELD_Tag macros. But on closer look these structs aren't really standard CMSIS-style definitions. First, there are distinct types for TIMER_A0_Type, TIMER_A1_Type, TIMER_A2_Type, and TIMER_A3_Type, but the definitions are identical. This means I can't write my code for a common TIMER_A_Type and pass in whichever timer instance I choose to use, because the compiler's been told they're different types. I'd have to explicitly cast the pointers, which is poor practice. Also, they're using some b

Unpacking MSP432_Driver_Library it appears there are CMSIS Core standard peripheral structs and defines, which will make it easier for those of us who like to use the hardware directly bizarre union/bitfield structs and defines that make programming an ARM look sorta like programming an MSP430 but not really. (Teach me to post before fully inspecting what's been given.)

Yes. See: http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/303823/1259157 http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/354937/1307407 http://e2e.ti.com/support/wireless_connectivity/f/968/p/348552/1432011

An ARM-based MSP would be nice, but if TI won't provide CMSIS headers for it I won't waste my time. AFAIK they're still not providing them for Tiva or the SimpleLink ones.

I'm still here, though not doing much with TI chips because I'm now using nRF51 chips (which I'm pretty happy with). Personally, I concur with @@Fred about putting Energia somewhere else. It's a fine system with a lot of traction, but programming with Energia is not really relevant to those of us who work on bare metal MCUs, and vice-versa. Over the past several months I've frequently noticed a topic and though "Looks interesting...oh wait, Energia." The degree of mixing waters down the value for both communities, in my opinion.

I liked the Dido CD on the bookshelf behind him. (I have some number of those books, too, from what I could tell.)

If this fails: #define _TIVAx #ifdef _TIVAx #include "TM4C_DS18B20.h" #endif #ifndef _TIVAx #include "GFDS18B20.h" #endif and this works: #define _TIVAx #ifdef _TIVAx #include "TM4C_DS18B20.h" #endif then Energia is doing something very strange, because the two should be equivalent, unless the C preprocessor is not what controls what Energia operates on. That's what I would expect.

I don't know why an include file would tell the linker what to link; that'd have to be an Energia thing, because it's not how C normally works. But part of the problem is you don't grasp how preprocessor conditionals work. Defining things to the lexical tokens true and false is irrelevant; the key is whether the macro is defined at all or not (when using #if defined(m) or #ifdef m) and whether the macro has a value that expands to an integer expression that is not equal to zero (when using #if m). Below is example code which produces the following when run through the preprocessor alon

That's not a compiler error related to the include file. It's a linker error because you're putting both object files into the target-specific executable. Link GFDS18B20.cpp.o or TM4C_DS18B20.cpp.o but not both.

Whitespace before #include directives should make no difference. Try just doing: #include "TM4C_DS18B20.h"unconditionally and see if the problem goes away. I suspect that with most of your attempts you're only getting that file included, and the problem is entirely within it. (Or that something somewhere else is including the conflicting definitions.)

That quote appears to come from avr-libc documentation (it may have come from an mspgcc-oriented site, but if so, it was either written more than five years ago or is simply wrong). mspgcc uses a completely different libc, and dtostrf is not in it. %f formatting is not supported by mspgcc, so unless Energia's transitioned to msp430-elf that won't work either. Using floating point on the MSP430 will simply cause pain. Get the value using a fixed point calculation, and format it in whatever way you need. "%u.%03u" would work if you split an integral milli-value into v/1000 and v%1000 c

The name of the type provided by <stdbool.h> is bool (lower case). Its constants true and false are also lower-case. You're apparently using PetitFS rather than FatFS; older versions of that had this in a header integer.h: /* Boolean type */ typedef enum { FALSE = 0, TRUE } BOOL; That sort of thing was mostly removed from FatFS releases around 0.9, and PetiteFS around 0.02a. My archival repository at https://github.com/pabigot/FatFs/tree/ff/master would be one way to see the changes per version.

The msp430 MCU headers that have USB support define DIR as a preprocessor symbol containing the value for the USB Data Response Bit. A solution is to include ff.h before anything includes msp430.h, or to not include both in the same file at all.

Set them in grout to make a coffee-table top.

While it has fewer users and targets a different audience than Energia, I'd meant to ask if you'd like your board supported by BSP430. I also use a couple mapping text file per platform and a couple cloned headers, so it's pretty easy. I'd do it in trade for a couple ready-to-use boards. Send me a direct message if you're interested.

Well, maybe. One thing: fix the comment to note that TASSEL_2 means you're actually using SMCLK (nominally 1.1 MHz) instead of ACLK (nominally 12 kHz on that MCU with that initialization sequence). At 1.1MHz I think you'd get 42.3 kHz with 26 ticks per cycle. Since DCO tolerance on the MSP430G2553 is +/- 6% it's probably not very close to 38 kHz.

Please clarify: is this a digital or analog signal? [edit: yes you do say "through the analog pins" which I missed on first reading, but if the signal could be treated as digital it becomes a lot simpler] For a digital signal any MSP430 device could easily satisfy your requirement using an internal clock (ACLK or SMCLK) at a known frequency and the timer capture/compare infrastructure. I couldn't say how to do it in Energia, though.

The error will almost certainly be on line 107. Recall that TI's headers define single-character macros that inconveniently interfere with variable declarations: /************************************************************ * STATUS REGISTER BITS ************************************************************/ #define C (0x0001) #define Z (0x0002) #define N (0x0004) #define V (0x0100) As a general rule, don't use fully capitalized symbols for variable names, and particularly not single-letter ones.

Thanks for reporting that issue there. It's possible that your report in early September led to the late September change to upstream gcc that started fixed the problem for msp430g2553 by adding a list of MCUs that have no MPY peripheral. Unfortunately, those changes didn't get it right for msp430fr5969. Decoupling the list of available MCUs and their characteristics from the toolchain sources is one of the things that wasn't done for msp430-elf. When I say it's "mostly not" passive-aggressive complaining on my part, that's because I'm absolutely disgusted with the way TI has managed the

No released version of mspgcc supports the FR4xx/2xx or FR6xx chips as those didn't exist in 2012 when the last usable updates for msp430mcu were received from TI (the 20130321 release incorporated the interrupt vector length change that released mspgcc doesn't support). Energia needs to update to msp430-elf for any chips that weren't at least in preview state in 2012, or (as you suggest) take responsibility for providing the header and linker include scripts. I really want to see folks including Energia moving to msp430-elf. I'm not doing any more updates to mspgcc and in fact am no long

BSP430 has been updated to the 20141115 release, which includes full support for msp430-elf and support for the new FR4xx/2xx chip families. Details are available on the web site. Of particular interest to 43oh folks might be the updated script to build an msp430-elf toolchain, and the newlib sys integration. If you use BSP430 and encounter any problems, please file issue reports on github. This is the last version of BSP430 that will default to mspgcc. Henceforth it's going to be msp430-elf, though mspgcc will still be supported (at about the level that CCS is supported, i.e. n

And all the constants and register names in the headers have prefix ADC (e.g. ADCSHT_0) instead of ADC10 (e.g. ADC10SHT_0) used in all the other ADC10 peripherals on all the other MSP430s. So we get to #define aliases for everything.