Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by basil4j

  1. Ok ive been thinking about the lookup table. If I make a table and lookup the result of P0/P, to find the result for the 'power of' bit that should work. Let's say I make 2k entries in the table and they are each signed long thats 8k FRAM right? Is 2k samples ridiculous? Sent from my GT-I9300 using Tapatalk
  2. Hi, I chose sensor as I need (wanted) to measure to 100k ft altitude and have a very small footprint. A bit off subject but here is my PCB to give you am idea of why a needed a tiny package... Sent from my GT-I9300 using Tapatalk
  3. Yup, been suggested lol My problem now is not how long it takes, but how much RAM the floating point math requires. During run time I can get away with comparing pressure with pre-set pressure target. However when the altimeter has detected landing, I want it to 'beep out' the max altitude, so I will need to calculate altitude at least once. This means the math function will still be there and still hogging all my space
  4. 0.2m may be unnecessary, but 0.5m would be nice. Its actually a bit inaccurate stating my accuracy/resolution as a distance, because the rate of change of pressure vs altitude changes as we go up, so it should really be expressed in mbar which is after all what we are measuring... The sensor has a resolution of 0.012mBar and an accuracy of +/- 1mbar.
  5. Potentially. However would that be smaller than the math library? We are talking 30000m max altitide with a resolution of .2-.5m (I forget which term to use lol). Accuracy is important so I wouldn't want it to be too linear. I understand the basic concept of lookup tables but I have never really looked into them (haha) so dont know the finer details. Im guessing this is where interpolation comes in? Sent from my GT-I9300 using Tapatalk
  6. That was the fixed point stuff posted above pressure to altitude is where I'm stuck MS5611 sensor Sent from my GT-I9300 using Tapatalk
  7. Ok, have managed to get my accelerometer math into fixed point which was pretty easy. //Calculate temperature compensated pressure. /* dT = temp reading - Tref temp = 2000 + dT * TEMPSENS / 2... Result is signed short (20.01deg = 2001 etc) OFF = POFF * 2^16 + (TCO*dT)/2...Result is signed 64bit(??) long long. SENS = PSENS * 2^15 + (TCS * dT)/2^8.....Again, 64bit result P = (ADC Reading * SENS / 2^21 - OFF)/2^15 */ pDT = bar[0] - Tref * 0x100; pTEMP = 2000 + pDT * TEMPSENS / 0x1000000; pOFF = OFF * 0x10000
  8. Thanks! Ill take a look! Does the fact that the math routines have a 'do not optimise' flag mean anything? Thats what the compiler is saying and im not sure the effect its having Sent from my GT-I9300 using Tapatalk
  9. Hi Enl, I am using MSP430_math.h which is, I believe, MSPMATHLIB? Making that math all 1 line doesnt change anything unfortunately. I have to reduce the buffer to 444bytes to fit it in, but that takes it right to 1024bytes RAM... Using Whole program optimisation for size has a negligible effect. Im sure most of this could be done in fixed point, and I will only ever need 8 decimal places, but I have no idea where to start with fixed point... EDIT : Ill start by reading this http://www.ti.com/lit/an/slaa329/slaa329.pdf Edit 2: Plenty of good stuff on Wikipedia t
  10. Ok looks like I do have a problem :/ When I add anything that needs the math library (either msp430_math.h or just math.h) my program wont fit in RAM. I have a 0.4second circular buffer which is 736 bytes, which if I reduce for 368 bytes allows me to fit everything in. Trouble is 0.2 second is hardly enough time as I need to store the 0.4 seconds of data prior to launch detection (which is delayed by a smidgen to prevent false detection). Also, the math library takes my FRAM usage from 2700bytes to 14438bytes! Nearly full! This is all just with the addition of palt = pseal
  11. Fred & Enl. I completely agree, I always start a program with the idea in mind that it has to make sense for someone else to read it. I asked about optimising because I like to learn all I can about whatever i'm doing to enable me to make smart choices. This was an educational thread, not one which is currently critical to my project. As it is, I have already applied some of the suggestions to some non-math code in my interrupts to keep them as fast as possible And they were a bit convoluted... Fred, not that it is too important in the scheme of things, but I need to do all the
  12. Ok I was thinking about what Enl said about pre-computing stuff. Pressure target for altitude is easy. I can do this on the pad at any frequency, say 1Hz, and stop after say 30 seconds to allow everything to stabilise and average out. altitude = user altitude target p0 = sea level pressure (changes depending on the weather) T = temperature at sea level (changes depending on the weather) L = lapse rate (Can be determined based on use configured altitude target and 4 'if else' ^ = to the power of, not XOR p = p0 * (1- (L*altitude/T)) ^ (0.2840437/8.31447*L) In flight I still
  13. Hi Enl, I have some algorithims which check if altitude is over a certain value, which is configured by the user. I also calculate velocity based on change in altitude and again, this velocity can be checked against a user setting. If altitude had a predictable relationship to pressure (i.e ADC value) I could convert those user altitude/velocity values into ADC/deltaADC before the flight (or even by the configuration program on a PC) and save alot of headache. Unfortunately, the altitude/pressure relationship changes depending on the atmospheric conditions at the time of launch,
  14. Hi, Thanks for the info, I have read that in detail over the last few months and will tackle Kalman filtering once I have this thing working without it first. Seeing as this is my first time using an MSP device I want to keep it as simple as possible to start with
  15. Interesting. Would this work with : Result = ADC * 0.049? and also P0 = 9085466 (max 16777216) ADC = something similar P0 (max 16777216) Result = P0 / ADC This is the first part of the pressure to altitude calculation with data from a 24bit barometer Well I think it is, trying to get my head around the hypsometric equations, as I want it to take into account lapse rate for altitudes over 11km and most equations stop there.
  16. Thanks guys, very helpful. I forgot to ask, is the dynamic range of single precision FP enough to hold a result which might range from -1500.00 up to 30000.00? Im having a bit of trouble understanding the pages ive been reading to learn about FP. For most of my results they only need 1 position before the decimal point, and max 8 after the DP, but I have a few with larger ranges. Fortunatly, I need fewer DP with those.
  17. Hi All, Hope no-one minds me bombarding the forums with these n00b questions I am writing the math for my rocket altimeter project and have some questions regarding the best way to do it. Im using CCS and MSP430FR5739 which has hardware multiply, and I have included the MSP430_math routines Lets say I need to perform the following equation (as an example) P = (D1 * SENS / 2 - OFF) / 2 D1 = unsigned long SENSE = signed long OFF = signed long Obvious optimisations aside (e.g. D1 / 2 before the FP mult to save an FP div...), would it give me faster code to break it into p
  18. Thanks for all that! I will read the link you provided. I dont think im pushing the memory that much. I dont know how to check how big the compiled program will be? EDIT: Found out Using 1950bytes of FRAM, and 952bytes RAM. So ive only used 12% of max FRAM which is good. I would say i've typed 60%-70% of the logic, but havent put any math into it yet (which will use MSP430_math library). Should have enough for that library though. The big thing which gave me memory errors was a buffer which I want to make 1840 bytes...until I realised this would be in RAM which is only 1k Bytes
  19. Hi Enl, Thanks for taking a look. i2c_start simply sets up the USCI module depending on whether im writing, reading or writing with a repeat start before reading. Should be fairly fast as there is 1 short if statment and a handful of direct register access'. void i2c_start(int addr, char cmd_type, int num_bytes) { //Configure command_type = cmd_type; UCB0CTLW0 |= UCSWRST; // put eUSCI_B in reset state UCB0TBCNT = num_bytes; // automatic stop after x bytes UCB0CTLW0 &= ~UCSWRST; // eUSCI_B in operational state UCB0I2CSA = addr; // address of slave without r/w bit if (cmd_t
  20. Thanks, I think that makes sense. The functions being called are what I would consider short, but having no previous experience with MSP, it would be good to have your opinion. The following is used once within the interrupt, so I will move this inline. int increment(int value, int max) { value++; if (value == max) { value = 0; } return value; } and used 9 times (i just realised this is a bad implementation of increment, so I will re-write and inline it too void i2c_add_to_queue(char cmd) { i2c_queue[i2c_queue_write] = cmd; i2c_queue_write++; if(!(i2c_queue_write < QUEUE_
  21. Hi All, I'm probably getting these due to my inexperience with C, but here goes... Im getting the following remarks and errors during compilation. "../main.c", line 321: remark #1538-D: (ULP 10.1) ISR i2c_send_complete calls function incr. Recommend moving function call away from ISR, or inlining the function, or using pragmas I use this function to increment a pointer, and it is used mutiple times within the ISR so I dont really want to put it inline as it will take up a whole lot more code space...is this a code breaker? If it is, how do I use pragma? Im getting this with ot
  22. Oh look at that! Thanks!
  23. Oh thats something I didnt think of. Does the USCI module add the read/write bit to the end of the slave address? I assume it does, because the address is refered to as 7 bits, not 8. Thought i'd check because I cant change the address before the repeat start without resetting everything...
  • Create New...