Jump to content
43oh

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by pabigot

  1. Which code needs a tweak, and what is that tweak?
  2. Mine also fails. Common factor appears to be those who have no awards.
  3. msp430.h should be defining __MSP430_HAS_FLASH2__ if the device has that peripheral. It's almost never correct for user code to define any macro that begins or ends with two underscores: those belong to the implementation. (The right answer may be to include msp430.h, though MspFlash.h should be including everything it requires; if it doesn't that's a flaw in whatever provides MspFlash.h.)
  4. pabigot

    On Bit-Banding

    Thanks for the pointer; I was unaware of them. More information here. They're accessed in gcc through the ARM variants of the atomic builtins. Thus something like: (void)__atomic_fetch_or(&events_, flg, __ATOMIC_ACQUIRE); becomes something like: .L2: ldrex r1, [r3] orr r2, r1, r0 strex r4, r2, [r3] cmp r4, #0 bne .L2 dmb sy which looks to be about what your loop does. It appears this was designed for multiprocessor systems, not for protecting writes from interrupts. The instructions don't exist on Cortex-M0 b
  5. I'm don't know how you're getting multiple definitions (unless you still have that declaration in a header, in which case get rid of it or at least its interrupt attribute). However, I just tried a more complete example and AFAICT mspgcc is going to put the default weak definition before anything else in the link line (it comes from crt0ivtbl*.o). It's not obvious how to get the application/energia-specific object file before that, so I think you'd probably have to use -Wl,--undefined=__isr_53,--defsym=__isr_53=TA0_CCR_updater, which is not a weak definition, to override it. At that point
  6. Actually, it's a little trickier, since you actually want this thing to be a second weak definition: there's the one in crt0 that's the default, and the one provided by the alias. My expectation is that which weak one wins depends on the order they're encountered by the linker; you need to do a link with -v to see exactly what gets passed to collect. If you play with the order of the files you can get the right one to be selected. It'll be a bit fragile, though. In your case, mspgcc provides a weak definition for when no other implementation is available (case A). You want to provide a
  7. @@energia Good point. Remove the weak attribute, leaving the alias.
  8. @@energia Try this version. I remembered that if you don't provide a specific interrupt, I had decided to skip the global symbol part, with the idea that you need to put it into the vector table explicitly (which can be done with the weak alias). #include <msp430.h> __attribute__((__interrupt__)) void TA0_CCR_updater() { /* ... */ } void __isr_53 (void) __attribute__((__weak__,__alias__("TA0_CCR_updater")));
  9. I suspect that as long as the __interrupt__ attribute is used mspgcc will generate a non-weak global symbol corresponding to the specific interrupt. The only solution that comes immediately to mind is to not provide that attribute, but instead use the alias syntax with the required specific symbol, which would be something like: void TA0_CCR_updater () { } #if TIMER0_A0_VECTOR == 0x6A void __isr_53 (void) __attribute__((__weak__, __alias__("TA0_CCR_updater"))); #elif TIMER0_A0_VECTOR == 0x60 void __isr_48 (void) __attribute__((__weak__, __alias__("TA0_CCR_updater"))); #else ... #endif The I
  10. The 4.7 dev version of mspgcc which supports 20-bit addresses tried to support mixed memory models so code could be small with data large, or vice-versa, but GCC wasn't architected for that sort of thing so there can be issues. AFAIK the Red Hat port supports only everything-16-bit and everything-32-bit, with -mlarge having a pretty big impact on code and data size (all pointers and size_t become 32-bit). I don't have a lot of experience with it, though, since a feature I need that's in the CCS6 version still hasn't been made available in the upstream source repositories.
  11. You don't really need a separate declaration in a header; it should be enough to put __attribute__((__weak__)) on the definition of the function. I do this sort of thing in my Cortex-M infrastructure. If you do have both, it may be necessary that they be consistent. For mspgcc, the compiler detects that the function has an __interrupt__ attribute and adds a second name to the assembly source which corresponds to the name crt0 is looking for, with the value being the address of the handler. crt0 in turn has a weak definition for that symbol that resolves to the default handler, so you do ne
  12. The power-up drive configuration is usable, unlike the power-up DEN configuration, so that probably won't help. I'd try taking the working Energia program and replace Energia operations one-by-one with what you believe is the register-level equivalents, to see where it stops working. Then figure out what the difference is.
  13. pabigot

    On Bit-Banding

    One last comment: bitbanding is an optional feature of ARM Cortex-M processors, and is not supported on some (all?) Cortex-M0 and M0+ devices (EFM32 Zero Gecko, in particular). Don't get too used to using it if you want to support those architectures.
  14. pabigot

    On Bit-Banding

    As noted in the previous post, a primary value of bit-band for user memory is to record an event in a flag variable without risking a race condition. Finding myself using this idiom inside an interrupt handler where it wasn't necessary I wanted to see whether I was decreasing code size or improving performance by doing so. Compiler: gcc version 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641] (GNU Tools for ARM Embedded Processors) Optimization-related flags: -ggdb -Os -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp A Read-Modify-Write update of a sin
  15. I don't think the while statement is necessarily wrong, if the intent is to wait until the condition fails. You're configuring PB0; is that the pin you intend to configure (pingPin isn't defined in what you showed)? Do you enable it for its digital function (GPIO_PORTB_DEN_R) somewhere else? See this post for the rather complex sequence necessary to configure GPIOs.
  16. Wouldn't git integration just be part of Eclipse, not something TI added themselves? Isn't it possible to install CCS5 into an existing (more up-to-date) eclipse installation and get access that way, or to add git support to the CCS version of eclipse? Just wondering; I have a full license for CCS for contracting work, but only use the IDE to verify a project builds under it before hand-off.
  17. An anomaly with this: if you're using driverlib TivaWare_C_Series-2.1.0.12573 on a TM4C123GH6PM (i.e. an EK-TM4C123GXL launchpad) you can use SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ); /* 2*PLL/5 = 80 MHz */ to set the clocks to 80MHz, but if you then call SysCtlClockGet() it'll tell you you're running at 66MHz. This is because SYSCTL->DC1.MINSYSDIV, which driverlib consults, insists that the minimum divider is 3, so you can't possibly be running faster than 66MHz. At least TI gives us the source code so we can figure these things out, a
  18. TI has claimed this is at least a beta since its release in December; I don't know whether they believe it's evolved beyond that. What's in CCSv6 is: gcc version 4.8.0 20130315 (experimental (msp430-130423-317)) (Red Hat/devo) [trunk revision 196673] (GCC) What TI makes publicly available with source through their website is: gcc version 4.8.0 20130315 (release (msp430-130423-272)) (Red Hat/devo) [trunk revision 196673] (GCC) I'm completely uninterested in the forked version TI is shipping as binaries in CCSv6, and more interested in what's in gcc 4.9.0, which is what will replace msp
  19. Y'know, it actually hurts to see how msp430-elf-gcc is turning out under TI's supervision. It could have been so cool.
  20. FWIW, DWT is a compile-time constant pointer, not a variable, so there's no double-dereference (the CYCCNT value is read directly from its register). This is true of all CMSIS pointers to mapped memory.
  21. Without looking at the source, there's a startup procedure for these displays that, if not followed, might explain that behavior. My implementation of it can be seen here.
  22. If 555 takes 100uA then definitely you should be using an MSP430 instead, which could be sub-uA on average. Yes. The description of static mode in the LS013B7DH03 datasheet recommends redrawing the data every two hours to avoid stuck pixels. I expect that applies to all displays with the same technology.
  23. For any compiler there will be vendor- and architecture-specific flags that you can determine. For gcc the following incantation will display them: echo | arm-none-eabi-gcc -dM -E - | grep -i arm This gets you things like: #define __ARM_SIZEOF_WCHAR_T 32 #define __ARM_ARCH_ISA_ARM 1 #define __ARMEL__ 1 #define __ARM_FP 12 #define __ARM_NEON_FP 4 #define __ARM_SIZEOF_MINIMAL_ENUM 1 #define __ARM_PCS 1 #define __VERSION__ "4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]" #define __ARM_ARCH_ISA_THUMB 1 #define __ARM_ARCH 4 #define __arm__ 1 #define __ARM_ARCH_4T__ 1 #define
  24. Yep, that'd be "the macho thing", right there: hack something together in a last-minute marathon then present yourself as a hero.
×
×
  • Create New...