Jump to content

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

pabigot last won the day on December 21 2014

pabigot had the most liked content!

1 Follower

About pabigot

  • Rank
    Level 3

Profile Information

  • Gender
    Not Telling
  • Location
    Roseville, MN
  • Github
    https://github.com/pabigot

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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 bizarre Hungarian naming solution on a union to provide bitfields within each register, so instead of just referencing SYSCTL->SYSTEM_STAT I'd have to do SYSCTL->rSYSTEM_STAT.r if I wanted the whole register. So, we either manipulate the register fields as bitfields independently on an MCU that doesn't have the BIC/BIS atomic RMW operations of the MSP430 that make such operations remotely sane, or we have to deal with a metric crap-ton of syntactic sugar smeared all over the native 32-bit mapped registers. Ugh. Looks like TI still hasn't fully grasped how to do Cortex-M. I probably won't bother getting one of these.
  5. 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.)
  6. 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
  7. 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.
  8. 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.
  9. I liked the Dido CD on the bookshelf behind him. (I have some number of those books, too, from what I could tell.)
  10. 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.
  11. 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 alone. I suggest experimenting with variations of it until you understand what's going on. Also look at the documentation for the GNU C Preprocessor. llc[211]$ msp430-elf-gcc -E /tmp/x.c | sed -e '/^$/d' # 1 "/tmp/x.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "/tmp/x.c" mTIVA=true 6 mTIVA is not true 9 mTIVA is defined mTIVA=false 20 mTIVA is not true 23 mTIVA is defined mTIVA=1 32 mTIVA is 1 37 mTIVA is defined mTIVA=0 48 mTIVA is 0 51 mTIVA is defined mTIVA=true #define TIVA true #if (TIVA) __LINE__ mTIVA is true #else __LINE__ mTIVA is not true #endif #if defined(TIVA) __LINE__ mTIVA is defined #else __LINE__ mTIVA is not defined #endif #undef TIVA mTIVA=false #define TIVA false #if (TIVA) __LINE__ mTIVA is true #else __LINE__ mTIVA is not true #endif #if defined(TIVA) __LINE__ mTIVA is defined #else __LINE__ mTIVA is not defined #endif #undef TIVA mTIVA=1 #define TIVA 1 #if (TIVA) __LINE__ mTIVA is 1 #else __LINE__ mTIVA is not 1 #endif #if defined(TIVA) __LINE__ mTIVA is defined #else __LINE__ mTIVA is not defined #endif #undef TIVA mTIVA=0 #define TIVA 0 #if (TIVA) __LINE__ mTIVA is not 0 #else __LINE__ mTIVA is 0 #endif #if defined(TIVA) __LINE__ mTIVA is defined #else __LINE__ mTIVA is not defined #endif
  12. 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.
  13. 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.)
  14. 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 components.
  15. 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.
×
×
  • Create New...