serial interface bus

[GARTHWILSON]

Samuel, is it ok with you to make CONFIG to be active low, like the SEL lines? This will allow using the 74xx75 to latch the SEL state when CONFIG is low. When CONFIG is high, the 74xx75 will be transparent.

[kc5tja]

I prefer CONFIG to be active low, personally. It'd make generating microcontroller interrupts easier for one, and secondly, things just seem to work better with active-low signals across a longish cable. Not sure why.

[GARTHWILSON]

So what you're saying is that we're on the same note, despite what it looks like, right? Most of the time, CONFIG is high. It only goes low for configuration.

[kc5tja]

Yes; I've always intended for CONFIG to be active low. I didn't use an overbar because you don't appear to use it for the SEL lines, and I was striving for consistency.

Inconsistent documentation conventions leads to things like, oh I dunno, Mars probes crashing into asteroids or otherwise going silent in the depths of space.

[GARTHWILSON]

I guess I just hadn't put the overbar on it yet because we hadn't discussed which way to make it. Active-low it is. And there's no 5V power supply line on the cable at this point.

[dclxvi]

GARTHWILSON wrote:

Thanks for the best laugh I've had since a German general fighting the gestapo on Hogan's Heroes last night suggested arming the prisoners!

uh...thanks...I think.

GARTHWILSON wrote:

Actually Bruce I was expecting you to chime in with some long posts too, but I guess I should expect that more when it comes to software and algorithms, not hardware, huh?

Believe it or don't I actually have an EE degree and not a CS degree. (I can hear the peanut gallery now: "That explains a lot about your software" ) But with hardware, I tend to have to draw a block diagram or schematic to explain (or understand) things. With software, code examples can be thought up and typed in or cut-and-pasted more quickly, so software can be more conducive to forum discussions.

[lordsteve]

Garth said...

Quote:

...Maybe that Scenix that lordsteve was recommending, or some other high-performance µC, could be used to bit-bang at good enough rates to detect the mode and translate between one bit-banged port and another. ...

Yes, it's true: This thread is a little much for my small mind, so I don't read everything in it. Sorry I missed your post about the SX's that I recommend.

The SX does not have an SPI port. What it has is pipelined operation rated up to 75 MHz, 1 MIPS per MHz. (They are overclockable). I am not sure what you meant about the SX having to access its parallel port or something to get to it's IO pins. Did I cross streams there? The SX has direct access to it's IO pins. There is still a DIP version available (among surface mount options).

With the wonderful speed you can bit-bang the dickens out of SPI or... pseudo-SPI or I2C or whatever. That's the wonderful thing about not having dedicated silicon purposed to a peripheral and having high-speed. At less then $3.00 a piece, even in one-offs, whether one wants to cry about how lousy one thinks the instruction set is or not, it can't be beat for cheap, custom serial protocol-ing. It's so cute and pipelined.

SX Microcontroller...will you be my valentine?

P.S. Here's the latest datasheet for the SX48 flavor: http://www.parallax.com/dl/docs/prod/da ... a-v1.5.pdf

[GARTHWILSON]

Quote:

The SX does not have an SPI port. What it has is pipelined operation rated up to 75 MHz, 1 MIPS per MHz. (They are overclockable). I am not sure what you meant about the SX having to access its parallel port or something to get to it's IO pins. Did I cross streams there? The SX has direct access to its IO pins. There is still a DIP version available (among surface mount options).

I was talking about trying to use the SX as an I/O IC on the 6502's bus. The 6502 would not have direct access to the SX's registers like it has to a 6522. If you kept the 6502 at very low speeds, the SX could be continually checking the line(s) you decided to make CS line(s), check the one you decided to make a R/W\ line, and the register-select lines, and either take in the bus data and put it in the appropriate register (in the case of writing to it) or fetch the appropriate data and put it on the 6502's bus (in the case of reading something from it) and possibly alter its own status afterward for both; but doing all this will take so many complete instructions executed per half clock cycle of the 6502 that I'm sure it would not be able to go over 1MHz, if even that, let alone 16MHz, and continue doing the other things it's supposed to be doing in the background. This is why I didn't want to use it at the bus master end, although it may work nicely for something like SPI mode translators (for individual devices on the bus) where the only processor that needs direct access to the SX's registers is its own.

[kc5tja]

I'm using an FPGA for my upcoming Kestrel, so "dedicated hardware" or "dedicated stack-based MISC I/O processor" or "IBM-style mainframe I/O processor" -- doesn't matter to me. I can hack hardware as easily as software.

However, this bus is intended to be used both with hobby SBCs that bit-bang everything (e.g., a Kestrel-1 with its one and only VIA chip) to custom hardware that supports 25Mbps throughputs. Only cabling affects top-end speed. The rest of the spec more or less remains the same.

[lordsteve]

Thus said Garth:

Quote:

...although it may work nicely for something like SPI mode translators (for individual devices on the bus) where the only processor that needs direct access to the SX's registers is its own.

I, too, wasn't thinking about using the SX as the master, but as interface devices to sit in between the slave device and the bus, doing any translation necessary between the two. In other words the SX could add the "intelligence" needed to dumb devices so they can hang on your crazy bus.

Garth:

Quote:

...let alone 16MHz, and continue doing the other things it's supposed to be doing in the background.

I have a feeling this is a silly question but...what other things?

[kc5tja]

Crazy bus?

All we did was package an existing bus (SPI) in a form that allows it to be useful as an external (versus internal) peripheral expansion bus.

I rather resent the insinuation that it's "crazy", because of the negative connotations it brings with it (namely, it's haphazardly designed, ill-specified, that sort of thing). While the auto-configuration protocol has not been fleshed out, the hardware specification IS being refined over time. Garth's experience is going to be the guinea pig test results on our current design iteration. Based on his feedback, since he'll be able to build an interface long before I ever will, we will then refine the interface specifications.

Like any collaborative project, the ultimate design will coalesce only over time. Give it a chance, please.

If I misinterpreted your intentions with the phrase, I apologize. But I have to admit, it sure read like trollbait.

[GARTHWILSON]

Although the "your crazy bus" comment could come across as insulting, I don't really take it that way. I know there has been a ton of material to read here. The reasons for everything are given in the last seven pages. They are partly based on a lot of experience with many needs on the workbench and low-end automation, and accommodate a wide range of synchronous serial devices (including thousands of ICs on the market using the various industry-defined SPI modes plus things that aren't really even SPI) from very simple all the way up to the intelligent auto-configuring plug-n-play devices kc5tja has in mind. I don't know of any other such wide-ranging bus. Some software protocol will still need to be defined, but overall, I'm rather pleased with what we managed to come up with. I know the improved connectivity as well as the more-standardized driver software involved will save me time over the way I've been doing things up to now.

I'll address the other question probably tonight when I get more time.

[lordsteve]

Sammy,

I wasn't being insulting so there's no need for hysterics. Good frickin grief, Samuel. Did you miss the point of my post only to concentrate on a presumed insult perhaps flung your way?

You're bus is "crazy" to me and I use the term lightly. There wasn't a shred of animosity in it. I don't have a clue how it works and I haven't read about it That's just how my personality formed the expression about it...a crazy ol' bus.

Maybe give some benefit of doubt when the majority of message's material is informative and benign when something potentially malignant pops into your view.

[kc5tja]

All I said is that I resent the insinuation that it was crazy, and that it rather read like trollbait. I wasn't being hysterical at all. The most hysterical thing I wrote was, and if you can call it hysterical, "Give it a chance."

I'll let your reaction to it speak for itself though.

A simple, "I didn't mean it that way, I meant it in the term of "that crazy ol' bus"" would have been sufficient and far more informative.

[GARTHWILSON]

Kind of O.T. but:

Quote:

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 against which signals get referenced. The "chainsaw" line effectively 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.

I had forgotten about this but I've had gerber viewer software for a couple of years or more so I can now just put up a picture. I do my CAD in DOS on another computer so I couldn't even do a screenshot before. This is the ground plane layer of a little board I did a couple of years ago:



(It shows up on my monitor about three times actual size.) This one is cut into four sections. Three of them are joined at strategic points where switching power supply noise can be controlled and kept out of the audio.

I'll try to post a preliminary 65SIB spec soon. First draft is nearly done. I've been working on it a little at a time for the last week, since someone mentioned again that there really ought to be a place to get it concisely and not have to read this whole topic.