Newbie looking for guidance

There's no "royal road" to learning. If you're a genius then you can maybe learn just by reading textbooks. For the rest of us, just start anywhere and see where it takes you. Doing this as a hobby gives you the luxury of taking any road you fancy, but omits the discipline of a goal you can't change. My own preference is for that unyielding target, but that may not be best for everyone.

If you're very rich then send yourself on training courses, but you'll still have to put in hard work and late nights to become competent.

The first step to that competence is knowing that you know enough to be dangerous. This puts you ahead of many who, after ten years of "professional" work don't realise that they're still dangerous.

Mike

I think it depends on whether your goal is to build a robot or to learn something completely new and not much related to robots. Yes, you can do many different things with FPGAs, but if you want to build a robot soon choose the path you already know...

/Mikhail

For robotics I think you're better off in the microcontroller realm, with something like your Amtel AVR or a Parallax Propeller that will easily interface with all kinds of easily available and relatively inexpensive modules

kinda stuff). I think of robotics more as a system integration problem.

Machine vision is pretty much entirely a software issue I think, so if you want to learn about it, I'd consider starting with a PC and a $20 webcam and the free programming language of your choice along with a book or two on the subject. Learning how to design a solution and implementing that solution in something like an FPGA are probably quite different tasks, and I'd be afraid of drowning in the details of implementation while trying to learn how to design what you want.

For SDR maybe some DSP hardware (or FPGA maybe, though I'm not sure how much fun doing serious DSP in a Spartan 3 would really be) probably makes sense. I think there might be a few reasonably priced experimenter's boards out there.

The Spartan 3 starter board is fine (I have one), but to get started and get a feel for things you can start by downloading the free ISE WebPack software from Xilinx to see what the development process looks like for their FPGAs. You can design/code, build and simulate all without actually having any actual hardware.

FPGAs are pretty cool, especially the "hardware becomes software" aspect which is quite appealing to those of us with more of a software background, but they're also very complex so if you're really interested in learning to design for FPGAs (programming in VHDL/Verilog etc.) then great, but if you're more interested in the applications than in the technology then something less generic and more specific to the problem you're trying to solve might greatly simplify things.

Just my random thoughts.

G.

The Propeller is interesting, it'll certainly get you thinking parallel which will stand you in good stead for FPGAs (and for future processors!)

You may think so - I'd disagree! Machine vision is an *algorithms* thing. Algorithms are often easiest to prototype in SW at a desk with a webcam, but if you want to make them run "standalone" then targetting an FPGA for the highly parallel parts makes a lot of sense. Of course, to do that successfully, you have to build your algorithms with FPGAs in mind - and to do that, you have to have tried to implement some already :-)

Agreed! But if you *ever* want it to run outside of a PC, run around the loop of "taking the algorithms into embedded hardware and changing them to suit" early and lots of times. You'll learn more that way.

Yeah, but it's much more fun when you can see that LED flashing like you told it to instead of a wiggly waveform on screen :-)

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Do you mean Xilinx's MicroBlaze processor? If so, note that this is a general purpose CPU with a fairly average MIPs spec. You'd easily be able to get comparable or better performance with an off the shelf microprocessor -and without all the headaches!

Yes, I meant MicroBlaze, thanks for catching the typo. This is good, so you are saying you would prefer working with a discrete microcontroller interfaced to a FPGA, instead of a FPGA with a MicroBlaze (or other core) onboard?

Thanks,

Philip

I'd tend to agree with you, it's an integration problem. I was trying, I guess, to come up with a good excuse to learn FPGA's and then DSP techniques. I have a lot of ideas, but robotics is something I actually have practical experience in so I figured I could sub out the FPGA for the AVR/MC68HC11/PIC's I've used in the past as a learning experience, before going on to other projects like vision processing and radio processing where I know very little and I'd have to learn more than just the FPGA design aspects. That was my thought.

Could I get you to expand on the difference between "DSP hardware" and "FPGA" in this context? My (albeit new) understanding was, DSP techniques were implemented on FPGA hardware to do digital signal processing. Or are you talking about a chip tailored specifically to audio processing versus a general purpose FPGA?

I am interested in learning. I do have experiance with various microcontrollers and I write various simulations/data reduction codes at work, but nothing in real time like a DSP would perform. It kind of sounds like fun.

I do appreciate them, thank you.

Philip

Depending on what sort of hardware you expect to have for your robotics, FPGAs can actually be pretty neat for the very low-level interfacing stuff. Standard mechatronics functions such as quadrature-encoder counters, PWM motor drivers and so forth go nicely into FPGAs, and the digital design is relatively straightforward so you can concentrate on the FPGA-specific aspects. Because you have an FPGA to play in, you're not locked to the limitations of software (response speed? time resolution?) and you're not limited by what a specific device manufacturer chooses to build and sell - so, for example, it's easy to make encoder counters that automatically latch the count value at the moment of an index pulse, so that your s/w can interrogate that latched value at leisure; encoder counters with some built-in timed interpolation or velocity measurement; unusual PWM structures to meet specialised needs; programmable triggering of external outputs when an axis reaches a preset position... Lots of stuff like that, which is tiresome to do in software - and probably near-impossible to do with microsecond time resolution. In some ways it's a waste of an FPGA, but hey, the thing is sitting there waiting for you to do something with it...

Just don't forget to think about the electrical robustness of connections to the FPGAs. Modern FPGAs have fairly feeble I/O structures [*] working at 3V or less, and they don't take kindly either to >5V external connections, or to the kind of unpleasant electromagnetic crud that tends to come for free with anything electromechanical. Much care with level shifters, buffers and snubber circuitry is needed to protect your FPGA investment. The nice folk at sci.electronics.design will likely be pretty helpful about that sort of thing, and will be up-to-date with what's available to make it easier.

[*] Feeble by the standards of industrial automation. No slight on the FPGA manufacturers intended!

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Well, first of all, DSP is probably the topic of yours that I know the least about so take anything I say with a couple grains of salt.

When I personally think DSP, what comes to mind are things like the TI DSP processors which were/are more like general purpose CPUs with an emphasis on high-speed fixed- or floating-point math rather than being a general purpose "sea of gates" as an FPGA is. TI has some introductory info here it looks like:

Modern FPGAs have some of the basic building blocks (interger multiply units, etc.) that make it possible to do traditional DSP processing, but you're still mostly building up a machine from scratch to do what you want rather than just writing a program to express an algorithm.

I don't think it's always easy to answer the question of what should be done in hardware versus software. Often there are techniques to do it either way, and the background of the particular designer tends to tilt the decision more than anything else.

FPGAs are incredibly cool. They're great when you need boatloads of exotic I/Os, extreme parallelism, and complete flexibility. They don't make great general purpose CPUs usually. From a software point of view they're again the most flexible but probably also the most complex. From a hardware point of view they're pretty much all cutting-edge technology and none of their design is there to make the life of a hobbyist easy, so building your own FPGA-based hardware designs is pretty complex. Fortunately there are lots of inexpensive boards you can buy to experiment with.

If you pick up an FPGA board to play with and spend some time with it then I don't think you'll regret that learning experience at all. Whether at the end you decide that the FPGA route is your best one for implementing the things you want to do is something you'll only know once you get there.

G.

PFGA+MicroBlaze lacks code memory, so that's a significant cost. Generally, if you can find a single chip uC that will fit your task, you get the EMC & reliability benefits of on-chip memory, and also (probably) get to use a smaller/cheaper FPGA+LoaderPROM

A good topical example of a companion processor for FPGA, would be the Atmel AT91SAM9XE series. 200+ MIPS, from 128 bit wide flash, and $7.30/10K, with 128/256/512K FLASH.

Plus all this fruit: [USB 2.0 Full Speed Host and Device Ports, an Ethernet 10/100 Base-T MAC as well as a two-slot Multimedia Card Interface (SDCard/SDIO and MultiMediaCard Compliant), a Synchronous Serial Controller (SSC), four USARTs, two master/slave Serial Peripheral Interfaces (SPI), a debug UART and two Two Wire Interfaces (TWI).]

If you need megabytes of code, then the balance tips back a little.

-jg