Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by pabigot

  1. Huh. I'm finding that essay to be somewhat incoherent, and am at a loss for how to apply it to Java. As best I can tell, its recommendations match Java's history extremely well: "It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing." Java in a nutshell.
  2. For non-volatile data that is not too large, consider using the INFO sections, rather than trying to find an address in flash that won't be used during programming. See the datasheet for your MCU to determine the address and size (there are 2 to 4 sections, sizes ranging from I think 64 to 256 bytes per section). Be very careful not to use INFOA if that holds device calibration values for your MCU. You may want to read out the contents of that section and save it somewhere before you start mucking about, just in case.
  3. Agreed, that works, assuming LED is a statically allocated variable and nothing else changes either it or the corresponding pin's output value. I dislike caching a last-known state when the actual current state can easily be read, but that's a combination of personal choice and the application requirements.
  4. I'm not clear on what your hardware configuration is. If you have a working exp430fr5969 launchpad and non-working MCU on some other board, you should be able to program the working launchpad with a BSL application then use it to manipulate the UART lines of the non-working MCU and reset it that way. I don't know if the source code TI provides will work on the FR5969, though. If you only have an exp430fr5969 launchpad and its msp430fr5969 is the one that's locked out, then you need another piece of hardware (which could be a PC or Linux system, all you need is a serial port with hardware co
  5. The "clean" way to solve this is to define an array in your code that will hold the data. Because the size exceeds the RAM capacity of the device, things get a bit complicated. @@spirilis' approach works (and I've used it before) but you do have to finesse const validation. The "clean" way is to define a new linker section and tell the compiler to put the array into that section. Here's part of a patch that does this for a large display buffer, assuming you're using Code Composer Studio: diff --git a/430BOOST-SHARP96_GrlibDisplay/LcdDriver/Sharp96x96.c b/430BOOST-SHARP96_GrlibDisplay
  6. Hard to tell, since you changed at least three things (loop bound, elimination of function call, more code in the loop). If you wanted to know why it works, you'd need to try them on the non-working code independently.
  7. You've allocated MAXPARTICLE elements (0..MAXPARTICLE-1), but your loop iterates from 0 through MAXPARTICLE, meaning you're indexing into one more element than you've allocated. Change the comparison in the upper bound from <= to <. (There may be other problems, but this is definitely one issue.)
  8. I don't believe driverware provides an API that supports XOR, only setting or clearing all the specified pins. The following hack will invert all three LEDs on the ek-tm4c123gxl in one step: ((uint32_t *)GPIO_PORTF_BASE)[GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3] ^= ~0; or the equivalent: HWREG(GPIO_PORTF_BASE + (GPIO_O_DATA + ((GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3) << 2))) ^= ~0; which uses material from <inc/hw_types.h> and <inc/hw_gpio.h> and is closer to how GPIOPinWrite() is implemented.
  9. Yes, this arises exactly from writing to the locations where the software JTAG passwords are kept. From slas704a (MSP430FR5969 data sheet) "Interrupt Vector Table and Signatures": For reference, my exp430fr5969 has: (mspdebug) md 0xff80 0x80 0ff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 0ff90: 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a |.J.J.J.J.J.J.J.J| 0ffa0: 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a |.J.J.J.J.J.J.J.J| 0ffb0: 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a |.J.J.J.J.J.J.J.J| 0ffc0: 80 4a 80 4a 80 4a 80 4a 80 4a
  10. That material is from TI and can also be found, along with other examples and documentation, on the microcontroller homepage at http://www.ti.com/product/msp430g2553 @biza: I agree that starting with working examples is the best approach to solving this problem. Change something that blinks until it blinks at 500ms, then see what you did wrong in your original version.
  11. Can you give details on why input/pull-down is better than output/low? The family users guides do not recommend one over the other, and my testing didn't reveal a power consumption difference.
  12. That looks wrong too; if either the BC1 or DCO calibrations for 1MHz are invalid you'll initialize BCSCTL1, then unconditionally you initialize DCOCTL.Maybe something like: if ((CALBC1_1MHZ != 0xFF) && (CALDCO_1MHZ != 0xFF)) { BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; }
  13. Just a heads up for those concerned with software licensing: although TI has open-sourced the MSP Debug Stack, in fact it now contains material that is not open-source, related to an Energy Trace facility. That facility and the change in licensing appeared in June 2013 in slac460f, prior to which this package was entirely BSD. I've confirmed that objects derived from the sources with the TI TSPA license (displayed below) are present in libmsp430.so, which appears to bring the licensing below into effect. There is a single API header which is BSD-3-Clause, but to use it would explicitly inv
  14. Took a few days longer than I expected, but after heroic keyboard banging I've got the basic documentation done for BSPACM's approach to linker scripts and newlib interfacing. Even if BSPACM isn't attractive people trying to use newlib could find useful information at: http://pabigot.github.io/bspacm/newlib.html As I may have mentioned, BSPACM uses a single linker script source file rather than requiring each application to have its own copy that has to be edited to add and remove exception handlers. This is done through the magic of weak symbols, as described here. The linker script a
  15. I can't answer your question directly, but I've generally found that a good way to figure out what the assembler expects is to write a trivial application in C that does what you want, then compile it with -S and look at the generated assembly. Probably the directives you need will be revealed by that.
  16. First suggestion: if you're going to publish software, get an account on github or some similar site and put it there. It's a much better distribution solution than opaque dropbox URLs, and allows folks to see what else you have available. Second: Don't assume people don't understand platform independency. It simply may not be relevant to their needs. Platform-specific solutions are not incompatible with modularity, layering, and techniques to improve maintainability and reduce development time. For the rest, I don't disagree. See BSP430 for one of my contributions in this domain. It
  17. With respect: to some extent I think you're wishing for a pony. Maybe a unicorn pony, at that. I empathize with your position, and I too fight against this by making a relatively large amount of software available with hopes others will be able to use it. It's not that easy. I've deleted all my generic musings about issues with re-usability---functional/non-functional requirements, API design, efficiency, portability, maintainability, context, cost---and am just leaving it to the following concrete example: You've made a debounce module available, which looks pretty good. Really good, honest
  18. Today's research is on Cortex-M sleep modes and interrupt handling. I'm still digesting the bulk of it, but the short form is there are three common operational modes (RUN, SLEEP, DEEP SLEEP) that are implemented through Cortex-M instructions WFI/WFE and bits in the SCR. (Anything lower than DEEP SLEEP, like "hibernate" or EM3/EM4, is probably vendor-specific). Based on a sample size of two (TM4C and EFM32), RUN and SLEEP are simple, but DEEP SLEEP can reconfigure your processor and peripheral clocks back to their power-up defaults. PRIMASK plays an important role in this too, if you want to b
  19. pabigot

    On Bit-Banding

    Having reached a new stage of enlightenment, what I wrote in another topic turns out to be wrong. I can't find any other posts here that discuss bit-banding in detail, so I'm starting this so the correction is easier to find. See also the relevant section of Cortex-M3 Application Note 179. I had said: This second use which allows manipulation of GPIO pins with only certain pins being modified is really cool and slick and is not bit-banding. It works because TI's implementation provides a 256-element array map to the state of the eight pins supported by each GPIO module. In Energy Mi
  20. Testing indicates that there's no difference in power consumption among the choices of output low, input pull-up, and input pull-down for unused pins. The pins that are connected still need special handling to achieve minimum power. Since output low takes one fewer instruction per port to configure from power-up state, it's probably the best default.
  21. Yeah; I got the blurb on that too (having purchased both a Logic and Logic16). Anybody have opinions on the approach they're taking? One reason I almost never use the two scopes I have (DSO Quad and Rigol DS1102E) is I find the interface on a dedicated device to be really unfriendly. I'm tempted to get either a Logic8 or Logic Pro8 in hopes it'll be usable. (Though they're three days into the campaign and are already at 78% of their goal, so by the time I decide it'll probably be too late to be an early adopter.)
  22. Excellent; thank you. For reference, here's a portable version using CMSIS, checked on Tiva and EFM32 processors. (You will need to include the CMSIS device header, e.g. TIVA.h for TM4C and em_device.h for EFM32. That's hidden in bspacm/core.h below.) For reference, the necessary information is in the ARMv7-M Architecture Reference Manual; you have to register with ARM to download the PDF. See sections C1.6.5 for DEMCR and C1.8 for DWT. /* BSPACM - demonstrate cycle counter interface * * Written in 2014 by Peter A. Bigot <http://pabigot.github.io/bspacm/> * * To the extent
  23. Again, most of these concerns need to be answered in context. For the reliability ones, if you're installing into extreme conditions, they're going to matter. If the product sits on a table in a residence, they probably don't. For bugs, as long as you're not working with early stage experimental silicon, it's unlikely you'll come across any that are unknown or don't have reasonable workarounds. When you read the errata list for an MCU, make sure you understand the conditions under which the problem can arise: some of them sound pretty horrible, but in the real world just aren't going to b
  24. I don't bother finding the optimal speed. Get the requirements, pick a solution that satisfies them or do an analysis that shows they're unrealistic, and negotiate until the stakeholders and providers reach agreement. What's the activity? How long does it take? What energy and functional requirements derive from the activity's needs? What else might cue the activity other than passing of time? Does it matter what time of day the activity occurs? There must be some precision requirements, since it's once a day not "whenever's convenient". Is it ok if the periodicity is every 25 hours
  25. Probably as slow as you can find a clock to feed it. Without hardware modifications, selecting VLOCLK as the source for MCLK would put it about 10kHz. Haven't tried that personally. It's not likely to be useful, though. The slower it runs, the longer it takes to do the work. The optimum speed for least power for a given task is almost certainly not going to be the slowest speed, even if that produces the lowest-power per unit time. You'd have to calculate based on duty cycles, durations of tasks, and a bunch of other application-specific information.
  • Create New...