Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    abecedarian got a reaction from JohnBaker in Can't get to Square One   
    CCS has a code-size limited install for MSP430 devices, and board-locked unlimited for some others (Stellaris & Tiva, I believe) which despite that, installs the drivers you need. You can change the license status from CCS' "Help" | "Code Composer Studio Licensing Information" menu.
    This does not affect current Energia releases though so for the most part you can compile your heart's desire on the boards supported by Energia, except any MSP430 that use 20 bit addressing, i.e. F5529 and maybe others since the compiler Energia uses doesn't support the MSP430X extensions.
  2. Like
    abecedarian reacted to Rei Vilo in Pin Names - Connected Launchpad   
    Welcome to Energia! 
    Energia release 12 supports the Connected LaunchPad. The way pins are numbered on Energia is PN_0 for pin PN0.
      Please find a pre-release of the pins map for the TM4C129 LaunchPad.   Update! Pins map with picture (Click to enlarge, full-sized picture)
  3. Like
    abecedarian got a reaction from JohnBaker in Can't get to Square One   
    EZ430 is not F5529.
    My first suggestion is download and install CCS. And maybe for fun, get into Device Manager (devmgmt.msc), right-click the device without drivers, choose to update drivers, select automatically search for drivers and then select the root ("My Computer" or even "C:/" maybe) of your system and allow searching subfolders.
    If you want, PM me and I'll give you my email address. You can then send me a remote assistance request and I'll help you out.
    But I've had no issues with drivers, other than EZ430 access points with Chronos, and I'm using Win 8.1.
  4. Like
    abecedarian got a reaction from spirilis in EK-TM4C1294XL silicon revision?   
    @@spirilis -
    /me bows down.
    And on the up side, it's been running 107 minutes and some 30 seconds without issue.
    *edit- now at 446 minutes. Not sure why it disconnected earlier other than like I said that maybe Exosite is worried about bandwidth.
  5. Like
    abecedarian reacted to spirilis in EK-TM4C1294XL silicon revision?   
    More like you are exhibiting unrealistic expectations for free code whose source you haven't examined that has been (likely) written in a hurry for experimental silicon just being released
  6. Like
    abecedarian reacted to grahamf72 in Probably dumb question regarding timers   
    As is, the code there will only go to 750Hz, but if you change the line where it says ID_3 (divide by 8) to ID_0 (divide by 1), you can get up to half the VLO clock speed, which will be approx 6kHz. If you use the 32768hz crystal you can get up to 16384kHz.
    By changing the TASSEL_1 line to TASSEL_2, it will use the system clock (you will also have to change the LPM3 to LPM0 so the clock stays running) which Energia sets to 16MHz. With careful use of the count figure and divide ratio you can get anything from 15Hz to 8MHz.  A slight tweak to Energia so that you can use the 1MHz clock with the 2553, and you can go from just under 1Hz to 500kHz.  By using the Capture/Compare registers and their associated pins, you can also vary the duty cycle so that you can have a short pulse instead of a 50/50 square wave.  
    The timers on the MSP430 are very powerful - I don't claim to be an expert on them though, I know enough to do the basics, but there is still a lot I haven't quite got a good handle on.
  7. Like
    abecedarian got a reaction from dubnet in Simple IRC example   
    That opens up a strange environment....
    Put this with the ECU thing, over Bluetooth to my phone, and now I can get chat messages about my engine's state on my watch and headset?
    "Warning. Exceeding posted speed limit."
    Maybe it could be set to do speech to text and I say "Increase fuel duration 1 millisecond" and it reprograms my ECU?
    And then someone joins the channel and says "Kill the engine" and I'm done for the day.
  8. Like
    abecedarian got a reaction from spirilis in Simple IRC example   
    That opens up a strange environment....
    Put this with the ECU thing, over Bluetooth to my phone, and now I can get chat messages about my engine's state on my watch and headset?
    "Warning. Exceeding posted speed limit."
    Maybe it could be set to do speech to text and I say "Increase fuel duration 1 millisecond" and it reprograms my ECU?
    And then someone joins the channel and says "Kill the engine" and I'm done for the day.
  9. Like
    abecedarian reacted to pabigot in EK-TM4C1294XL silicon revision?   
    Yes; mine turns out to be an A1 die revision, which at least doesn't have quite as many ugly errata as the A0 revision.
    For $20 per board I think we can expect to be beta-testers.
  10. Like
    abecedarian reacted to enl in Probably dumb question regarding timers   
    Still quite doable. Probably want linear response on a pot, So I would go with a table for the divisors. Either of the above methods will work, but to match the pulse width for the short pulse will be easier with the interrupts. As the cam turns at half crank, if it has one tooth for the sensor, that is divisor of 64, not 32. does it have 2 teeth?
    This range is great enough that I would handle the low rate pulse with an interrupt, even if the high rate is handled with hardware. Interrupt each rising edge of high speed, and keep a counter in the ISR. At 0x1f in the low bits (easy test with AND), output  high, otherwise output low.
    Your base freq at 11000RPM with 32 teeth on crank is 5867HZ, for a divisor at 1MHz of 85 if using up/down counting. Low end of 200RPM is 106.7HZ, for a divisor of 4716 at 1MHz. Using a clock  of 4MHz for the timer quadruples these divisor values and gives higher resolution for smoother transition.  16MHz clock with clock divisor of 2 gives best precision at 8 times these divisors.
    Given the new info, and @@grahamf72 pointing out the easier way, I would likely go hardware for high rate with interrupt and counter for low. Update count limit each time the low rate is output is set low by reading ADC input, triggering next ADC cycle, and storing the new limit value in the CCR. The ADC reads are one cycle behind the response. Still better than the response of any throttle.
  11. Like
    abecedarian reacted to grahamf72 in Optimising math   
    Over in the Energia libraries forum I have posted a port of the libfixmath 16.16 fixed point math library. It is not Energia specific, so should compile if you are using CCS. It is much smaller and faster than the floating point libraries, and is more than accurate enough for barometric altitude calculations. The whole reason I ported it was because I was using a BMP085 on an MSP430G2553 and the floating point was taking up so much flash I didn't have enough left to do anything useful.
  12. Like
    abecedarian reacted to chicken in Probably dumb question regarding timers   
    How about this library: http://forum.43oh.com/topic/2861-energia-library-mstimer2/
  13. Like
    abecedarian reacted to grahamf72 in Probably dumb question regarding timers   
    Outputting frequencies on a pin can be done by the timer modules without needing to use interrupts & manually toggling pin outputs. The MSP430G2553 for example has 2 timers so can produce 2 different frequencies.
    The following code is based on the MSP430G2553 and will produce 1 frequency on P1.1, and 1/32 of that frequency on P2.0.  As you will note, there are no interrupts, and no code is used to toggle pin outputs - they are purely conrolled by the timer.  In fact, the CPU isn't doing anything in this example - in my loop I put it into Low-Power-Mode 3, to show that the timer is doing all the work.  The code is designed to run at a slow speed so the effect can be observed on the Launchpad's LED's.  Note that the standard launchpad has the LEDs connected to P1.0 & P1.6. But you can remove the jumpers and use a F-F cable to connect P1.1 & P2.0 to the LED-side of the pins where the jumper attaches.
    I know this example isn't exactly what you were asking, but you should find it fairly trivial to make the necessary changes.
    All you need to do to change the frequencies at run-time is alter the TA0CCR0 and TA1CCR0 registers. 
    void setup() { //This is designed to run on the MSP430G2553 which has 2 Timer A modules. //The output of TimerA0 Capture/Compare Register 0 is attached to P1.1 //The output of TimerA1 Capture/Compare Register 0 is attached to P2.0 //This will output a square wave on P1.1 & a square wave of 1/32 the //frequency on P2.0 //P1.1 & P2.2 can be jumpered to the Launchpad's LEDs for a visual //indication of the operation. P1DIR |= BIT1; //P1.1 set to output P1SEL |= BIT1; //P1.1 set to SEL = select timer output P1SEL2 &= ~BIT1; //P1.1 clear SEL2 = select timer output P2DIR |= BIT0; //P2.0 set to output P2SEL |= BIT0; P2SEL2 &= ~BIT0; //The desired frequency of the fast clock in Hz #define FREQUENCY 2 //The value that we count up to. Shown like this to show how it is derived: //clock frequency (nominally 12khz) divided by the amount we divide the timer //by with our TAxCTL command, divided by the desired output frequency, divided by 2. #define COUNT (12000 / 8 / FREQUENCY / 2 ) //note the exact frequency depends on the accuracy of the VLO clock, which is not very //accurate. For more precise timing we could use the crystal as the timebase, or //the system clock. Note that the maximum the timer can count to is 65536, so if //using the 16MHz system clock, speeds low enough to observe will be impossible to achieve. TA1CCR0 = 32 * (TA0CCR0 = COUNT); //set TimerA0 to our count, and TimerA1 to count*32. //this will make TimerA1 run 32 times slower than TimerA0 TA1CCTL0 = TA0CCTL0 = OUTMOD_4; //Set to toggle the output every time the count hits CCR0. TA1CTL = TA0CTL = TASSEL_1 // Source timer's clock from ACLK | ID_3 // Divide by 8 | MC_1; // Count up to TA0CCR0 mode } void loop() { LPM3; //stop in LPM3 mode. }
  14. Like
    abecedarian reacted to enl in Probably dumb question regarding timers   
    How precise do you want the rate and what characteristic do you want for the adjustment? Linear with resistance? More precision at one end or the other? How much resolution?
    Without the answers to these questions, I'll give a basic summary of one way to approach it.
    Connect the pot between Vcc and Gnd, and the wiper to a ADC input. This gives 1024 steps for freq selection. For (fairly) precise timing, you will need a crystal, but the standard clock system is pretty good, and will give greater resolution. At 5.5Hz, the higher speed osc will be 176Hz. At the low end, you are looking at 32Hz. Consider only the higher frequency, and every 32 transitions of that (every 16 full cycles) toggle the lower frequency output. For a symmetric square wave, your maximum basic timing is 362Hz.
    If you aren't concerned about exact frequency, or having perfectly uniform steps, it is easier. Assuming a main clock of 1MHz (the lowest G-series clock from DCO that is factory calibrated), you can built a table of 1024 divider values for the timerA, with the highest freq value being 2762 and the lowest being 31250, to get double your higher freq. Write an interrupt handler that toggles your high freq output on each interrupt and your low freq output every 32nd interrupt (using an counter in the interrupt handler to keep track). Periodically read the ADC for pot position, and use this to set your timerA period.
    There are a lot of way to do these things, so I am not being really specific. You could just scale the ADC value by 28 and add 2760 to it for your period, if less linear behaviour is ok. A table will allow you to get very close to linear. The timer can be set up several ways. One easy way to handle it is let it free run, for a period of about 1/160th of a second. Each interrupt, add the count increment to the trigger value for the interrupt, Then have it interrupt on each period and use that to trigger the ADC read for pot position.
  15. Like
    abecedarian reacted to energia in New Energia release 0101E0011 - 12/17/2013   
    The msp430 gcc port that is in CCS is pretty stable but not stable enough for me to pull into Energia. I hope to pull this toolchain into the june/july release.
  16. Like
    abecedarian reacted to spirilis in New Energia release 0101E0012 - 03/20/2014   
    Tiva don't need it
  17. Like
    abecedarian reacted to energia in New Energia release 0101E0012 - 03/20/2014   
    I am happy to announce that release 0101E0012 just went up on energia.nu. 
    I want to thank everybody for their support and contributions. Energia would not have been possible without such an awesome community!
    Details of the release can be found on http://energia.nu
  18. Like
    abecedarian reacted to enl in Optimising math   
    If float is used, moderate memory overhead. Most (all?) operations are implemented as function calls, so te functions used must be included. The difference between one add and 20 adds is minimal, tho. Once the function is in the build, calling it isn't a lot of space.
    Big thing is time. Software implementations of FP can be slow. A device with hardware mult (integer) can do many FP operations a lot faster than those wihout hardware mult. Hardware div (integer) makes things better yet. A few operations are not going to be a big issue, timewise. The functions that use a lot of operations are the killer, like exponentiation and logs. These can be worth optimizing in many cases. If previous thread hadn't given pretty loose timing for the altitude comp, I would call this a prime candidate for a specialty function for the exponentiation. Might still need it, but my guess is not.
    Greeg's methods apply to the integer math (or fixed point), and can be used to avoid FP in cases where the final result needed is integer )or, again, fixed point), but intermediate comps may need FP or fraction.
    A question I still have is: Must the altitude be computed in-flight? Or can the sensor date be stored and converted on the ground? Is the altitude needed? Or only some property, such as detecting when max altitude is reached? The answers can make a big difference in what math need be done on MSP430, and on how to doit.
  19. Like
    abecedarian reacted to Fred in Optimising math   
    Lots of interesting stuff, but you're forgetting one thing. Do you NEED to optimize? For example, if you're checking altitude 5 times a second and your non-optimised code takes a (relatively) very slow millisecond to do the calculation then you are very far from needing to optimize.
    It's very relevant to consider performance on an embedded device. However, optimised code tends to be less readable, less maintainable and more likely to have bugs. If your "improved" code is quicker but causes you to trip up later on a subtle bug, is it really better?
    Don't take this it mean that you shouldn't have asked or that I'm not interested in the answers! My view may be tainted by the fact I spend a lot of my day job (as a C#/Java developer) working with convoluted buggy code where people were trying to prove they were clever when really they didn't need to.
  20. Like
    abecedarian reacted to enl in Optimising math   
    @Fred: I agree with you 100%. As I said: modern compilers tend to be smart.
    @basil4j: Based on the operations you listed, I would guess close order of magnitude of 200 cycles NOT INCLUDING the logs/antilogs for the exponentials (basing this on about 20 cycles for FP mult or div with the hardware integer mult) At 25MHz, this is 8 microseconds. The only real time taker will be the exponentials. I doubt that they will be more than on order of magnitude longer, giving an estimate of roughly 100 microseconds for the math, almost certainly less than a millisecond.
    Going back to your needed time scale, I don't think efficiency is likely your main concern. Efficient enough does the job. Within broad limits, the guideline is make it right, then make it fast. If you need to worry about fast to make it work, only make it as fast as you must, then put effort elsewhere. Ditto for size: If it fits, don't worry about saving a few bytes. If it doesn't fit, you need to worry, and it is often more than a few bytes that are the concern.
  21. Like
    abecedarian reacted to spirilis in The Datasheet "Book Club"   
    Ok so this was an idea that came to mind last night; These datasheets and related documents are huge, and sometimes have surprising & interesting details nestled into their labyrinth-like chapters.  Why not start a thread for sharing noteworthy details?  No need to be a pack of lone wolves about these things...
    I'll start - with the TM4C123GH6PM datasheet: http://www.ti.com/lit/ds/symlink/tm4c123gh6pm.pdf
    Reading through Chapter 2 yesterday, "The Cortex-M4F Processor", a few details stuck out that I hadn't realized before-
    1. Didn't realize there is a 16-bit SIMD vector processing unit.  How do you access/use it from GCC I wonder?
    2. Debug - SWV, Serial Wire Viewer, is a feature where you can export a stream of software-generated messages, data trace, profiling information.  Software-generated messages -- How do we access that?  I assume we need OpenOCD to use this feature, but is there an API for writing to this debug interface?
    3. Like most complicated processors, there is a notion of "privileged" vs "unprivileged" execution modes.  The Cortex-M4F extends this further by declaring two operational modes too--"Thread" mode (i.e. normal application runtime, either privileged or unprivileged) and "Handler" mode, exclusively privileged and only available as the context for ISR handlers.
    4. Coming from MSP430 land, I'm always looking for analogies to the MSP430 in here.  The equivalent for the "GIE" (global interrupt enable) bit is the PRIMASK register; when bit0 is set, it disables all interrupts (of configurable priority, so RESET/NMI/Fault interrupts still fire).  This is important for sleep modes below...
    5. Interrupt priorities run from 0-7, with *lower* numbers being of "higher" priority.  Default priority for all interrupts is 0 (the highest).  BASEPRI register declares the minimum priority required to fire, and besides setting 0 (=no exceptions masked), the setting masks all interrupts of that priority and those higher in number ("lower" in priority).
    6. The CONTROL register has an interesting bit, "FPCA", which will adjust the latency for entering an interrupt ISR; it determines whether or not the Floating Point Unit's registers should be pushed onto the stack during ISR entry or not.  This makes a substantial difference, as seen on page 109; the difference between FPCA=1 exception frame and FPCA=0 exception frame is many-fold.  So folks not using floating point would do well to keep that disabled (not 100% sure how GCC handles this yet, i.e. whether there's a builtin, a TivaWare ROM_* function or if you have to do an inline ASM code).
    7. Bit-banding is available for everything; flash, SRAM, peripherals.  I think TivaWare has some macros to make that easy, need to look into it.  It's a feature for doing single atomic writes or reads to a single bit of any byte in the address space, by writing/reading a 32-bit word (0x00000000 for bit 0, 0x00000001 for 1).
    8. The Cortex-M4F provides two user IRQs for operating system support; SVCall (Supervisor Call) and PendSV (pendable, interrupt-driven request for system-level service--typically used for context switching).
    9. Sleep modes.  The Cortex-M4F uses instruction-based sleep entries, but it has some features that allow the MSP430's "event driven" paradigm too.
    9a. WFI = Wait For Interrupt, goes to sleep and will wake up only if an unmasked interrupt occurs.
    ** Sometimes waking requires a common "clean-up" or reinitialization routine to run; to support this, your app would enter WFI inside an idle loop with PRIMASK enabled so that the CPU wakes up, but does not enter the ISR right away; does its cleanup work; then disables PRIMASK so the Cortex immediately jumps to the highest-priority IRQ's ISR.
    9b. WFE = Wait For Event, goes to sleep and will wake up if ANY interrupt occurs, even if it's masked; If it is masked, the CPU will not branch to its ISR but just continue from the point where the WFE instruction occurred.  If it is unmasked, then the CPU will jump to the ISR immediately.
    9c. Sleep-on-Exit; if the SLEEPEXIT bit of SYSCTRL is set, then the CPU will return to sleep mode after servicing ISRs.  Similar to MSP430's LPM modes if the ISR does not issue a __bic_SR_register_on_exit(LPMx_bits); type of call.
    That's all for now.  Chapter 3 later today.
  22. Like
    abecedarian got a reaction from basil4j in Optimising math   
    "P = (D1 * SENS / 2 - OFF) / 2" could become... I think...
    "P = (((D1 * SENS) >> 1) - OFF) >> 1"
    ... or ...
    "P = ((D1 * (SENS >> 1)) - OFF) >> 1"
    I don't think the result is any different but I'm not sure what the rules of precedence are when dealing with mult/div and bit shifts.
    Bit shifting right 1 bit is equivalent to dividing by two, as long as you don't need the remainder.
  23. Like
    abecedarian reacted to greeeg in Optimising math   
    Since your MSP430 has a hardware multiplier, the multiply would be quicker. But modern divide function don't take too long.
    One interesting trick, since alot of maths (especially with ADC) will involve multiplying by a fraction. you can often factor out the divide when you use a HW multiply.
    X = Y * 2/3; // original X = Y * (2*(65536/3))/(3* (65536/3)); // multiply top/bottom to get 65536 on bottom X = Y * (43691/65536); // the result of this adjustment. (Y * 43691); // use the HW multi for this X = RESHI; // take the high word The trick is to get the result stored entirely within the higher word of the result.
    To my knowledge, compilers wont do this.
  24. Like
    abecedarian reacted to enl in Optimising math   
    @abecedarian: first one is good. second can lose precision, as the LSB is thrown away before mult. Makes a difference if SENSE is odd. Compiler should do it first way
  25. Like
    abecedarian reacted to OzGrant in Does the Bluetooth and PC serial port clash..   
    Tks abe...n,  Serial1.print and Serial1.available did the trick. Will now have a play with Bluetooth and see what gives.
  • Create New...