Whats better for extra I/O, data bus based or I2C?

[Cloud9TN]

Whats better for extra I/O, data bus based or I2C/SPI?
I need lots of I/O on a project. What are the pros and cons of expanding my I/O with I2C vs the old style of using an 8bit wide data bus? Whats faster? Whats easier to design? Whats easier to write firmware for?

I do realize I get interrupts with some I2C/SPI I/O modules which is nice.

I think I would like to go with an FPGA for expandability but I havent had good luck with that so far. None that I have tried have a tri-state bus primitive. Even VHDL (copied from multiple sources) was not able to work to implement a 3state bus.

The ultimate project is going to be 8bit micro (most like 8032based).

 

[Noway2]

Are you trying to start a flame war or what? Be prepared for multiple, wildly differing opinions. Here is mine.

The answer to most of your questions (what is faster, what is easier, etc) is that it depends. It depends on the architecture and features provided by your hardware. For example, if your processor supports an external memory interface, writing a data bus style interface could be the easier approach.

The question of which is faster also depends and the answer isn't clear cut. I2C is a multi drop half duplex serial bus, which means that data is transfered one bit a time, with only one device transmitting. Data will have to be broken up into a frames or packets and there is some overhead associated with this. On the other hand, a parallel bus has limitations regarding the clock rate, setup and hold times, bus loading, etc. In the end, an actual analysis of your proposed hardware will be required.

An FPGA is an excellent means to provide expandability for a design. I even read an article in Embedded Systems Programming a few years back that showed statistically that a large percentage of "successful" projects were so because of their ability to adapt to future needs. It then pointed out that most of designs provided the expandability via an FPGA.

I am not quite sure what you mean by most of the ones you have tried do not have a tri-state bus primitive. Whether or not they have this exact primitive isn't really the important part but rather whether or not the device supports tri-state capability on the IO. If the device supports tri-state IO, you can build a tri-state bus. The syntax will depend on which platform you choose. In some it can be as simple as designating the bus attached to the tri-state device as being 8 bits wide (e.x. Altera in schematic capture).

 

[itsmoked]

Both I2C and SPI have their specific abilities and hassles.

You can run I2C with less lines. I2C is a far bigger PITA to hand write than SPI.

SPI can run way faster than I2C.

I2C tends to have bigger available memories.

I2C will let you pile on a few more chips fairly easily. SPI often needs a separate chip select for every added chip.

You typically find the I/O chip you need then provide the protocol it requires.

You said I/O several times. This means input and output pins - no real functions like memory, or an A2D, or DAC, or RTC. If you really only need I/O then don't use either SPI or I2C! Just use shift registers. Much easier and less hassle.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[benta]

Go with SPI. I2C has a limited number of adresses, which often gives problems.
Outputs you can do dirt cheap with 74HC595, there is another 74HC-something for inputs, don't remember which one.
Concerning too many chip-selects, you can limit this by daisy-chaining your devices.

Benta.

 

[MacGyverS2000]

As with anything, if you want speed, go with a direct connection. Anything beyond that trades off speed for functionality.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[zappedagain]

What defines 'lots of IO'? How much?

Xilinx CoolRunner CPLDs have tri-state capability.

How fast do you need the IO to switch? If is fast a CPLD/FPGA is probably a good fit; if it is slow you can do it with multiplexers and a micro.

 

[Cloud9TN]

Hi All. Thanks for the great input! My IO is just general purpose stuff, read a few switches here, control a few actuators there.

Additionally, I have to read 2 16-bit counters on a bus (or whatever we decide is best). I am sure this 16-bit count will be 2 cascaded 8bit counters.

In the old design a data bus was interfaced to an XC3042 FPGA which handled 90% of all IO with some application-specific circuits in there as well.

I have heard of the coolrunner but it seems like I checked it out before and it didnt do something I wanted, perhaps the tristate. My problem trying to implement tristate on an FPGA (Xilinx Spartan) was frustrating. When I say a tristate primitive, I mean like a component I can just drop in an FPGA schematic to get the functionality. I looked at several different examples of VHDL implementation of the 3state but it would never compile for me. I will have to dust of my Xilinx softare to recall the actual error message.

I think the bottom line speed doesnt have to be blazing but swift. If I can set an output within 200mS I will be happy. For reading the input, I can handle up to 400mS because any important 'read-it-NOW' inputs can be put right onto the processor.

This project registers where a bullet strikes a target by using triangulation of the shockwave. Neato. See attached pic.

Thanks again for all of your time and wisdom!

 

[analogkid2digitalman]

Like these geeks did? Cool LabVIEW application.

http://www.youtube.com/watch?v=WNZCS-coZjY

Here's the LV source code and description of algorithm:

http://decibel.ni.com/content/docs/DOC-6106

Happy Shooting

-AK2DM

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"It's the questions that drive us"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Cloud9TN]

Well thats pretty neat. I actually thought about going that route once upon a time. The catch-22 is that if you shoot through a bullet hole, you get no or irregular data. We require at a minimum 2000 shots on a target silhouette before we scrap it. Plus our target can only be about 2x4ft. Additionally, we cant have exposed sensors...they'll be shot.

Our method uses non-contact based results. We can detect the bullet in a 2d plane in space. We use curved rods with piezo xducers that are triggered by the shockwave of the bullet breaking the sound barrier. We use time diffs to calculate an arc length on the rods. Then the arc length and radius is used to calculate an angle and a slope. Those values from the 2 different rods are used to find an intersection point.

The math is staggering but not nearly as baffling to me as making a solid circuit to replace our old out of date system. I am abit out of my league. I am a jack-of-all-trades (master of none). I do the firmware/software programming,electronic design/layout, testing, troubleshooting, as well as work the company IT... sheesh, HELP. And as always with my company, the timeframe to complete this is RIDICULOUS! We have to deliver in March :/

I just gotta buckle down and take all the advice I can get. A couple engineers in my pocket wouldnt hurt either.

 

[zappedagain]

For a Xilinx CPLD, such as the cool runner, look in the 'Language Templates' under the <Edit> menu in ISE. Here is a VHDL example of a tri-state for a CPLD:


-- OBUFT : In order to incorporate this function into the design,
-- VHDL : the following instance declaration needs to be placed
-- instance : in the architecture body of the design code. The
-- declaration : instance name (OBUFT_inst) and/or the port declarations
-- code : after the "=>" assignment maybe changed to properly
-- : connect this function to the design. Delete or comment
-- : out inputs/outs that are not necessary.

-- Library : In addition to adding the instance declaration, a use
-- declaration : statement for the UNISIM.vcomponents library needs to be
-- for : added before the entity declaration. This library
-- Xilinx : contains the component declarations for all Xilinx
-- primitives : primitives and points to the models that will be used
-- : for simulation.

-- Copy the following two statements and paste them before the
-- Entity declaration, unless they already exist.

Library UNISIM;
use UNISIM.vcomponents.all;

-- <-----Cut code below this line and paste into the architecture body---->

-- OBUFT: Single-ended 3-state Output Buffer
-- All devices
-- Xilinx HDL Language Template version 8.2.2i

OBUFT_inst : OBUFT
generic map (
DRIVE => 12,
IOSTANDARD => "DEFAULT",
SLEW => "SLOW")
port map (
O => O, -- Buffer output (connect directly to top-level port)
I => I, -- Buffer input
T => T -- 3-state enable input
);

-- End of OBUFT_inst instantiation


Xilinx has some nice tools in ISE where you can do a design via schematic if VHDL or Verilog isn't for you. ISE is pretty nice for a free tool.

John D

 

[Cloud9TN]

John,
Thanks so much. I'll have to give that a try. I notice you use the variable T to represent the 3state select.

T is the actual line (input) correct?
So I can set the output O to any of these values:
0,1,'Z' correct?

I dont remember exactly the syntax but I was trying something along the lines of:
if (T = 0) O => 'Z'
else O => I;

I really need to dust of my ISE so I can share some of the actual output of the errors I get as well as the code I tried.

Oh and my ultimate plan, since VHDL isnt down my lane, was to create a top-level component using the VHDL then use it in the schematic entry. I have the complete logic schematic of what I need, so it would simplify what I am trying to achieve.

Thanks.

 

[Cloud9TN]

So I pulled out ISE. My error is Signal is connected to Multiple Drivers. That doesnt help... I am aware of that since its 2 tristate OBUFE's connected to an output pin (on purpose even).

I read this on a post:
Of course you can assign 'Z' to a signal. But you should follow the rules laid it in the synthesis guide. First and foremost, the signal must be a port pin. It cannot be an internal net. (As I noted, tristatable lines are not in any recent Xilinx device -- I think the old XC4000 series from over ten years ago was the last to have them.)

Well this makes since. We did exactly this 10 years ago on a XC3042. So if I cant do internal tristates.. then what?

I plan on having lots of data (a few 8bit counters, some latches) all sharing the same 8bit data bus (they get addressed and decoded to activate). If I cant do it internally, I have to bring all ports out of device seperately and connect externally? No way! Thats too many pins.. at least 40-48 bits of data.

Please note simplified. sch picture attached.
And please tell me I am overlooking something silly.

 

[Noway2]

The lack of internal tri-states makes sense from the standpoint that it is physically part of the (output) driving buffer, not part of the internal net.

If Xilinx devices won't meet your needs, for example doesn't support bidirectional or inout buses, consider using a different brand that does such as Altera.

Even if you decided to stay with brand X and it doesn't support bidirectional buses (which I would find hard to believe) you can run two buses internally and then use a tri-state on the output to only ensure that you drive the output pins at the right time.

 

[zappedagain]

You are correct, my example is only for an output pin, not for use within the IC. Xilinx has a forum that may get you better answers to this; there are some pretty good power users on that site that have helped me in the past.

http://forums.xilinx.com/xlnx/

While I don't know the solution, this seems like something that they must have support for, otherwise everybody who encounters this would be switching to other brands as Noway2 suggests.

John D

 

[zappedagain]

Xilinx does have primitives for internal tri-state buffers (buft). I compiled a quick design and it works fine.

ISE complains it has to use a 'wired-or' connection but it synthesized properly.

John D

 

[Cloud9TN]

Thanks again for the input.

John, I see the difference between my sch and yours is OBUFT vs BUFT. Unfortunately, the Spartan3AN (which i have) and CoolRunner2 (which I am considering) do not have the BUFT primitive. Doh!

Makes sense, OBUFT is for output pins only!

May I ask what device you built and synthd that sch for?

As a work around I am thinking about using a MUX8 ( i have 6 different data[x]'s - leaving 2 unused bits per mux). The only thing I dont like is that I will need to use 8 of those, one for each different bit on the bus.

Does this sound feasible?

 

[Noway2]

Before you go a route like that, give a call to your local FAE. I guarantee that someone else has had this very problem with these devices and I am certain that there is a solution. In addition, look on the forums and the knowledge base. If all else fails, you really should consider a different brand. Xilinx isn't the only reputable device and isn't the only one with free tools.

 

[zappedagain]

That was for a device from the XC9500XL family.

A mux is a good solution too; that way you eliminate the wired-or.

Avnet is my local rep for Xilinx; they have some very good FAEs on staff.

John D