Jump to content
43oh

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

Posts posted by pabigot

  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. Oh and while I'm at it, huge thanks @@pabigot for your support of mspgcc, you're the man

    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. Out of interest, which manufacturer(s) actually get this right?

    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. Out of curiosity, have you looked at the device header file? In there, not only CMSIS but also MSP-style definitions (e.g. #define TACCR0 0xHEX_VALUE) are available. Which one would you rather use for direct hardware access?

    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. 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.

  7. pabigot

     

    As the following also fails regardless if I define _TIVAx or not, would you deduce that it is an energia problem.

    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.

     

    I thought I knew what was going on, if _TIVAx is defined #include "TM4C_DS18B20.h" is used, and if _TIVAx is not defined then #include "GFDS18B20.h" is used.

    That's what I would expect.
  8. 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
    
  9. 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.)
  10. I think it is likely to do with mspgcc's double/float support. dtostrf is part of stdlib.h but not actually located in libc

    Note that these functions are not located in the default library, libc.a, but in the mathematical library, libm.a. So when linking the application, the -lm option needs to be specified.
    

     

    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.

     

    A quick fix would be to use a more common function. something like sprintf.

    %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.

  11. 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.
  12. We've been playing with the prototypes for a few weeks now and wanted to start adding support for our board in Energia and...after some searching, it's not at all clear if that's possible right now.  I will keep looking, but figured I should post here for now since someone probably knows the answer, "Is is possible to add new processor boards to Energia via text configuration files?"  ...or is it more complicated?

    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.

  13. 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.

  14. 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.

  15. 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.
  16. Hey, I've been doing my part. Maybe I'm not posting the problems to the right place. I assumed that posting on e2e.ti.com would be the right place as they deal with most of the issues related to specific chip configs. Is that not the right place?

     

    I reported the problem with the hardware multiple back in Sept.

     

    http://e2e.ti.com/support/development_tools/compiler/f/343/t/367209.aspx

     

    and other problems with c++ ..

     

    Where do you think this stuff should get addressed? From TI or RH? Seems like TI has the money and RH only does stuff when poked by TI?

     

    -rick

    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 transition from mspgcc. It's been more than two years since they started the process; only now is the toolchain usable, and it has fundamental gaps (like inline hardware multiply using the appropriate peripheral) that mspgcc was doing correctly over three years ago. The correlation between your report and subsequent changes upstream suggests that there is some responsiveness from TI, even though there's no visibility into the process and the chosen approach of using hard-coded MCU characteristic lists within the gcc sources is fundamentally flawed.

     

    To your question: I use the upstream GNU sources, not TI's fork. Consequently I'm mostly filing bugs on the gcc bugzilla for things that are clearly GCC errors.

     

    But bugs reported against GCC are usually ignored unless you can attract the attention of somebody, so I also post them on the mspgcc-users mailing list because folks who use mspgcc need to move to msp430-elf and to do so they need to know what issues they're going to run into. I also know the Red Hat folks monitor that and take some responsibility for fixing problems in the port they wrote. So far, I've been lucky: the only time I really needed something fixed Nick Clifton from RH was on duty and merged the patches for me.

     

    If you're using the TI fork, probably E2E is the only place to report it. If you can reproduce the problem with the upstream trunk versions, report it via the appropriate GNU channels such as https://gcc.gnu.org/bugzilla. In either case, it's worth posting a note about it to mspgcc-users, and probably also on E2E, to raise visibility and hopefully encourage people to address the issue.

  17. Haven't checked yet to see if mspgcc 4.6 supports the FR4133 or 6989 as it is (considering interrupt vector table size, etc). If so it'd require shipping the header and ldscript files separately along with Energia core changes.

    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 longer using it myself. Honestly I'm getting a bit tired of being the one who gets to diagnose and report all the issues msp430-elf has: it looks like passive-aggressive complaining on my part, and it mostly isn't.

  18. 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. not very much). I highly recommend everybody else start transitioning too. The new toolchain has its problems, but it's still the way forward.

  19. Which ADC is it? Surprise: it's the ADC10_B from the old FR57xx line, except that the internal temperature sensor is on channel 12 not channel 10 and it doesn't have an internal voltage sensor.

    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.
×
×
  • Create New...