Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by basil4j

  1. Oops, typo haha thanks.


    I did this to the port registers. 

    P1SELC |= I2C_SDA | I2C_SCK; 	//Configure I2C pins

    P1SELC sets P1SEL0 and P1SEL1 simultaneously.


    I assume USCI is tertiary function, the pin list on the datasheet says there are up to 5 functions on some of the pins, so who knows how i'd use something beyond tertiary :/

  2. Revised code. This should take care to avoid resending the data byte over and over...How does this look? 

    case 0x16: // Vector 22: RXIFG0 Ready to take data from buffer
       accel[UCB0STATW >> 8] = UCB0RXBUF; //UCB0STATW byte counter starts at bit 8
    case 0x18: // Vector 24: TXIFG0 TXIFG0 is set when TXBUF is empty or when Start condition is generated
    /*  The UCTXIFG0 bit is set when the START condition is generated and the first data to
        be transmitted can be written into UCBxTXBUF. The UCTXSTT flag is cleared as soon as the complete
        address is sent.*/
       if (UCB0CTLW0 && UCTXSTT) { // UCTXSTT is still set so this branch will be taken the first time around (i.e. start condition generated)
          UCB0TXBUF = 0x32;// put byte of data into TX buffer.
       } else { // UCTXSTT will be cleared by now and TXBUF will have been transfered to shift register
          UCB0CTLW0 &= !UCTR; 	// Put into receive mode
          UCB0CTLW0 |= UCTXSTT; 	// generate start condition.
  3. I think the initialization sequence needs to look like this:

    UCB0CTLW0 = UCSWRST; // put eUSCI_B in reset state
    UCB0CTLW0 = UCMODE_3 | UCMST | UCSSEL__SMCLK | UCSWRST; // I2C master mode, SMCLK, retain reset flag state
    UCB0BRW = 0x0008; //clock scaler
    UCB0CTLW0 &= ~UCSWRST; // eUSCI_B in operational state (clear reset flag)
    UCB0IE |= UCTXIE0; // Enable TX interrupt for address 0


    Thanks! Not something someone new to MSP would know too well haha



    The "get things going" block looks ok (apart from a couple more uses of UCB0CTL1). You might have issues due to taking the module out of reset before setting the slave address. I'm not sure on that though, the fact that UCTR is clear at that time might mean it's safe.




    Thats the main bit I am confused about. The Family giude says 


    After initialization, master transmitter mode is initiated by writing the desired slave address to the

    UCBxI2CSA register, selecting the size of the slave address with the UCSLA10 bit, setting UCTR for
    transmitter mode, and setting UCTXSTT to generate a START condition.


    None of these registers say the module needs to be in reset mode to access, so I just left them out of it to keep things simple in my code (i.e. only things which must be done in reset are done in reset).


    The timing diagram says it starts when both UCTXSTT and UCTR = 1, it then generates a start and sends the slave address so I figured as long as I set the slave address before these 2 registers it would be ok.



    In the interrupt I think you're clearing UCTR and setting UCTXSTT too early. According to the timeline diagrams in the user guide you should wait for UCTXIFG0 to go high again after you set UCB0TXBUF to the command value.


    The receive looks ok, though I've not used USCI_B interrupts before so can't be sure.




    I think you're right, UCTXSTT needs to be set and UCTR clearing during transmission of the last byte (not before). UCTXIFG0 goes high once UCB0TXBUF is being sent.

  4. Hi All,


    Using the MSP430FR5739 UCSI_B in i2c mode.


    Just checking ive got this right, as I've never used it before.
    I neod to do the following, Ive left out the ack's
    S= start
    E= stop
    [Address+write][Register][Address+read][Read 6 bytes][E]
    Setup at beginning of program:

    UCB0CTL1 = UCSWRST; // put eUSCI_B in reset state
    UCB0CTLW0 = UCMODE_3 | UCMST | UCSSEL__SMCLK; //I2C master mode
    UCB0BRW = 0x0008; //clock scaler
    UCB0CTL1 &= !UCSWRST; // eUSCI_B in operational state
    UCB0IE |= UCTXIE; // Enable interrupts

    Program calls the following to get things going:

    UCB0CTL1 |= UCSWRST; // put eUSCI_B in reset state
    UCB0CTLW1 |= UCASTP_2; // stop after bytes sent
    UCB0TBCNT = 6; // automatic stop after bytes
    UCB0CTL1 &= !UCSWRST; // eUSCI_B in operational state
    UCB0I2CSA = 0x3A; // address of slave
    UCB0CTLW0 |= UCTR; //transmitter mode
    UCB0CTLW0 |= UCTXSTT; // generate start condition,
    Transmit interrupt (should 1 byte and then get ready to send a repeat start once that byte has finished)
    case 0x18: // Vector 24: TXIFG0 Ok to accept data into buffer
    UCB0TXBUF = 0x32; // send register of first byte of data
    //I2C will start sending this data
    //Get i2c ready for next bit
    UCB0CTLW0 &= !UCTR; //receive mode
    UCB0CTLW0 |= UCTXSTT; // generate start condition.
    Receive interrupt (accel[] is a char array where I want to store the data, should receive 6 bytes into this array then stop.
    The auto stop was setup at the beginning.
    case 0x16: // Vector 22: RXIFG0 Ready to take data from buffer
    accel[UCB0TBCNT] = UCB0RXBUF; //Get data from buffer

    Thanks in advance!

  5. Thanks Katie, my confusion is more around the statment in the manual 'if the TBxCCR1 and TBxCCR2 CFIG flags are set when the interrupt servicr routine accesses the TBxIV register, TBxCCR1 CCIFG is reset automatically. '


    This says to me the interrupt routine itself resets the flag once it's decided to use the vector, thus will clear before my switch case even sees it?


    Sent from my GT-I9300 using Tapatalk



  6. Hi,


    I found a few QFN32 CM3 devices which would be nice from NXP, downloaded LPCXpresso, installed it and got lost :)

    Technically, the MCU's would be more suitable for this application just to ease the workload on the math, but I am finding everything extremely complicated when it comes to learning the programming side of things of ARM devices (regardless of brand). 


    Seeing as we are on the subject, might as well run my thoughts past you just to double check the amount of math I need to do really isnt much :D 


    Main clock at 20MHz (DCO), with SMCLK doing the timing of the sensor reading interrupts and writing the 256bytes to dataflash (SPI) every 0.05s


    Most of the math I think I can do in integer math (this is for a rocket altimeter by the way....)

    Heres my thinking...


    From Barometer data:

    -Find pressure ---ADC reading * 0.012 mBar ---easy to do in integer as its a linear relationship (convert mBar to uBar)

    -Apply temperature and offset adjustments

    -Calculate altitude ---   =((((P0/P)^(1/5.257))-1)*(T+273.15)) / 0.0065...havent got my head around this one yet, cant figure out the best way to do the x^(1/5.257) bit, rest is fixed point math

    -Calculate velocity from altitude -- Can be done in integer

    -Calculate acceleration from altitude -- can be done in integer


    Accelerometer X, Y, Z axis, for each axis:

    -Convert to G's ---can be done in integer math (multiplication/division)

    -Apply temperature and offset adjustments

    For X axis only:

    -Calculate acceleration - can be done in integer math (addition/division)

    -Calculate new velocity --can be done in integer math (addition)


    Gyroscope X, Y, Z axis, for each axis:

    -Calculate change in angle --- I think this could be done in integer math.

    -Apply temperature and offset adjustments

    -Calculate new angle ---again, I think integer math

    -Combine Y and Z angles to come up with a modifier for the vertical velocity --- sine/ cosine and fixed point mult/div


    Combined accel X velocity and gyro tilt

    -Calculate altitude from X Velocity and tilt modifier ---floating point???


    Most frequent sample rate is the accelerometer at 400Hz, Gyro at 100Hz and Barometer at 40Hz. 


    And heres how I intend to process everything:


    Interrupts in order of priority:

    -Get data from ADC's

    -----Interrupt on timer at 400Hz

    -----Interrupt determines if Accel, Gyro and/or Baro needs to be read from based on an incrementing counter (all sample frequencies divide into 400Hz nicely)

    -----Write to a variable to tell the main routine which math stuff to work on.

    -Start write block of data to Dataflash (SPI) @ 20Hz (20Hz is the time it takes to fill 256bytes)


    In main loop, determined by Switch/Case:

    -Do Accel math

    -Do Gyro math

    -Do Baro math


    If the MSP430 is up to this i'm more than happy to stick with it :) What do you think?


    Hi All,


    Im having a bit of trouble with these interrupts on TimerB2 on the MSP430FR5739.


    I am using 3 compare registers, TB2CCR0 = 250, TB2CCR1 = 150 & TB2CCR2 = 50


    CCR0 Interrupts are easy enough, but im confused when it comes to the rest.

    The Family guide says:


    The TBIFG flag and TBxCCRn CCIFG flags (excluding TBxCCR0 CCIFG) are prioritized and combined to
    source a single interrupt vector. The interrupt vector register TBxIV is used to determine which flag
    requested an interrupt.
    Any access, read or write, of the TBxIV register automatically resets the highest-pending interrupt flag. If
    another interrupt flag is set, another interrupt is immediately generated after servicing the initial interrupt.
    For example, if the TBxCCR1 and TBxCCR2 CCIFG flags are set when the interrupt service routine
    accesses the TBxIV register, TBxCCR1 CCIFG is reset automatically.
    I was hoping to use the following code, using TB2IV to detemrine which CCRn caused the interrupt but if I read this correctly it will be cleared before I get a chance?
    Can someone help? Am I misreading or is there a trick around this?
    //=====Interrupt for 40Hz timer pre-sample=====
    #pragma vector=TIMER2_B1_VECTOR
    __interrupt void Interrupt_40_pre(void)
    	switch (TB2IV)
    		case 0x02: //Temp
    		case 0x04: //Baro
  8. Hi Spirilis,


    What I meant by 'operate with just a few capacitors' was I don't need an external EEPROM (like the Prop) or a crystal (with the obvious tradeoffs), just a few decoudpling capacitors and it will run quite nicely...well at least I assume so from what ive read! 


    Hardware FP is nice, but at 40mA I might as well go back to the propeller.


    Is there a way I can estimate the time required for certain calculations in CCS?


    Regarding the power supply. The power supply ive planned is a 3.3v, 250mA LDO supplied by a 9V battery or 3.7V LiPo usually. 

    The highest minimum voltage of the sensors I am using is 2.7V (dataflash memory), everything else is happy around 1.8V to 2.4V minimum.


    I am REALLY stuck for board space, and using this 3pin SOT-23A with 2 external capacitors (plus the super cap) is about the smallest I can find, and about the largest I can fit!

    If im reading you right, you're suggesting adding the DC-DC converter after my main power stage? If so, i'm afraid I wont have room for that :( I was hoping the LDO and external caps would keep the power clean enough...


    If you know of a DC-DC converter which would be equally as compact as my LDO that would be fantastic as I prefer them over LDO's!

  9. I have planned on using the FR5739 which looks nice. I also considered a few cortex parts (ST parts mainly) but got lost when trying to find nice learning resources. Ultimately I turned to the MSP as they can operate with just a few capacitors and be happy and I love the integration. If the borg army also runs on minimal components I will reconsider them due to their strength in the math department, but as I say, I got lost searching :)


    Sent from my GT-I9300 using Tapatalk


  10. Hi All,


    I have never used an MCU with interrupts before (previous experience using the Propeller which does not have interrupts), and am trying to nut out the main routines in my upcoming project. Hoping I can get some insight from people here!


    My program needs to sample 3 sensors, 1 every 2.5ms, 1 every 10ms, 1 every 25ms, perform some logic and write 256 bytes to SPI Flash memory every 25ms.

    I plan to use interrupts for each of these tasks, and synchronise the start times so the time periods line up at the end of 1 second (i.e. in 1 second I will have recorded 400 samples, 100 samples and 40 samples, before writing all this to dataflash and starting over.

    Each sensor will have a bit of fixed point math applied to the results.


    I'm not sure yet if I will include this math in the sensor interrupts (which will spread the load but make my interuprts longer), or to put the in the main routine and perform them once an interrupt returns with a new sensor reading (which will allow the math to be interrupted and keep my sensor readings more in sync). Im leaning towards the later.


    Question 1: My question relating to this is, what happens if an interrupted is triggered while i'm handling an earlier interrupt? Does it queue up and start once i'm done with the first one? Do interrupts have certain priorities and an interrupt with a higher priority will interrupt one with a lower priority?


    Regarding writing 256 bytes to DF. It seems I can only write 1 byte at a time using the USCI.


    Question 2: Is my thinking correct, that to send larger chunks of data I can trigger an interrupt once the byte is sent, and in that interrupt increment a pointer to the next byte then start transmitting the next byte etc etc until 256 bytes have been sent?


    Question 3: Do timers restart automatically once they have triggered their interrupt (thus staying in sync) or do they restart after the interrupt has been handled (thus, I need to re-sync them)?


    Question 4: Last question for now is just a general electronics question.


    I am using a super cap in this design which I have never done before. I have it in parallel with the 3.3V LDO output, and calculate it will hold the system above 2.7V for ~8 seconds in the event of battery disconnection or brownout. Do I need to put a resistor in series with the supercap to prevent it discharging too much power into my devices, or can I just use it as is?


    Sorry for the wall of text and thanks in advance!

  11. Hi Graham,


    If altitude had a linear relationship to the barometer output, then no I wouldn't. Unfortunately I need to know actual altitude for a few flight events so it needs to be calculated in real time.



    I should note that the main altitude measurements will be done by the barometer, the inertial calculations will be secondary but I will be combining the results in certain cases.

    Sent from my GT-I9300 using Tapatalk


  12. Sorry Enl, forgot to answer your questions! The majority of the math will be determining accurate vertical altitude and velocity from one axis of a 3 axis accelerometer, adjusted for tilt using data from a 3 axis gyro. I will also be calculating barometric altitude using data from a pressure sensor. (This project is a rocket altimeter) which I believe uses log...


    With this in mind id like to be as precise as possible.


    The adc readings are only for battery voltage and a few minor checks on various parts of the circuit so do not need to be as accurate.


    At some point I hope to implement a kalman filter on the acceleration data but will leave that until ive proven the basic hardware works.


    Sent from my GT-I9300 using Tapatalk


  13. Hi!


    Thanks for the info :) that will come in useful for another project I'm thinking of :)

    For this application, even using no power saving tricks the MSP will be low enough :) I'm more concerned about whether or can so all the required tasks in the time allowed.


    Sent from my GT-I9300 using Tapatalk



  14. (Specifically MSP430FR5739)


    Hii All,


    Newb question here.


    I have a project i'm working on which I have currently designed around the Parallax Propeller with which i'm familiar.

    For this application it is very overkill and uses a ton of power (~30mA at the freq im running it at), but i'm familiar with it and its very fast/flexible to develop for.


    This project is battery operated and at a point in its use will be powered by a supercap for some seconds. Obviously if I can reduce consumption in any area I should! The prop is ~60% of the consumption so reducing this to just a few % of total consumption would double the time the supercargo can hold it up. On top of that i can save some board space by removing an external EEPROM, ADC and crystal (?), which I am truly pressed for.


    Before i get carried away, I am just wondering if an MSP device would be capable of the following, I have never used one but am pretty keen to give it a go IF the MSP will work for my application (using the right tools for the job and all).

    If not, I guess ill use it for the next project :)


    Every 2.5ms (loop freq is 400Hz) I need to do the following:


    -Read 3 i2c sensors, combined 36 bytes data plus overhead (addr, cmd, ack etc)

    -Read 5x ADC inputs

    -Perform some fixed point math. Say 10 mult/div and 2 Sin/Cos plus a few dozen addition/subtraction

    -Write 256 bytes to SPI Dataflash

    -Send 64 bytes over UART (RN-42 bluetooth)

    -Perform some basic if/then logic, mostly if statements (about 40 of them).

    -Toggle a few outputs


    My main points of concern are the math and secondly the i2c/SPI routines and the time they will take...


    Now this might be well within the capabilities of the MSP430, in which case just laugh at me and say 'what a stupid question', but i've always been taught there are no stupid questions ;)


    I also need to write to SD (FAT16, human readable txt file), but this happens after the main task has been performed so is not time critical and all the other tasks will have stopped.

  15. Hi All,


    New the MSP430 so please excuse potential ignorance :)


    I am working on a project using the MSP430FR5739 which will be used to fire some pyro igniters (high powered rocketry).

    Port J would be easiest to use with regards to PCB layout, but as this is also the JTAG port i'm just checking what state they are initialised in, and if I should be careful of anything when using them to prevent accidental misfire?


    I will be using SBW to debug/program.


    Thanks in advance!




  16. Hi All,


    Another semi related question :)


    Each MSP will also need to output a constant 32kHz square wave for some sensors and also keep a few timers running to sync the communication windows for the bus output (I'm implementing a round robin type comms bus between devices) and various other things. These other timers only need 0.05ms accuracy or so, I've yet to sort out the details of these, may be stricter requirements, may be looser.


    The device I'm looking at has 1 timer which I'm thinking would be best used for the constant 32kHZ output. Is it easy enough to code in software a couple of timers to take care of the comm window timing and a few other things? I've never used interrupts as I'm coming from the propeller MCU which doesn't have any, sorry if there is a simple solution to this!

  17. Thanks for the super quick reply!


    That's what I thought, I am completly un familiar with this MCU so wasn't sure on how many cycles instructions take etc :)


    Ill be using 8kb or 16kb devices if pos, so it looks as though ill be stuck with the CCS compiler. I assume the libraries are the same?

  • Create New...