drkm

Like others have said the peripherals is what makes the C28x series a beast. If you have spent any time designing digital power supplies the peripherals make all the difference in the world. The newer dsPICE series are getting better (70MIPS and 12bit DAC, improved ADC, ect) but you cant beat performing the control calculation in ~10 instructions. Not to mention the floating point makes implementation 1000x easier. Its niche is in high performance digital control, something that hobbiest or consumer applications don't really get into all that much.

Unfortunately I work in the 175C range and it limits the available electronics even more then 125C. Microchips high temp selection (with some caveats) work well at and above 150C. The only offering for the 175&200C range is are the 32bit CPUs and dsps, and cost around 400$ per ic. Power pigs to say the least. All of us in the high temp realm are waiting patiently for an ARM cortex to become available.

I have mixed feelings about the PIC24. (I should preamble this by mentioning I do high temperature electronics and use the high temp selection of ICs which are all quite old with respect to the most recent micros available...) I like peripheral options that are available on the PIC24 and PIC33/DSPIC, they seem to really have the actual application level in mind when they set them up. Programming in C is quite simple. The huge amounts of RAM and flash are nice to work with too. Another positive is the re-map-able I/O, the I/O and the peripherals are multiplexed. The ADC is quite fast and

While again not low power, you could use RS-485 to accomplish what you want. But you would need to set up the protocol handling yourself. A reasonably low power (and low speed) option is to invert the output of a regular UART and run it on a single wire using a tri-state driver. This will consume very little power and allow you to do multiple drops (since you would use the gate of a fet to trigger the reciever). But again you would need to impliment a master-slave protocol if you want to be passing information both ways. I don't have much experience with CAN, from what I understand i

When a GPIO in an input state the input is high impedance. Meaning that there is a large resistance between the any voltage that could be present on the pin and the GND/0V. Since V=IR, if R is high then we can guarantee that the current will be low. Pulling the pin low with a pull down resistor provides a path to ground (while maintaining a large input impedance) that any stray EMI from say an ossilator or power supply. When a GPIO is set to an output it is either sinking or sourcing current. Meaning that if you were to pull the line low you are allowing the current path to go through

Also remember if you are using the onboard serial USB->Serial convertor on the board that it limits the board rate to 9600. You will have to use jumpers to get speeds higher than 9600. You may also run into difficulties with missed packets if you are using a polling method to transmit data. Remember that at 9600 baud you a character takes ~1ms to transmit. I found that if you are using 9600 baud you will need the DCO to be ~12Mhz to avoid losing packets. If you were to implement the receive and transmit (even just the transmit) through the DMA I am sure it would go alot smoother/less

For some reason I can not download the family guide for the any datasheets at the moment (the TI web site is acting funny?). The UART RX lines generally are a high impedance input that rely on the Transmitter to pull the line high. (I can not remember if it is the case on the MSP that you are dealing with). Regarding unused pins, or pins going out to headers that will be used in the future. It is best to have the GPIO set to high impedance AKA: an input. Pulling down the lines will ensure that no transients cause any strange issues. Regarding the pins that are used, you are takin

I am super excited for this! I hate writing fixed point maths, it takes forever to debug and test. Where did you see the benchmark code?

Nice job!

I heard about this a few weeks ago from our AVNET sales guy. Its super exciting! Apparently the automotive guys are going nuts over it since they can now get high resolution data with simple/cheap components without having to worry about hi-temp components. Think ABS, brake sensors, sensors closer to the combustion chamber, ect. Even for motor control/robotics applications this is huge, especially the resolution you get out of this thing!

I am not sure that the MSP would be the ideal candidate for this project. Simply due to the floating point calculations and the tracking algorithms. Look at the C2000 or the Stellaris M4. I can not comment on the M4, but the F28069-piccolo is a control beast. The CLA (control law Accelerator) makes processing data much faster/easier since it acts as a second core to do computations. As for the MSP, I am sure that it could be done fixed point style, but for the effort involved go with something that has an onboard floating point multiplier.

When I first started to learn Fortran, I was always reminded to leave the complexity in the structures. Now after using OOP lanuages (C#) I have a much better understanding of this. Its pretty cool the stuff you can do with data structures to simplify design.

Awesome Stuff Zeke, Did you ever get around to using the QM modeling software? I just got the Miro Samek book and am starting to go through it. I have been working on larger and larger projects and my nested states are getting a little over whelming. When I start using the QM tool I will post here my results.

When I am having trouble viewing variables, either make them static and put the break point locally or make the variables global.

I love the m3, but I have to use the C28x line for speed. I was really excited about the LM4F (with floating point accelerorator!!!) Now go and check attached image. Prepare for mind explosions...