6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Apr 25, 2024 11:52 pm

All times are UTC




Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Fri Sep 26, 2008 4:35 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
GARTHWILSON wrote:
This board is actually two projects, with the five ICs at the right end being a circuit to let me use a VIA's serial port to put raster graphics on an analog oscilloscope. It was cool the first time I was able to put a paragraph of text on a totally analog 'scope! It uses the Z-axis input to turn the beam off and on.


Complete off-topic, but, any chance you have a collection of pictures of this thing in action?

Thanks.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Sep 26, 2008 6:20 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8427
Location: Southern California
Quote:
Complete off-topic, but, any chance you have a collection of pictures of this thing in action?

As I wrote about it, I was thinking that I should take pictures of the screen with it working. I have not done that yet. It's one of many projects lacking from my project pages on this site. Some of the project pages that are there need to be updated.

The beam on the oscilloscope is not nearly as fine as what's on my monitor in front of me, so I have to give it only about 128 dots across and about 100 down on the 8x10cm CRT screen. Since it's a normal oscilloscope however, you can pan and zoom with the front-panel knobs.

I got it going in Forth with code to generate characters (upper and lower case, plus special characters) by looking up the dot patterns in a table and putting them in the video array which gets sent out the VIA shift register repeatedly. The idea, for next time I want a graphics display with the workbench computer, is to also write drawing routines for instrumentation graphics like a spectrum analyzer display for example, with various points labeled in text.

The VIA's shift clock output increments a counter whose output goes to one D/A converter. That controls the left-to-right position of the scanning beam. I'm not using the oscilloscope's internal time base. The serial data output goes to the Z-axis input, to turn the beam off and on. When the counter for the left-to-right position rolls over, it increments another 8-bit counter whose output goes to another D/A converter that governs the vertical position of the beam, to start another line. One more VIA output bit is used to reset both counters at the start of each frame.

In the picture, the RCA jack goes to the Z-axis input on the back, and the two oscilloscope probes get clipped to the four little posts seen at the right edge of the proto board. Since the horizontal position of the beam is governed the the D/A output instead of the oscilloscope's internal time base, the workbench computer has total control of the data and sweep rate. If you stop the data briefly, all the dots will still be in their correct places, but the one dot it was on when you stopped will appear brighter.

I can't scan as fast as I would like to because the Z input on the scope does not have high enough frequency response, and the picture gets smeared if I try to scan too fast. As it is, if I use a suitable scan rate for the Z input's response speed, and go for too many lines per frame, the frame rate gets too slow-- more than just a noticeable flicker. It's better if I limit the vertical to only 64 lines. Someone gave me another oscilloscope that I hope has a better Z input, but I haven't had a chance to try it yet. Another thing I should try is interlacing, which would require a small change in both the hardware and the software.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Sep 26, 2008 7:24 pm 
Offline

Joined: Tue Nov 18, 2003 8:41 pm
Posts: 250
GARTHWILSON wrote:

I can't scan as fast as I would like to because the Z input on the scope does not have high enough frequency response, and the picture gets smeared if I try to scan too fast. As it is, if I use a suitable scan rate for the Z input's response speed, and go for too many lines per frame, the frame rate gets too slow-- more than just a noticeable flicker. It's better if I limit the vertical to only 64 lines. Someone gave me another oscilloscope that I hope has a better Z input, but I haven't had a chance to try it yet. Another thing I should try is interlacing, which would require a small change in both the hardware and the software.


I suppose you know this already, but I'll mention it just in case.

They used to do it with just rectangular waves such that the
"pixels" are the tops/bottoms of the wave and the beam in between
gets swept (vertically) off the screen (or to the bottom/top of the
screen) too fast to see, (though in my experience the vertical part is
usually not completely invisible)


Add another DAC and do vectors


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Sep 26, 2008 8:28 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
Obligatory video of someone employing Bogax's approach:

http://www.youtube.com/watch?v=s1eNjUgaB-g


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Sep 26, 2008 9:11 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8427
Location: Southern California
Quote:
I suppose you know this already, but I'll mention it just in case.

They used to do it with just rectangular waves such that the
"pixels" are the tops/bottoms of the wave and the beam in between
gets swept (vertically) off the screen (or to the bottom/top of the
screen) too fast to see, (though in my experience the vertical part is
usually not completely invisible)


Add another DAC and do vectors

Yes, I laughed when I saw how simple the oscilloscope readout was for one of the vintage computers, maybe the Sym-1. They used a sawtooth wave and pulled the line to the bottom when they didn't want a dot at the particular height of the wave at that point. They could only do one line of text though, whereas I can do a dozen or so lines of text, plus any raster graphics (as long as it's monochrome and without gray scale). I've done minor vector (non-raster) graphics with a quad DAC on another board. There's one DAC built into the workbench computer, and I've thought about adding another.

MrLinuxGuy, please feel free to take back your thread which we kind of hijacked. If you would like, we can start another topic and take the oscilloscope graphics discussion there (although I'm not sure there's much more to discuss at the moment).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Sep 27, 2008 4:53 pm 
Offline

Joined: Fri Sep 19, 2008 8:06 pm
Posts: 17
Location: Bordeaux, France
Quote:
MrLinuxGuy, please feel free to take back your thread which we kind of hijacked. If you would like, we can start another topic and take the oscilloscope graphics discussion there (although I'm not sure there's much more to discuss at the moment).


Ah, I don't mind. It's an interesting read anyways. If you want to move to another thread, go ahead, but feel free to stay here. My dad has an old oscilloscope as well and I was also wondering how to send images/text to it.

Another question: Why doesn't the WDC have their 6551 chip out for sale yet? I mean, its not a real problem (I can always get a 6551 from Jameco or some other electronics supplier), but I read a thread made 4 years ago, and it said it was coming soon.

PS: I hope you don't take offense in this, but to see that picture of those stacked up RAM modules made me chuckle. I'd never thought of that, and I have never seen something a simple and ingenious (although a bit awkward) as that :). Consider it a compliment.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Sep 27, 2008 6:27 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8427
Location: Southern California
Quote:
Why doesn't the WDC have their 6551 chip out for sale yet? I mean, its not a real problem (I can always get a 6551 from Jameco or some other electronics supplier), but I read a thread made 4 years ago, and it said it was coming soon.

They have the 65c51 available in samples, but the bug on page 33 of the data sheet is apparently still keeping them from considering it ready for full production. Take a look and see if you can put up with it. The other brands won't be good for nearly as many MHz. You can also use other UARTs, like the Maxim SPI MAX3100 which is smaller (14-pin DIP) and, in general, more capable. Being SPI, you'll have to bit-bang it through a VIA (until Daryl finishes his 65SPI CPLD [Edit: It's available at http://sbc.rictor.org/65spi.html]), but that's much simpler and faster than bit-banging RS-232, and without the timing requirements, and the MAX3100 has an 8-byte buffer anyway.

The IC-stacking has not been a regular practice for me, but it's more attractive sometimes than wire-wrapping more sockets and taking more board space. I have a stack of two half-flash A/D converters too, which you can essentially read voltages from as if it were a couple of memory locations, as long as you don't go over a MHz or so. Being that fast, you don't have to tell it to start a conversion and then come back later when it's done.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Sep 27, 2008 7:56 pm 
Offline

Joined: Fri Sep 19, 2008 8:06 pm
Posts: 17
Location: Bordeaux, France
Quote:
They have the 65c51 available in samples, but the bug on page 33 of the data sheet is apparently still keeping them from considering it ready for full production


That bug wouldn't bother me a whole lot, but I think I will just use the MAX3100 for the moment. Maybe when they get it fixed I'll see if I can implement it.

Quote:
Being SPI, you'll have to bit-bang it through a VIA (until Daryl finishes his 65SPI CPLD), but that's much simpler and faster than bit-banging RS-232, and without the timing requirements, and the MAX3100 has an 8-byte buffer anyway.


I'm guessing bit banging through a VIA means that I'll have to use the VIA as a proxy from the MAX3100 to the 65826, right? (and the MAX3100 should be connected to a MAX232 Line driver/receiver). Maybe I should add another VIA to my system, because I'm already planning on using at least 1/2 a VIA for the keyboard, and now another 1/2 for the serial communications.

As for the keyboard, I'm looking to either go Apple IIe-style (a matrix of keys, if I do remember so), or connecting a PS/2 keyboard to it. Hopefully I'll be able to find something that isn't power hungry, although keyboards have never had a reputation of being so.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Sep 28, 2008 3:17 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8427
Location: Southern California
I'm not quite sure what you mean by "proxy," but it does sound approximately right. If you put the clock line on PB0 or PA0, you can toggle it with INC/DEC PB or PA (with A in 8-bit mode) after you start with it in a known state, without chaning the other bits. It's not necessary to AND and OR them. If you make your data-in line to the master (MISO) a bit 6 or 7, you can test it with BIT, again without ANDing, and do a conditional branch immediate following the BIT instruction, with no concern for what's in A at the moment, and without affecting A, X, or Y.

I would not stop at one VIA for a computer, but I will say that one VIA can be used for a lot more things simultaneously than most people realize. If you have 3 bits of I/O dedicated for serial I/O, plus let's say three more for SPI selects, that lets you use 7 SPI devices and a load of I²C devices (UARTs, A/D and D/A converters, keyboard controllers, display drivers, serial memory, hundreds of bits of I/O, etc., and you still have more than half the VIA free. A lot of things can be doubled up, since bits can be toggled on connected devices that are not selected at the moment. On a single VIA, I have a synchronous serial port (the SR) for dumb shift registers, the timer (T1) for the software RTC, the printer port, LCD interface, keypad interface, beeper output, I²C port, and ABORT button input (like a RESET button, but not as drastic since you can get the processor's attention with an NMI without resetting all the hardware), and a few of the bits are shared with other interfaces (like the oscilloscope raster graphics). The other two VIAs are only used for half as much stuff and are more free for non-dedicated I/O.

The MAX232 is what many people think of first for RS-232 line drivers and receivers, but there are lots of ways to accomplish the same purpose. For example, if you already have ±12V (or anywhere near it (like for LCD bias, supply for op amps for data converter input and output, etc.) you can use the MC145406 which needs no external parts and has three line drivers and three line receivers, instead of two, in the same size of package. Or, if you are on a super-tight budget, the 1488 and 1489 pair give four pairs of drivers and receivers for about twenty-five cents per IC, and again require no external parts like the MAX232 does.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Sep 28, 2008 7:55 pm 
Offline

Joined: Fri Jun 27, 2003 8:12 am
Posts: 618
Location: Meadowbrook
if you REALLY want to go cheap, and you have +-12 volts, use 2N3904 transistors to bias and invert :)

_________________
"My biggest dream in life? Building black plywood Habitrails"


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Sep 29, 2008 6:08 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
From www.ntia.doc.gov/ntiahome/ntiageneral/i ... ossary.htm, a proxy is:
Quote:
A device that acts on behalf of another device by taking on its identity to interact with the outside world.
A more general meaning of proxy is any entity which operates on behalf of another when interacting with still another. A go-between. Something which isolates. Etc. (E.g., opto-isolators can be thought of as proxies for wires -- they do the same basic job as wires, but there is an isolation between either side of it.)

In this case, the VIA is a "proxy" because the 65xx isn't driving the MAX3100 directly; instead, it's driving it via the VIA (heh, always wanted to write that).

In fact, all peripheral chips serve the roll of proxies -- they literally adapt one interface into another, more standardized interface more suitable to the processor's (or software's) liking.

You can also have software proxies as well -- this is the foundation of all remote procedure call systems, including DCE RPC, CORBA, DCOM, and SOAP systems. Even in single address space environments, proxies are often quite useful for loading and saving data from/to files on-demand, making for quicker disk I/O. You'll find many object oriented environments usually have some standardized method of "serializing" object state into some generic concept of a stream. These streams could well be disk files, but they could also be network connections, for use in RPC systems. DCOM is built this way, for example.

Anyway, I thought I'd clear up the use of the term, plus show how the term is analogously applied in other areas too.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Sep 29, 2008 7:24 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8427
Location: Southern California
The word "proxy" is not new to me, but I didn't feel I had a clear idea of what Mr.Linux had in mind in his question.

If we go with this definition
Quote:
A device that acts on behalf of another device by taking on its identity to interact with the outside world

then I'd have to say "not really," because the VIA won't "look like" the MAX3100 at all. The definition above bears more resemblance to an emulator. (And no, I don't mean a simulator which is software only and is what people often erroneously call an emulator. An emulator includes hardware.)

If we go with this definition
Quote:
any entity which operates on behalf of another when interacting with still another. A go-between. Something which isolates.

then yes. But the SPI bit-banging is only a distant relative to the RS-232 bit-banging. It is much simpler and faster than RS-232, and leaves much of the real work for the MAX3100 to do. Are you familiar with SPI, Mr.Linux? SPI, I²C, Microwire, and other synchronous serial methods are super-nice solutions for a lot of interfacing problems.

Garth
Microsoft-free, with Linux


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Sep 30, 2008 7:33 pm 
Offline

Joined: Fri Sep 19, 2008 8:06 pm
Posts: 17
Location: Bordeaux, France
Quote:
Are you familiar with SPI, Mr.Linux? SPI, I²C, Microwire, and other synchronous serial methods are super-nice solutions for a lot of interfacing problems.


Err, I daresay I only know what they are in rough terms. Its basically, instead of sending the data at regular time intervals over a parallel bus or the sorts, you simply send it like serial communications would, except at higher speeds. That's my rough idea for it. I have no clue what SPI, I²C, Microwire, and the other things are. Even my concept of RS232 communication is pretty bad.

Quote:
if you REALLY want to go cheap, and you have +-12 volts, use 2N3904 transistors to bias and invert


Now that's an idea. After all, isn't that what a line driver is? (Looking at the schematic on the data sheet, I think that that's all there is to it).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Oct 06, 2008 1:04 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8427
Location: Southern California
Quote:
Err, I daresay I only know what they are in rough terms. Its basically, instead of sending the data at regular time intervals over a parallel bus or the sorts, you simply send it like serial communications would, except at higher speeds. That's my rough idea for it. I have no clue what SPI, I²C, Microwire, and the other things are. Even my concept of RS232 communication is pretty bad.

I'll try my hand at a description that's short yet useful.

In interfaces, bits go through one at a time, not 4, 8, 16, or any other number like processor data buses use.  Obviously the receiver needs a reference so it can tell what bit it is receiving at any given time.

In RS-232, that reference is strictly the timing, and the transmitter and receiver must agree that every bit takes a certain number of microseconds.  Each frame begins with a "0" start bit, and its leading edge starts the receiver's timer.  Then the receiver knows when to sample the data for each bit after that, usually 8 data bits, optionally (but not often) a parity bit for error detection, and one or more "1" stop bits which also serve for error detection as well as setting up the line for the next frame's start bit.  You can see that if the transmitter's and receiver's bit clocks don't quite run the same speed, you'll be coming up with errors.  After ten bits in a frame, a 5% error is half a bit time, which will put you in the transition area between bits.  In many situations, you can get away with a 2% speed error.  RC timing is not tight enough; but ceramic resonators, which have less than 1% error, will be good enough.  Usually crystal control is used, which it more accurate.

RS-232 voltages are high to minimize interference, which is the main reason line drivers and receivers such as the popular MAX232 are used.  (There are plenty of other line drivers and receivers though.  I prefer the MC145406 which has three of each in a 16-pin IC.)  The RS-232 specification says the receiver must interpret -3 to -25 volts as a "1", and +3 to +25 volts as a "0".  (The line drivers and receivers invert the voltage, making a "1" the low voltage and a "0" the high voltage.)  The transmitter must transmit -5 to -15 volts for a "1", and +5 to +15 for a "0", and must withstand shorts to ground indefinitely without damage.  The area from -3V to +3V is not defined.  The load offered by the receiver is to be 3,000 to 7,000 ohms.  Additional lines are often used, most commonly for the receiver to tell the transmitter if it is ready for more data.  These additional lines are simple logic states (driven to RS-232 voltages), and do not have the start, stop, parity, and data bits.

Intended uses for RS-232 are for communication between pieces of equipment across a room, even a big one like a factory or large office.  RS-232 can typically go at least a few hundred feet, depending on bit rate and wire type.  It reaches much, much farther than USB.  I have an RS-232 primer on my website, at http://wilsonminesco.com/RS-232/RS-232primer.html .


If RS-232 doesn't go far enough for you, or you want something similar that goes a lot faster, you can go to RS-422 or RS-485 which are differential (balanced), and the output can come from 5V or 3V drivers since the inputs can tolerate up to 6V and you only need 200mV difference between the two wires to get a valid logic level.  Here's the idea, showing transmitting $D3:
Attachment:
RS-485_waveform.gif
RS-485_waveform.gif [ 8.13 KiB | Viewed 1165 times ]

RS-422 can do 10Mbps at 40 feet, and RS-485 can do 35Mbps at 33 feet.  Both can go at least 90kbps at 3/4 mile.  A rule of thumb for RS-485 max speed versus cable length is that the speed in bit/s multiplied by the length in meters should not exceed 10^8.  Thus a 50-meter cable (164 feet) should not signal faster than 2 Mbit/s.


There are several popular synchronous serial interfaces.  They are more commonly used to communicate between ICs on a board, not across a room.  ICs using these have fewer pins, take less room on the board, and dramatically reduce the number of connections you will need to make.  Take for example a multi-megabyte EEPROM or flash memory in an 8-pin package, as opposed to a parallel equivalent having 48 pins.  The synchronous serial interfaces, as far as I can think of right now, all transmit the most-significant bit first, unlike RS-232 which transmits the least-significant first (after the start bit).


SPI (serial peripheral interface) was devised by Motorola.  There is a master and one or more slaves.  Each slave has 4 unidirectional SPI lines:  data in, data out, clock in, and select in.  The master has a minimum of four:  data in and out, plus clock out, and one select line for each slave, so it may have several select outputs.  For brevity and clarity, the data-in and -out pins are referred to as MISO (master-in, slave-out), and MOSI (master-out, slave-in).  MISO, MOSI, and clock are bussed to all devices.  These typically operate at 3-5V and light CMOS loads, unlike RS-232.

To talk to a slave, the SPI master sets that slave's select line true, puts the first data bit on its data-out line (which goes to all the slaves' data-in lines), and puts the first active edge on its clock-out line.  The slave will put its first data bit for the master on its data-out pin for the master to latch in on the clock's next active edge.  Since a bit is sent by the master and another one is sent by the slave with every clock cycle, sometimes there's dummy data going one of the directions when there's no need for data transfer in that direction.  There's more than one mode relating to clock polarities, but if you look at the data sheet for any IC of interest, it will have all the info you need in order to use it.  You don't need to first get familiar with the SPI spec from another document.

I have a note here that you can daisy-chain SPI parts if desired, but from what I know about the SPI parts I've used, I have a hard time imagining they could be used that way.  If you daisychain them, the same select line will go to the select pin of every IC in an entire daisychain.

There's a 65c02 assembly-language example of bit-banging SPI on 65SIB with a 6522 VIA at http://wilsonminesco.com/6502primer/SPI.ASM .


Microwire is National's invention and is very similar to SPI, but there is only the one mode instead of SPI's four modes of clock polarity.


Going down the line of intelligence, you can use a long daisychain of dumb shift registers like the 4094, 4021, 74HC165, and 74HC595 connected directly to the VIA's CB1 and CB2 to get hundreds of bits of I/O through that port.  Instead of a select line, you'll need a VIA output bit to latch the shift registers' values into the outputs (in the case of serial-in to parallel-out) or to load the parallel inputs into the shift registers to send serially to the VIA (in the case of parallel-in to serial-out).  The VIA's SR can be used for output or input, but not both at once.  I have a diagram showing how to connect a lot of 74HC595's to the VIA's shift register pins here, one showing how to connect a lot of 74HC165's to the VIA here, and one showing both types connected at once here about 60% of the way down the front page of the math look-up tables section of my website.

The 4094 and 4021 can handle up to 15 volts.  They're nice in systems where for example you have to have a lot of 12V inputs and outputs, and you don't want to have to put voltage translators on all those bits.  You run the 4021's and/or 4094's on your 12V and only put the translators on the data line, the clock line, and the latch line, totaling only three instead of possibly hundreds.  (This example is actually from my own work.)

Some synchronous-serial parts, for example National's LM1973 digital potentiometers, may never need to send data back to the master, and in that case, you can eliminate the master's data-in connection and just go with three wires for a whole daisy chain of them: MOSI (which goes to the first IC's data-in), clock (which gets connected to all ICs), and select (which may get called something else like "shift/load\").  The first IC's data-out pin gets connected to the next IC's data-in pin, its data out goes to the third one's data in, and so on.  Eight of those LM1973's would get you 24 channels of digital pots on three VIA pins, and of course you could put other things on the same daisy chain.


I²C (inter integrated circuit) is a two-wire synchronous-serial interface from Philips.  One wire is clock and the other is bi-directional data.  At least the latter must have a passive pull-up resistor, and any of the ICs can pull the data line down to ground to produce a "0".  There are a couple of situations where the clock line may need a passive pull-up.  One is if there are two or more controllers that may control the interface at different times.  Another is if you have one or more devices which may hold the clock line low to pause the master so the device doesn't fall behind.  IOW, it's a way to ask more more time.  Of course, if the controller does not pull the clock line up itself, a pull-up resistor will be needed.  Often there's only one resistor—the one on the data line.

Instead of using select lines which make for more wires, a "start" condition is produced by lowering the data line while the clock is high.  A "stop" condition is produced by letting the data line up while the clock is high.  Otherwise the data line state is only changed while the clock line is low, and data is only sampled during positive (up-down) clock pulses.  Each communication starts by shifting out an address (usually one byte) telling all the ICs on the interface which one is to be selected.  After that, only the selected one pays attention, and the rest ignore everything until there's another "start" condition.  After the address, there's an instruction, potentially followed by data.  If the instruction tells a slave to send data, then the controller will listen on the data line instead of transmitting.  As with SPI, Microwire, and the chain of dumb shift registers above, the controller controls the clock and therefore the data rate.  There's no need for the bit speed to be constant like RS-232 needs.

There is an additional clock pulse after each byte, for the listening end to respond with an acknowledge.  One function for that is that for example if the controller has started a sequential read from a memory device and that device is doing the transmitting at the time, the controller can, after it has gotten all the data it wants, refrain from acknowledging a byte so the device will stop sending data and release the data line so the master can produce a "stop" condition.  The acknowledge (ACK) is made by the receiving end pulling the data line down for that 9th clock pulse.  Not-acknowledge (NAK) is accomplished by letting it remain high for that 9th clock pulse.

I²C speed is limited by the time constant produced by the pull-up resistance multiplied by the capacitive load on the data line.  400kbps is pretty typical, which, although faster than virtually all RS-232, is nowhere near as fast as SPI's tens of Mbps.  Some I²C devices can go 1Mbps, and a few can go faster.

There's a 65c02 assembly-language example bit-banging I²C with a 6522 VIA at http://wilsonminesco.com/6502primer/GENRLI2C.ASM .  The circuit used is at http://wilsonminesco.com/6502primer/pot ... ITBANG_I2C .


I²C versus SPI pros and cons (since feedback showed confusion):

  • SPI needs three lines (clock, data to the device, called MOSI, for "master-out, slave-in," and data from the device, called MISO, for "master-in, slave-out") plus one select line for each device; so you need four lines for one device, five lines for two, six lines for three, etc..  I²C only needs two, regardless of the number of devices on the bus: clock, and bidirectional data.
  • SPI can go much faster.  I've seen up to nearly 200MHz clock speeds for SPI.  I²C's rates are severely limited by the fact that the outputs are open-drain (or open-collector), and pullups are passive, and they take time to charge the parasitic capacitance on the lines.  Most I²C devices are made for 400kHz or 1MHz clock speed.  None go over 5MHz.
  • I²C only has one mode, which is simpler, whereas SPI has four (modes 0, 1, 2, and 3), and you have to pay attention to which mode(s) any given device can operate in.
  • SPI's lines are always unidirectional, making voltage translation easier.  However, most I²C devices (and certainly all the ones I've used) can operate at a range of voltages up to 5V, making voltage translation unnecessary.  Many SPI devices cannot go above 3.3V.  That's why the SPI-10 proposed connector standard has different versions for 5V versus 3.3V.  You wouldn't want to damage a 3.3V module by plugging it into a 5V port; and a 5V device may not work properly at 3.3V.  To keep them straight, one hole of the socket is plugged, and the corresponding pin of the plug on the motherboard is cut.  For 5V, it's pin 3, and for 3.3V, it's pin 4.
  • Many I²C devices can dictate the data rate by holding the clock line down if they need more time to process each bit.  The controller watches for the clock line to be up before pulling it back down; so it won't get ahead of the device.  With SPI, you just have to know ahead of time how fast it can go (although we're not in any danger of outrunning it with our 65xx projects and bit-banging).
  • Because of the tradeoffs between speed, number of connections, and operating voltage range, the availability of certain IC functions will lean more toward one or the other.  Large flash memories for example will be SPI, because it would take too long to transfer a large file by I²C, whereas things like keypad interfaces, RTCs, and digital thermometers may be more available in I²C.
  • I²C allows passing control from one master to another, something SPI does not.  Myself, I've never had the need for that.

I like, and use, both I²C and SPI, for different reasons and applications.


SMBus, defined by Intel and Duracell in 1994, is almost the same as I²C.  One of the main differences is that there are time-outs built into the SMBus specification.  I²C is much more common.


1-Wire is the invention of Dallas Semiconductor, now part of Maxim.  It's almost carrying it too far if you ask me.  The master produces a clock pulse on the line by pulling it down for a microsecond.  If the sender (whether that's the master or a slave) wants to send a "1", it lets the line float up at the end of that clock pulse.  If it wants to send a "0", it then holds the line down a little longer.  The receiver will look anywhere from 15 to 60µs after the low clock pulse to see if the transmitter is still holding the line low to indicate a 0.  After the 60µs plus adequate time to make sure the line has time to float up by the pull-up resistor, the transmitter can make the next low clock pulse.  As you can see, it won't be very fast.

Every 1-Wire device has a serial number; so even if you have a bunch of three-pin digital-thermometer ICs of all the same type for example, the master can still address them separately.  As you can see, it is important to have control of the timing on 1-Wire, even though it's supposedly a synchronous-serial interface, ie, one where the master controls the clock and all the devices adhere to it.  You cannot allow interrupts during bits when bit-banging. Interrupts between bits is ok.


You can put I²C and certain modes of SPI on the same lines if you take a couple of precautions.  First, when using the SPI, you must be careful not to accidentally toggle the data line while the clock line is high, since that could produce an unwanted "start" condition on the I²C.  Second, make sure no SPI select line is ever true (low) when you carry out I²C communication.  SPI speed might also have to be held low enough that an I²C device would not misinterpret something to be a start condition; but you probably would not be bit-banging it that fast through a home-made 6522 system.  You can probably also see by now that you could combine more than just these two interfaces on the same clock and data lines, as long as you don't violate the rules for any of the interfaces.


some links:
my RS-232 primer, with 6502 and 6551 relevance
RS-422 article on Wikipedia
RS-485 article on Wikipedia
I²C overview from Philips Semiconductor
SMBus article on Wikipedia
I2CChip.com I²C, SPI, 1-Wire interfacing made easy
Guide for reliable long-line 1-Wire networks
B&B Electronics (Advantech): serial converters
SD-card SPI Maxim ap note
SD/MMC cards, using SPI mode
SD/MMC/SDHC card library
MAX3421E USB peripheral/host controller IC with SPI
National Semi Microwire description (.pdf)
SS22: 6522 synchronous-serial data link between computers
65SIB: a hobbyist-friendly serial interface bus, compatible with SPI but more flexible
I2C-6: a hobbyist-friendly connector standard for small I²C modules, suitable for common perfboard
SPI-10: a hobbyist-friendly connector standard for small SPI modules, suitable for common perfboard
Daryl Rictor's 65SPI chip he sells, version 2, made using using an Atmel ATF1504 CPLD. (65SPI is a 65-family SPI I/O IC, not to be confused with 65SIB which is the super-flexible interface method)

Edited Dec 2, 2020 to fix links that had gone dead, and May 3, 2022 to add the pros & cons of I²C versus SPI.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Last edited by GARTHWILSON on Tue Apr 10, 2012 5:27 am, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Oct 06, 2008 6:13 am 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 990
Location: near Heidelberg, Germany
I might add that there is an example SPI interface using the VIA and an input SR on

http://www.6502.org/users/andre/csa/spi/index.html

Cheers,
André

P.S.: SPI is also used by SD-Cards, which is what I use it for. It requires 3.3V conversion though


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: