Beginner needs help choosing microcontroller platform & software

A very good point and good points made in the post you link to. But I'm not claiming a $5 MC is equivalent to a $79 Stamp. I'm saying when I accidentally ground a pin and fry the MC I only need replace a $5 part instead of a $79 part.

Rather than complain of newbies' ignorance I think it would be much better to keep a positive attitude and sell the added value that bridges the gap between $5 and $99. You sort of do that, but it is encapsulated in so much frustration and indignation one has to read between the lines to see that a good point is being made.

I don't have a parallel port, nor a parallel port cable. And I was told that programming an AVR (without a bootloader) needs a programmer cable, which is about $50. Can anyone clarify which is correct?

Thanks,

- Joe

,------------------------------------------------------------------. | Joseph J. Strout Check out the Mac Web Directory: | | snipped-for-privacy@strout.net

| `------------------------------------------------------------------'

All the programmer does is convert some serial or parallel stream provided by the PC, in some different stream respecting the timing constraints of the device being programmed. you can do that directly by twiddling the ports of the PC. see

guy has several programmers here is a mac-avr page do some googling.

If you are going to be hacking, use a motherboard and OS with hackability potential. You need a parallel port, it's the best way to tinker and control zillions of things with your computer, for really cheap. The replacement of the RS232 and parallel ports by USB ports is maybe great for manufacturers, but a shame for hobbyists, tinkerers and students.

Since you are a Mac user, and Mac OSX is basically FreeBSD, you might want to find some old 486 or pentium PC (certainly you can find one for free) and install BSD or linux on it. You can network it with your mac, use the PC as a universal programmer/controller, and do all your work on the Mac.

I personally use mostly FreeBSD, and windows when I have to. I have also a Mac OSX machine. I use the right tool for the problem at hand.

The fact is: for hackability, microcontroller and electronic hardware development, you have a lot more choice on BSD/Linux/Windows machines. Windows because that is what the manuacturer's tools run on. BSD/Linux because people interested in that kind of stuff generally run Open Source systems. Macs ? don't get me wrong, but macs are still geared toward the hip and stylish designer-types, not the engineering types. OSX is somewhat changing that though.

If you want to exclusively use a Mac, it is going to be a lot harder merely by the fact that there are few people out there doing that stuff on a Mac.

bruno

PS: did you ever get my email about the OWI arm ?

Joe Strout wrote:

What is the problem you are trying to solve ? If you detail it, we can figure out how powerful a uC you will need... BTW, software people tend to choose a uC way overpowered for the task. Hardware people do the opposite :-)

For example, with an atmel atmega8535, I am doing motion control with unipolar stepper motors along 3 axis (could do more if there were more IO pins...) with linear and circular interpolation, a bunch of limit switches, an interpreter to parse commands and return current information through the serial port.

bruno

MrMJPEG wrote:

[...]

You don't need a parallel port. If your computer doesn't have serial (RS422) ports, you'll need a USB to serial converter. I can recommend the Keyspan devices, that have been working marvellously well for me.

You'll also need Atmel's AVRISP programmer, which probably is the "cable" that is referred to above. (You can build a programmer yourself, but then Catch 22 strikes: You'll need a programmer to program the programmer...)

I'd recommend that you install the AVR GCC stuff via Fink, , because that way you'll get it updated more or less (your choice) automatically. You can read more about the programming environment here: and here: .

Myself, I also use the AVRA assembler, that can be found here: . It compiled "as is" under Fink.

Good luck! /Bjarne.

bruno said

Cool! I don't suppose you have a website showing how you did it?

What's "circular interpolation"? Interpolating based on degrees (orientation), rather than position?

Also, how are you able to do this with ONE uC? Conventional wisdom appears to be you need one uC per axis. Are the limit switches for defining a home position? Is a mechanical switch accurate enough?

Thanks. I'm glad you see it. Hopefully, then, I'm not wasting my time.

Actually, I would. The $5 MC and a $79 Stamp are rather equivalent (if you ignore the value added of the additional parts and assembly) because they have the same "class" of processor.

And in the case of motion control, you're probably better off with a $5 AVR than you are with a $79 Stamp (by which I assume you are refering to a Parallax Basic Stamp). The AVR is a ~1995 designed processor, and the PIC in the stamp is a ~1990 designed processor. While the stamp offers a much easier to access mechanical package, and the ease of Basic, you won't likely get the job done in Basic, and so is much less convenient than using an AVR with C.

I can see that point. It is not unusual for beginners to fry a processor or two. Much more likely though, if they use a chip than a board. With a board, the power and ground are usually already wired and protected. So you'll fry many more $5 processors than $xx boards. But it does still happen.

BTW, you are not likely to cause problems for a micro by grounding a pin. They are generally pretty tolerant of an accidental grounding, and will run indefinitely that way, and still recover. They are slightly less tolerant of the application of +5 (some +3)accidentally, but almost always survive short duration shorts.

However, applying a mildly negative voltage (more than -0.7V), or a moderately high voltage (typically over +7V) will toast almost all micros, board mounted or otherwise. This is very common with motion control projects with higher voltages present.

Well, I threw my first reply out, and restarted, and then did extensive rewrite, before sending. Okay, I'll try again a bit further on.

Yes, I have a great deal of frustration. Maybe even indignation, although I tried not to direct it at you. But I am frustrated. As you can see, it's a pet peeve of mine. When I saw Gordon tell you, you might be able to get this done with a DSP, and I saw blueeyedpop tell you you could do it with an PlugaPod(TM), I figured I would stay out of it. But that $5 comment, and the IsoPod(TM) being MUCH more of an investment..., brought me out. I feel I need to set the record straight.

Let me try an analogy. Let's say, your neighbor on the right comes over and asks about lawn mowing. You start to say, well, you can get an incredibly good deal on a cheap lawn mower at "Lawn Depot" for $99. But your neighbor on the left says, My dad used to cut our lawn with scissors. Plus, if the scissors break, you're only spending $5 on a new pair.

Well, you think, it actually is possible to cut a lawn with scissors, but its just not a practical approach. You wonder if they understand the quality versus the effort it will take. Wonder if his time is worth anything to him? Wonder if the blisters he gets will be too painful? Wonder if it matters before he finishes the back, the front will need cutting again? Wonder if he has a job or a life that might interfere with his lawn mowing?

Next day, the neighbor behind you comes over and asks about cutting down a small oak. You're thinking maybe that Remington 16" electric on sale for $89 at "Tree Depot" is perfect for light duty tree trimming. The neighbors on the left and right jump in and say, hey they just got these scissors! They are cheap, and you can use them for anything that needs a sharp blade... Excitement builds...

There may be no listening to your opinion at that point. Maybe all you can do is suggest they don't run with their scissors.

After you'd heard the $5 scissors answer to everything from cutting tin to digging wells, about 100 times, how would you feel? Remember we get a "newbie" asking about processors here about once a month or more, and it's been going on for years and years...

What I think what you've heard me say, is, don't buy a $5 micro, buy a $99 board. You suggest I explain the value added by the board.

That isn't what I am saying.

I say, don't buy a $5 micro which isn't up to the task, but a more expensive micro that actually is. Not only is the advanced micro (generation later development ~2001 design) faster than the other processor (about 20X), it also has power hardware built in for motion control (like the engine on the mower or the chain saw - it adds the power to make the job practical).

Now these faster micros are fine pitch SMT parts. They don't come in through-hole packages that will fit on a breadboard. Beginners don't have much luck working with them. Your best move is to buy it assembled on a board, rather than a chip per sa.

So the right value is the processor on the board. It is completely wired, has a high level language installed that can get you there, but MOST importantly actually can do the job because it has hardware built into it.

Okay, for specifics, to prove my point:

How are you going to tell where the Pan, Tilt, Up, Down, etc. motors actually are? Common way is to use quadrature encoders. How fine does the resolution of the quadrature have to be? Well, for smooth video, pick a number, maybe 2000 counts per inch. Okay, how fast do the axes have to go maybe a foot or two a second? So just as a minimum guess, let's say 2000 counts per in. x 25 in. per second. So you need to read

50,000 quadrature counts a second. Or go open loop. Or have much slower movements. Or less resolution and jerky video.

How many quadrature decoders does an AVR have? None.

How many quadrature decoders does a stamp have? None.

So how do these processors do quadrature for motion control? They have to do it with software - processing power. Does that put a limit on how many quadrature inputs you can read? or how fast they can be read? Yes. For a beginner to do quadrature AND something else usually requires a multitasking system, or interrupt driven programing techniques. How fast can a stamp read a quadrature input in Basic? Oh, I don't know, but I'll estimate up to 200 counts a second. The processor would be pretty well used up there, and would have difficulty also communicating with a master, and there is no multitasking built-in. How fast can a AVR programmed by a beginner in C read a quadrature input? Another guess, maybe 20,000 times a second. (I've heard clever assembly language programmers claiming ~100,000 counts.) The processor would be pretty well used up there, and would have difficulty also communicating with a master.

Now, for comparison, how many quadrature decoders does the DSP on the IsoPod(TM) have? Well, two in completely dedicated hardware, but it also has 16 timers, and in pairs, these timers have a mode where they can read quadrature. So the short answer is the IsoPod(TM) has an easu 6 available hardware quadrature input channels (and still has a timers left over).

How fast can the IsoPod(TM) read these quadrature inputs? Since they are hardware, and they require no software support at all to do the counting, they can read quadrature up to 40,000,000 counts a second. 80 times faster than required!

So maybe my point is clear now. A clever AVR programmer can capture quadrature just fast enough to do your minimum requirements of 50,000 counts on one channel. (Not considering the communications, and PWM output to the motors, which are also competing software tasks.) On the other hand, a beginning programmer can read 6 channels of 40MHz quadrature on an IsoPod(TM) with very little trouble at all, just a handful of writes into setup registers (and has a dozen hardware PWM outputs to boot).

I hope you understand, I'm not talking about something as trivial as differences in brands of scissors. I'm talking about real differences in the hardware features, like the difference between scissors and power mowers/saws.

The fact this point is a hard sell, and takes great efforts to explain, is the source of my frustration. I wish I knew a better way to do it. But somehow the prevailing wisdom is the $5 micro is as good as anything out there for any job you care to name. It's a dangerous myth that prevents many projects from getting where they ought to be.

My limited experience has shown the GCC stuff is easier to get going under Linux than a Linux emulator on M$.

Debian provides a nice GUI sitting on top of XWindows, and it is free. I have recently repurposed a 600 mhz celeron laptop. W 64 mb ram, it is happy w/o the gui, w/128 mb ram, it is fune running the gui

I don't know what to say, Randy. First reaction is I wanted a Ginsu to cut an apple, not a food processor + mixer + espresso machine. But let's get beyond that. Let's also get beyond the need to count 2000 ticks per rev at

1500 rpm, as though I couldn't find an encoder with an index mark.

I've visited your site in the past, and I peeked at it again just now. I still haven't much of a clue why I would want an IsoPod. Sure, I like FORTH. Brodie was one of my early heroes (a full quarter century ago now). But what the heck is an IsoMAX? It's all cool stuff I'm sure, and probably useful to me this very moment if I took the time to look at it deeply enough. And that's the problem.

Your site is all backwards, Dude. I don't really care to know what an IsoPod is. I need a five axis controller with certain capabilities. We should both be pissed that I passed up a perfectly workable, debugged and packaged solution, and instead wired up a few jelly-bean PICs out of reflex. And it's your fault. How hard should I have to work to figure out you already solved my problem? What might compell me to hit that IsoPOD(TM) button when I'm looking for a 5-axis controller?

Regarding IsoMax... Jingo-ism scares me. I think you're selling me a Ginsu with a fancy instruction sheet. So far, I've gathered that it's a realtime scheduling system. Is it any better than the one I'm already using? I don't think I'll ever know.

Taking it all together, I'm a little uneasy. I'm clutching my wallet tightly, protectively, because the fancy man with the fancy named goods is not to be trusted. (It's not stamped sheet metal with a serrated edge; it's a Ginsu(TM).) Every day, we're all deluged with basically what amounts to junk that some guy is hawking to pay off his Volkswagen. And I don't know you from Adam. You can help me best by helping yourself. Fix that site. Tell me what your "stuff" can do for me, and why I might care.

I mentioned this to illustrate that it is indeed possible, not that it is easy :-) What you mean by "motion control" is what is going to define wether you can do it on a limited uC without too much effort, or if it would just be better (time saving) to use a more powerful uC.

In my case, motion control consisted in controlling several motors like this: they all start and stop at the same time, they all (can) run at different speeds. Imagine a robot with 6 degrees of freedom, where all motors have to run in unison so that all movements are smooth. That would be linear interpolation. One of the motors (the faster one) sets the pace and all others follow at a rate such that they will all stop together, no matter how big or small each motor movement is.

For the circular interpolation, I am basically coordinating two axes to draw a circle in any plane. This is all geared toward robotics and machine tools.

If you have different requirements, like motors not starting and stopping all together, setting acceleration curves, etc. you need a different approach obviously. Fastest is interrupt-based, either some sort of cooperative multitasking (or coroutines) or state machine. It is still possible to do that really fast. Well-written C can be as fast as assembly.

To put things in perspective, an atmega8535 at 16MHz hits 16Mips. It takes 8 clock cycles to get in and out of an interrupt routine. To take the example of some other poster on the thread, to manage a quadrature encoder you just need to catch an interrupt (some raising signal on a pin), check the state of the other quadrature signal, and increment or decrement the current count accordingly. So in assembler it would take about maybe 16 cycles. You could catch the quadrature signal up to... <

1MHz ! (and doing nothing else...). Adding tons of margin, saving time to actually do something useful, etc. and you realize that 10-20KHz quadrature is totally feasible. With a $6 uC that will need almost no external components.

Using a multi-tasking kernel might be fast enough too and will make development easier by keeping the logic of the program simpler. There is one, open-source, for the AVR that I hear is really good (I have not tried it yet, but the numbers and look good).

You can use mechanical limit switches, yes. For less noise and more precise home position, use photo-interrupters. A cheap source of those is discarded floppy disk drives. Actually old floppy disk drives (specially the 5" 1/4 type) are a great source of electromechanical components. You could prototype your whole project with one :-)

conventional wisdom also said that one would never need more than 640KB or RAM in a PC, or that nobody wants to run several programs at the same time :-)

bruno

Ok, true, integrating a PWM pulse gives you a varying signal, but I wouldn't use it to drive an amp for motion control...

Well, the Forth in IsoMax(TM) isn't the only way to go on our board. You can develop with the Small C we've provided just as well. Then there's always CodeWarrior. And of course, C came out a full quarter century ago, lest we loose perspective.

IsoMax(TM) is an operating system, in this case a set of words on top of Forth. It is a paradigm based on state maching concepts. So if you follow the paradigm, you can string almost unlimited unmbers of state machines together in a background, interrupt driven task provided by the language, and they will all cooperatively multitask. And you can still communicate in the foreground, dump memory, change settings, print results, even continue to develop additional code, as the processes run in the background.

Now the remarkable Pete Gray who posts here sometimes has actually taken the IsoMax(TM) concept of operating system, and transformed it into a C like language as well.

So IsoMax(TM) isn't a Forth only concept, but can be applied as an extension to other languages as well. The key to it, is the state machine approach to designing real time systems.

Well, the IsoPod(TM) isn't a five axis controller. I'd be a "Ginsu" salesman if I said it was.

But hold that thought a moment...

In order to protect my property rights, should someone try to copy the "xxxPod" names, I have to follow it with the (TM). If I don't take my trademark seriously, no on else will be required to either. I don't like typing that all the time either, not at all. But... If protecting my property rights seems slick or silly... to bad.

Now back to the pod stuff.

The IsoPod(TM) is a board with a processor, which is cross between a DSP and a general purpose controller designed for motion control. With the addition of software, it can be a six axes motion closed loop PID controller. (A version of the IsoMax(TM) language is with PID functions built in is in late testing. Then it really will be a 12+ channel PID controller, with software built-in.)

Or it can be a 26 RC Servo driver with _hardware_ generated PWM now. (If you did software RC Servo outputs like the SSR's do, you could easily do another 20 RC Servo outputs on the port pins.) We tried to show that off by driving the Lynxmotion 18 servo hexapods directly with smooth profiled motion, without any SSR's helping.

How did that go?

I don't know. I suppose that is why I participate on these groups, trying to get the word out. Apparently I'm not doing a good job of it.

I will look into your suggestions. Thank you. Actually, thank you very much.

Now I'm interested. :) It wasn't that hard, was it?

Done it before; will do it again. Unless someone has a better idea. ;)

hmm... I am not really following you. I am not talking about generating some continuous signal from a PWM. I meant interpolating in the sense that one stepper motor stepping rate derives from another one, thus one stepper "interpolates" the other stepper movement within it's own limits. Imagine you want to draw a line on an XY table, one stepper controls each axis. The stepper controlling the axis having the most movement is used as reference. For each step, a decision is made: do I step the other stepper or not ? You can scale this to any dimension, i.e. any number of steppers.

That is basically line drawing in a discontinuous manner, i.e. rasterizing. Look up the Bresenham line rasterizing algorithm. To have complex movements, small patches of straight lines can be 'drawn' after each other.

In my project, I also handled circles directly because it is more efficient and there are better algorithms to do circles than approximation by straight line.

bruno

blueeyedp> Ok, true, integrating a PWM pulse gives you a varying signal, but I wouldn't

Hi

I too am only a lowly newbie. I am studying part-time for an Advanced Diploma in Electrotechnology. This year I did an introductory C programming course called Programming Fundamentals (next is Electrical Control C Programming, then Advanced Control Using C++). The course taught C extensively using an 8255 IO PPI (parallel port interface ) digital card (and also an analogue PPI card).

These can be used for things like reading a signal from light sensors, switches, controlling DC and stepper motors, LEDs, interfacing with a uC (microcontroller), controling relays, and others. I don't know what sort of speed you need, but for my major project I programmed a tethered Lego buggy (no uC) to follow a white line around a circuit that had some tight bends and it responed well. It used relays and light sensors to control the motors.

Although I haven't done it myself, would interfacing an 8255 PPI card to a uC work? I mean you have the processing power and larger memory resources of the PC to use. Even an old cheap or FREE PC with ISA and PCI ports would do. Surely one of the latest PICs or AVRs is pretty fast? Or even a DSP? FREE trial DSP compiler in BASIC and Pascal from:

You could probably get free PIC samples from:

I have gotten HEAPS of FREE samples from them. They also have a FREE student version of a C compiler for the 18 series PICs.

Yesterday I received two ARM7 32-bit uCs from Texas Instruments. They were FREE samples! I think they have 1MB of flash memory, 64kB of RAM, and operate around 60MHz or more. Mainframes in the 1960s/70s used 64k of RAM! Surely with that grunt, scores of IO pins and a PC linked to an 8255IO card you could get some serious work done? TI bundles an evaluation kit with a limited (FREE) IAR compiler, and maybe there are others (gcc port?). The challenge is to make a PCB or prototype board and solder the ARM7.

I have even seen websites on how to make your own 8255 IO card for an ISA bus. For some cards less than AUD $100, and with drivers and examples in Visual BASIC, C++ and Delphi:

One card has 72 IO channels.

The book "Build Your Own Humanoid Robots" has a project interfacing a simple robot arm with 6 DOF to PC and to a PIC using a Visual BASIC GUI, although this could be adapted to similar RAD IDE like FREE open source IDE for C# and Visual BASIC, or if you can pick up a free copy of MS Visual Studio, C++, C#, Delphi or Visual BASIC:

Eventually I will tackle some projects using similar resources.

If I can find and use these resources, I am sure that if you too are resourceful you can find some solution. The only thing I have found with some open-source/FREE stuff is that sometimes a lot of effort is needed - but then there is no such thing as a free lunch. ; -]

Anyway give it a go! If you can accomplish this you will surely kick ...

ps What does everyone think of these ideas?

Cheers

| -]

Dale

right, but to control the motor itself, unless you are bit banging on an interrupt, a timer is a very handy way to generate the pulse.

I guess I'm kind of confused who the customer is for the Isopod(TM;). It sounds good to me, but as a beginner I get this feeling, "Don't mess with this unless you're REALLY serious, need something powerful and know what you are doing." Which is fine! If that's what it is supposed to be.

I think the problem is that the industry only caters to two extremes. One is the novice who has plenty of money and low ambitions, the other is the techno-geek who's either comfortable enough with the programming or with the electronics to get them beyond all the user-unfriendliness you have to wade through.

I'm in the middle.

There's LOTS for people in the middle, and lots of products that address this space. An AVR chip and an $80 STK500 programmer is perfect for this level. You can choose your development language, including the free version of Bascom, which works quite well for many types of projects.

Or, if you want something ready-made you can purchase a board like the AVR-based MAVRIC II, which is made for robotics applications, and does not need an external programmer. (In reality, most AVRs don't need any special hardware to be programmed, just some wires and maybe a resistor and/or diode here and there, depending on the design.)

-- Gordon

Seems like a strange comment for me to respond to. If you buy it you are the customer, and if you don't, you aren't.

The company name "New Micros" is based on the idea of selectivly choosing what we think is the best in new micros, and putting them on an easily accessible board. IsoPod(TM) is based on the DSP56F805 processor.

So generally, our customers are ones who, want the latest or best technology in some particular area, (for motion control it's IsoPod(TM)) and want to get after their project and get it done. So yes, we hope for a serious customer, because serious customers are very likely to be successful customers, and we like to sell to successful customers.

This is a very interesting comment, because, I see the underlying micro as perhaps intimidating, but not unfriendly. On the otherhand, IsoMax(TM) with Forth under it, is all about user friendliness. We've kept from closing it for several years now, as we continue to add features to the language to accomodate user requests for more friendly words to deal with internal features of the micro, like interrupt driven serial and SPI support, and quadrature readers, and modes to set timers, etc. We even added an RC word to make dealing with RC Servos easier.

I'll look into this and make a report of what I mean in a new thread, as I have time.