Jump to content
43oh

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by pabigot

  1. It gets better. This device has an ADC. Here are the conditionals that identify the specific flavor of ADC on all previous MSP430s: #define HAVE_REF (defined(__MSP430_HAS_REF__) \ || defined(__MSP430_HAS_REF_A__)) #define HAVE_ADC10 (defined(__MSP430_HAS_ADC10__) \ || defined(__MSP430_HAS_ADC10_A__) \ || defined(__MSP430_HAS_ADC10_B__)) #define HAVE_ADC12 (defined(__MSP430_HAS_ADC12__) \ || defined(__MSP430_HAS_ADC12_PLUS__) \ || defined(__MSP430_HAS_ADC12
  2. It would be if the msp430fr4133.h header didn't contain: #define __MSP430_HAS_MSP430XV2_CPU__ /* Definition to show that it has MSP430XV2 CPU */ #define __MSP430FR5XX_6XX_FAMILY__ I expect that to change in the future (__MSP430FR2XX_4XX_FAMILY__) but getting things right the first time seems to be a difficulty for TI, and us cross-device library folks can't assume the external headers are updated the way TI can within CCS. For CS I look for presence of SELA which is a single-bit in the 4xx version and multi-bit (SELA0, SELA1, SELA2) in the other variants. For eUSCI I'm still figuring but
  3. Awesome. The eUSCI module is different too (ACLK at nominal 32 kiHz isn't a valid source for the FR4xx/2xx eUSCI device: the same bits now select MODCLK at nominal 5 MHz).
  4. So now that msp430-elf is robust enough to be usable, I'm updating BSP430 one last time before taking on a job where I'll be working Nordic chips. I figured I'd add the EXP430FR4133 since it's the first launchpad that mspgcc can't support. All went swimmingly until I tried to compile the nop bootstrap application, and things blew up in the clock configuration. "Wonderful," I thought, "TI's gone and made a third version of the CS peripheral, subtly incompatible with the original FR57xx CS and the revised FR58xx CS_A." Nope. It's not subtly incompatible. They've taken the UCS module fr
  5. The origin of the scripts was some combination of years of experience, the scripts to build the GCC for Embedded ARM toolchain, and advice from DJ Delorie on configuration for msp430 posted on the mspgcc users mailing list last spring. newlib (providing libc) is built outside gcc because the target runtime libraries of gcc have some dependencies on the libc that they will work with. The configure flags for everything except newlib are pretty straightforward; for newlib it was reading the available options and tuning to get something that balances functionality against code bloat. Yes,
  6. The current version of my msp430-elf build script is available in BSP430's next branch. It might be helpful.
  7. It's exactly correct for statically allocated memory. Both heap (malloc) and stack (local function variables aka auto) increase the total memory required. Stack starts at the top of RAM and goes down toward the top of bss. If you have call chains nesting more than two or three levels, or basically any local variables (such as those char[3] arrays), you're probably going to get corrupted data in whatever you have at the higher RAM addresses. You can use the __read_stack_pointer() intrinsic in mspgcc to determine what the stack pointer is at various points, and compare that against the symbol
  8. I haven't worked this since whatever's in BSPACM, but as I recall the behavior is entirely vendor-defined, and that what needs to be reset is generally controllable through module registers. Tiva-C low power wasn't impressive enough to get me to spend much time on it; EFM32 is, but there aren't cheap equivalents to launchpads around to make that worth the effort either. I'm still using MSP430 for anything where long-term battery-supplied power is an issue.
  9. In all releases of msp430-libc used by mspgcc log was missing, but logf (which is equivalent since double==float) is present. My local repository has a fix from 2013 but that was after the RH msp430-elf initiative was well under way so it it never got released. edit: double == float under mspgcc, not in general. in case somebody's confused.
  10. Some of it is that msp430-elf doesn't generate quite as compact code as mspgcc did. There should be a flag you can set to enable large memory model, which will make the code and data larger but also use the high memory. Use msp430-elf-gcc --target-help to see what your options are.
  11. I'm not paying a lot of attention to this because it's Energia and Tiva neither of which I use right now, but for low-overhead delays of reasonable duration you might want to look at how BSPACM does it. For microsecond counts you should just be able to convert the count to cycles based on the CPU frequency. Wouldn't be dependent on systick then. There's some discussion of this on the Stellarisiti forums somewhere. For what that's worth.
  12. Have you confirmed that these arrays have the ASCIIZ values that you expect, by displaying them? In C, initializers elements like this must be computable at load time. GCC allows what you're doing as an extension, but it may not be working correctly. I suggest it's worth your time debugging this approach so you understand why it doesn't work. Then replace it with this solution (which you will first test, since I haven't done so): int min = data[10] - '0' + 10 * (data[9] - '0'); int hr = data[13] - '0' + 10 * (data[12] - '0'); return min + 60 * hr; Also, if you are using gcc
  13. That depends on the level you're working at. Yes, at the bottom it's all bytes (or bits, or transistor states, or whatever). In C, you're nominally limited to text that can be expressed as ASCII characters, and the side comment that led us down this rabbit hole was prompted by the OP's confusion between text strings and sequences of characters and NUL-terminated sequences of characters: three distinct concepts. Even if it's not necessary to completely understand a specific subtlety at a particular stage of development, I do think it's worth a hic sunt dracones (i.e., "by the way, you're
  14. I'm gonna have to object, mostly because your statements on XML and programming for Unicode are unclear in a way that obscures my main point. So I'm going to expand on that main point and try to clarify XML along the way. There is a strict conceptual difference between text and representations of text by encoding schemes such as ASCII and Unicode, just as there's a difference between integers and representations of integers as two's complement, one's complement, or sign-magnitude. I'm trying to express two points: first, be aware of that difference; and second, take into account the possi
  15. I agree there should be no difficulties in building an msp430-elf toolchain on the BBB other than the time it takes to do a build. I'm curious, though: why do you want to do this? That is, what goal requires the ability to build new MSP430 firmware images on an embedded Linux device rather than select from pre-compiled images or request a customized image from a build service via network? The only one I can think of is using the BBB as a development platform, which is just painful.
  16. These are alternatives to ASCIIZ, but they're imprecise (does "string" mean text?) or unnecessarily language-specific ("string" means text in C). If you see them, you can guess what they mean; I recommend you do not use them, though, unless you are intend to be language-specific. But that's not ASCIIZ: if it's UTF-8 encoded the content is not characters, but octets. That should be documented as "null(U+0000)-terminated UTF-8 encoded text", and the underlying type of the array would ideally be uint8_t (though it might need to be char because of the API for Unicode support libraries). Tha
  17. You could try: #define PHONE_NUMBER "123456789" Serial.print("AT+CMGS=\"" PHONE_NUMBER "\""); which would combine the adjacent string literals. You can't do it with a variable, though.
  18. Being pedantic (which I am...): Ignoring the past-end-of-array error: In C, the macro NULL as defined in various headers denotes a null pointer constant, nominally compatible with type void * but not necessarily of pointer type. In C++ NULL is an integral constant expression that evaluates to zero; it cannot be a pointer type. In C++11 the literal nullptr replaces NULL. The end-of-string terminating character in C and C++ is the ASCII code NUL, which is character value '\0' or equivalently an integral value zero. One is a pointer, the other is a character. You shouldn't mix those
  19. Although sources(1,2) conflict, IEEE Std 802.11-2012 annex D "Regulatory References" and Table E-2 "Operating classes in Europe" strongly suggests that the UK falls under ECC/ETSI/CEPT's regulatory domain and does permit use of channels 1 through 13 in the 2.4 GHz ISM band for Wi-Fi. That may not have been the case at the time of the 2006 reference Cisco cites.
  20. If you have an existing application, converting it to BSP430's architecture might not be worth the pain. If you use the CCS IDE or develop under Windows, BSP430 is probably not the right solution. For completeness: BSP430 is supposed to support the TI compiler in a Linux command-line environment, by using WITH_CCS=1 when building and possibly correcting the CCS_INSTALL_ROOT path. See make/Makefile.common for details. However, last serious testing was done with CCS5 and a basic check of CCS6 just now didn't work. From within the IDE and/or on Windows, I have no idea how long it might take.
  21. Note that channels 12-14 are not legal for full-power use in North America, so depending on your location the fault may be in the configuration of your AP. (I haven't unboxed my CC3200, but I'd be pretty surprised if it couldn't handle at least channels 12 and 13, but not surprised if its default configuration excludes them.)
  22. You can take a look at how BSP430 does it to see if that's helpful, though you'd have to refactor the I/O to do single bytes in interrupts rather than polled I/O, if you're doing enough I2C activity to be worth it.
  23. The panStamp NRG should do this once it's released. At one time Anaren also sold EZ boards similar to the TI ezRF RF2500T that used the 900 MHz and 433 MHz versions of their CC110x modules, but I can't immediately confirm these still exist. The NRG has a thermistor; for the ezRF ones you could use the on-chip sensor or for accuracy attach a DS18B20 as suggested earlier.
  24. You're right. I misread "formally called CPUXV2" as "formerly called CPUXV2". (BTW: If you reference a SLAU, please specify which version. SLAU208M page 183 documents the UCSCTL8 register, and doesn't have the "formally" phrase added in SLAU208N.) What I was afraid of was that the preprocessor symbols were going to change, which would be bad. (Still reeling from TI changing the version register values in the CC110x radio line because they went to a different manufacturing process but kept the same functionality.) TI should check the headers though. The msp430fr4131.h header from msp4
  25. So now the term "CPUX" is ambiguous and differs on a per-family basis. Excellent. We needed more inconsistency and confusion in the MSP430 product line.
×
×
  • Create New...