Jump to content
43oh

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by pabigot

  1. That was my guess within the analysis time I wanted to spend on the question, yes. In fact, though, it's not that simple: Experimentation confirms that it is not a loop: .syntax unified .arch armv7-m .text .thumb .thumb_func .align 2 .globl Test .type Test, %function Test: b .L_loop1 nop .L_loop1: nop .end llc[19]$ arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m3 x.S llc[20]$ arm-none-eabi-objdump -d x.o Disassembly of section .text: 00000000 <Test>: 0: e000 b.n 4 <Test+0x4> 2: bf00 nop 4: bf00 nop 6: bf
  2. The bit value of the instruction tells you which encoding it is. For example, if it were T1 the first four bits would be 1101 and the instruction value would be 0xd???. Since it's 0xe000 you know it's encoding T2. It can't be T3 or T4 since they'd be 32-bit instructions beginning with 0xf???????. So it appears to be an unconditional branch to an 11-bit immediate offset from PC, where the value of the offset is zero. I'm guessing it's an extremely optimized idle loop in an interrupt-driven application.
  3. After 0.7.0 hidapi switched to autoconf/libtool. If you ever do want to rebuild libmsp430.so, use hidapi 0.7.0, which will produce the object file you need with the API the rest of the stack expects. You may need to add -fPIC to the CFLAGS and CXXFLAGS settings in linux/Makefile.
  4. Saleae. Started with the 8, and about a year later added the 16 for lower-voltage and faster signals.
  5. In a word: no. More than one word would just get me all wound up. I'm just gonna go take a blood pressure pill and lie down for a while.
  6. Thanks for tackling this. Maybe TI will pay more attention to you than they did to me when I noted the problems and provided fixes last December. (For C++ it's pretty simple: all uses of those macros are within the extern "C" block provided in each header when C++ is enabled, so you don't even have to bother special-casing their definitions for C++.)
  7. Probably it was used in a calculation that was replaced during peephole optimization, which follows prolog/epilog generation. The bis-to-memory operation at f958 is one that probably was originally a read into r14 followed by a write of r14 to the memory location.
  8. Dunno why it'd do that. Same behavior in my internal 4.7.2 version. I no longer maintain mspgcc unless contracted to do so, and am transitioning to msp430-elf for my own work. msp430-elf-gcc (4.9.0-based and TI msp430-130423-371) generates a call to a rotate subroutine. Somebody should probably document the msp430-elf issue and submit it to RH/TI to be fixed; I don't expect to be doing anything with msp430 in the next month or two or I'd do it myself. [FWIW, with mspgcc the fact a function is an ISR should have no impact on code generation except in the function prolog and epilo
  9. "Give back" is a tricky subject. I give a discounted rate to customers who are willing to open-source any re-usable aspects of the solution I develop for them. I find that approach is not understood by most corporations, though. Based on the details @@bluehash has provided I think a small (~ 5$) fixed-price fee for any solicitation is a reasonable solution: making the solicitor have "skin in the game" should reduce the spam considerably. I'd hope the micropayment infrastructure would not be a huge impediment. A "free if the result is made public" policy is probably too complex to work.
  10. Given how 43oh collects postings across a couple microcontroller lines including Tiva and STM stuff, I think postings for pay or barter-compensated contract projects involving microcontroller hardware or software development would be appropriate, even if they aren't MSP430-specific (sometimes an MSP430 may not be the right solution). I don't see a clear need to support searches for new employees, since those have a well-developed Internet infrastructure. A fee to advertize for opportunities with value exceeding some limit ($10K?) makes sense, but without the limit would probably drive off
  11. Specific devices (MSP430G2553, MSP430FR5739) have datasheets. These provide pin mappings, power consumption, available peripherals. Families of devices (2xx, FR57xx) have user's guides. These provide descriptions of each peripheral, what registers are available, and the effect of manipulating those registers. You need to be familiar with both to develop non-trivial applications. Look for them here. Energia provides a familiar interface and lowers the barrier to entry for people familiar with Arduino. From everything I've heard it's a great solution; it's just not one that accommodates my
  12. So that's evidence supporting the possibility that Energia should work around that. Not a fight I'm interested in. It's a feature of the more advanced MSP430 chips: ultra-low-power that shut everything down and power up back at the start of the application, with or without SRAM retention and other features, resulting in current use that's fractions of a microamp. It's present in the 5xx/6xx and 57xx/58xx/59xx families; you'd have to read the users guides for more details.
  13. Or not. I think there's going to be too much functionality on this device that's locked down in the no-source-provided ROM interface to allow development of any real advanced applications. For example, the CC3000 is useless in low power solutions: I get maybe 1500 one-shot UDP transmissions with CC3000 shutdown and LPM3 between them before two AAs drain on a EXP430F5529LP+CC3000 demo. Somewhere TI claimed the CC3100 could run for a year on two AA batteries, which means they must have done a whole lot of enhancements. If you read the CC3100/CC3200 Wi-Fi Network Processor Subsystem gui
  14. If Energia is to provide the same interface as the Arduino API it emulates, it may be appropriate that it provide an initial configuration when invoking the pinMode command. Or it may not; I have no idea what sort of behavioral promises are made by either Arduino's normal API or Energia. There could even be times when the value set before a reset is exactly what you want to inherit after a reset: that need is why there's the more general LOCKLPM5 feature on the chips that support LPM3.5 and LPM4.5 modes. Getting that level of control is why I prefer to interface directly with the hardware
  15. I'm also a little concerned about the suggestion that there's yet another compiler needed for these things (unless that thread just means the update will add new linker scripts and headers to the existing ARM compiler in CCS). That, and lack of CMSIS support, continue to leave me unhappy about the state of TI's ARM Cortex-M offerings and support for open source toolchains (arm-gcc, openocd, lm4tools, etc.)
  16. It's also not surprising. PxOUT is not cleared on reset; since you enabled the pin for output, the previous setting is left unchanged. This is documented in the 2xx family user's guide (Table 8-2 Digital I/O Registers) from slau144j. A sufficiently long power-down might cure the problem, but in general if you're going to change the configuration of a GPIO from its power-up state you should set all the relevant registers.
  17. I don't use CCS but in general if the instruction pointer is past the last point where a local variable is used, the debugger information may be removed because the stack space or register has been reassigned to another purpose.
  18. This thread shows how to measure the duration of a code sequence using the cycle timer. That's probably the best solution for comparisons like this: read the cycle counter, run the loop for N iterations, then read it again and figure out the speed.
  19. I'd start by comparing the SPI and GPIO module register configurations in both programs, probably by dumping the register memory for the modules. Also, looking at the analyzer traces the SPI clock in both versions looks odd (I'd expect 8 evenly-spaced pulses per octet transferred, with a slightly larger gap between octets). The ENABLE line is clearly wrong in your program: normally you'd see ENABLE low at any time when there's clock activity. (That it goes high again between octets in the Energia program is unusual but may be appropriate if the slave chip's interface operates on single-oc
  20. Just a reminder: in addition to a 43oh FatFS port that I believe @@bluehash has made available somewhere around here, I maintain a github repository that tracks all releases of FatFS and Petit FatFS and the sample code, including patches, updated whenever I happen to remember. This may be useful to people who want to see how it changes over time, since ChaN only publishes packaged releases. (For example, R0.10 introduced an API change to f_mount.) BSP430 has an example fatfs interface that may also be useful, as the FatFS sample package dropped the generic example back in 2013.
  21. Interesting; thanks for the pointer. The big problem is that over the last couple years TI has completely failed to make the CC3000 robust enough to be deployable solution, and their support for it has diminished significantly over the last couple months. Maybe the CC3100 is intended to magically fix all the CC3000's problems, but my expectations aren't high.
  22. SystemInit is a CMSIS standard startup function normally implemented in the system_DEVICE.c file and referenced from startup_DEVICE.s. TivaWare doesn't use CMSIS, so that may explain why it can't be found: looks like you're using the standard Keil ARM infrastructure but it's not compatible with the device-specific material provided by TI. Ignoring the specific application you want to get working, are you able to build and run a standalone blink-the-led application on your target hardware under Keil? If not, get that working first. If so, see what the difference is between that working pro
  23. @@Lyon The code is being gratuitously tricky: the "first argument" is a preprocessor token that expands to two arguments. @L.R.A Don't do that sort of thing; it misleads the people who are trying to help you.
  24. If the sole reason you're creating and assigning to tictac is to generate a delay to avoid a hw fault operating on the GPIO before the module warms up, then (1) see this and some related thread somewhere about how the NOP instruction might be spelled in energia, and (2) just move the enable of PORTA up and use the time it takes to enable SSI0 to generate the delay. In straight-line code as you have it, it's nice to keep the internal order the same anyway: enable all the modules (PORTA, SSI0); configure all the modules (PORTA, SSI0). By following this practice you'll absorb the necessary m
  25. Is the posted code complete? Certainly placing functional statements such assignments to SYSCTL_RCGC1_R at functionfile level is not valid C, so perhaps that's inside a code block that was removed (or was not added as it needs to be). It's unusual in pre-C99 code to intersperse variable declarations like the one for tictac with code, so that warning may be a different issue.
×
×
  • Create New...