6502.org • View topic - serial interface bus

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Hardware

All times are UTC

serial interface bus

Page 3 of 8

[ 109 posts ]

Go to page Previous 1, 2, 3, 4, 5, 6 ... 8 Next

Previous topic | Next topic

Author

Message

GARTHWILSON

Post subject:

Posted: Fri Jan 05, 2007 5:45 am

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California

Quote:

Correct. The DCE on each side could be an Ethernet interface, for example. I'm also interested in freespace optical networking as an alternative to wifi too.

The 14-pin-DIP MAX3100 SPI UART can be used for IrDA as well, if that interests you.

Quote:

1) To keep costs of the controller down, I think it would be wise to not stipulate that you must have +12, -12, +5, and -5V on the bus, regulated or otherwise.

My purpose was to keep the cost and complexity of devices down by eliminating the need for their own power supply (or even batteries) for the ones that take a small enough amount of power that the controller would hardly notice the load. This eliminates the need for some of the wall-wart power supplies and their cords, mess, and expense. BTW, I've never seen a modern requirement for -5V. That seems to be something older than 7400 TTL and the 6502, so I won't ask for that. If someone needs it, a 7905 or 79L05 is small and cheap way to get -5V from another negative voltage in the range of -7V to -30V. OTOH, you could also use an LT1054 switched-capacitor voltage inverter in an 8-pin DIP to get a regulated -5V from an input of anywhere from +6 to +15V, using four capacitors and two resistors. I have one breadboarded here and got a 0.06V drop at 87mA, meaning a 0.67-ohm output while it was able to regulate! The regulation is essentially analog though IIRC.

Quote:

2) I fear that taking true grounds away in place of supply rails will reduce its ability to function correctly. Ripple will be introduced which regulators may not be able to compensate fully for.

I don't expect any problem as long as the bypass capacitor leads are kept short. I can't claim to have this exact type of experience but I did work in VHF & UHF power transistor applications engineering in the mid 1980's, and it's also similar to the matters of keeping stray noises out of our audio systems in aircraft installations. We had to be very specific in the installation instructions because otherwise technicians tend to think ground is ground is ground, and they think they can connect any and all grounds to the airframe just because there's continuity between them already. Then they get all kinds of noises into the system.

Quote:

In every circuit I've seen where this may be a problem, a clear distinction between types of grounds are provided (e.g., analog grounds versus digital).

I addressed this on my workbench computer's data converters where I don't even have a ground plane, let alone one with a chainsaw line. DC-wise, you'll find continuity between digital grounds and the audio jacks' grounds; but they're not the same AC-wise, and the digital noise does not get into the analog signals or disturb the converters. I also addressed it in our aircraft audio system designs where I had switching power supplies on the same boards with audio circuitry where the switching noise had to be kept out of the audio. It can be done, although a novice probably won't get it right, which is a consideration.

Quote:

3) If Kestrel provides a true ground on pins you decide to use -12V or -5V on, what happens if I try to insert one of your peripherals into my bus implementation?

Without the negative-voltage power, certain things won't work right, but I can't think of any damage that would be done. The cheap RS-232 line drivers that don't produce their own negative voltage just won't be able to go below ground for valid marking, the outputs of the higher-performance op amps that want plus and minus power supplies won't be able to get all the way down to ground (meaning they'll distort), LCDs requiring a negative backplane voltage (common for STN) might appear blank, some D/A converters won't work right, etc.. There's a small risk of damage if the device expects to be able to get positive supply voltage from the bus and there is none when positive signal voltages start arriving.

Quote:

Or, vice versa? Will damage come to the peripheral or to the bus?

If the controller puts power on those pins and the device has the bypass capacitors, no problem. If the device shorts the line to ground and the controller tries to power that line, the controller should have some sort of protection. On the rare occasion that I turn the power on to my workbench computer and have something shorted, right away I see either the excessive current or the fact that the power supply's output voltage dipped because the current limit kicked in, and I shut it down. You're right though— this thing needs to be a little more foolproof is we expect it to be used by a wider range of users.

What I might have to do is add a separate power connector, like disc drives have. I just thought it would be a cleaner setup to have it all in one connector.

Quote:

Yes, and that is what I wanted to avoid. But as I said-- you don't have the multi-controller requirement. I basically have, and that is the reason that for this peer-to-peer connection I want to stick to peer-to-peer and not a bus. Arbitrating between two controllers is easier than between multiple controllers.

Would you ever need two or more things to be able to act as a controller in the same session, or can you (the user) tell one to be a device for a particular session? The two hand-held computers seen at http://www.6502.org/users/garth/projects.php?project=4 are both equipped with HPIL (Hewlett-Packard Interface Loop), and I have used them to control and take data from a lot of equipment. (Especially in the 1980's, people would freak out to see a hand-held device controlling a stack of lab equipment in a rack!) The larger of these two hand-helds does not insist on being the controller, but the simpler, smaller one does; so the few times I've connected them together to transfer data, the smaller one was the controller.

_________________
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

kc5tja

Post subject:

Posted: Fri Jan 05, 2007 7:06 am

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706

GARTHWILSON wrote:

The 16-pin MAX3100 SPI UART can be used for IrDA as well, if that interests you.

It definitely does. Thanks for the heads up!

Quote:

Definitely. But I wonder how much a ribbon cable will be able to provide.

A MAX765 can provide a -12V regulated supply given a 12V input, at what appears to be 250mA output current. That translates to 3W of power. I'm assuming that there is a similar MAXIM chip that provides a +12V regulated supply also at 250mA; that's a total of 6W of power. Will ribbon cable be able to deal with that kind of power?

Also, the price of a MAX765 appears to be $6 or so for an 8-pin SOIC.

Quote:

I addressed this on my workbench computer's data converters where I don't even have a ground plane, let alone one with a chainsaw line.

I Google'd for this term ("chainsaw line") in various forms, but was unsuccessful in finding what it means. What is a chainsaw line in this case?

Quote:

It can be done, although a novice probably won't get it right, which is a consideration.

Sounds like another 6502.org article about to appear. ;D

Quote:

What I might have to do is add a separate power connector, like disc drives have. I just thought it would be a cleaner setup to have it all in one connector.

Yup, I agree; I would prefer to keep things simple on one cable too. I just want to make sure it won't break the bank for us home-brewers, and that things are kept so easy to build that you'd have to work harder to explicitly break the standard instead of conform to it. (If that makes any sense...)

Top

GARTHWILSON

Post subject:

Posted: Fri Jan 05, 2007 7:48 am

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California

Quote:

A MAX765 can provide a -12V regulated supply given a 12V input, at what appears to be 250mA output current. That translates to 3W of power. I'm assuming that there is a similar MAXIM chip that provides a +12V regulated supply also at 250mA; that's a total of 6W of power. Will ribbon cable be able to deal with that kind of power?

How big is ribbon-cable wire? #26? #26 copper wire's current capacity is about 350mA (fusing current is about 20A!), and it has about 41 ohms per thousand feet. (I might reach a max of 10 or 20 feet for this.) If anything needed the kind of power you're talking about, I would expect it to have its own power supply and not rely on power that the controller supplies.

Quote:

I Google'd for this term ("chainsaw line") in various forms, but was unsuccessful in finding what it means. What is a chainsaw line in this case?

Imagine this senario. You have a printed circuit board with one or more plane layers, as for a ground plane. The circuitry on part of the board produces electrical noise that cannot be allowed into another part, and yet they need to be connected to each other. You may have to cut the ground plane so each circuit has its own, and then join them at only one point, where you can control the noise. Besides having bypassing and possibly other filtering at that point, the cutting of the plane means ground currents from one part of the circuit won't be running across the other part and producing IxR (ie, voltage) drops to which signals get referenced. The "chainsaw" line effective cuts through the plane layer(s). Even if the only planes are on inside layers, you can clearly see the chainsaw line if you hold the board up to the light, since the board will be translucent there. I've used this to keep computer noise and switching-power-supply noise out of the audio.

Quote:

Sounds like another 6502.org article about to appear. ;D

Hah! I seem to have gotten a decent feel for it that works for our stuff, but don't ask me to model anything. I have loads of articles on this kind of stuff from people like Dr. Howard Johnson (no relation to the motels, although I expect he's stayed at quite a few as he's traveled giving seminars), and I'd probably do best to just find a bunch of links.

Quote:

I know what you mean. This power thing kind of turned into a little can of worms I wasn't expecting. However if we're going to come up with some spec we hope others will adopt, it has to be not only workable for the majority of those who'd be interested in this kind of application, but not so easy to damage things. One thought I had (which I'm not super-crazy about) is to have a pin header on the controller where I could plug those tiny shorting bars onto pairs of pins to connect the power. OTOH, if you mix device types so that one device expects power on a line while another device connected at the same time shorts it to ground, there will be problems again. Do you have any other ideas for how to do it? Is there anything else you have reservations about? You never commented on the idea of having the boot-disc (-flash, whatever) device at address 1.

Are we getting close enough to give the whole thing a name? 6502.orgSPIbus may be a little long, not descriptive enough, and implies you can't use it with a different processor family. (OTOH, "IEEE-488" is not exactly self-explanatory either.) Subsequent refinements (like for the switch protocol) might add ".1", ".2" etc. on the end.

_________________
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

fachat

Post subject:

Posted: Fri Jan 05, 2007 10:17 am

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1043
Location: near Heidelberg, Germany

Coming to think of it, I would probably add one additional line from device to controller. So far it seems you assume that the device can always receive whenever the controller sends. The purpose of that new line would be that the device could "throttle" the controller so that slower devices (in terms of bytes per second, not CLK ticks) could temporarily halt the controller before it sends the next byte. A simple devices like shift registers would not need to use that line.

Physically only a selected device should drive the line. If the controller could actually detect an "open" line, it would even be useful for autodetection (but that is a nice-to-have). Otherwise the controller sees if the device is able to receive (or send on MISO) and can wait appropriately.

I could also use this line in a peer-to-peer setup I think.

What do you think?
André

Top

GARTHWILSON

Post subject:

Posted: Fri Jan 05, 2007 7:16 pm

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California

I think this is always built into the SPI device. Remember that data is shifted out at the same time data is shifted in. Sometimes such data is irrelevant. Sometimes it tells you if you need to wait for an operation to finish before the part can accept more data. Some operations are specifically to poll the device and see if it's ready for more data or instructions. If you can think of an example where such a line is necessary, let's examine it; but I've worked with a handful of SPI, Microwire, and I²C flash, EEPROM, UART, data-converter, digital-pot, and other ICs, and this is already taken care of in every case I've seen. And, as you say, if we're just using dumb shift registers, they can take or dish out the data as fast as they can shift anyway. That is a valid concern however, so if you can think of examples where this needs to be addressed, please post them.

_________________
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

fachat

Post subject:

Posted: Fri Jan 05, 2007 10:54 pm

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1043
Location: near Heidelberg, Germany

I was thinking about when the device is a small computer itself that when the first byte has been sent by the device, the cpu there needs to reload valid data.

From your answer I assume that these devices seem to have a roll-over SR to provide the data to send and need only to load that when the data has changed.

In that case, however, if the device CPU is to slow to update the data, duplicated bytes would be received if the controller tries to read faster than the device.can provide the data. This is I would think no problem if the device is a simple 8-bit input, or if the device is fast enough like e.g. SD- or MMC-cards.

André

Top

kc5tja

Post subject:

Posted: Sat Jan 06, 2007 12:56 am

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706

Part of the perceived protocol to avoid this problem is hidden in the auto-configuration phase. When a device is probed, it is queried for its capabilities, including:

* The number of nanoseconds for a single bit (determines the fastest possible bitrate)

* The minimum number of nanoseconds between single bytes (determines the fastest rate at which you can send it bytes).

* The minimum number of nanoseconds between bus transactions to be considered safe for most commands.

For example, if I have a SPI controller that can handle 25Mbps peak, the feedback from autoconfig will say that a bit period has 40ns. But what if it's a Commodore 64? You're looking at a minimum of 16 to 20 microseconds to process a single byte, stuff it into a buffer, etc. So it would report a byte period of 20000 nanoseconds (note that the byte period does not include the time it takes to receive a full byte too). As a result, the controller will know a priori how fast to clock data so as to never overflow the receiver's SPI hardware, or the processor behind it.

This technique is called "explicit rate notification flow control" in networking circles.

For more asynchronous problems (e.g., waiting for a key press or other factors dependent on times indeterminable locally), the IRQ line is used. The basic protocol here is to send a request to the device such that it asserts its IRQ signal upon satisfaction of the command.

Garth, with regards to restricting the boot device to device 1, I consider this an implementation issue. I'm not a fan of restricting what the user can or cannot do with the bus. You're free to write your firmware as such, but I'm not going to do this. While it's not likely that I will personally have more than two MMC ports on the chain, I cannot say what others will or will not have in the future.

Top

GARTHWILSON

Post subject:

Posted: Sat Jan 06, 2007 3:08 am

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California

Putting that info in the configuration polling whether automatic or not sounds like it should do the job nicely. Then as long as the controller complies with those speed limits, the device can always receive a poll message and respond even with a "not ready to send more data yet" message if necessary. The select line going true might produce an interrupt in the device's computer so it can pause what it's doing so as to give the port whatever attention it needs, even if it needs to bit-bang (which takes more attention for a non-controller to do).

Before you answered André's post Samuel, I was trying to think of what other devices I've worked with do. Flash memories need a little time to program each page (like 5 or 10ms); so the protocol is that you send the page info (which is a set number of bytes) and tell it to program, then poll periodically to see when it's ready for more. They may have dual buffers so you can be reloading the second buffer while the first one is busy in the program cycle; but you could still outrun it if you don't poll. Upon reading, the protocol is that you would read a set number of bytes at a time. If you need to cut it short, you just de-select the device. I²C (which only uses two wires, not four) takes care of the job a little differently. You produce a start condition and send the device address and see if the device pulls the data line down during the next clock to acknowledge. If it does not, the device is not ready for more business yet, and in that case, the device really doesn't even have to detect that its address has been sent, because it's not going to respond anyway.

Quote:

Garth, with regards to restricting the boot device to device 1, I consider this an implementation issue. I'm not a fan of restricting what the user can or cannot do with the bus. You're free to write your firmware as such, but I'm not going to do this. While it's not likely that I will personally have more than two MMC ports on the chain, I cannot say what others will or will not have in the future.

I was thinking along the lines of PCs where at bootup time it starts looking for a disc starting with the A: drive. If A has a disc in it but it's not a boot disc, the computer will say so and stop, and not keep looking (if I remember correctly-- I haven't booted from a floppy in years).

So what's your feeling now Samuel (or anyone else) on feeding power over the ribbon to simple, low-power devices that hardly justify having their own power supply?

_________________
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

kc5tja

Post subject:

Posted: Sat Jan 06, 2007 7:48 am

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706

The PC's boot sequence is entirely defined by the BIOS, and is not enforced by the hardware. In fact, ALL modern motherboards allow for booting from devices other than "A:" (BIOS has, by the way, no concept of A:, B:, C:, etc. This is a DOS/Windows thing) by pressing the F8 key to bring up a menu of bootable devices, including USB, CD-ROM, harddrives, floppy drives if present, etc.

I will respond regarding the power on the bus shortly. I'm currently knee-deep in program code for the Kestrel's firmware, and I haven't put much more thought into it.

(On the other hand, the Kestrel firmware's book is now about 80 pages.)

Top

fachat

Post subject:

Posted: Sat Jan 06, 2007 3:53 pm

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1043
Location: near Heidelberg, Germany

Quote:

Putting that info in the configuration polling whether automatic or not sounds like it should do the job nicely.

Sorry, did I miss anything? How is configuration polling done when there is no ADMIIN line on the bus again?

Quote:

The select line going true might produce an interrupt in the device's computer so it can pause what it's doing so as to give the port whatever attention it needs, even if it needs to bit-bang (which takes more attention for a non-controller to do).

The problem is that /IRQ is a shared line. So any device requiring attention may affect the communication. I'd rather have a separate line that is defined to be driven by the selected device only.

Quote:

Flash memories need a little time to program each page (like 5 or 10ms); so the protocol is that you send the page info (which is a set number of bytes) and tell it to program, then poll periodically to see when it's ready for more. They may have dual buffers so you can be reloading the second buffer while the first one is busy in the program cycle; but you could still outrun it if you don't poll

If you program a flash, you write data to the device, and can poll for a status. If you want to read data from a device, how do you know you outrun the device in case something happened that the configuration polling did not foresee? You could only on the device side detect the outrun and send a status byte after the actual data, from which the controller can then see that an outrun has occurred - and that he has to re-read the data. That also requires that the controller buffers the data so it can be invalidated in case of outrun etc. which makes things much more complex.

Well, just me few cents.
André

Top

kc5tja

Post subject:

Posted: Sat Jan 06, 2007 5:57 pm

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706

Remember that the SPI interface runs independently of the device behind it. So when you poll the device, if you've outrun the device proper, the SPI interface will continually return "not ready" status bytes until such time the peripheral has responded. This is how outrunning flash memory is prevented, or how SPI ADCs prevent aliasing, etc.

Top

fachat

Post subject:

Posted: Sat Jan 06, 2007 9:24 pm

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1043
Location: near Heidelberg, Germany

But the Flash can only send a status byte before actual data transmission, and afterwards, or how do you know whether a byte read is a status byte or a data byte?
Thus the device has to buffer all the data needed for the controller (assuming the length of the data to read is included in the command), so when it sends the "ready" status byte before the actual data transmission it is sure that it can actually send all the data required.
Either way controller or device needs some buffering.

André

Top

GARTHWILSON

Post subject:

Posted: Sat Jan 06, 2007 10:25 pm

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California

In the case of the flash you mention here, yes, it has page-sized buffers, allowing you do transfer a whole page at a time at full speed. In the case of something like an EEPROM where you can program one byte at a time (instead of a page at a time), you would poll it before doing another byte, to see if it's still in the program cycle. In both cases, they are able to both send and receive the prescribed sizes of records at the full speeds given in their data sheets, without losing anything. I speak from some experience here, but it's still possible for me to overlook something; so keep the questions coming. There have been things in this thread I'm glad you made me think about.

I'll address the other things later. In trying to write up a response, I see it's a bit of a challenge to communicate it clearly.

_________________
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

kc5tja

Post subject:

Posted: Sat Jan 06, 2007 11:49 pm

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706

Maybe posting a link to a real-world EEPROM or flash datasheet will be of help, so that we have something concrete to reference while reading your response.

Top

GARTHWILSON

Post subject:

Posted: Sun Jan 07, 2007 1:22 am

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California

Quote:

Maybe posting a link to a real-world EEPROM or flash datasheet will be of help...

Here are a few I've used:
Atmel 2Mx8 Dataflash: http://www.atmel.com/dyn/resources/prod ... OC0807.PDF
MAX3100 UART: http://datasheets.maxim-ic.com/en/ds/MAX3100.pdf
National Semiconductor LM1973 digital pot: http://cache.national.com/ds/LM/LM1973.pdf

A quick look at the MAX3100 datasheet again tells me that the handshaking things were taken care of better than I remembered. The digital pot doesn't need or have as much intelligence.

_________________
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

Page 3 of 8

[ 109 posts ]

Go to page Previous 1, 2, 3, 4, 5, 6 ... 8 Next

Board index » 6502.org Users Forum » Hardware

All times are UTC

Who is online

Users browsing this forum: daniMolina and 30 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