CPU <> Memory chip communication interface
|
From: Pooh Bear on 5 Aug 2005 04:00 Skybuck Flying wrote: > "Pooh Bear" <rabbitsfriendsandrelations(a)hotmail.com> wrote in message > news:42F3092F.FA71FA17(a)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
From: Bob Monsen on 5 Aug 2005 05:10 Skybuck Flying wrote: > "Bob Monsen" <rcsurname(a)comcast.net> wrote in message > news:8uudndJMU45UTm_fRVn-qg(a)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
From: Ken Hagan on 5 Aug 2005 05:15 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.
From: Skybuck Flying on 5 Aug 2005 06:10 "Bob Monsen" <rcsurname(a)comcast.net> wrote in message news:5vmdneq0d61ksW7fRVn-jg(a)comcast.com... > Skybuck Flying wrote: > > "Bob Monsen" <rcsurname(a)comcast.net> wrote in message > > news:8uudndJMU45UTm_fRVn-qg(a)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.
From: Skybuck Flying on 5 Aug 2005 07:10
"Ken Hagan" <K.Hagan(a)thermoteknix.co.uk> wrote in message news:dcvanf$ho3$1$8300dec7(a)news.demon.co.uk... > 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. Well that wasn't so hard ;) Can you answer my other questions too, are did MIT dumb you down to much to answer it ? ;) Bye, Skybuck. |