What I was always thinking is that if the XLINK protocol is used then the XMOS end of it is all handled in hardware (If I understand correctly). Which means no threads or cores there wasted in managing some other protocol and perhaps messing up timing in the actual application code there.
Where is the best description of the XLINK protocol? I seem to have missed the "self clocking" part somehow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think that self-clocking is inherent in the transition-based NRZ signaling that is used. The best document is the XS1 System Spec. (xsystem.pdf). The XMOS transmitting clock will need to be slowed down, of course.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Sorry yes I was thinking about "self-clocking" backwards for a while. The clock is in the signal rather than in a dedicated clock line. But how do you set the transmitting clock down to a speed low enough that the Prop can handle it? I had a quick look through some docs a while ago and didn't get it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You will see a couple of good code suggestions from, guess who?, PhilPilgrim.
I was a bit under hand in posing that coding challenge at first which, quite rightly, annoyed a couple of people. My apologies for that. I purposely left out any mention of XMOS in the initial post because I guessed the reaction might be along the lines of what has happened on this thread.
Anyway I was also posing it as a possible Prop to Prop protocol but I guess it has no benefits there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: The clock for the xlink can be set down to 512 khz or so. I asked that a while ago in the xmoslinkers forum. I think you have to use one of the clock lines and use the prescaler.
The XMOS AVR XLink code is written in C (gcc), and includes both 2-wire and 5-wire implementations. It was developed by XMOS themselves for an application. It could be converted into PASM quite easily.
I just had a look at Heater's thread, and didn't see complaints from anyone.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
You did not see any complaints because I did not mention XMOS throughout the thread. Instead I said "a certain multi-core embedded processor chip" and I guess few people cottoned on.
I did so firstly because did not want to be seen to be promoting a competitors product on the forum and secondly because I feared the response similar to the one on this thread.
As it was I got told off for being "disingenuous, maybe even deceitful". Which is quite understandable because, well, I was. Sorry about that. I hope everyone can see how I got my self into that bind.
Anyway, we are here now and it looks like the XLINK problem has a solution. One step closer to some new peripherals for the Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I've sent an eMail to XMOS yesterday how I could order some proto-boards, because I don't have a gold card or PayPal or such. Got an answer today that I can pay by IBAN (Europe related).
So I'll make my order these days ...
Just have to decide what board(s) to order. BGA isn't fun, but I'm interested what *could* be done.
I think I'll buy a XC-5 and a XC-2.
And an XMP-64.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
That XMP64 is an example of why I was touting the idea of fast links between COGS, and fast serial links between Props for the Prop II. The idea comes to me and many others here from the old Transputer architecture.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
> The idea comes to me and many others here from the old Transputer architecture.
That's what the three do have in common to a more or less extent.
And that's why I think the Prop has a lot of potential.
I think as soon as Leon has the communication working, it can be used as a Prop-Prop communication and at the same time allow a Prop-XMOS communication. Nothing to complain about.
Nick, quite distracted by the tool & cutter grinder I got today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
I suspect that the XLINK protocol is not optimal for Prop to Prop communication. That was half the point of my coding challenge thread, to find out how well it could be done and what advantages it offered, if any, over the many other Prop to Prop solutions.
I would still like some one to enlighten me as to why the XLINK protocol is as it is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
> I suspect that the XLINK protocol is not optimal for Prop to Prop communication.
I neither had a look at the XMOS-protocol nor your challenge.
However, I'm tempted to say that as long as it is robust and as it is reasonably fast, it would serve for Prop-Prop-communications with the advantage to use the evil chip[noparse][[/noparse]tm] as some kind of interface-extender. A single well tested protocoll is better than 7 variants.
Just my two cents,
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Not sure how robust the link protocol is. It is designed for devices communicating within the same chip or on the same PCB. That is it assumes an error free connection in much the same way as any other connection on your circuit boards.
So, not designed for running down long cables etc. I guess it would be possible to add error detection/correction to a protocol layer above XLINK though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My problem is not with the XMOS chip, but the way it is being promoted on the Parallax forums.
If an XMOS chip can be used for it's real value with a prop, then that is fantastic. Just like we use a FT232, Viniculum, ENC28J60, Xport or whatever.
There are probably excellent uses for the XMOS chip. Every chip has it's advantages and disadvantages. If the XMOS can be put to real use with the Propeller, I am all for it. Just as long as it is not an excuse to promote the XMOS chips over the Propeller.
I·think the XMOS can do USB (host and slave) and Ethernet - is that true??? These are missing items in our·prop circuits·without other support chips.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
XMOS chips can do high-speed USB (480 Mb/s) and Ethernet, in software. High-speed USB takes four threads. Full-speed USB takes two threads. A Phy chip is needed, of course. The Propeller II should have the same capabilities, of course.
I could add high-speed USB or Ethernet to that little PCB of mine. It would need a few more connections to the XMOS chip, of course.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Cluso, I agree. There is a fine line here between "Hey here is this neat device we can use with the Prop" and "Hey here is a neat device that makes the Prop obsolete and replaces it"
I am in the former camp. Here is a device that has the potential to replace a lot of other peripherals and glue logic that we already tack onto the Prop. Ethernet, USB etc etc. In fact for the meagre cost of $7.50 its worth it just to provide 64 extra I/O pins.
Yes it can do USB slave/host and Ethernet and SPDIF and .... There is a growing library of software available for it to do these things.
So I'm all for figuring out the best ways to interface a Prop and an XMOS. Optimising for cost, space, simplicity... all the usual engineering trade offs.
As for promoting the XMOS over the Prop. Well reality is there is a set of problems XMOS can handle which the Prop cannot. So we can just direct discussion of of that set of apps over to the XMOS forums and be done with it here.
There is a set of problems which they can both handle. So why not weigh up the pros and cons of each here?
Then there is a set of problems the Prop can solve that the XMOS cannot.
I do not see the Prop and XMOS as being directly comparable. Superficially they are similar, multi core, deterministic timing etc etc. But, as I have said before, taken as a whole from the architecture, the programming languages the IDEs all the way up to the plug and play objects in OBEX they live in different worlds.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I managed to find my stock of 10 MHz SM crystals last night, and added one to the board.
I've just got the XMOS chip setting the port high and low alternately, and am reading the values with the Propeller and sending them to SimpleDebug. I should have double-checked the connections on my PCB, the port is offset by one pin, so I'm getting 7F instead of FF. Rewiring all the tracks to the Propeller is really needed, but I'll just fix the one pin for now and sort out the connections in software.
Here's the XC program I'm using:
/*
============================================================================
Name : main.xc
Description : Test program for XC-1/XProg - writes
0xFF and 0x00 to 8-bit port pins X0D26 - X0D23 (P8C0 - P8C7)
============================================================================
*/
#include <platform.h>
#define PERIOD 20000000
out port Data = XS1_PORT_8C;
int main(void)
{
timer tmr;
unsigned t;
tmr :> t;
while (1)
{
Data <: 0xFF;
t += PERIOD;
tmr when timerafter(t) :> void;
Data <: 0x00;
t += PERIOD;
tmr when timerafter(t) :> void;
}
return 0;
}
More than I follow this thread, and after I have had a read of the heater challenge, this XLINK seems very familiar to me (it seems a clone of the wiegand protocol)
Well Wiegand does seem to put "ones" on one line and "zeros" on another line like the XLINK 2 wire protocol.
After that I don't know. Wiegand also has something to say about the higher level formatting of data bits, start bits etc which I'm sure is different.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'd like to add another perspective which I think is lacking here, that of someone who doesn't own either a Prop or XMOS chip. This thread has me considering getting Leon's hybrid board or Kludging something like it. Another thread recently reminded me of Jeff Fox' F*, a super-simple implementation of distributed shared memory in Forth. While you could provide hardware support for that with an FPGA, Leon's board seems both simpler and arbitrarily scalable. You might consider DSM as the software model for interfacing the Prop and XMOS. Then everything would appear as existing in shared memory space. I'm looking at this from the Prop's standpoint mostly, that you would program the Prop(s) and the XMOS chips would provide communications, control memory access, address translation and memory locks on critical data.Less often I think people would program the XMOS side, for instance, gamers might write a 3D engine to run on the XMOS side and access to this would be through designated memory locations in shared memory space.
I don't think this would be hard to do in Forth, but it seems unlikely you could interest other language implementers to buy into this unless it became fairly popular. Still possible to work with without extensive language support, but you probably end up working with raw memory addresses rather than the software creating named data structures in shared memory for you.
I've got those, as well as two XC-1s (one is on loan to someone). You really need the latter for my Propeller PCB, but it could be interfaced to the XC-2 or the XK-1 with an intermediate PCB or some awkward wiring.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
I've just got the data transfers working in the opposite direction, with the software correction for my hardware error implemented on the XMOS chip. Now to get the handshaking working.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Comments
Where is the best description of the XLINK protocol? I seem to have missed the "self clocking" part somehow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
http://forums.parallax.com/showthread.php?p=845309
You will see a couple of good code suggestions from, guess who?, PhilPilgrim.
I was a bit under hand in posing that coding challenge at first which, quite rightly, annoyed a couple of people. My apologies for that. I purposely left out any mention of XMOS in the initial post because I guessed the reaction might be along the lines of what has happened on this thread.
Anyway I was also posing it as a possible Prop to Prop protocol but I guess it has no benefits there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
-Phil
I just had a look at Heater's thread, and didn't see complaints from anyone.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 11/20/2009 5:45:20 PM GMT
I did so firstly because did not want to be seen to be promoting a competitors product on the forum and secondly because I feared the response similar to the one on this thread.
As it was I got told off for being "disingenuous, maybe even deceitful". Which is quite understandable because, well, I was. Sorry about that. I hope everyone can see how I got my self into that bind.
Anyway, we are here now and it looks like the XLINK problem has a solution. One step closer to some new peripherals for the Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
So I'll make my order these days ...
Just have to decide what board(s) to order. BGA isn't fun, but I'm interested what *could* be done.
I think I'll buy a XC-5 and a XC-2.
And an XMP-64.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That's what the three do have in common to a more or less extent.
And that's why I think the Prop has a lot of potential.
I think as soon as Leon has the communication working, it can be used as a Prop-Prop communication and at the same time allow a Prop-XMOS communication. Nothing to complain about.
Nick, quite distracted by the tool & cutter grinder I got today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I would still like some one to enlighten me as to why the XLINK protocol is as it is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I neither had a look at the XMOS-protocol nor your challenge.
However, I'm tempted to say that as long as it is robust and as it is reasonably fast, it would serve for Prop-Prop-communications with the advantage to use the evil chip[noparse][[/noparse]tm] as some kind of interface-extender. A single well tested protocoll is better than 7 variants.
Just my two cents,
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Not sure how robust the link protocol is. It is designed for devices communicating within the same chip or on the same PCB. That is it assumes an error free connection in much the same way as any other connection on your circuit boards.
So, not designed for running down long cables etc. I guess it would be possible to add error detection/correction to a protocol layer above XLINK though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
If an XMOS chip can be used for it's real value with a prop, then that is fantastic. Just like we use a FT232, Viniculum, ENC28J60, Xport or whatever.
There are probably excellent uses for the XMOS chip. Every chip has it's advantages and disadvantages. If the XMOS can be put to real use with the Propeller, I am all for it. Just as long as it is not an excuse to promote the XMOS chips over the Propeller.
I·think the XMOS can do USB (host and slave) and Ethernet - is that true??? These are missing items in our·prop circuits·without other support chips.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The *only* reason I'm using other processors with the propeller : Multiply.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I could add high-speed USB or Ethernet to that little PCB of mine. It would need a few more connections to the XMOS chip, of course.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 11/21/2009 8:51:48 AM GMT
I am in the former camp. Here is a device that has the potential to replace a lot of other peripherals and glue logic that we already tack onto the Prop. Ethernet, USB etc etc. In fact for the meagre cost of $7.50 its worth it just to provide 64 extra I/O pins.
Yes it can do USB slave/host and Ethernet and SPDIF and .... There is a growing library of software available for it to do these things.
So I'm all for figuring out the best ways to interface a Prop and an XMOS. Optimising for cost, space, simplicity... all the usual engineering trade offs.
As for promoting the XMOS over the Prop. Well reality is there is a set of problems XMOS can handle which the Prop cannot. So we can just direct discussion of of that set of apps over to the XMOS forums and be done with it here.
There is a set of problems which they can both handle. So why not weigh up the pros and cons of each here?
Then there is a set of problems the Prop can solve that the XMOS cannot.
I do not see the Prop and XMOS as being directly comparable. Superficially they are similar, multi core, deterministic timing etc etc. But, as I have said before, taken as a whole from the architecture, the programming languages the IDEs all the way up to the plug and play objects in OBEX they live in different worlds.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I've just got the XMOS chip setting the port high and low alternately, and am reading the values with the Propeller and sending them to SimpleDebug. I should have double-checked the connections on my PCB, the port is offset by one pin, so I'm getting 7F instead of FF. Rewiring all the tracks to the Propeller is really needed, but I'll just fix the one pin for now and sort out the connections in software.
Here's the XC program I'm using:
/* ============================================================================ Name : main.xc Description : Test program for XC-1/XProg - writes 0xFF and 0x00 to 8-bit port pins X0D26 - X0D23 (P8C0 - P8C7) ============================================================================ */ #include <platform.h> #define PERIOD 20000000 out port Data = XS1_PORT_8C; int main(void) { timer tmr; unsigned t; tmr :> t; while (1) { Data <: 0xFF; t += PERIOD; tmr when timerafter(t) :> void; Data <: 0x00; t += PERIOD; tmr when timerafter(t) :> void; } return 0; }and here's the Spin program:
'Test.spin ' ' CON _clkmode = xtal1 + pll8x _xinfreq = 10_000_000 P0 = 0 P1 = 1 P2 = 2 P3 = 3 P4 = 4 P5 = 5 P6 = 6 P7 = 7 P8 = 8 P9 = 9 OBJ debug : "SimpleDebug" VAR Byte v PUB Go DirA[noparse][[/noparse]P0..P7] := %0000_0000 'all inputs debug.start(9600) Repeat v := InA[noparse][[/noparse]P0..P7] debug.hex(v, 2) debug.putc($20)Alternating between XC and Spin like this makes my brain hurt.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 11/21/2009 3:40:43 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
Here's the Propeller code to fix my hardware design error:
'Test.spin ' ' CON _clkmode = xtal1 + pll8x _xinfreq = 10_000_000 P0 = 0 P1 = 1 P2 = 2 P3 = 3 P4 = 4 P5 = 5 P6 = 6 P7 = 7 P8 = 8 P9 = 9 OBJ debug : "SimpleDebug" VAR Byte v, temp PUB Go DirA[noparse][[/noparse]P0..P7] := %0000_0000 'all inputs debug.start(9600) Repeat v := InA[noparse][[/noparse]P7..P0] temp := v & $01 temp := temp << 7 v := (v >> 1) | temp debug.hex(v, 2) debug.putc($20)It needs some more testing, but I think it's OK.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 11/21/2009 6:58:40 PM GMT
After that I don't know. Wiegand also has something to say about the higher level formatting of data bits, start bits etc which I'm sure is different.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I don't think this would be hard to do in Forth, but it seems unlikely you could interest other language implementers to buy into this unless it became fairly popular. Still possible to work with without extensive language support, but you probably end up working with raw memory addresses rather than the software creating named data structures in shared memory for you.
Something to think about anyway.
-phar
www.leonheller.com/Propeller/XProp/Index.html
I'll tart it up over the next day or two.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
You seem to have turned the critics completely around. Good for you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH