Propeller nybble-serial interchip communications speed

Lord Steve

I am thinking about doubling up Propellers on a project and wonder what other people have got for asynchronous serial communication speed between two Propellers.· I assume one cog per full duplex UART.· Also, I am interested in nybble-serial (four bits), but bit-serial or byte-serial numbers, etc., are ok; I can interpolate from that data.

So, what's the fastest stable serial communications you've got your Props to do?

Harley

My application uses just two Props; i/f required a few more than the 32 I/Os. Communications between them is at 115,200 baud and is adequate for my needs; no more than 5 bytes need be sent at a time, max. If I recall, FDS can run about twice that, but I had no need to push near maximum.

One Prop uses a 5 MHz crystal and x16 PLL and outputs a 5 MHz square wave using one of the counters for a clock to the second Prop, also running x16 PLL. So they run in lock step, though phasing doesn't seem to be any problem.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Lord Steve

At a bit width of 4, I was hoping for 4 megabits per second, allowing for some time to insert the received byte or long into a ring buffer.

Ken Peterson

I think I have read in this forum that someone has used SPI up to 1 Mb/s or more. That should give you 4 Mb/s with a 4 bit bus + clock. Not sure about maximum asynchronous rates.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

stevenmess2004

Beau or Paul made a serial link between two props that run at about 12Mb/s. The object is posted somewhere in the forum. I've done a 16 bit output to a dac (just a bunch of resistors) that run at about 2MHz. If you only wanted 4 bits this would be about 8Mb/s so its possible and shouldn't be too hard. If you want it to be duplex you will probably need two cogs though.

Bob Lawrence (VE1RLL)

Beau Schwabe (Parallax) - IC Layout Engineer

NEW 12/12/2007

14.5 Meg Baud Upgrade

http://forums.parallax.com/showthread.php?p=691952

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob

Lord Steve

Thank you very much, artist formerly known as Bob Lawrence.· That's what I wanted to see. [noparse]:D[/noparse]

hinv

Of course, if you clock your propellers at 96MHz, you should be able to get 17.4MBaud! Very cool indeed!

Doug

hippy

Over-clocking is something which most people don't seem to promote much, I suppose because it's such a black art, and is outside the official datasheet spec.

I ran with 7.3728MHz XTAL1+PLL16x for a fair while and didn't see any problems, just short of 118MHz. No special environment, just a normal ProtoBoard. That would take Beau's link over 20Mbps.

stevenmess2004

I'd be careful about running it that fast. The latest version of the datasheet (1.0) has a max clock speed vs temperature graph that is pretty interesting.

hippy

I didn't even expect it to work ( and mine only worked with PLL16x, not PLL8x - very odd ! ), and it seems Beau has had success as well ...

Beau Schwabe (Parallax) said...
But it's funny that you mention 7.3728 MHz... I have several of these myself, and have used them without any issues.

http://forums.parallax.com/showthread.php?p=717643

I don't want to start the whole "How Fast Can a Prop Go" debate again, but Parallax soak test to 104MHz and Cog breakdown is reported at around 120MHz, so I suspect 118MHz is just low enough to sneak in under the radar with a fair wind. I wouldn't recommend it for commercial product though. This is definitely way out on the limb.

It would be interesting to hear how successful others find 7.3728MHz, especially as that's +48% over 5MHz, 6MHz is just (!) +20%.

Sorry, this is going a bit off-topic.

Ken Peterson

Hippy:

Weren't you involved in some work to use the video output to implement an ethernet connection? That might be more slightly on-topic.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

hippy

@ Ken : Well remembered. It sort of worked ( some packets went out ) but I'm not an electronics engineer and how to wire up a RJ45 to get a suitable signal got me stumped, and I don't have a scope. It's a shame no one else took up the challenge of bit-banged ethernet as it looked promising, albeit transmit only, no collision detection.

stevenmess2004

You may be able to do receive. The prop should be able to get the data fast enough (1 cog can sample at 20MHz) but doing something with the data may be a different matter

hinv

As far as overclocking, 6MHz x16PLL =96MHz is in more than 2 commercial products already.
6.25MHz would be a bit better to top it at 100MHz or 25% overclock. Since 128MHz failed(oled PROP), and 120MHz is reported to fail, I think 118MHz is bit on the pushing it side, and could end up
with hours of debugging your code when it wasn't a code issue at all, and 7.3728 base clock just doesn't make even number at 117.765MHz which can be a little tricky on the math, I would suspect, ie hippy's ethernet project.

Doug

stevenmess2004

96MHz is good for tv broadcast because it lines up with the channel spacings or something better. There was a big discussion about it ages ago.

Looking at the chart in the data sheet the fastest you can run at 25 C and 3.6V is about 125MHz. If you cool the prop down to -55C then you can do about 140MHz so it all depends on temperature. Since hippys in England its probably a bit cooler than other places and he can get away with running it a bit faster.

hippy

Since hippys in England its probably a bit cooler than other places and he can get away with running it a bit faster.

That could well be a part of it. I don't like hot temperatures at the best of times, so I guess it's ranges between 18C-22C. It's in free-air so no enclosure to trap the heat, but nothing on-board even feels warm.

I can't understand the techno-babble in the datasheet nor know how to derate the Temp versus Frequency graph nor understand what that means in Real Life (TM), but under those test conditions 115MHz+ at 25C, 3V3 seems to work.

Maybe I've just got lucky, but it's been running multiple cogs for 24 hours now with no noticed problems driving TV and doing 38400 baud bit-banged serial in/out in Spin.

Ale

I have a board with two props in in it, using Beau's method for sending 32 bits at a time, writing to HUB memory and reading from HUB memory I attain a speed (measured with logic analyzer) of 1.8 MBytes per second (@ 80MHz) for 256 bytes that are my packets. Must be noted that such a system should be timed quite precisely because it can get out of sync for long packets due to HUB instructions having variable times if the maximum is not used in the equation !

Edit: 2 photos of the board mentioned. 640x480 LCD, just a half is used because... well there is no enough memory in one propeller for a 640x480 image. This is a sort of DSO for special purposes (3 CH). FFT is done on the fly, well when I get the OAs to work as I want

Post Edited (Ale) : 4/20/2008 7:48:40 PM GMT

hinv

Wow, thats's pretty cool! Care to share some pictures/schematics of your board?
HUB instructions having variable times? Once you sync up to the hub, it should be the same time every time.

Ale

On the left is a bread board with some level shifters for the display (it needs 5V signals!) and a positive power supply. A charge pump just does not cut it :-( (is on the board 4 diodes and the ACT00).

Harley

Ale,

I note two crystals. If both are same frequency, you could just use one crystal and use a counter to output clock/pll divisor if you have a spare pin and to ensure they are synchronous. (I use a 5 MHz crystal on one Prop with PLL=16 and a counter to output a 5 MHz square wave to second Prop.) Just a suggestion.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

hinv

Hi Harley & Ale,

Do either of you boot one prop off of the other also?

Harley

hinv said...

Hi Harley & Ale,

Do either of you boot one prop off of the other also?

Each of the Props have their own EEPROM, if that's what you're asking.

However there is communications between the two, both ways. For instance, on power-on/reset Prop#1 queries Prop#2 of its 'date of source' and number of cogs in use; a DAT section contains this info which is updated each build. This is displayed for both Props via TV_text object; this is for debug only. In use, a minimal display and keypad on a separate pcb is used.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Ale

I use two crystals, both 5 MHz both with the pll16x option. I did not think of that possibility because... I was a bit short of pins . I'd have used just one prop if it had 64 IOs (and a little more HUB mem), sadly it only has 32. I had hoped they would launch one with 64 IOs, it does not seem to be the case.

My comm is a bit different:

right COG sends commands to second and second answers with a number of longs depending on the command. The ADC data are 64 longs packets. Other commands (except an ID) are not yet implemented. I used 4 pins without pull-up/pull-downs. In noisy conditions (my Oszi seems to be one source of that), the comm fails. I think some pull-downs may help (I thought about 100 k pull-downs).

Edit: each prop has its own EEPROM.

Harley

Ale said...
I had hoped they would launch one with 64 IOs, it does not seem to be the case.

I assume you've heard by now that Propeller II will have the 64 I/Os. I was in the same boat, needing more than 32 I/Os. Am (im)patiently awaiting Prop II release as are most others.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Paul Baker

hippy said...

I can't understand the techno-babble in the datasheet nor know how to derate the Temp versus Frequency graph nor understand what that means in Real Life (TM), but under those test conditions 115MHz+ at 25C, 3V3 seems to work.

I didn't provide de-rating because everyone's application is going to be different. Someone with a non-critical app could probably get away with a 5% derate of thier maximum expected operating temperature. For something whose product reliability is important may need to de-rate by 20% just to be sure thermal effects will never become an issue with thier design, especially in when deploying into an extreme environment. If there's any other techno-babble you'd like me to explain I would be happy to.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Paul Baker

Harley said...

Ale said...
I had hoped they would launch one with 64 IOs, it does not seem to be the case.

I assume you've heard by now that Propeller II will have the 64 I/Os. I was in the same boat, needing more than 32 I/Os. Am (im)patiently awaiting Prop II release as are most others.

It has been completed, but the LVS utility chokes on the design. Until we can resolve this issue, the P8X32B (Prop-1 w/ 64 I/O) will remain on the shelf.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

hinv

Wow, this is news to me. I didn't know there was planned a Prop-1 with 64 I/O. Is it likely to come out before the prop-2, or just stay shelved? What is a LVS utility?

Doug

hippy

Paul Baker (Parallax) said...

hippy said...


I can't understand the techno-babble in the datasheet nor know how to derate the Temp versus Frequency graph nor understand what that means in Real Life (TM), but under those test conditions 115MHz+ at 25C, 3V3 seems to work.

I didn't provide de-rating because everyone's application is going to be different ... If there's any other techno-babble you'd like me to explain I would be happy to.

Apologies if any offense was perceived it wasn't intended nor was it a criticism. It wasn't however a good choice of phrase. It's my lack of understanding and knowledge which is the problem on this subject.

Ken Peterson

Interesting bit of information from Paul. I guess when faced with such a setback, it's better to concentrate one's resources on the PropII than on the incremental Propeller upgrade. Hopefully the Prop II development isn't destined to encounter similar difficulties.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Beau Schwabe

The Prop1-64pin IO is being worked on by another individual who worked on the original Prop1-32pin IO.· The Prop2 layout is being done by me.· Also,·I am providing a second set of eyes to look into the current Prop1-64pin IO issues.
LVS or (Layout Versus Schematic)·is a term implying a tool used to check·that what you have created in layout matches the design parameters placed in the schematic.· Another common·design check is called DRC or (Design Rule Check) ... this makes sure that wires meet metal migration rules, and that various structures are not too close to one another in the design.
"Hopefully the Prop II development isn't destined to encounter similar difficulties." - Unfortunately it's the nature of the LVS beast, however many errors can be avoided if a hierarchical 1:1 correspondence can be maintained between the layout and schematic.· Sometimes however under certain conditions this rule·needs to be broken.· This·can cause anchoring reference points to be lost and confuse the LVS tool.
·





▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 4/22/2008 2:48:11 AM GMT