High-speed PIC 16C57 as FPGA

Hi all,

here [www.opencores.org] is an interesting method to make a custom-designed high-speed-microcontroller - here for example a PIC16C57 with 320! MHz.

In the actual german c't-magazine ( [www.heise.de] - should be next week online ) we have a project with PCB and software, where a Xilinx Spartan3-FPGA is surrounded by an ATmega-Controller with a 128MB-SD-card for the different configurations, so you can develop and swap all types of custom electronics.

This should be great for developing and testing with different controlling- and interfacing-systems or complete simulated microcontrollers without soldering.

Viktor

Viktor

Open Cores also have Atmel Atmega CPU soft cores and the stuff for PWM and PID already available from their libraries. (Not to mention a whole bunch more)

Turning out an entirely FPGA device with the specs as you describe but actually running arduino firmwares and dedicated hardware realtime PID, PWM, Full Bridge Drive and Quadrature Decoding is entirely within reach. (Given time & Money)

As also is the Pic and other cores ie ARM etc.

This is something I have been toying with for a while, already got some samples from Xilinx but am currently looking at the Atmel FPSLIC as well.....

Running soft processors in FPGA is pretty resource intensive and eats up a lot of the gates etc you want for clever peripherals (Hardware PID, PWM etc)

I am at the moment diverted into getting a use able Darwin together that I can do some of the PCB prototyping on.

Part of this when I get back to it is the work I started off and have yet to finish on DC Brushed Motor Servo Control.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

You will probably find that the expense of an FPGA capable of running a microprocessor core is rather high. A swift glance at Farnell suggests that little FPGA is going to be at the very least a few times more expensive than a microcontroller, and you won't have little things like ADCs or DAcs on board.

I've been looking at using programmable logic to potentially replace some of the more expensive ICs in the system, such as the L297 stepper controllers. A suitably programmed CPLD would be cheaper and just as good, and potentialy have other interesting bits of logic built in such as networking modules.

If the FPGA was doing processor only I would agree.

As you have pointed out though the cost is in the processor and the rest of the IC's neccesary to signal condition and drive.

If you are going to the effort of putting a processor on an fpga then it also makes sense to integrate the rest as much as possible into the same design.

Total system cost reduction is the goal. Don't forget the real estate and assembly costs too, then factor in being able to redesign the hardware without redoing the PCB's etc.

AtoD and DtoA is also eminently doable at least in the digital/time domain. Digital to time, time to analogue voltage/power are very well understood principles.

If you don't want to go that way, implement an SPI interface and hook up as much serial DtoA as your project needs. but no more. Yet still reserve the option to add more later (SPI and other serial buses are like that)

You also gain by being able to ditch functionality you don't use from the processor/peripheral complex, gain response time by putting more out to hardware, gain processing cycles from the same and also gain the ability to stack your processor in a direction you want more of something. Ie more memory than Atmel provide, More speed etc etc etc.

Curiously the FPSLIC is a 40K FPGA and Atmel hardware processor core.

Food for thought.....

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

... i was thinking in the direction of 'solder-free' developing of PCB's and all sorts of discrete electronics.

I have some developing-boards of 8051- and PIC-microcontrollers lying around and a handfull of 'radio-stamps' (30x30mm PCB with an C8051F330 processor and a 2,44GHz-modem on board: [www.hst-elektronik.de] )

With the stamps i can build and simulate any hardware, AD/DA, SPI, I2C or other interfaces or discrete modules - i used them for developing wireless force-sensors for closing bottles with live-monitoring (for 16 to 32 caps in a caroussel!)

But another application-example reported some years ago impressed me much more: - a Neural-Network-simulator crosslinked with a FPGA started 'evolving' circuits and PCB's on his own. The results were some extreme capable and efficient circuits for FFT- and High-speed-encoding no human brain would be able to develop!

Viktor

Edited 1 time(s). Last edit at 09/01/2008 02:54PM by Viktor.

Quote

Total system cost reduction is the goal. Don't forget the real estate and assembly costs too, then factor in being able to redesign the hardware without redoing the PCB's etc.

The major cost I see is the learning curve and relative sparsity of HDL developers compared to, say, C developers... even using developer in its loosest sense as 'someone who knows about it and can fiddle with it a bit'. Without a handful of fairly capable coders, it will be tricky for such a project to advance with the speed the gen2 electronics have.

It would be tricky to implement, say, an FPGA with a softcore AVR uC which could run the arduino environment... you have all the challenge associated with developing the FPGA combined with all the problems that changing the arduino firmware is going to bring. Keeping simple, consistent interfaces throughout for the sake of the people who want to write better firmware to make printers run a little better will be pretty important, after all.

Replacing peripheral chips which can then be treated as black boxes seems a much simpler way to go, and everyone can appreciate the

Edited 1 time(s). Last edit at 09/01/2008 04:49PM by Ru.

Very little in deed....

Particularly if you design it that way.....

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I design FPGA's in VHDL as part of my job. I put a tiny custom CPU in one the other day to do SHA1 encryption because it used less of the gate array than a VHDL implementation. I don't see why this project needs anything that complicated. You can get CPUs with everything we need for about $5-8.

Add 3 modern stepper controller chips and a serial link to a smaller CPU for the extruder and the job is done. The total electronics should only be about $30 in parts. All the firmware can be written in C, why increase the skill set required to participate to include VHDL?

The only reason RepRap is on its third / fourth generation electronics is that the electronics get designed around a random CPU instead of selecting a CPU with the features required to solve the problem.

---

[www.hydraraptor.blogspot.com]

I think there is actually room for several "Competing" hardware solutions providing they can run the same code/host interface/machine interface.

I guess with hindsight we can always look back and say we should have used this or that microcontroler but as ever hindsight is only available after the fact and is the inevitable distilation of a whole bunch of trial and error.

The work that is currently being done is both invaluable and unavoidable, using Off the shelf chips is a good way to trial and prototype and I don't think we should be approaching this problem/solution in any other way.

There is a longish runnig debate else where on the issues re running out of IO and pins, memory, resources and so on. So much so that the need has been felt to go to a next generation Arduino. In fact so much so that one has been created using a larger micro.

This is the next step great, I think we should be all for it.

Where to after that ??????

Which limitation will we encounter next. I suspect processing power as the device takes on more tasks that can be shelled out to dedicated hardware.

Do you actually realy want to be limited in where to go to next by backwards compatibility re the huge body of work that has been done on the software. (ie re write for a different processor) Limited also by Atmels commercial vision/constraints (if Atmel still exist, corporate land is volatile)

or

Do you want to start discussing and preparing now to safeguard that investment for later by developing (yes it will take time and effort) FPGA based hardware that can run everything we have got now as is, and is fully expandable (multi processor, hardware pid/stepper etc) as well as what is in the pipeline.....

For my money whether you start off doing individual discreet devices in CPLD (it's still VHDL or Verilog and you have to program them) or you go for an all in one including soft processor it will inevitably end up as all in one further down the line and the investment in time and effort is worthwhile.

The debate over device numbers and system partitioning is a touch moot as it's all the same technology.

There are more FPGA vendors than Xilinx, the designs though are portable providing you write them that way.

Many of the tools are free to use or there are Open Source tool chains coming on line. Your own code and OpenCores code is royalty free.

Re the discreet IC's again you are completely depenant on a manufacturer continuing to manufacture. There has been so much promising silicone fallen by the way side over the last 20 years (where did the transputer go ?? the SGS linear voltage regulators with inbuilt bridge rectifier ??) that dedicated companies have sprung up to profiteer from the demand for legacy, fallen by the wayside silicone.

The Hobby of electronics as we knew it is currently dying. Through Hole components are now the rarity and you pay a premium. Open the back of most commercial kit (Try a Cisco Router for example) and there you will find FPGA's . Once prolific suppliers of components to home constructors and fledgling business now sell mostly toys (Maplin & where have all the others gone ??? cirkit, greenweld etc etc etc)

This is progress, this is change, this is where it is going. Prepare now.

Thoughts for what they are worth.

aka47

BTW Farnel and RS have never been the most economical of suppliers and are less so as the competition has dwindled.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

3 modern stepper controller chips and a serial link to a smaller CPU for the extruder and the job is done. The total electronics should only be about $30 in parts.

The steppers where where I was particularly interested, as moving to a CPLD based chip rather than an off the shelf controller saves you a few pennies (

Hi all. I was wondering when people would start discussing the use of FPGAs for RepRap.

First up, a word of warning: the PIC / AVR / ARM soft cores on OpenCores are almost certainly not licensed for use. If we start using these cores en mass Microchip / Atmel / ARM Limited will probably NOT be happy. There are however royalty free cores that look quite good (but I haven't used any of them yet).

I myself quite like the idea of using an FPGA with a soft core processor and custom peripherals to handle motion etc. One can even build a complete control system in an almost drag and drop manner using BitStream control (see link at end of text) which I'm doing as my PhD. (Yes, it _is_ good enough for real work and I'm getting some good simulation results for vector control of three phase AC equipment.)

The major pros for FPGAs (as I see it) are:
1) Dedicated motion control hardware could ease timing issues.
2) The ability to synthesise specialised hardware such as stepper motor drivers.
3) Mammoth amounts of IO are available.
4) Designs can be scaled - we could fit 4 axes of motion (x,y,z,feed), each with their own dedicated processor into a single FPGA with room left over for a supervisory control unit. Seriously.
5) The firmware can still be updated by a user who doesn't know about FPGA design. An 8Mbit flash chip will store a lot of code...

On the other hand, I suspect that going to FPGA technology would be a major barrier to entry for hobbyists for the following reasons:
1) Difficult to prototype with. You need a development board and these can be pricy.
2) To create portable hardware designs, the user would need to learn how to code in Verilog or VHDL or both. This is certainly possible but quite hard when you're starting out. Don't be seduced by the graphical design utilities - they are vendor specific.
3) Serious increase in construction difficulty. They only come in surface mount packages, and the bigger devices are all Ball Grid Array types.
4) The initial electronics cost will almost certainly go up. (Note that you need separate config memories, extra supply rails, JTAG tools etc. etc.)

For future development, I think what would be best is to develop software/firmware that can be implemented on a variety of platforms, which will protect us against supply problems to some extent and allow the terminally keen to look into higher technology areas. If someone cooks up a particularly juicy piece of custom hardware it could be distributed to the rest as, for example, an add on CPLD board which talks to the micro over SPI. This would allow for the diffusing of ideas back into the main branch without making it too hard for new players.

REAL TIME DIGITAL CONTROLLER IMPLEMENTATION USING DETERMINISTIC UNIFORMLY WEIGHTED BIT STREAMS
Nitish Patel and Sing Kiong Nguang
www.ijicic.org/05-050.pdf

... my idea was a split way:
-'solderfree' developing on FPGA with simulating discreet IC's and modules, so when ready, the shematics could be published - so the 'normal' user could solder his PCB's as published ...

The other direction is 'playing' with new concepts and technologies which can be transferred into the design - here the promise of solderfree 'evolvable' electronics was the point ...

Viktor

Certainly getting off the ground with SPI based peripherals is a winning idea.

The magnetic encoder board has a SPI interface that is not currently used and offers a bunch more useful functionality.

There are also many more SPI peripherals out there ie 20Bit A to D etc.

Picking a serial buss interface as a standard and then developing peripherals for it is a very good way forward over all I feel.

Whether you stick to discreet ASIC's, CLPD's or integrate it all onto a single FPGA device is actualy irrelevant and open to your personnal preference.

On FPGA development boards the most cost effective solution is to design your own open source board for this project. The same for CPLD parts too. The fact that the Arduino is fully open source is what makes it cost effective.

The PCB's etc from the RRRF are cost effective for similar reasons ie Open Source + suficient demand.

Re interfacing and development the current easiest way is to design in a USB interface to the FPGA board itself. the FTD2232 has two interfaces one for the host/system comms and the second would be the dedicated JTAG interface.

Once you have JTAG you have ICSP and ICE.

No other cables or adapters necessary.

This opens up the rest to open source development of the programmable logic parts.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

Certainly getting off the ground with SPI based peripherals is a winning idea.

The problem with SPI is the requirement for lots of IO pins... two plus one per slave device. A centralised control board is going to have to use up lots of pins to support a handful of peripherals.

It is mainly of interest because there are a few relatively complex devices that can't conveniently be accessed in other ways.

Bus based networks (1 wire, I2C, CAN, etc) are desirable in that they eat up fewer pins for more attached devices... but there's a whole other thread about networking so I won't rehash all of that

(Incidentally, CAN is a very nice protocol, but implementing it in softcore logic may require licensing from Bosch, which is one reason to avoid it)

Last time I counted such things pin numbers required for CS of slave peripherals ran at :-

Num Pins - Devices
1 - 2
2 - 4
3 - 8
4 - 16
5 - 32
etc etc etc

Unless you are feeling very wasteful.

How many devices do you want ???? 8 pins allows you 256 devices.

If you are again struggling for pins then larger programmable logic devices have it...

Can is'nt really suitable for inter IC connects over short haul. Much too much complexity for something that should be simple and fast, particularly if you want to play with the restricted resources of CPLD's.

Given that the current trend with the development of the control electronics is towards centralization and more features per board. It is clear that the trend is currently away from the networked boards of the first generation.

Again bringing you back to the questions :-

How do I get more, in less space for less cost???

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

It is clear that the trend is currently away from the networked boards of the first generation.

I am not at all sure that this is a good thing, for reasons that I've listed elsewhere, but to summarise: simple and modular is good, toolhead logic belongs on the toolhead.

Monolithic firmware and huge, expensive and complex control boards capable of doing everything under the sun do seem to be the opposite of this.

I always envisaged pushing much of the logic out to toolhead specific controllers. Any commands the control board did not recognise would be passed on to the toolhead. A simple toolhead-controller protocol would be required to announce things like z-offsets for different lengths of toolhead, or whatever.

The controller board need never care about thermistors or quadrature encoding. The touch probe need never care about PWM control. The pick'n'place head might know about interpreting 4th axis movement codes, but nothing else needs to.

Big reduction in IO requirement and complexity and expense of any one board. Also where CAN is useful, because we are not doing inter-IC comms here... we want a nice high level protocol with addressing and error correction and so on to talk to a network of periphers on separate boards.

But I've already gone on too long and repeated what of I've said elsewhere.

I think if that is what I wanted I would be buying Zigb modules and do away with the wiring all together other than for power.

They have io on them already and use an atmel atmega processor.

See:-

[www.radiocrafts.com]

Can has it place/s I am not sure this is one of them.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

You're looking at a vendor lock in problem there. What if they stop making them??

Also, RF comms could lead to unreliable or poor motion control. Although we're not looking at high performance motion, a few hundred milliseconds of radio downtime could really mess up your build. I suppose this applies to any comms scheme: delay => unhapiness.

If people want to get into high performance servo control, it becomes necessary to add cross axis coupling channels to the motion stages to improve the motion, which would probably saturate most comms systems. (Say 2*16 bits per axis * 15000 samples per second = approx 500Kbit/sec). Any takers.....?

The notion of intelligence on tool is a good one, though.
I was distantly involved in a health and safety investigation of a major CNC mill accident a few years ago, where the operator manually loaded the machine with a boring bar and the mill tried to spin it up to 3000 RPM. It broke apart under the stress and shrapnel went through the operators door and then killed the poor guy. This was all due to a fairly subtle programming issue, and if the toolhead had known that it couldn't go that fast he'd still be alive. Fortunately RepRap energy levels are nowhere near this high, but we could still end up with wrecked builds or fires.

I like the thought of minimum connections - particularly if using a multiple toolhead system - but once you're moving 2 wires adding another pair shouldn't be that hard. Maybe some form of auto plug with multiple pins?

Vendor lock in and product obsolescence are what you are trying to avoid by going programmable logic.

Or greatly reduce your susceptibility to......

(Vendor lock in, is correctly speaking, a ransom position occupied by a vendor who has a form of marketing hold over the consumer and generally exploits it, ie Camera Lenses, Inkjet Cartridges, Smart Batteries, RP Consumables etc)

You have the same question re Atmel, Dallas Semiconductor, Intel etc.

What if they stop making it/them. What if they come up with the excuse that supply is short, demand is high and therefore you are going to pay 4 times the price per device.....

What can you do about this ?????

Not only do you have to construct new hardware but you have to rewrite/port all your software.

If you are running on a soft core and soft peripherals they cannot be retired by a vendor.

Yes the device your running them on can be vendor terminated, but then you use another vendors device. The code for the programmable logic transfers very easily.

Freedom is generally something you have to make or take, No one with a vested interest (Particularly Financial) will ever give it to you.

In a very real way Vendor Lock In and Product Obsolescence are something you are making yourself free from by degrees when you build a RepRap. You are taking back your freedom to choose, modify & innovate without someone else trying to abuse your want/need to their advantage.

For me personally the next technology we use is as much about what RepRap is about as it is about the technology.

Thoughts for what they are worth.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

I think if that is what I wanted I would be buying Zigb modules

At 40USD per radio module, I doubt I'll be joining you in that any time soon! It would indeed be a very sensible idea, were it not for the cost.

Quote

Can has it place/s I am not sure this is one of them.

I really cannot see what your aversion to CAN is. It uses differential signalling so it will be capable of communicating between boards even in the presence of a moderate amount of EM noise. If offers addressing of more devices that you'd want to attach to a single reprap at once. It has a sensibly designed communications scheme to allow multiple devices to share a bus and deal with comms arbitration. The protocol itself gives a nice packet-like format which is easy to understand and handle, and very lightweight (compare it to ethernet, for example). It also offers a hell of a lot of bandwidth if needs be.

The only problem I have found with it is the need to have it licensed before implementing it in softcore logic. That's all. And you can get discrete tranciever modules for as little as

If you want a multi drop buss and packet structure with differential signaling there is plenty of hardware out there to do it, that is not can.

Protocol engines, stacks and state machines are not particularly difficult to construct.

FPGS ie Xilinx Spartans and those offered by other vendors come with LVDS transceivers inbuilt for no extra cost.

RS485/422 is pretty much well defined, electricaly resilient, cheap as chips and been around for years. (I was using it 18 Years a ago for multidrop instrumentation, in noisy environments).

[para.maxim-ic.com]

Addressing is down to the implementor to define and you can make it as large or small as you want.

Packet structure and protocol is down to what you write. You only need to implement what you need and certainly no more.

No licensing at all. Why pay any license for something you don't need. Why take a chance on the licensing/IP police choosing you for their example to terrorize the masses.

I actually don't have any aversion to CAN whatsoever, it's simply a case of horses and courses. For me personally CAN is not the horse for this course.

It's a bit like saying everyone should own a Hum V because it can go anywhere any time. When the actual application is take the kids to school and a walk or a small lightweight car is perfectly adequate for the application.

On a more direct note I can (no pun intended) honestly say I don't understand your obsession with CAN for this particular application (sorry but it shows). You are however as entitled to your opinion as I am to mine.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

your obsession with CAN

I'm bringing it up now precise because you're being so discouraging.

But since you mention it, it is cheap and hardware support is common.

Quote

it's simply a case of horses and courses. For me personally CAN is not the horse for this course

So what is the course that CAN is suited for? I simply cannot see why it is not suited to reprap. It is simple, lightweight, and very readily available.

Quote

Why take a chance on the licensing/IP

Given how common CAN hardware is, licensing is not a problem. Legitimate hardware can be purchased cheaply.

Quote

RS485/422 is pretty much well defined, electricaly resilient, cheap as chips and been around for years

This is very true. It is an ideal physical layer, but it is not a complete protocol...

Quote

Protocol engines, stacks and state machines are not particularly difficult to construct.

...but given that I don't *need* to contruct them, what is the incentive for spending my time doing so?

We still appear to be missing the point.

"It's a bit like saying everyone should own a Hum V because it can go anywhere any time. When the actual application is take the kids to school and a walk or a small lightweight car is perfectly adequate for the application. "

Clearly if you own a Hum V you don't *Need* to walk, You don't *Need* to have a lightweight appropriately sized vehicle.

If your thing is to take your kids to school in a Chelsea Tractor, be my guest, get on with it, do it.

If CAN is your thing, be my guest, get on with it, do it.

Is it the right tool for the Job, I don't think so. Will I be actively selecting it as an appropriate solution for board+ level interconnect problems, I don't think so. Simple as that.

Is a Hum V the right tool for the Job, I don't think so. Will I be actively selecting it as an appropriate solution for taking my kids to school, I don't think so. Simple as that.

As I said horses and courses...

Do I use a chisel as a screwdriver, ummmm never.

Do I uses a screwdriver as a chisel, ummmmm never.

Will I ever choose CAN as a board+ level, interconnect solution. ummmmm never.

Would I choose as a board+ level interconnect 422/485 possibly, SPI pretty certain, I2C yup, 1 Wire yup, etc etc etc.

Would I use a screw driver to put a screw in, ohhhh yes. (Picture winston the head wagging dog)

Would I use a chisel to cut a mortice in my door frame, ohh yes. (Picture winston the head wagging dog.

That's the way it is for me.

That it' is'nt this way for you, I can't help you with. Sorry.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I'm still not seeing why you think it is inappropriate. You're using lots of metaphors, but they aren't actually casting any light upon the subject.

Why are you likening it to a humvee?

You clearly have experience in this area, which I do not. I would genuinely like to be enlightened in this area.

You seem to be implying that it is overkill, but that implementing your own network stack upon, say, RS485 is not. There seems to be a contradiction here. If you could explain why CAN is a bad thing, without resorting to metaphors, I would be quite grateful.

I have already discounted the protocol for licensing reasons, but every other facet of CAN seems ideal, as I've already said. What is it that I am missing?

editted for lousy typing

Edited 1 time(s). Last edit at 09/03/2008 09:26AM by Ru.

Viktor

"In the actual german c't-magazine ( [www.heise.de] - should be next week online ) we have a project with PCB and software, where a Xilinx Spartan3-FPGA is surrounded by an ATmega-Controller with a 128MB-SD-card for the different configurations, so you can develop and swap all types of custom electronics."

I have had a quick look through this do they do English versions ??

Sorry my German is somewhat challenged.

The magazine article I would like to see, it sounds remarkably similar in spec to the FPSLIC from Atmel. It would be fun to see if someone has done it in a more discreet way. Particularly to see what the cost comparison to the FPSLIC is.

I like the idea of virtual circuit development using programmable logic too. It is after all what they are all about.

The main attraction for programmable logic solutions for me is the ability to have several completely different motion control solutions but using a greater degree of common electronic control hardware.

Take for instance A machine using any of the following:-

1. Servo Controlled DC Brushed motors
2. Servo Controlled DC Brushless motors
3. Servo Controlled hydraulics
4. Stepper Motors without positional feedback
5. Stepper Motors with positional feedback

If you attempt to do this with dedicated discrete IC's there would be very little comonality.

Using Programmable logic however you should be able to push the differences right back to the signal conitioning and power driving.

The middle technology specific bit loaded into the programmable logic according to what your motion control solution is.

It certainly opens up the field for more experimentation with circuit design and controller concepts as well as broadening the options for RepRap bots. With far less PCB hacking and component sourcing.

Thoughts for what they are worth.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Hi Andy,

... didn't find it in english - here the german link with the BOM: [www.heise.de]

And here the ordering site with costs (complete kit nearly 100 Euros): [cgi.segor.de]

Viktor

*** Edit: the SMD-parts are already pre-soldered in the kit ...

Edited 1 time(s). Last edit at 09/03/2008 09:11AM by Viktor.

A Hum V is to the school run what a network stack and protocol is to connecting a couple of IC's together at board+ level.

Compare and contrast SPI to CAN in terms of Memory Usage, Processor Cycles, Power Consumption et al and the above metaphor is extremely clear.

I guess it is in the names.

Serial Processor Interconnect (Board + level Interconnect)

versus

Controller Area Network (Controllers Spread about an Area+ level Interconnect)

The topic is discussion around programmable logic, specifically Soft processor core versus Dedicated Hardware Processor on/off die. with a side line on one FPGA versus a farm of CPLD's,

Or at least that is what I understood it to be, I am happy to be told that I have got the wrong end of the stick and apologize in advance if this is not the case.

On CAN versus the world that's it for this topic from me. I would rather discuss programmable logic.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

Or at least that is what I understood it to be, I am happy to be told that I have got the wrong end of the stick and apologize in advance if this is not the case.

Ahh, we do appear to be talking at cross purposes here. I was interested in a network between boards with smaller CPLDs on each board, rather than on-board peripheral interconnect with a single large FPGA. Reading back, I note we both mentioned what we were looking at, which we both evidently missed. Oops

Hmmm

Interesting article...

I pushed it through Google's translate page. The translation is very literal but I can pretty much get the idea and the Schematics clear up the bits that don't translate at all well.

We could probably do quick and dirty equivalence using a three layer approach.

Top Layer, Arduino (quickest easiest route to Host connection with some inteligence) soketed vi it's io headers to :-

Middle Layer, FPGA Board with unused arduino io pins led out along side the fpga's io pins via headers that allow this board to plug into :-

Lower layer, PSU, Signal Conditioning and Drivers/Pre Drivers

Pretty much a quick and dirty approximation.

As they point out (And why my initial design ideas used the same device) the lower pin count XIlinx Spartan 3E devices (Not the BGA variants) use QFP. effectively a very fine pitch gull wing style lead format that can be soldered by hand if you are skilled enough and have a small enough hot air soldering tip. (I have done SMD with a 1mm Soldering Iron bit before now) You do loose some IO pins but you still have the same internal count etc.

I guess you could get away quite comfortably with a Boarduino or one of those very tiny ones that fits a DIP socket.

BitBanging of SPI is fairly straight forward. I think the PIC folk actually cover it in an application note and provide libraries in my C compiler for it as well. JTAG is a bit more fun.

Not entirely sure I would want to go this way though, feels a bit messy....

What do you guys think ??

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I still can't see the need for an FPGA to do motor control. Just pick a micro that has all you need, e.g. STM32 Cortex. Its cheaper and simpler.

---

[www.hydraraptor.blogspot.com]