enl

@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 t

Could you be a bit more specific? Do you mean the maximum A/D sampling freq as given by @@yosh? Or do you mean something else, like the actual sampling frequency in an application?

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

@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

(please excuse crummy typing. Cat on lap takes one hand as he has paws wrapped around it) Last thing first: It is the same. If n is a const, then it really doesn't matter... the compiler will precompute what it can. In a case like this, I use #define for the constant, but a const variable should generally work the same: compiler precomputes where it can, and only makes var if it needs to, such as if you make a pointer to it. Note that to do exponentiation, you need to call a (slow) function. The ^ is exclusive-or. The underlying function uses log and antilog. If you have a fixed power, y

@Druzyek: Have fun with the epoxy. Keys are clean, tooth, and proper mix. Light scuff both parts where attachment to occur, clean -- denatured alcohol is good preclean for most epoxies -- then work proper mix epoxy onto both surfaces with applicator stick before joining to insure good coverage. If mix is off, strength is off. Copper side will regrow oxide very quickly that will inhibit bond. Scuff, clean, bond one after the other. No rush, but a few minutes is best time frame. Don't forget to build a small fillet around the bolt head. More surface area and out of plane both improve strength (

It is generally best, absent other information, determine whether inlining is worth it. The appropriate optimization settings will tell the compiler what you want, based on size vs. speed considerations, and it will do what is needed. Often, inlining leads to further optimization. Back in the day, it was common to write even fairly complex functions as #define macros for this reason.... a good compiler will optimize out the irrelevant, and optimize what isn't in the context of where it is used, rather than doing a best compromise on its own. Long functions, with multiple calls, tend to do

I wouldn't worry about that, then, timewise, if there is no critical timing on the interrupt otherwise. I'm not sure the pragma FUNC_CANNOT_INLINE will eliminate warning (and I am too lazy to set up a test right now... gotta get exams graded), but the warnings are just that: warnings. The intent is that you take a good hard look at what you are doing and determine if it is an issue. Don;t ignire warnings, but a warning doesn't mean things won't work. Only that what you have is a place where a problem MAY occur.

@dubnet: Calculus if fun! Algebra if the pain. Hardest part by far.

First two are definite inline. The calls may take as much or more space than the function will inlined and optimized. Certainly not a significant loss in the worst case. The switch is a different matter. No issues using it in an interrupt (in my opinion) as switch is fast, but there is likely an interest in keeping it all in one place if it is called from elsewhere, and it is getting to a size where inlining is going to grow your code significantly. My key concern here would be the call in the switch cases to i2c_start(). Does this take time? can it stall? Interrupts are blocked when t

Grading papers and having a beer (or, more accurately, distracting myself from grading papers. Students are doing pretty good, but decoding vector calculus proofs takes a mental toll...) Oh, in general.... Working on an articulated tail, neck, and head. Too many servos! If I ever get anywhere with it, I will post. Right now, still mocking up test system. I can't wait for next haloween......

This warning comes about because it is generally (but not always) bad practice to call a function from within an interrupt handler. Interrupt handlers should generally be as short as possible and as fast as possible. The function call overhead can slow things down, increasing response time to other interrupts, and add to the stack burden, which is a significant thing when you have limited memory or time critical response. I would ask if you are sure that inlining it (or replacing the function with a #define macro) would increase code size. Incrementing a pointer isn't a big deal. Functi

1) encoders are the easiest way to go, but are not strictly needed. They can be free, if you know where to look. An old printer, floppy disk drive, ball-type mouse, or any of a large selection of other devices is a good source for a LED-phototransistor pair, and the encoder wheel can be made from pretty much any opaque material that you can cut round and put a few holes or slots into and mount to the motor or wheel shaft.2 2) Yes, if you have a bluetooth com device available for your controller on the robot, but this is a "if you have to ask, probably not" type question in regard to YOUR

What type of hall sensor? --- If it is a switch type (output is active if there is a field of the appropriate orientation): tie the output of the sensor to an input that can trigger an interrupt. Have a counter (global) that the interrupt routine increments or decrements (as appropriate based on direction) each time the interrupt is triggered. If the sensor needs to have a response, respond in the interrupt handler. The counter will need to be declared as volatile, and can be read anywhere in the code as a position. ---- If it is analog output, tie it to a comparator input and use

As @@spirilis said, a quirk of the architecture. It is actually a good feature, as it greatly simplifies the memory hardware. If it were not for this, then either two memory accesses would be needed to access a 16bit word (like in the8085, Z80, etc) with a bit more logic to handle it, or a LOT more real estate would be needed for memory access logic, taking away space for other options and reducing the manufacturing yield, raising cost for the device.

As mentioned in previous thread, you need to ramp up the step rate. The initial step rate that you can get away with goes down as the inertia of the load goes up. The maximum step rate goes down as the friction loss goes up. Warning: Gross oversimplification to follow: For example, the bare motor will probably go faster than you have it now by reducing the delay a little at a time, but, with no load, it isn't likely to go a lot faster. The unloaded rate is limited by the inductance of the coils, which limits the rate of change of the current -- ie: the maximum switching speed -- and fr

Unless I need to, I NEVER use a float. I would store the raw data and process it after pulling it from the MSP430. If you can trim the raw data to a byte rather than a 16-bit word, more space is available, as well. If you use float, you will have space for 48 readings (or 64 if you lose the factory calibration data). This is less than the 5 min you want, so is a bad move. When you pull the data from the device, then convert to actual voltage readings. If you are certain about the range you need, and you don't need other features of the INA219 than voltage (I was figuring that you might als

Flash will be retained after power down. You will also want to build in to you software the ability to read the flash data later. Simplest way is send it via serial. I might structure things this way: Initialize (clear) flash triggered by a pushbutton on one input. I would halt after this, so as to require reset before collecting data. This allows clear at the bench and autostartup in the field. Default to monitoring on power up. Insure that the clear value can never be a valid data written to the flash (not a big deal.. the ina219 is 12 bit. you can easily insure that at least one

Another question on the thought you may have a common ground through the power supply connections, even if not directly from the LP board): Are you driving the pins in the correct sequence? Start with one at a time at maybe 2 changes per sec. A, B, a, b (or A, B, A', B'... or 1A, 2A, 1B, 2B... However the phases are labeled for this motor) Only one on at a time. This should give slow rotation.

Second that it appears the common ground is missing. The driver is suitable for 500mA. That motor phases probably don't take that much. Measure the DC resistance of a winding. Should be about 50ohms, for a per-phase current of 100mA. Will likely be lower than this, as the ULN1003 has some voltage drop across it. Also note that the max step speed is about 100 steps/sec, and you can't just go there. Need to ramp up speed, and ramp down to avoid losing positioning when stopping.

The ^(1/5.2....) has a couple options that I might consider: Lookup table with interpolation (pretty good speed, accuracy ok) Expand a Taylor series for it, optimize the series, and evaluate using Horners method (might be a bit time consuming on MSP430, but, then again, we used to do this kind of stuff on 1MHz 8080 for real time work) Store raw data and decode on the ground. If actual measures are needed in the air, and you know what they are, pre-compute the raw data value so you can compare simply

Def worth taking time over. It is a lot of money, unless you have elephant VC $$$ to blow. You need to identify what YOU need. It probably isn't the same as what I need. I am happy with the 2000 series Rigol so far, and don't anticipate needing to buy another scope for a good number of years. After all, my old one was over 50 years old, analog, nominal 500KHz, and it has done a LOT of work including debugging 10base2networks, which was way out of the spec for the scope. But I also use a low end 16channel logic probe plugin for the computer when needed (unbranded. I thing I got it from Jameco?

@@Fred I just popped the $$$ for the 2000 series Rigol analog only. For many things, you don't need the full logic analyser. But I looked very hard at the 1052D. Very hard. I thought about my needs, desires, and what I currently have on hand. Then I went for the 2000series without logic. My needs are not the same as yours. Some questions to ask are: How many channels of logic are you likely to need? Do you need the ability to trigger on complex logic signals or do boolean operations for triggering? Do you need a deep memory for logic monitoring? Do you have a need for analog? For me,

If the edges are rounded, and the solder comes to, but not over, the top edge, there is mechanical grip and they will hold. Soldering into a well helps with this. I have had the sam eexperience soldering to a surface.... the plating cracks off eventually

one resistor and cap will cover all 3. They may not reset at exactly the same time due to differing thresholds on the reset lines.