Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by tripwire

  1. I took some measurements for CC3200 DMA in this thread. The peak speed is four cycles per transfer (whether byte, halfword or word). The first transfer takes eight cycles and the transfer following an arbitration check is seven cycles. I think Tiva will follow the same pattern, since this matches the timings indicated by the ARM documentation.
  2. That IO performance on Tiva is impressive. It looks like it's due to the use of an AHB bus for the GPIO on the Tiva rather than APB bus used on MSP432. That said, I think it can only achieve that rate when not performing RMW operations. Toggling one pin with XOR would presumably have a maximum frequency of 13.33MHz (one cycle to read, one to XOR and one to write back). The uDMA on Tiva, CC3200 and MSP432 isn't great in terms of raw performance. It takes a lot of cycles to read the channel data structure and source data before each write to the destination. It's quicker to write using
  3. Yes, it does. The ROM functions don't get linked into your executable, just these little trampoline stubs that jump into the ROM. It's possible for a DriverLib function to be smaller than the trampoline needed for the ROM version, but those are very rare.
  4. Yeah, I was surprised it worked at all without VCORE1. The chances are that the MCU would flake out and crash or reset if your program did anything too demanding at 48MHz with VCORE0. You can go a lot higher by using the timer peripherals instead of bit-banging the port with the CPU. You can also output one of the clocks (MCLK or SMCLK, can't remember which) to a particular port pin. That's useful if you just need a fast square wave for some reason. There's also the option of using DMA to write to a port, but then you you have to set 8 pins at a time (ie the whole port has its eight
  5. I'm not familiar with the internals of Energia, but from your plain C version I can see a few possible problems. First of all you're not setting the Power Control Manager to VCORE1, which is required for MCLK frequencies above 24MHz. Second, you're probably getting hit with excess flash wait states. You only need 2 wait states for ordinary flash reads at 48MHz, but the default is 3. See this thread for more information: http://forum.43oh.com/topic/8435-msp432-sram-retention-and-flash-waitstates-check-your-settings/
  6. Ok, I took a look at the preferences.txt file for my Processing PDE install, and noticed the line "editor.laf.linux=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". I'm running Windows, and normally my menus look like this: I shut down PDE, and changed that preferences line to "editor.laf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel", which gave this result: What's annoying is that the default windows look and feel class isn't specified, so I don't know what it is. Anyway, I think it will be possible to change menu fonts by finding an appropriate look and feel or editing the cu
  7. I think it might be this. Until now, when you buy a licence you also get 1 year of subscription which entitles you to free major upgrades (5->6, 6->7 etc). Minor version updates are always free. Once the subscription runs out you needed to renew to get any major updates. It sounds like TI are dropping the subscription aspect, but the initial licence still needs to be paid for. EDIT: Confirmed at http://www.ti.com/tool/CCSSUB:
  8. As I understand it, the Energia IDE is based on the Arduino IDE, which in turn is based on the Processing IDE (aka PDE). I think the PDE is written in Java using Swing/GTK. It might be that someone has had the same issue with one of the other IDEs and has a fix that will work for Energia too.
  9. Thanks! Position tracking would indeed be cool, but I think I'm going to stick with distance/speed/altitude logging for this project. That's mainly to keep the power and storage requirements down. I've got a target of 128 hours for the logging duration which will cover eight days (assuming I'm stationary for at least eight hours per day). That works out as about 9 bits per second for the 4Mbit flash on the SensorTag. Currently I'm using about 36 bits per second just for altitude, but I have a plan for getting that down to about 11 and a few viable options to go further from there.
  10. MSP432 uses a Cortex-M4F core, which includes an instruction set extension designed for signal processing tasks. It has faster MAC and SIMD instructions with support for saturation arithmetic. I think there might be some marketing at work (from ARM) in calling it DSP, but it's nice to have nonetheless. The DSP instruction set reference is here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100166_0001_00_en/ric1417449098079.html I don't think the MSP432 is in the same niche as Tiva. MSP432 is lower power and has peripherals derived from MSP430 family. The peripherals
  11. I've been playing with the new CC2650 SensorTag over the past few weeks, and am just getting started on my first proper project using it. It uses the onboard BMP280 sensor to measure atmospheric pressure, works out the altitude and continuously logs the data to the external SPI flash. I'm trying out TI-RTOS for the first time which is interesting. It's pretty easy to throw together a proof of concept, but I'm not entirely sure I'm doing things right Anyway, I got it working well enough to try some real-world testing over the weekend, so I fitted the coin cell and went for a bike ride.
  12. I think it might be. There could be some system task that wakes up every millisecond causing the small delay.
  13. Are you sure the pauses are being caused by the watchdog? Perhaps try toggling another LED a few times before the while(1) in your loop function. That will confirm whether the code is resetting and running from the start or not.
  14. FYI, that was introduced in C99. It's not part of the K&R, ANSI C or C90 standards.
  15. That kit's pretty cool - it includes the cc2540 dongle that can be used with TI's SmartRF Protocol Packet Sniffer software.
  16. Do you mean something like this? #define SOME_CONSTANT 123 #define OTHER_CONSTANT 34 uint8_t fun(uint8_t arg) { if(arg == SOME_CONSTANT) { arg = OTHER_CONSTANT; } return arg; } That can result in warnings as the integer constants are of type "int" or larger by default. You can fix that by casting the constant to the appropriate type as part of the definition: #define SOME_CONSTANT ((uint8_t)123) #define OTHER_CONSTANT ((uint8_t)34) ...or by using type suffixes if appropriate (long/unsigned types only).
  17. Thanks for the tutorial! This will be very useful for testing code on the CC2650 SensorTag.
  18. I got caught out by this too. Looking at the TRM I got the impression that bit-banding is good for performance, but in general that's not the case. I found that a bit-band write took at least as many cycles as the equivalent (interruptible) read-modify-write instruction sequence. I think it basically just implements the RMW sequence inside the bus controller, so the CPU kicks it off with a single instruction and then waits until it finishes. Bit-banding has two clear advantages over the RMW sequence - it's non-interruptible and it occupies less space in flash memory. If you don't n
  19. TI recently updated the MSP432 Technical Reference Manual to "revision A". Looking at the revision history shows some particularly interesting changes... First of all, the documented default value of SYS_SRAM_BANKRET has changed from 0x000000FF to 0x00000001. That means that only bank 0 retains its contents in LPM3 and LPM4. I've seen some mention of this here already, but I'm repeating it because it's quite important to know. The program stack lives at the top of SRAM by default; from bank 7 down. If you don't enable retention on the banks containing the stack then bad things will happen
  20. I'm happy to post the code to show how I got the results, but be warned: it ain't pretty! I used direct register access instead of driverlib so I could keep things consistent with the MSP430 version. Also the test setup doesn't use interrupts directly related to the DMA operation. Instead it wakes up when the timer module measuring the DMA transfer captures the falling edge of its input. For those reasons it's a pretty bad example of how to write DMA code on CC3200. This post is probably a better place to look for that. Anyway, enough excuses, here it is: DMATest.c (Does an
  21. I got a CC3200 launchpad and did some testing in comparison to the MSP430F5529 launchpad. The test programs configure three DMA channels to run in sequence. The first channel writes to a GPIO port setting an output high, the next does the measured transfer and the third writes the GPIO again to take the pin low. The CPU is asleep during the transfers, preventing any delay due to contention. The output pin can be traced on a scope to see how long the transfer took, and is also fed back into two timer capture inputs. This allows timing to be measured automatically and printed to the debug co
  22. TI have posted an MSP432 FAQ on the E2E forum: http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/411030
  23. Out of interest, which manufacturer(s) actually get this right?
  24. Does anyone have any good sources of performance information for the PL230 uDMA used in Tiva and CC3200 MCUs (or any MCU using the same DMA controller)? I'm used to using MSP430 DMA which is quite clearly specified. Each transfer spends two MCLK cycles accessing the bus (which halts the CPU), plus an extra two cycles each time it's triggered. The synchronisation time required to wake up from various low power modes is also given. The Tiva and CC3200 TRMs don't give any details of this type. I'd like to know how many cycles each transfer takes in the best case, with no contention, arbit
  25. Here's a direct link to the video
  • Create New...