View previous topic :: View next topic |
Author |
Message |
vinniewryan
Joined: 29 Jul 2009 Posts: 154 Location: at work
|
clocking at the speed of electricity |
Posted: Thu Feb 03, 2011 1:06 pm |
|
|
This is an odd idea I had a while ago, but I haven't been able to find anything like it. I'm designing a concept for a type of communication that rather than being limited by clock speed, is limited by internal switching speed of the unit which the micro controller is communicating with. For instance, instead of a constant synchronous clock signal that cycles on every high pulse, it would cycle on both high and a low pules, similar to Manchester but without the center clock signal, and instead of the clock pulsing at a certain speed, it would only advance when a feedback pulse is detected letting it know a bit has been successfully received. Does this sound like any type of known communication? It seems to me something like this would be much faster than using a serial line.
For example, MCUT is transmitting and MCUR is receiving. There would be 2 clock lines between the MCU's, one controlled by MCUT and one by MCUR, and a DATA line which determines the bit sent H(1) or L(0). When transferring a bit, DATA goes high or low depending on the bit it's sending, MCUT CLK goes high to let MCUR know a bit is ready. MCUR detects that high pulse, monitors DATA line and saves the bit, and sets MCUR CLK to high which tells MCUT that the bit has been successfully saved. Now that both CLK lines are high, the next cycle starts but this time MCUT and MCUR will set CLK lines LOW when a bit is ready or received. This method would seem to have the least possible latency as there is no time wasted between communicating each bit. Most of the latency would be caused by MCUR and MCUT saving bits to their ROM and monitoring their clock inputs, even then this is a very minimal amount of time wasted, and the same time would be required by a processor that's monitoring a clock high/low signal. Additionally, DATA line can be used to send other information such as the beginning and end of a transmission, by changing state independently of the clock line.
I would like to conduct an experiment using a 40MHz PIC transferring data via the fastest possible method known on a PIC, would SPI achieve a higher transfer speed than SERIAL at the highest possible baud? I want to compare using SPI or SERIAL to transmit a byte of data, then use my method (all software based) to transmit a byte, and compare the time consumption. A hardware system would be much faster (instant) but first I need to prove out the time benefit.
So for those of you who missed the 'question' in this post, I just want to know the fastest type of communication available on a 40MHz PIC (including all instructions and latency required to send one byte) with hardware SPI, I2C, UART/USART, USB, and which ever other data transfer types are up there speed wise.
Thoughts? _________________ Vinnie Ryan |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
![](templates/subSilver/images/spacer.gif) |
vinniewryan
Joined: 29 Jul 2009 Posts: 154 Location: at work
|
|
Posted: Thu Feb 03, 2011 1:49 pm |
|
|
True, but in current serial communication propagation is still a present factor, so would it not be possible for this (non-uniform clock) type of communication to exceed the possible speed of a typical serial system where a clock signal requires a high and low pulse in every frame, and a few clock signals to sync up? I don't see why an instruction shouldn't be able to run on every high 'and' low pulse, virtually doubling the data rate, or rather increasing it by 2/3 when factoring in the feedback pulse required by the receivers clock line. _________________ Vinnie Ryan |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Thu Feb 03, 2011 2:47 pm |
|
|
Seriously few high speed communication systems 'require a high and low pulse in every frame'. Do a search on 'trellis encoding', which is the most basic type....
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
vinniewryan
Joined: 29 Jul 2009 Posts: 154 Location: at work
|
|
Posted: Thu Feb 03, 2011 3:39 pm |
|
|
Thanks for the suggestion Ttelmah, I found a great document that explains Trellis Coded Modulation very throughly. Is there a 'fastest' type of data communication in your opinion? I hadn't even considered modulated signaling for data communication, though with my limited knowledge with this type of signal, it still seems the minimum Euclidean distance between sequences of data is greater than it 'could' be if there was a 2-way clock instead of a 'required time' between each bit or wave of information. _________________ Vinnie Ryan |
|
![](templates/subSilver/images/spacer.gif) |
miro
Joined: 15 Jan 2011 Posts: 62
|
|
Posted: Sat Feb 05, 2011 12:08 pm |
|
|
Vinnie,
I think the fastest way to communicate with the native HW pic24HJ interfaces is the communication via SPI. The max bitrate is Fclock/4 = 40/4 = 10Mbits = 1Byte in ~800ns. You can do 8bit or 16bit transfers. As you are sending data out you are receiveing a byte in as well. So in one transfer of e.g. 8bit out from MCU1 you get 8 bit into MCU1 from MCU2. If not considering overhead like data preparation and polling SPI's input buffer full flag, the 40MHz clocked pic24HJ can do best case 32 instructions (there are 1,2,3 -clockcycle instructions however) during the time of sending/receiving one byte via SPI. So when your transfer coding scheme fits into ~800ns timeframe you may be faster than the SPI. My experiments showed when polling the SPI's input buffer full the "efficiency" of SPI transfers is only 30-40%. Microchip shall do something with this (e.g. a 4-8xPLL multiplier for the internal SPI clock) as the most modern external devices run up to 40-66MHz SPI clocks. Miro. |
|
![](templates/subSilver/images/spacer.gif) |
vinniewryan
Joined: 29 Jul 2009 Posts: 154 Location: at work
|
|
Posted: Thu Feb 17, 2011 8:44 pm |
|
|
Thank you for this information! I'll do a little more research, then some tests. I'll update if anything looks promising, thought for now it's just an idea that's been haunting my mind ever since a 64MHz PIC wasn't fast enough for a project.
Cheers! _________________ Vinnie Ryan |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9170 Location: Greensville,Ontario
|
|
Posted: Fri Feb 18, 2011 6:30 am |
|
|
I'd like to know over what distance do you require. A few inches or a few miles?
If the former, you can easily get 8x performance in speed using data transfer called 'parallel'.
If the latter, my remote energy control modules can get about 24 miles over one solid copper wire.Huge tradeoff in speed vs. distance though. |
|
![](templates/subSilver/images/spacer.gif) |
|