I'm using this in a temp control app (not motor control) and running off

battery power.

MSP430 MSP430 from TI looks good...so does the PIC16F1823-I/P PIC16F1823-I/P from Microchip.

But the PIC16F1823-I/P PIC16F1823-I/P has a full H-bridge output...MSP430 has PWM but not 4

lines.

I can still prog the MSP430 MSP430 to do what I want, but its cumbersome.

Frank

Hey Paul,

I am starting out with Embedded "stuff" and I had a question. What's the deal with the various manfuactuers in terms of the chips? I want to design something that uses an ARM7 or above and I see that you can get the processor chip from Atmel, Philips, Samsung, etc.

What motiviates a circuit designer to use one brand over another?

Also, we would like to work in the .net MF environment. If you know of any procs that have a ported .mf framework, any insight would be appreciated. I looked at the other IDEs and don't really want to use assembly or an Embedded brand derivative of C for development. After like 8 languages, it gets crazy to go after more if you know what I mean.

Many Thanks!

Ed

You don't really give enough detail about the kind of work you plan to make any but the most general advice possible. Embedded covers everything from very simple (like a relay timer with 2 logic level inputs and 2 outputs) to very complex (like a network router or a Satnav).

If you come back with a bit more detail I'll try to help.

Regardless of the size of the job I would think very carefully about the .Net Micro Framework. I think it would be fair to say that this has not been the succes that MS hoped it would be (and they have "open sourced" it). There are very few ports and it looks far too resource hungry for simple applications. For applications which are more like an embedded PC I think you would probably be better off with WinCe (or Windows Embedded Compact 7 as we are meant to call it ) which would allow you to stick with Visual Studio type development tools and keep you in the mainstream of the MS eco system.

The good news (if you go that way) is that modern (Cortex) ARM micros are programmed in standard C and the use of assembler is not required.

Michael Kellett

In my case, we buy a product manufactured by others and programmed by others per our spec. The device uses an ARM5 processor. We wanted to refresh and change a bunch of different things to "do it ourselves". So, on the surface, anything greater than an ARM5 in terms of feature-set, speed, etc. is better.

Other than using ther standard IO (Analogs & Digitals; I need 12 analog inputs and 8 digital inputs with 8 digital outputs), we need to have ethernet (10/100) and at least one serial port. There is no external display requirement so we won't have to worry about that.

Ultimately, think of the application as one where we are using a serial port to read/control the analogs and digitals of the proc and an ethernet port that allows the same along with a CLI and a small web server. There is more in terms of whats connecting to the analogs and digitals but until I can get this going, that part of the concept is moot. I can verify the values with a meter on the output and short the digitals to test the inputs.

I get what you are saying about the .net CF. I see that it tends to take up a lot of overhead. My concern with going with a standard C implementation is everything has to be created from scratch. For instance, if I want a simple web server, I would have to decode the HTML and then respond back per HTML standards. With a .net implementation, it can handle the actual back and forth syntax for me.

Are there C libraries available that handle that type of stuff that you know of?

Also, if we went that route, what IDE would be used for Standard C?

If we went with a WinCe implementation, does that require Microsoft licensing?

Sorry for all the questions but I am trying to rapidly wrap my head around this.

Thanks so much!

Ed

@Paul,

The .net, for me, is because I already use about 6 programming languages daily. Adding one more has implications in terms of cost of the IDE, ramp up time in terms of using the IDE and the associated language requried, etc.

I have explained the choice of ARM above; in short it's because of what's in our product already. Also, from what I have seen, it's the "in fashion" proc. Having said that, since I am just starting out, I want a proc that I can scale up or down as needed.

I read your article (thanks for the link) and I agree that I don't want to go overboard on the proc if I don't need to. However, in my opinion, there are other factors than just what you are trying to physically do with the proc. For instance, if you create a design using a proc that totally fit your requirement but was in high demand and not easily available vs. one that was a bit more than you need and readlily available (at a small price difference), you may go with that, right?