CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

clocking at the speed of electricity

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
vinniewryan



Joined: 29 Jul 2009
Posts: 154
Location: at work

View user's profile Send private message MSN Messenger

clocking at the speed of electricity
PostPosted: Thu Feb 03, 2011 1:06 pm     Reply with quote

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
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Feb 03, 2011 1:25 pm     Reply with quote

There is a limit to the propagation time of electrical signals. You can do
the following experiment on your bench, which I have done in the past,
to show this. Here is a web page that shows how to do it:
http://www.physics.ucsb.edu/~lecturedemonstrations/Composer/Pages/76.18.html
vinniewryan



Joined: 29 Jul 2009
Posts: 154
Location: at work

View user's profile Send private message MSN Messenger

PostPosted: Thu Feb 03, 2011 1:49 pm     Reply with quote

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
Ttelmah



Joined: 11 Mar 2010
Posts: 19327

View user's profile Send private message

PostPosted: Thu Feb 03, 2011 2:47 pm     Reply with quote

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
vinniewryan



Joined: 29 Jul 2009
Posts: 154
Location: at work

View user's profile Send private message MSN Messenger

PostPosted: Thu Feb 03, 2011 3:39 pm     Reply with quote

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
miro



Joined: 15 Jan 2011
Posts: 62

View user's profile Send private message

PostPosted: Sat Feb 05, 2011 12:08 pm     Reply with quote

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.
vinniewryan



Joined: 29 Jul 2009
Posts: 154
Location: at work

View user's profile Send private message MSN Messenger

PostPosted: Thu Feb 17, 2011 8:44 pm     Reply with quote

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
temtronic



Joined: 01 Jul 2010
Posts: 9161
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Feb 18, 2011 6:30 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group