CPU <> Memory chip communication interface

S

Skybuck Flying

Guest
Hi,

First I would like to program a simple CPU and Memory chip in pascal/delphi.

(Maybe a better word for memory chip would be memory controller ?)

The CPU and Memory chip communicatie in serial bits with each other.

These serial bits could be commands/addressess which the memory chip can
understand.

I would like to program the cpu's microcode with blocking
routines/functions.

For example:

ReadBit( A ); // block until a bit has been read.
ReadBit( A ); // block until the next bit has been read.
ReadBit( A ); // block until the next bit has been read.

WriteBit( B ); // block until a bit has been written.
WriteBit( B ); // block until the next bit has been written.
WriteBit( B ); // block until the next bit has been written.

For simulation purposes the implementation of these routines could be really
simply to fake communication with the memory chip.

The question is if these two functions can be implemented two BLOCK in a
realworld microcode cpu enviroment (cpu's usually work with clocks which
keep on ticking... ) ?

Bye,
Skybuck.
 
On Thu, 4 Aug 2005 11:23:23 +0200, "Skybuck Flying"
&lt;nospam@hotmail.com&gt; wrote:

First I would like to program a simple CPU and Memory chip in pascal/delphi.
[...]

You're asking all the right questions, but as someone else has said,
you are asking them in lots of little pieces and you will therefore
get fragmentary answers and fragmentary understanding.

You seem to be trying to build an understanding of digital
electronics, simulation and modelling almost from scratch.
This is admirable but doomed. PLEASE, PLEASE find out about
what others have achieved (it's a great deal) in this area.
Because you have tried to invent the concepts for yourself,
you will be receptive to the ideas and you will learn very
quickly, and then you can go on to do creative new stuff.

Try for these search terms...

SystemC
Transaction level modelling
Untimed functional models
Bus functional models
Finite state machines
Handshake protocols
Wait states

Go to www.systemc.org and find what's there. The SystemC
reference simulator is free, so you can see how its kernel
is built and how it helps you build interesting simulations.
SystemC has a highly developed set of ideas about the
relationship between transaction-level modelling (your
"read" and "write" actions on a memory are transactions)
and the behaviour of hardware that works clock by clock,
"cycle-accurate" modelling. Take a look at the SystemC
part of our website and see if any of the examples are
helpful.

Right now, you are frantically trying to re-invent a
wheel that's taken five decades to build. It's
a great way to prepare for learning, but a lousy way
to get anything useful done.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Skybuck Flying wrote:
Hi,

First I would like to program a simple CPU and Memory chip in pascal/delphi.

(Maybe a better word for memory chip would be memory controller ?)

The CPU and Memory chip communicatie in serial bits with each other.

These serial bits could be commands/addressess which the memory chip can
understand.

I would like to program the cpu's microcode with blocking
routines/functions.

For example:

ReadBit( A ); // block until a bit has been read.
ReadBit( A ); // block until the next bit has been read.
ReadBit( A ); // block until the next bit has been read.

WriteBit( B ); // block until a bit has been written.
WriteBit( B ); // block until the next bit has been written.
WriteBit( B ); // block until the next bit has been written.

For simulation purposes the implementation of these routines could be really
simply to fake communication with the memory chip.

The question is if these two functions can be implemented two BLOCK in a
realworld microcode cpu enviroment (cpu's usually work with clocks which
keep on ticking... ) ?

Bye,
Skybuck.
Two protocols you may wish to become familiar with are SPI and I2C. They
are both serial protocols, which are designed to communicate with
peripherals. There are memory devices that use both of these (and many
others...). Many microcontrollers have built-in support of them, meaning
you can do a 'write' or a 'read', and the microcontroller will handle
the gory details.

Now, Pascal is simply a computer language. It can run in a variety of
environments. However, access to the hardware is generally controlled by
the operating system. If you are programming on the 'bare metal' as they
say, then you can do whatever the hell you want. Your "ReadBit" routine
can simply loop, waiting for the hardware to respond. It can block, and
let other processes or threads do work while it waits. It can shut off
the CPU, and wait for an interrupt.

On the other hand, if you are programming through an OS, which is
controlling access to the ports, you must use whatever facilities are
provided by the OS in your "ReadBit()" routine.

This particular question may be better answered in the embedded software
newsgroups.

--
Regards,
Bob Monsen

If a little knowledge is dangerous, where is the man who has
so much as to be out of danger?
Thomas Henry Huxley, 1877
 
the operating system. If you are programming on the 'bare metal' as they
say, then you can do whatever the hell you want. Your "ReadBit" routine
can simply loop, waiting for the hardware to respond. It can block, and
let other processes or threads do work while it waits. It can shut off
the CPU, and wait for an interrupt.
Where can I find an example of this concept on the internet, if any ?

I don't know how complex this technique is... but if it's not too complex I
would like
to see a drawing of the gates required etc, as to get a better understanding
of
how it works together with the clock signal etc.

Bye,
Skybuck.
 
Skybuck Flying wrote:
the operating system. If you are programming on the 'bare metal' as they
say, then you can do whatever the hell you want. Your "ReadBit" routine
can simply loop, waiting for the hardware to respond. It can block, and
let other processes or threads do work while it waits. It can shut off
the CPU, and wait for an interrupt.


Where can I find an example of this concept on the internet, if any ?

I don't know how complex this technique is... but if it's not too complex I
would like
to see a drawing of the gates required etc, as to get a better understanding
of
how it works together with the clock signal etc.

Bye,
Skybuck.
There are lots of examples of PIC code which drives I2C or SPI devices.
Google for "PIC I2C SPI". I got 35,000 hits.

--
Regards,
Bob Monsen

If a little knowledge is dangerous, where is the man who has
so much as to be out of danger?
Thomas Henry Huxley, 1877
 
I guess these routines could simply loop around and have the cpu looping
inside them.

So a simply concept of cpu&lt;-&gt;memory chip communication could be the
following:

one line to indicate information bit is ready/stable
one line to indicate information bit has been read
one line for the information bit.

So a memory chip places the data bit on the information bit line. Then it
turns ready/stable line to on.
The cpu sees this and reads the information bit line. Then the cpu turns the
information bit read line to on.
The main memory chip turns the ready/stable line off. The cpu turns the
read line to off.

And now a transfer of a single bit has occured :)

And vice versa for the other way around.

This might be an inefficient way to transfer bits... since if the
lines/wires are very long it would take a long time for the electrons ;) to
travel across the wire... but still not bad for a simple concept to work
with :)

Later ofcourse the implementation of the read/write functions can be changed
to use different cpu&lt;-&gt;memory chip communication
protocols/architectures/techniques like a wire made up of
transistors/flipflops/etc to have multiple bits travel across the wire ;)

Bye,
Skybuck.
 
"Bob Monsen" &lt;rcsurname@comcast.net&gt; wrote in message
news:8uudndJMU45UTm_fRVn-qg@comcast.com...
Skybuck Flying wrote:
the operating system. If you are programming on the 'bare metal' as they
say, then you can do whatever the hell you want. Your "ReadBit" routine
can simply loop, waiting for the hardware to respond. It can block, and
let other processes or threads do work while it waits. It can shut off
the CPU, and wait for an interrupt.


Where can I find an example of this concept on the internet, if any ?

I don't know how complex this technique is... but if it's not too
complex I
would like
to see a drawing of the gates required etc, as to get a better
understanding
of
how it works together with the clock signal etc.

Bye,
Skybuck.



There are lots of examples of PIC code which drives I2C or SPI devices.
Google for "PIC I2C SPI". I got 35,000 hits.
Ok, the PIC description seems a bit to general, too complex, too many
variations for me to understand ;)

http://en.wikipedia.org/wiki/PIC_microcontroller

The I2C bus is something I can understand :)

http://www.semiconductors.philips.com/markets/mms/protocols/i2c/

However it seems to be really slow :)

"
To begin, the bus has kept pace with performance and today provides three
levels of data rate transfer: up to 100 kbps in Standard mode, up to 400
kbps in Fast mode, and up to 3.4 Mbps in High-Speed mode
"

That's per second ??

And ofcourse it uses fixed bit address, 8 bit bytes, and is ment for
multiple devices on the same bus which might be interesting, but it's not a
requirement for me at the moment :)

So first I would have to understand why this thing is so slow... probably
the electronics or maybe it's the clock rate ? etc...

Or... is it a physical limitation ?

So first I would need to understand how fast eletronics and a 0 or 1 signal
can move across a wire and can be detected by devices, ports etc.

So first I would need to compare my own idea which is kinda simple to this
idea...

So the first question would be: How fast would my alternative idea be with
the latest and greatest hardware thingies... like gates and stuff and
resistors.

The second question would be: How fast would it be if it used
generally/common available components on the market today ? ;)

Now on to SPI ;)

I guess this is the one you mean ;)

http://en.wikipedia.org/wiki/Serial_Peripheral_Interface

Ok that's a very general description. Not much use but ok ;) It does explain
some benefits... like reduced cost ;) and disadvantages slower ;)

http://embedded.com/showArticle.jhtml?articleID=9900483

This link is also about SPI and explains it's more suited for data
streams... ;) instead of addressed stuff ;)

It's also point to point ;) ( the lack of device addressing means less
overhead. )

"
At a higher level

SPI does not have an acknowledgement mechanism to confirm receipt of data.
In fact, without a communication protocol, the SPI master has no knowledge
of whether a slave even exists. SPI also offers no flow control. If you need
hardware flow control, you might need to do something outside of SPI.
"

Ok, that sounds bad... the text above it also sounds pretty bad... lot's of
problems.. but hell it was ment for point to point... maybe single device to
single device... not necessarely single device to multiple devices...

Anyway both communication methods seems to require/work based on the concept
of a clock.
So the cpu and the memory need to run at the same clock speed. If the cpu
can not keep up.. it would miss important bits ? Sounds a little bit bad ;)
But then again... since the cpu would be looping around or something like
that... maybe it wouldn't miss a single bit of everything was timed right :)

However my cpu might need to talk to multiple devices hmmmm... :) but I
would simply add more lines :) :p

Well two nice examples of serial communication. I really need to find out
the physical limitations of signals across wires first :)

Bye,
Skybuck.
 
Skybuck Flying wrote:

Hi,

First I would like to program a simple CPU and Memory chip in pascal/delphi.
Holy Shit. You really are a cretin.

May I suggest the 'Ladybird Book of Electronics' to you ? Ohh... maybe you just
read it ?

Graham
 
Nice introduction to signals across a wire.

http://penguin.dcs.bbk.ac.uk/academic/technology/physical-layer/asynchronous/index.php

I never understood the difference between voltage and ampere... to bad this
page doesn't discuss how ampere is related to voltage. (voltage&lt;-&gt;ampere
very confusing )

One thing I do understand now. The higher the voltage the higher the one ;)
(or maybe is ampere at work here as well ? )

Another surprising things is ;) +voltage is zero and -voltage is one. I
would have done it the other way around... 1 is closer to positive so
+voltage is 1 and -voltage is closer to zero so -voltage is 0.

Bye,
Skybuck.
 
Skybuck Flying wrote:

Nice introduction to signals across a wire.

http://penguin.dcs.bbk.ac.uk/academic/technology/physical-layer/asynchronous/index.php

I never understood the difference between voltage and ampere... to bad this
page doesn't discuss how ampere is related to voltage. (voltage&lt;-&gt;ampere
very confusing )
That's pretty fundamental. The classic example is to compare electricity to water.

Voltage is like water pressure - current is like water flow. With no pressure no water
flows. The larger the pipe ( less resistance to flow ) the more water flows. In a similar
way, the less electrical resistance, the more Amps flow in a circuit for a given voltage.

Reduce the pressure ( Volts ) and the flow ( current ) will reduce likewise.

You sound interested in electronics. An admirable interest.

Why not do what I did when young and simply do some self-study ? Books can be good you
know ! Maybe today's way of living tends to overlook this obvious source of excellent
info ?

Now - please stop trolling here.

http://en.wikipedia.org/wiki/Usenet_troll


Graham
 
Here is another nice advanced introduction to signals over wires or other
mediums:

http://www.analog.com/library/analogDialogue/archives/30-3/mix_sig.html

It also mentions modulation. So maybe the ReadBit/WriteBit functions should
communicate
with another little communication chip on the cpu itself. So that the cpu
itself can simply communicatie with this little communication chip in a very
simple way. The communication chip can then communicate with the main memory
chip which might also have such a communication chip ;)

Lol sounds a lot like athlon's x2 design... a cpu chip with another chip
inside it...

I have no idea what a north bridge and south bridge chip is... but could
this be the same design ? :):):)

Bye,
Skybuck.

"Skybuck Flying" &lt;nospam@hotmail.com&gt; wrote in message news:...
Nice introduction to signals across a wire.


http://penguin.dcs.bbk.ac.uk/academic/technology/physical-layer/asynchronous/index.php

I never understood the difference between voltage and ampere... to bad
this
page doesn't discuss how ampere is related to voltage. (voltage&lt;-&gt;ampere
very confusing )

One thing I do understand now. The higher the voltage the higher the one
;)
(or maybe is ampere at work here as well ? )

Another surprising things is ;) +voltage is zero and -voltage is one. I
would have done it the other way around... 1 is closer to positive so
+voltage is 1 and -voltage is closer to zero so -voltage is 0.

Bye,
Skybuck.
 
"Pooh Bear" &lt;rabbitsfriendsandrelations@hotmail.com&gt; wrote in message
news:42F2F56E.2B3369B2@hotmail.com...
Skybuck Flying wrote:

Nice introduction to signals across a wire.


http://penguin.dcs.bbk.ac.uk/academic/technology/physical-layer/asynchronous/index.php

I never understood the difference between voltage and ampere... to bad
this
page doesn't discuss how ampere is related to voltage. (voltage&lt;-&gt;ampere
very confusing )

That's pretty fundamental. The classic example is to compare electricity
to water.

Voltage is like water pressure - current is like water flow. With no
pressure no water
flows. The larger the pipe ( less resistance to flow ) the more water
flows. In a similar
way, the less electrical resistance, the more Amps flow in a circuit for a
given voltage.

Does this mean a pipe diameter (of a certain material) always allows a
certain maximum voltage ?

So if the source of the voltage becomes to high the pipe blows ? :)

Probably yes, ok that's easy.

Now what about two different pipes:

Pipe A has a large diameter with a maximum of 100 volts to flow through it.

Pipe B has a small diameter with a maximum of 15 volts to flow through it.

Source A has a pressure of 14 volts and is connected to pipe A.

Source B has a pressure of 14 volts and is connected to pipe B.

I have two meters.

I stick a voltmeter A in pipe A.... what would it measure ?

I stick a voltmeter B in pipe B... what would it measure ?

Both would probably measure 14 volts.

The difference would be the ampere.

The flow through pipe B would have to be faster, since it's smaller.

The flow through pipe A could be slower, since it's wider.

According to your explanation:

Sticking an ampere meter in pipe A should show a lower ampere.

Sticking an ampere meter in pipe B should show a higher ampere.

If this is how it works I think I understand it a little bit :)

However microelectronics are very very very small.

So for me it's hard to see the diameter and the resistance... (resistance is
related to the material ;)) :)

Ok I think I am starting to get it.

Let's see even a more complex example:

Pipe A is split up into

Pipe A1 with a diameter of allowing 5 volts

Pipe A2 with a diameter of allowing 95 volts.

Now a good question is the following:

The voltage at pipe A1 would be 5 volts ? or would it blow up ?

It could be possible that the remaing 9 volts would simply go into pipe
A2...

It probably depends on the strength of pipe A1...

At this point I really wouldn't know what the answer is ;)

Maybe it's related to the resistance or something... if it could resists 15
volts it might survive...
But I don't think this is what resistance means ? or maybe it does ?

I thought resistance means how much voltage is lost....

Maybe this is the correct answer after all... if Pipe A1 has a resistance of
9 volts it could allow 5 volts to flow through it...

But what would happen to the other 9 volts ?

Would it go lost in Pipe A1 or would it flow through Pipe A2 without loss ?

I dont think the voltage would be simply halfed... since that's not how
water behaves ;)

So the point is: The concepts pressure, flow, maybe even resistance are easy
to understand... but how it behaves in reality especially in electronics is
a little bit more difficult to understand ;)

Unless the answers are really simple... so I am curious what the answer(s)
would be :) Especially the splitting up of the pipe question ;)

Bye,
Skybuck.
 
Skybuck Flying wrote:

I have no idea what a north bridge and south bridge chip is... but could
this be the same design ? :):):)
Yeah ! No surprise sunshine ! Why not simply do some self-study ? It worked for me.

Graham
 
Skybuck Flying wrote:

"Pooh Bear" &lt;rabbitsfriendsandrelations@hotmail.com&gt; wrote in message
news:42F2F56E.2B3369B2@hotmail.com...

Skybuck Flying wrote:

Nice introduction to signals across a wire.


http://penguin.dcs.bbk.ac.uk/academic/technology/physical-layer/asynchronous/index.php

I never understood the difference between voltage and ampere... to bad
this
page doesn't discuss how ampere is related to voltage. (voltage&lt;-&gt;ampere
very confusing )

That's pretty fundamental. The classic example is to compare electricity
to water.

Voltage is like water pressure - current is like water flow. With no
pressure no water
flows. The larger the pipe ( less resistance to flow ) the more water
flows. In a similar
way, the less electrical resistance, the more Amps flow in a circuit for a
given voltage.

Does this mean a pipe diameter (of a certain material) always allows a
certain maximum voltage ?

So if the source of the voltage becomes to high the pipe blows ? :)
That would be exceptional and irrelevant to any sensible understanding.

I'm getting bored of your trolling now.....

Graham
 
"Pooh Bear" &lt;rabbitsfriendsandrelations@hotmail.com&gt; wrote in message
news:42F3092F.FA71FA17@hotmail.com...
Skybuck Flying wrote:

"Pooh Bear" &lt;rabbitsfriendsandrelations@hotmail.com&gt; wrote in message
news:42F2F56E.2B3369B2@hotmail.com...

Skybuck Flying wrote:

Nice introduction to signals across a wire.



http://penguin.dcs.bbk.ac.uk/academic/technology/physical-layer/asynchronous/index.php

I never understood the difference between voltage and ampere... to
bad
this
page doesn't discuss how ampere is related to voltage.
(voltage&lt;-&gt;ampere
very confusing )

That's pretty fundamental. The classic example is to compare
electricity
to water.

Voltage is like water pressure - current is like water flow. With no
pressure no water
flows. The larger the pipe ( less resistance to flow ) the more water
flows. In a similar
way, the less electrical resistance, the more Amps flow in a circuit
for a
given voltage.

Does this mean a pipe diameter (of a certain material) always allows a
certain maximum voltage ?

So if the source of the voltage becomes to high the pipe blows ? :)

That would be exceptional and irrelevant to any sensible understanding.

I'm getting bored of your trolling now.....
I am not trolling I am trying to understand it. But ok I can see how a dirty
mind might think that's funny.

And in case you didn't understand that sentence here it is again:

So if the pressure of source of the voltage becomes to high the pipe blows ?

Without the smiley :D :p :D

Bye,
Skybuck.
 
"Skybuck Flying" &lt;nospam@hotmail.com&gt; wrote in message news:...
"Pooh Bear" &lt;rabbitsfriendsandrelations@hotmail.com&gt; wrote in message
news:42F3092F.FA71FA17@hotmail.com...

Skybuck Flying wrote:

"Pooh Bear" &lt;rabbitsfriendsandrelations@hotmail.com&gt; wrote in message
news:42F2F56E.2B3369B2@hotmail.com...

Skybuck Flying wrote:

Nice introduction to signals across a wire.




http://penguin.dcs.bbk.ac.uk/academic/technology/physical-layer/asynchronous/index.php

I never understood the difference between voltage and ampere... to
bad
this
page doesn't discuss how ampere is related to voltage.
(voltage&lt;-&gt;ampere
very confusing )

That's pretty fundamental. The classic example is to compare
electricity
to water.

Voltage is like water pressure - current is like water flow. With no
pressure no water
flows. The larger the pipe ( less resistance to flow ) the more
water
flows. In a similar
way, the less electrical resistance, the more Amps flow in a circuit
for a
given voltage.

Does this mean a pipe diameter (of a certain material) always allows a
certain maximum voltage ?

So if the source of the voltage becomes to high the pipe blows ? :)

That would be exceptional and irrelevant to any sensible understanding.

I'm getting bored of your trolling now.....

I am not trolling I am trying to understand it. But ok I can see how a
dirty
mind might think that's funny.

And in case you didn't understand that sentence here it is again:

So if the pressure of source of the voltage becomes to high the pipe blows
?

Ok one more try:

So if the pressure of source of the voltage becomes to high the pipe blows
up ? ;)

Bye,
Skybuck.
 
Skybuck Flying wrote:

"Pooh Bear" &lt;rabbitsfriendsandrelations@hotmail.com&gt; wrote in message
news:42F3092F.FA71FA17@hotmail.com...

I'm getting bored of your trolling now.....

I am not trolling I am trying to understand it. But ok I can see how a dirty
mind might think that's funny.
Your amusement factor is declining fast.

I suggest ( if you're serious ) that you start reading a few decent books on electronic
theory and practice. It'll come in handy !

Ohhh... hobby magazines such as Elektor ( if it still exists ) are a good source of info
about practical circuits that can be easily built on a hobbyist basis. They are good
foundations upon which to learn.

Graham
 
Skybuck Flying wrote:
"Bob Monsen" &lt;rcsurname@comcast.net&gt; wrote in message
news:8uudndJMU45UTm_fRVn-qg@comcast.com...

Skybuck Flying wrote:

the operating system. If you are programming on the 'bare metal' as they
say, then you can do whatever the hell you want. Your "ReadBit" routine
can simply loop, waiting for the hardware to respond. It can block, and
let other processes or threads do work while it waits. It can shut off
the CPU, and wait for an interrupt.


Where can I find an example of this concept on the internet, if any ?

I don't know how complex this technique is... but if it's not too

complex I

would like
to see a drawing of the gates required etc, as to get a better

understanding

of
how it works together with the clock signal etc.

Bye,
Skybuck.



There are lots of examples of PIC code which drives I2C or SPI devices.
Google for "PIC I2C SPI". I got 35,000 hits.


Ok, the PIC description seems a bit to general, too complex, too many
variations for me to understand ;)

http://en.wikipedia.org/wiki/PIC_microcontroller

The I2C bus is something I can understand :)

http://www.semiconductors.philips.com/markets/mms/protocols/i2c/

However it seems to be really slow :)
The advantages of I2C and SPI are that there are already devices that
use these protocols.

However, most general purpose computers use a parallel bus to connect to
the memory controller. There is a hardware protocol, specified by the
processor, for presenting the address and doing the read or write. This
is a very fast scheme, but has some inherent flaws, such as signals
arriving at the destination at different times, ground bounce,
crosstalk, etc. Improperly terminated memory busses can ring, producing
data errors.

There are some new serial ICs that allow one to serialize these parallel
accesses, but I don't know much about them ( I read an article on them
in EDN... ;). I believe their primary purpose is to allow the designer
to bypass the traditional problems of clock and signal skew at higher
speeds. As I recall, the clock and data are transmitted using some kind
of manchester encoding scheme (similar to ethernet), so a single
connection can be used. Special hardware on both sides encodes and
decodes the data, and presents the 'user' with a parallel interface.

There are also schemes where multiple of these asynchronous serial
connections can transmit parts of words, which can then be reassembled
at some point elsewhere on the board. This is even faster.

In general, there are an infinite number of answers. I believe you don't
know enough to ask the right questions. Perhaps a better approach would
be to describe what it is you are really trying to do, rather than
asking general, open-ended questions that generate far too much
information for you to process.

Sadly, this forum is not very good for obtaining general knowledge. A
book like "The Art of Electronics" or something like that might be a
better place to start. An electronics course at your local Junior
College might also be way to go.

"
To begin, the bus has kept pace with performance and today provides three
levels of data rate transfer: up to 100 kbps in Standard mode, up to 400
kbps in Fast mode, and up to 3.4 Mbps in High-Speed mode
"

That's per second ??

And ofcourse it uses fixed bit address, 8 bit bytes, and is ment for
multiple devices on the same bus which might be interesting, but it's not a
requirement for me at the moment :)

So first I would have to understand why this thing is so slow... probably
the electronics or maybe it's the clock rate ? etc...

Or... is it a physical limitation ?
The speed limit has to do with the nature of the protocol. It works by
one of the communicating processors grounding the bus through a
resistor. However, there is capacitance inherent in any device, and this
grounding must drain this capacitance. This takes time, proportional to
the product of the resistance and capacitance.

So first I would need to understand how fast eletronics and a 0 or 1 signal
can move across a wire and can be detected by devices, ports etc.
Again, you need a basic course in analog electronics. Try the MIT open
courseware, which is free. 6002 is a good place to start.

So first I would need to compare my own idea which is kinda simple to this
idea...
You don't even understand the problems yet, much less the solutions. I
understand your desire, but the first step towards competence is first
finding out what you don't know.

So the first question would be: How fast would my alternative idea be with
the latest and greatest hardware thingies... like gates and stuff and
resistors.

The second question would be: How fast would it be if it used
generally/common available components on the market today ? ;)

Now on to SPI ;)

I guess this is the one you mean ;)

http://en.wikipedia.org/wiki/Serial_Peripheral_Interface

Ok that's a very general description. Not much use but ok ;) It does explain
some benefits... like reduced cost ;) and disadvantages slower ;)

http://embedded.com/showArticle.jhtml?articleID=9900483

This link is also about SPI and explains it's more suited for data
streams... ;) instead of addressed stuff ;)

It's also point to point ;) ( the lack of device addressing means less
overhead. )

"
At a higher level

SPI does not have an acknowledgement mechanism to confirm receipt of data.
In fact, without a communication protocol, the SPI master has no knowledge
of whether a slave even exists. SPI also offers no flow control. If you need
hardware flow control, you might need to do something outside of SPI.
"

Ok, that sounds bad... the text above it also sounds pretty bad... lot's of
problems.. but hell it was ment for point to point... maybe single device to
single device... not necessarely single device to multiple devices...

Anyway both communication methods seems to require/work based on the concept
of a clock.
So the cpu and the memory need to run at the same clock speed. If the cpu
can not keep up.. it would miss important bits ? Sounds a little bit bad ;)
But then again... since the cpu would be looping around or something like
that... maybe it wouldn't miss a single bit of everything was timed right :)
For both of these protocols, the master provides the clock. For I2C,
there is a mechanism for a slow slave to hold off the master. For SPI,
there is no such mechanism. It is up to the master to clock the slave at
a speed the slave can handle.

However my cpu might need to talk to multiple devices hmmmm... :) but I
would simply add more lines :) :p

Well two nice examples of serial communication. I really need to find out
the physical limitations of signals across wires first :)

Bye,
Skybuck.

--
Regards,
Bob Monsen

If a little knowledge is dangerous, where is the man who has
so much as to be out of danger?
Thomas Henry Huxley, 1877
 
Skybuck Flying wrote:
Ok one more try:
If you aren't trolling, then might I suggest that the design of a
completely new computer architecture is probably beyond someone who
doesn't know about volts and amps. I'd guess about ten years of full
time study might be enough to raise your general level of knowledge
to a level at which the project wasn't a complete waste of everyone's
time. In the meantime, please understand that even with the best will
in the world (and whilst I may have been a little shirty yesterday,
others have certainly indulged you) you simply aren't credible as
an honest poster anymore.

So if the pressure of source of the voltage becomes to high the pipe blows
up ? ;)
Yes.

Bye,
Skybuck.
 
"Bob Monsen" &lt;rcsurname@comcast.net&gt; wrote in message
news:5vmdneq0d61ksW7fRVn-jg@comcast.com...
Skybuck Flying wrote:
"Bob Monsen" &lt;rcsurname@comcast.net&gt; wrote in message
news:8uudndJMU45UTm_fRVn-qg@comcast.com...

Skybuck Flying wrote:

the operating system. If you are programming on the 'bare metal' as
they
say, then you can do whatever the hell you want. Your "ReadBit"
routine
can simply loop, waiting for the hardware to respond. It can block,
and
let other processes or threads do work while it waits. It can shut off
the CPU, and wait for an interrupt.


Where can I find an example of this concept on the internet, if any ?

I don't know how complex this technique is... but if it's not too

complex I

would like
to see a drawing of the gates required etc, as to get a better

understanding

of
how it works together with the clock signal etc.

Bye,
Skybuck.



There are lots of examples of PIC code which drives I2C or SPI devices.
Google for "PIC I2C SPI". I got 35,000 hits.


Ok, the PIC description seems a bit to general, too complex, too many
variations for me to understand ;)

http://en.wikipedia.org/wiki/PIC_microcontroller

The I2C bus is something I can understand :)

http://www.semiconductors.philips.com/markets/mms/protocols/i2c/

However it seems to be really slow :)


The advantages of I2C and SPI are that there are already devices that
use these protocols.

However, most general purpose computers use a parallel bus to connect to
the memory controller. There is a hardware protocol, specified by the
processor, for presenting the address and doing the read or write. This
is a very fast scheme, but has some inherent flaws, such as signals
arriving at the destination at different times, ground bounce,
crosstalk, etc. Improperly terminated memory busses can ring, producing
data errors.

There are some new serial ICs that allow one to serialize these parallel
accesses, but I don't know much about them ( I read an article on them
in EDN... ;). I believe their primary purpose is to allow the designer
to bypass the traditional problems of clock and signal skew at higher
speeds. As I recall, the clock and data are transmitted using some kind
of manchester encoding scheme (similar to ethernet), so a single
connection can be used. Special hardware on both sides encodes and
decodes the data, and presents the 'user' with a parallel interface.

There are also schemes where multiple of these asynchronous serial
connections can transmit parts of words, which can then be reassembled
at some point elsewhere on the board. This is even faster.

In general, there are an infinite number of answers. I believe you don't
know enough to ask the right questions. Perhaps a better approach would
be to describe what it is you are really trying to do, rather than
asking general, open-ended questions that generate far too much
information for you to process.

Sadly, this forum is not very good for obtaining general knowledge. A
book like "The Art of Electronics" or something like that might be a
better place to start. An electronics course at your local Junior
College might also be way to go.

"
To begin, the bus has kept pace with performance and today provides
three
levels of data rate transfer: up to 100 kbps in Standard mode, up to 400
kbps in Fast mode, and up to 3.4 Mbps in High-Speed mode
"

That's per second ??

And ofcourse it uses fixed bit address, 8 bit bytes, and is ment for
multiple devices on the same bus which might be interesting, but it's
not a
requirement for me at the moment :)

So first I would have to understand why this thing is so slow...
probably
the electronics or maybe it's the clock rate ? etc...

Or... is it a physical limitation ?


The speed limit has to do with the nature of the protocol. It works by
one of the communicating processors grounding the bus through a
resistor. However, there is capacitance inherent in any device, and this
grounding must drain this capacitance. This takes time, proportional to
the product of the resistance and capacitance.

So first I would need to understand how fast eletronics and a 0 or 1
signal
can move across a wire and can be detected by devices, ports etc.


Again, you need a basic course in analog electronics. Try the MIT open
courseware, which is free. 6002 is a good place to start.
I seek a simple but realistic answer to my question for a real world device.
If it's not simple then so be it.

I do not seek a dumbed down version of reality so the MIT open courseware is
not for me.

Bye,
Skybuck.
 

Welcome to EDABoard.com

Sponsor

Back
Top