From: Skybuck Flying on 4 Aug 2005 22:52 I guess these routines could simply loop around and have the cpu looping inside them. So a simply concept of cpu<->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<->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.
From: Skybuck Flying on 5 Aug 2005 00:39 "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 :) " 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.
From: Skybuck Flying on 5 Aug 2005 00:58 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<->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.
From: Pooh Bear on 5 Aug 2005 01:13 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<->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
From: Skybuck Flying on 5 Aug 2005 01:54
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" <nospam(a)hotmail.com> 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<->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. > > |