Entering the embedded world... help?

Why does _everyone_ ask that. There's gazillions to choose from.

You may be better driving your PWM outputs from a processor that has PWM hardware. Are you driving SCRs directly (i.e. do you need to synchronize with the power line) or are you just PWMing for DC?

For tones you can either use the PWM outputs or you could drive a DAC (to get nicer tones). Either way you're not going to get much complexity from 2000Hz.

Almost anything compiled will run faster than almost anything interpreted. You'll have to run benchmarks to make sure, though. If you use an ANSI compliant compiler you're guaranteed a 32 bit integer by using 'long int'.

You can get drivers to go on your output pins if you choose a processor with wimpy drive electronics.

Most everyone uses C or C++ these days.

I would suggest that you get a processor board then, and just breadboard your peripheral stuff.

Greedy.

Subscribe to Circuit Cellar magazine.

Consider using a PC-104 stack -- the hardware is more expensive but it'll look just like a PC to your tools. You can choose to run DOS, Linux or (ick Windows).

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

As Tim pointed out there are a lot of good MCU's. What I suggest is to pick up datasheets and read them and then decide. This way you can find the MCU that shines where you need it to shine in your application.

If this is the case, you may be limitied to a 32-bit MCU (ARM). These are fairly cheap and by the looks of it may be the best choice.

If I recall correctly PIC's can sink or souce close to 25mA on each pin. Definitely more than the Javelin you posted.

code in assembly as a learning experience. You do gain an insight and gain more respect for the work that compilers do.

If you are using 7805 or 7812 and a decent supply of AC bypass caps I believe most of them can supply up to 1A of current (of course if you hit this, you will need cooling for sure). Of course you won't need to use active only passive cooling (heatsinks). If you need more than that, then you will need pretty BIG heatsinks.

You paid that much for an MCU?! $89 is a lot of dough, you can buy like

20 PIC's and low end ARM's using single unit prices with that cash. Heck, I can buy myself a PSP game for that price :)

Books are a good help, but I prefer to learn by experimentation. I believe you learn a lot more this way. Grab a devkit for the PIC/ARM or whatever MCU your using and code away.

As a side note, if you have a gameboy advance and a flash cart you can use that to program the GBA's CPU (ARM7TDMI at 16.777Mhz). That is what I have and plan to use it to experiment more with ARM chips.

I ask because there's a gazillion of them, and I'm ignorant. The Javelin looked good to me, until I ran out of both speed and pins. So I ended up with 2, and a fiddly protocol between them, and sucking more power than I expected, which made things unstable, so I ended up with a PC's power supply just to keep things happy... I made a bad choice at the outset and it cost me days of work and plenty of dolalrs. Ignorance is expensive.

(to get nicer tones). Either way you're not going to get much complexity from 2000Hz.

My needs are minimal, and it'll be better than the current 555's, whose options are beep or silent. Given my desire to minimise external components (I'm a software guy: I loathe hardware), I'm willing to keep to simple tones, to keep the external part trivial (a ULN2003 driving a speaker is what I use now).

your peripheral stuff.

Sounds good. What's a clever choice? I'll look at the PC-104, but I was having trouble finding ethernet support and multiple serial ports for cheap...

Maybe take a look at the Rabbit family - they have ethernet and upto about 6 serial ports, IIRC. And they're cheap, as are the dev tools.

(This is my second plug for Rabbits recently. I have no connection other than as a happy customer.)

Re interfacing etc: *the* book to get is Horowitz and Hill, "The Art of Electronics". Indispensable, and a very approachable primer for a code-monkey ;).

Steve

Yea, "cheap" and "PC-104" don't go together real well. That's part of the reason I was suggesting Circuit Cellar -- for the ads in the back. I have yet to use anyone's pre-made processor board; everything I do somehow ends up being full-custom. For processors it's easy: once you choose 8/16/32 bit you've narrowed it down to 5 manufacturers or so, then you start looking at speed, tools and on-board peripherals.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

Look at the SiliconLabs C8051F330 : Comes in DIP, and with Tools and a OnChip Debugger. Chain them up on the SPI bus, as you need more smarts...

You can also get their USB ToolStick, just ~$10 to see if you like their tools and peripherals.

-jg

-snip-

"The Art of Designing Embedded Systems" by Ganssle --

I haven't even touched the book, but I read Ganssle's columns all the time in Embedded Systems Programming. If you have been doing software in an IT context then you need to shift gears somewhat to program for embedded systems.

Oh -- and subscribe to Embedded Systems Development (or whatever they're calling themselves now). At least check their website once a month -- their subscription department is _weird_; it can be hard to get copy from them.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

Gosh! There is at least one other sane person out there. I think another point is that it seems like the power-point people assume that a RTOS is mandatory, regardless of system requirements.

------------------------------ H. Stuart Brooks Fredericksburg VA

Have you thought about implementing some of this in an FPGA/CPLD?

The rs232 ports, IO, PWM and tone generation are almost trivial to implement (when you know what you're doing). The most difficult bit could be designing and implementing the control interface from whatever uC you decide to use. Something like a simple SPI interface would be easy to do.

Just food for thought.

Nial

ports, IO, PWM and tone generation are almost trivial to implement (when you know what you're doing).

Hrm. I don't think I want to implement RS232 in software. I expect I could, but I'm really looking for a small cheap board with ethernet and serial ports already in place, and a nice little TCP/IP stack on board. Writing my own TCP/IP, in particular, is no fun at all.

There's a fair amount of logical state in what the room controller does. It's intergrating inputs from phone, doorbell, water sensor, touch sensors, 2 motion sensors, door and window sensors, a complicated stereo protocol over RS232, and taking complex commands from ethernet. It's generating 4 channels of 0-10v for dimming lights, controlling the stereo (which has a lot of states and modes and rules), tones, and a bunch of on/off devices like amps and LEDs. It handles things like "If the room is in Movie mode, AND someone opens the door, then bring up the back lights so they can find their seat, then fade back down". "If playing music, and doorbell is pushed, mute music, play doorbell tones, blink LEDs, resume music." The cases sound simple individually, but having the responses and reactions all interruptable and adjustable on the fly in realtime, amounts to a good sized state machine.

As a software engineer, I'll put in a plug for OO languages. State machines like that are a lot nicer when you have an OO language. Though I personally DON'T like Java, because of the overhead it imposes, but it did make the state management a lot simpler. I could have done it in C, but the code would have been that much more obscure, and having things to be trivial to modify (as I change gear) is very important to me.

C++, despite some of what I read here, is better than C for just about anything where perfofrmance matters. The key with C++ is not to use it stupidly (which is easy to do and frequently done.) Used with an eye towards efficiency (ie, no STL, no misuse of new/delete, leave the string classes alone, use well designed classes with a minimum of virtual declarations), it produces better code than C compilers, because C++ demands fully specified interface, so it can optimize more intelligently than C.

Maybe that's not true in the embedded world - no idea how good the tools are in this space. But I have every hope of wriring in C++. If I can't find good tools, I can always cfront it down to C, and compile that.

Unfortunately, I've seen a lot of stupid C++ - but then I've seen C which is absolutely obscene. As someone who writes VMs and optimizing compilers as fun projects, there is a LOT I can say about using C++ right, where Java went wrong, and where C could have been a little bit better. :-)

I meant using an FPGA/CPLD to implement the PWM and enable you to handle a much larger number of IOs than with a stand alone uC. Uart cores can easily be implemented (there are free ones about) if you don't have enough in your chosen uC, as you say the TCP/IP implementation is best left to the software.

An Altera EP1C6 in 240 QFP gives you about 170 pins to play with!

Nial.

I prefer OO *design* and a neutral language. I routinely write OO in C, and much prefer it to C++, which to my mind is flawed (private elements in a public class definition? wtf?). I also have seen far too many C++ projects flounder due, IMO, to over-reliance on language features and not enough on design. I feel I can do a better job of implementing the spirit of OO in C (neutral, limited semantics) than I can in C++.

In theory, I take your point. In practice, not so sure.

They're getting better, for sure. It's far more common now to use C in embedded projects; years back we simply couldn't afford the overhead vs assembler. And it's not just that hardware resources (RAM etc) are cheaper - the venerable 8051 still sees a lot of use, and probably most 8051 code (I'm guessing) is written in C these days.

It's not just the tools, though, it's the understanding (as you indicate) of what's actually going on under the hood. The main thing about embedded work is that It Must Not Fail At Runtime. This often means no heap, and a healthy distrust of runtime language features (garbage collection, late binding etc etc). There's a mindset involved in writing code such that it's robust *by design* and simply can't generate runtime errors - one can write bad code in any language. My experience has been that C++ does not per se promote good code - it tends to promote obfuscation due to confusion over whether "data hiding" means "lack of side effects" (as it should) or "where the **** is this member variable defined and used??" ;). My (strongly-held) view: the clearer the code, the more likely it'll be bug-free.

Yup ;).Fairly recently I had to maintain someone else's code. This guy was held in high respect - mainly, it seems, because no-one else could understand his code. His main() function had 1435 lines and 30-odd gotos. Good going, chap. (I scrapped it and started over.)

Steve