High-speed PIC 16C57 as FPGA

... the core idea is the possibility to experiment with different (simulated) electronic circuits, modules or even microcontrollers without soldering or holding a big stock of different IC's.

It's not intended for the common user, but for developing and switching between different concepts and solutions - simple reload your configuration, change your motors/encoders and you can drive a complete different hardware ...

Viktor

Need is such a harsh word <|

Why not populate a board with a bunch of PIC's that already have advanced PWM and Full Bridge drive outputs ?

Why not populate a board with a bunch of CPLD's each having soft SPI and Peripheral of your choice ?

Why not use any micro anyone you fancies ?

Why not use anything other than Programmable logic ?

I think these are all very valid questions. Overall I can't see that we *need* any one solution over any other.

We can though I am sure discern advantages to one solution over another.

1. Flexibility
2. Cost Benefit
3. Response/Real Time
4. Future proofing (never guaranteed but some degree can be designed in)
5. Specificaly targeted functions

Ever had those moments when a piece of of the shelf silicone looks like it should be just the thing but when you study the data sheet it lacks a simple fundamental (to the intended application) something you really feel you want in the implementation.

Take the PIC18FX620. the PWM peripheral has output logic to give you full bridge drive straight of the chip. Great you say. Lets look at the datasheet. the data sheet shows full bridge drive outputs one pin per out put. But whats this the sequencing is free run only. No braking mode.

I am controlling CNC machinery I want free run on the acceleration up ramp and braking on deceleration down ramp. Certainly I want braking mode when moving very small distances. (Ever tried parking your car on a hill without using your brakes)

Then you look at the plethora of options you have to set as the peripheral is trying to be all things to all people.

Suddenly programmable logic makes a lot of sense. You can have a peripheral that does exactly what you want, how you want it, specifically targeted to the application. Not only that you can have it all at real time speeds and response the like of which you could never realise with a microcontroler (Interupt latency, loop timings etc etc).

Not only that but each peripheral can be streamlined and automated such that they are all running fully in parrallel with zero processing overhead.

FPGA v CPLD.

FPGA's are bigger so you can get more into them. Either more peripherals or cleverer peripherals.

CPLD's are smaller so you get less into them.

FPGA's tend also to have clever macro blocks that can do things that you would probably take up much of your CPLD synthesizing. So for clever functions and lots of gates FPGA's have it over CPLD's


In summary then,

who *needs* real time response from subsytem/functions that run concurrently.
who *needs* the capability to have enough gates floating around to give a degree of future proofing.
who *needs* the capability to experiment and evolve the circuitry without rehacking PCB's

If not real time precision motion control applications, then who ??

Just for fun take a rummage through the EMC2 and Linux CNC pages for what folk are using for their Motion controllers, FPGA boards figure quite prominently and give a silly number of axes and drives per board.

A good example is:-

[www.knjn.com]
[www.linuxcnc.org]

Who indeed, I don't pretend to have the answer. I guess we are debating here is that who us ??

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

This discussion is worth having a look at as there is a bunch going off on using RepRap to leverage Surface mount technology. (Pretty much necessary for FPGA work and certain classes of CPLD)

[forums.reprap.org]

Any body got any ideas/contributions on devices.

So far I have been looking at the Xilinx Spartan 3E in the VQ100 package. Viktors article seems ot be using the same device.

The Xilinx devices are incredibly complex (even for fpga's) and the Spartan 3E has really horrible power requirements (3 different voltage supplies) that make the supporting electronics more costly than you might really want.

For datacomms I had been looking at the FT2232 USB to serial & JTAG. But am currently looking at the price comparison of using a USB PIC with suitable firmware to do JTAG serving and serial pass throughin it's stead. More so after looking at the data sheet of the smallest USB capable PIC. You can put a bootloader into it then reprogram the rest on the fly at any time (down the USB if you code it in the bootloader)

what do you guys fancy ??

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Xilinx also do the Spartan 3A range which can run from only 2 supply rails - making your board a little easier. Their gate count : IO ratio is a little lower, but that may be acceptable.

I believe that Altera devices also need multiple supply rails. It's inconvenient, but not the end of the world.

There are standard SMPS designs with dedicated chipsets - look on Linear or TI.com or (I think) IRF and you can find a few. Alternatively, we could just not worry about power dissipation and use linear regs off a 5V power supply rail.

If people want to use multiple CPLDs, there rapidly comes a point where it would be easier to amalgamate them into a single device anyway.

Anybody done anything with the Atmel devices ???

I've worked professionally with Altera and been looking at Xilinx but have absolutely no idea about the Atmel stuff other than the FPSLIC device (Prohibitive one off pricing).

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

Anybody done anything with the Atmel devices ???

What is their software like? Xilinx and altera offer pretty reasonable packages, and I rather hope that they'd make less awful tools given that programmable logic is what they do best.

Quote

FPGA v CPLD.

FPGA's are bigger so you can get more into them. Either more peripherals or cleverer peripherals.

CPLD's are smaller so you get less into them.

Presumably there are other reasons for choosing CPLDs? The internets seem quite unable to offer me useful information here, but as the market hasn't killed off CPLDs in favour of FPGAs, there must be *some* reason to use them.

All I can find are things like "CPLDs are awesome!" from altera, possibly because xilinx make better FPGAs than altera do so they need to market themselves this way. They cite a few vague architectural reasons, including things like deterministic signal transit time across a CPLD due to their different interconnect strategy. I'm not sure where this might have a noticable impact on a design though, and my friendly programmable logic consultant is out of the country so I can't ask her

The only other nice thing I found was that xilinx make a very cheap CPLD that fits into a PLCC socket, making it relatively easy to add/remove/replace them. Though assuming you made your peripheral board with a JTAG connector, that sort of thing would be less important. Also, you don't get too many IO pins in such a small package, meaning this is only useful for peripherals rather than main controllers, I'd have thought.

Pretty much the major difference is number of gates and logic/macro cells.

For what we are doing here the cross die speeds are not that relevant. Were not doing video timing or graphics processors etc. (although you can)

Every manufacturer will claim they are the best.

Minor differences are FPGA's use ram to store the logic configuration and need an external memory device (normaly a flash device) to load their ram from at power up. Or you hang them off a processor/host with storage and squirt their config into them. You can also theoretically reconfigure FPGA's without power cycling your board (on the fly), I would not try it in practice what ever you have attached to the io pins could do some expensive/dangerous things.

A good feature though for remote operated systems and fault tolerance like a space program or satellite systems etc.

CPLD's etc tend to be ROM or EPROM devices. (some are EPROM with no window) you drop your design in and that is it. finito no modification without device change. Unless of course you have a windowed eprom device that you can erase. I haven't looked recently but there might be some flash devices around by now.

Usual application for CPLD's is glue logic, instead or armies of 4xxx or 74llxxx devices. Which is why there is a fraction of the discreet logic IC's about these days that there used to be.

Usual application for FPGA's is custom system on a chip, ie soft processor core and peripherals or just very big very complex peripherals. Can also be used for farms of less complex peripherals. It is standard practice at these complexity levels to go through several revisions. Just like software development.

Advantages to programmable logic over programmed (micro processor logic) are full parallelism and real time operation. if using FPGA's you can re hack your circuitry for ever or until you run out of resource. without ever re hacking the PCB.

FPGA's frequently have much more internal resource than IO pins. CPLD's tend to be somewhat less so.

There is a question as to whether as gate density increases (an manufacturing cost decreases) the days of dedicated silicone micro controlers etc are numbered.....

Horses and courses really.

As ever the devil is in the detail, but as a potted summary this is OK.

Hope this helps.

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

As an FPGA designer one FPGA family I like is the Actel ProASIC series. They are flash based (rather than the SRAM based Xilinx and Altera FPGAs) so they do not require an additional memory or external device to program the FPGA on each power up. Here is an example of this device for about $5:
[www.mouser.com]

Actel will give you a 1 year license (renewable each year) to their development environment called Libero for free if you register. The unfortunate part is the jtag programming pod is $100+. It may be possible to build one.

FPGAs vs microcontrollers is a big tradeoff in many designs these days and often they coexist together to leverage each others strengths. In many cases a sufficiently large FPGA can perform any job a Microcontroller can and a sufficiently fast microcontroller can do any job an FPGA can. That doesnt necessarily mean you want to discard either. For reprap the best use of an FPGA would be to offload any processor intensive algorithms that would overload the main microcontroller, ie a co-processor. Someone with actual hardware and reprap experience would have to comment on whether any such algorithms exist, from the outside it looks like the current microcontrollers are sufficient if the preliminary data crunching is done on a PC.

Conclusion: An FPGA would be an interesting tool to play with in conjunction with a reprap and algorithm development but it would be an extra complexity and cost for the mainstream design.... As viktor proposed in the first place.

Edited 1 time(s). Last edit at 09/05/2008 10:47AM by d0ubled.

Quote

for reprap the best use of an FPGA would be to offload any processor intensive algorithms that would overload the main microcontroller, ie a co-processor

I think I can safely say that processing power is cheap and easily available if we ever needed it. Hell, as a last resort, you could get the host PC to do the hard work

I don't believe that reprap is limited by the power of our various chosen uCs... it is the lack of IO capacity and peripherals which is causing the most irritation.

Algorithmic boosting depends on where we are going.

If the current state of the art is as far as we go. Then there is A. no need for programmable logic and B. no need for any other devices than we are currently using.

If however you want more than 2.5D motion control (milling compound curves and shapes realistically needs 3D) You need more than what we currently have.

If you want the RepRap as an applicance ie like a laser printer it has everything it needs in it and the host only send print files, then we are going to need more than we have got (quite a lot when you consider the 2.5D versus 3D question).

If we want more than 3 axis simultaneous synchronized control, and you should count feedstock control (multiples in the case of multiples heads) and heater control as axes each. We will need quite a lot more than we have got.

Processors and I do stress *all of them* only do one thing at once, ever where they pretend to do more.

If you want more happening in parallel you have to have either more processors, or dedicated subsystems or both.

dedicated subsystems are where your algorithms and programmable logic come in.

Essentially the question is are we all completely happy with what we have got and don't want anything more than it currently actually, really does. (not what you imagine it does) ???

I can't answer for anyone else, but for me certainly not, what we have is a start "And miles to go before I sleep" (to quote robert frost)

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

> I think I can safely say that processing power is
> cheap and easily available if we ever needed it.
> Hell, as a last resort, you could get the host PC
> to do the hard work
>
> I don't believe that reprap is limited by the
> power of our various chosen uCs... it is the lack
> of IO capacity and peripherals which is causing
> the most irritation.

I don't think it should be discouraged to experiment with FPGAs; a novel and interesting or even just cheaper solution may be discovered. That said the current focus on a microcontroller based core design seems sufficient and wise.

Has anyone proposed using an I/O expander chip for extra I/O?
[focus.ti.com]

I think this was part of Ru's suggestions re using CPLD's etc AS IO expanders.

I have been trying to have a rummage through the Actel web site unfortunately it currently looks to be down or inaccessible from here. I will try later.

It could also be worth considering looking into knocking up a SPI Mux using a CPLD if only to fix the concerns Ru was having re usage of Controller pins as device selects.

SPI + two device selects in, should be able to get you SPI out and as device selects out as the device has pins left.

One device select in, selects the MUX and sets the address that the second device select will refer to.

The second device select is then mapped to whatever device select out you set with the first.

As SPI is fairly simple gate count wise and the addresing for the Device select out is a simple binary to one of X decoder this should be dead easy.

There's a novelty if ever there was one.

With a SPI mux you could expand IO until you ran out of processing/memory power. Not sure how exactly you would handle interrupts efficiently for that lot though....

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

The FPSLIC by Atmel does much of what's been discussed on this thread. It has no ADC though. It's possible to run charge/discharge cycles through external hardware in series via a capacitor (i.e. a PTC resistor), and time the transition periods, but it's messy.

I think the IDE is freeware.
Price:
[search.digikey.com]
(size with smallest FPGA, in secure mode (on chip configurator) 144 pin LQFP !

I think, that you could make the PCB, with ISP for the AVR side, then install a bootloader to configure the configurator, plus the main program, and then play...
All you'd need then, is a programmer to talk to that model of AVR, and I think the standard Atmel development programmer works for that, so long as you have the correct version...

If done, then you can automate all the timing and logic parts of the stepper motor control, PWM control, monitor encoders with built in debounce, and, of course, you get way more pins.

In terms of ease of the approach, the firmware in the arduino could be shifted with minimal changes, the L297s would, of course be obsolete (why aren't they already??), extra heads could be catered for as PCB with/without populated components.

[www.atmel.com]

I've been looking at using the STM arm-cortex-m3 for an all in one PCB, but this is another option. It does tie the project more heavily to one manufacturer, though, to use the FPSLIC approach, and I don't know what the product production lifetime will be.

The cost of going down the FPSLIC path versus the arm cortex path is about $9 higher per processor, but the development environment is more open, and the results would be much faster.

I see nophead is comfortable with VHDL, and I doubt that Atmel's variant would be a stretch for him.

I've done some minor work with AHDL back when I was running my electronics/SW design business, and I can safely say, that the requirements to integrate the current off chip logic, and simplify some of the on chip work load, are fairly easy to implement, I'm only an HDL beginner, and it's relatively simple stuff.

Cons, summary:
expensive,
No ADC,
No USB.

Another option to leverage the existing processor, is to take all the digital I/O and make it available through a port, to and from an FPGA.

Then, you address the FPGA, tell it to speed the X-stepper, slow it, stop it, interogate it as to the position, tell it to go to a set location, etc. Lots of functionality can be put in the FPGA, if required. The port could also access one of more print heads, fans etc, so pin availability on the AVR is not an issue, you only need pins on the AVR for:
USB
ADC
ISP (only if SMD, and not socketed)
Memory...Only if not using a memory interfaced to the FPGA
(I can see people thinking of DIMM memory modules... 4Gb part libraries..mmmm)

Graham.

Luminary has some good ones, and pretty cheap too. Some even have built-in motion control, but the cost on those ones gets up to about $20
[www.luminarymicro.com]

If you're looking for something to make motor control simpler, an FPGA is overkill. Have you considered a CPLD? There are a few that are available for about $1 which can do quadrature decoding, etc. check out the Xilinx XC95xxxXL series. The XC9536XL is quite cheap, at $1.42 in single unit quantities, and the XC9572XL is available for as little as $2.71. These devices are available in PLCC which means that through-hole sockets are an option, eliminating the conventional anti-surfacemount argument.

Grael wrote:

> I've been looking at using the STM arm-cortex-m3 for an all in one PCB,

A couple of us are looking at ARM and/or Cortex chips. (The STM32 cortex chips have a 12bit A2D, which I like.) Similarly he Fab@home project uses an NXP arm chip LPC2xxx on an olimex/sparkfun board. These are a nice bit of bang/(currency of choice) -- though (as I've said) I don't want to tax mainstream reprappers with yet another CPU/toolset change until the Sanguino runs out of memory, I/O or steam.

I just got an inexpensive STM32 board from www.futurlec.com, the: ETSTM32STAMP "ET-STM32 Stamp Module" USD $25 (modulo delivery time from Thailand.) However, I haven't gotten through the toolchain setup, to get an LED blinking, yet. (Fingers crossed.) I would probably have gotten an Olimex/sparkfun STM32 board (since those have a JTAG connector; this board has only serial download/monitoring), but the cortex ones have been out of stock, last I checked.

-- Larry

Hi Annirak,
I haven't done enough FPGA work to have a feel for device size required (model,complexity), but I like their flexibility. It's quite possible to implement the quadrature encoding, position counting, terminal stop count reset, and a custom addressing system, even LCD control in an FPGA, and I'm sure complexities are up, and prices down from when I last played with one about 6 years ago.

I've just wikied CPLDs, having not remembered exactly what they are capable of, and I agree with you, they look ideal for the job.

Larry,
I'm interested in how you go with the toolchain on the STM stamp...
Personally though, I want to do an all in one PCB, so that rules out a stamp type device, I will be hand soldering a TQFP100 in myself.

If I was already involved in the reprap project, and had been involved in the AVR firmware, I would be very tempted to put in a larger AVR, the FPSLIC, or an AVR32.

O, the joys of a fresh start...

Do NOT put in an FPSLIC. They're an awesome idea with a ridiculous price tag. It's much cheaper and much more bang/(currency of choice) to do an ARM + XC3Sxxx solution. You can load the config memory with SPI on the spartan 3 devices, so they pair very naturally with a MCU. For extra points, use an LPC2378 or LPC2468 and interface the FPGA to the MCU host expansion bus!

Thanks Annirak,
I think the price is not that bad if you look at what they can do, except for the ommisions compared with other modern micros. They are a natural for a high speed printing controller if the quantities are too small for an ASIC, and if you want small foot print and code security.

However, I've asked around, and it seems that Atmel are not doing much volume of the product since their inception some years ago.

I think their main failing, is that they present as too complicated to most people, and also that many companies specialise, so the microcontroller people are looking for pure micro, the HDL people are looking for pure FPGA, CPLD, and once happy in their environment, their comfort zone is "Stuck"

Anyway, I'm getting more convinced of using the Arm cortex as time passes. It cuts my external component requirement to a minimum, has plenty of grunt, USB, PWM, ADC, an MMU, extra serial, should I decide to leverage the code into another project, and it's dirt cheap.

So, the design process begins...

My only annoyance, is I can't find a source here in NZ for a cheap but fast JTAG programmer.

Graham Daniel.

Surely if using something as large as a spartan you would put the processor on the FPGA using the Open Cores designs as a roll your own micro-controler with IO specifically designed and tailored to the application.

AKA47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Andy,
you have a point (I looked up spartan arm cortex and got this:
[www.arm.com] ),
but I would be missing out on the dual ADC and the dual banks of analogue 1-of-8 selection.

Sure, I could do the analogue with a cheap microcontroller, but, that's what the Arm Cortex is anyway.

These are digikey pricings for two of the FPGAs that ARM list as being compatible with a core of that size:
[parts.digikey.com]
[parts.digikey.com]

This, for the STM32 cortex in a 100 pin package with 128k program memory (the arm cortex):
[search.digikey.com]

This for the ATmega168:
[nz.farnell.com]

I must admit, there is some variance in there between what Digikey charge, and what my distributor charges, and it wouldn't be the first time he's significantly charged me less for the product first time around, and then stung me for the same product later...

OK

Systems stuff

If you are implementing a SOC (System on Chip) roll your own Micro and Peripherals you can roll in an SPI port for sure and a number of select lines so that you can address a number of external SPI based peripherals ie SD-CARD and AtoD.......

Rather than going for restricted proprietary IP and limited distribution cores do a search on the Open Cores Project.

You will find cores for AVR, PIC and ARM as well as a hole bunch of ready to integrate peripheral cores, including memory controlers, Dedicated Servo Controlers etc etc etc.....

Most micro AtoD is only a single AtoD converter anyway with the 8+ inputs multiplexed. Using multiple actual converters gives you a quicker cycle time to capture all of your inputs.

Do a search also for SPI and AtoD. You will probably find the devices have better resolution and capture times. Not to mention the devices that already specifically set up for specific applications like thermocouple temperature measurement.

Quadrature decoding is most readily done on the FPGA as a peripheral and you can do multiple channels that have quicker response than you can code, are concurrent.

Doing more in dedicated logic means less interrupts and more processing time.

Doing it all on an fpga means that you access whatever peripherals you want to code at bus speeds.

It also means that one set of hardware can have differing personalities, for example the same logic board could run servo motors with one set of add on drivers or steppers with a different set of add on drivers all with just a code change.

Yes of course it does cost more and means you have to deal with more of the complexity than buying off the shelf black boxe IC's. It does though give you the ultimate in flexibility and experimentation.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Hmmm...
We're looking at two sets of tradeoffs.

One, is loosing the inbuilt ADC, which typically would only be used for thermal measurements. That could be done on a dallas 1-wire bus anyway. There's a little bit of accuracy required on the timing for that, but I'm sure it's out as a soft solution to fit on a CPLD anyway.

The alternate tradeoff, is having to run time intensive tasks requiring a level of synchronisation that affects the precision and performance of the end unit, all on a microcontroller running a serially processed algorithm set.

Do you have a suggestion, Andy, for a competitively priced CPLD that you believe could handle the required level of complexity, and not get in trouble with, for example Atmel for copyright infringements on using a core that runs the same program object code as theirs ?

Unless the price is very close, all the CPLD extras are not going to be seen as worth while, at least not on an all in one PCB, because it would be too customised for the end application by the connected power output devices. Or, if you run is as a processor/CPLD PCB only, straight away, you have pumped up the component and PCB real estate cost.

Graham.

aka47 Wrote:
-------------------------------------------------------



> Rather than going for restricted proprietary IP
> and limited distribution cores do a search on the
> Open Cores Project.
>
> You will find cores for AVR, PIC and ARM



Unfortunately(with respect to ARM), if you look at the processors at opencores [www.opencores.org], and look at the ones that are obviously ARMish:

[www.opencores.org]
(Guts removed from opencores.org cvs in 2001, pending "discussions" with "a company." I presume the Co. is ARM, but I have no direct knowledge. And I suspect the discussions were along the lines of "If you don't remove this ASAP, we'll bury you in lawsuits....")

[www.opencores.org] (planning stage, last update 2003)

[www.opencores.org] (beta, incomplete IU, last upate 2004)

I think you'll find that they are either (effectively) abandoned and/or blocked by litigation. I wish this were not so, but I don't see any working ARM cores.
I'd be pleased to hear that I missed one; is there one available as open source?

---

Larry Pfeffer,

My blog about building repstrap Cerberus:
[repstrap-cerberus.blogspot.com]

Your probably right larry...

last I looked the stuff was there. Must admit though as we are currently running avr code I really wasn't that interested in the Arm core, just the AVR core and the servo controler cores. So may well have missed something.

Being a pragmatist if I were going down this route I would start of with an avr core and get all of the peripherals working. Then later worry about changing the processor core for another.

I am more likely to go with a second processing core (or more) as a performance enhancer before changing the type. I have been a big fan of multiprocessing since the transputer days.

More pertinently perhaps because I would want to take all the other folk who have put effort into developing AVR code with me.

Think of it as backwards compatibility with the wetware. Technology is far more amenable to change than people.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I have played around with FPGA's quite a bit and even gotten the openrisc OR32 to run ucLinux on a Digilent and Xess board. The biggest headache for me is dealing with timing issues. You get all this wonderful RTL synthesized and working in the simulator, but when you load it into the FPGA it acts erratic.
My last go round with a board from XESS had me going in circles for several weeks before I could get the board stable. Ultimately that one took me doing a command line synthesize, building each module separately and using a floorplanner to lay everything out.

I think FPGA's are great for their flexibility, but they do have their share of thorns.

One note: You're not going to get a processor core of any kind to run on a reasonably priced CPLD. There isn't even enough logic to implement an ALU, let alone a whole CPU. That is decidedly the realm of FPGAs.

I really do think that an ARM with an external host bus and an FPGA are the best way to do a reprap. It's pretty cheap, and there is a ton of uncommited logic to play with. You can synthesize a peripheral bus inside the FPGA, and then you get the same advantages as putting everything inside the FPGA, but without the headaches.

Use the right tool for the right job, that's what I say. FPGA's are not the right tool for a CPU. CPU's are not the right tool for implementing custom logic. FPGA's are terrible at mixed-signal support. And finally, the best kind of thermocouple sensor is the kind that does the whole job for you (MAX6675).

Brendan

I pretty much agree with all of that one......

I guess this is why I was interested in the FPSLIC. But held back due to pricing.

The Actel silicone mentioned above looks more promising though.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

It's a nice luxury to think about having an FPGA/CPLD and a Micro on the same PCB to run a 3/D printer/router, but the atmel seems to be doing an "OK" performance already, esp after recent revisions on the arc plot calculations (which could be done on the PC anyway)

I see the Arm cortex is available via NXP, as well as from STMicro, which is where I got mine from. The first issue of NXP LPC processors had, I believe, a lower pin count.

Considering the current Atmel processors (approved on the project) also have a very modest pin count, it's natural to seek different solutions to boost the pin count.

Then, the L297 are being used currently to reduce the pin count, and to simplify current control.

I think the ARM Cortex are actually fast enough though.
* Go for one with a high enough pin count, and you won't need to apply a "patch" by expanding I/O via a CPLD
The STM32F103 family have LOTS of PWM outputs, we need PWM for:
* Winding power enable (2 per standard stepper)
* convenient for heater control, though not necessary

As far as actual stepping requirements go, it should be well within the capabilities of the ARM Cortex to run the L297 functionality (only a matter of stepping up or down through output lookup tables, and anding each channel's result as a nibble across a byte or word wide port. Then, the actual positioning, is calculated by a processor with some grunt for the maths, and plenty of Flash memory for any look up tables required (pre calculated sine/cosine etc) The static memory is bigger, so it can run a bigger print buffer and doesn't need to tell the PC to slow down so much. Using a static Ram buffer, and pointers, doesn't give the bottle necks or rewrite cycle limits that occur with EEPROMS.

There are ample pins available to have spare for an SD card etc, and RS485 if required.
I'm designing my board up now, early stages though.

Graham Daniel.

Graham,
Did you notice that the LPC23xx and LPC24xx have hardware SD card ports? They implement the complete SD spec. They may not be ARM Cortex, but there's nothing wrong with ARM7-TDMI. The LPC23xx is limited to 6 PWM, but the LPC2468 has 12 PWM.

Brendan

Annirak,
No, I didn't notice that. I'm at the stage, where I've looked at what's around and well known, looked at what's in my stock (out of date Atmel of different sizes, FPGAs, CPLDs from back when I ran a design business), and my nwer stock of Atmel for a small project, and untouched STM32 Arm Cortex, and I've made the decision to go with the STM32. It will take me longer to get results than going with the reprap official stuff, but I'll have a better hardware platform with space for real expansion, speed and if anyone else is interested, I'm thinking the package will have a lower hardware cost due to the integration on one PCB.

I have made a start now, on the STM

I'm not really sure when I'll have something ready to party with Gcode though... lots of work to do yet !

Graham.