Not yet. I want to get my parallel port working first. There is XLink FPGA code on Xlinkers, and for the AVR (in C). I'd copy the AVR code for the Propeller and rewrite it in PASM. Both 2-wire and 5-wire code is provided, IIRC.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
The only thing I see here is a cult kool-aid drinkers mentality where certain folks flip out and get real nasty when someone brings up another micro in discussion. Especially the X chip which many see here as the enemy which for some reason must not mentioned at all. Shades of Lord Voldemort.
Look the Prop isn't the only micro out there and comparisons will be made no matter how badly you want to go Big Brother and silence folks who violate your or Heaters unwritten forum rules.
And what was Leon's crime? Attaching a Prop to the X chip and posting about it.
Just amazing.
Walt, that is a totally unfair characterization. Can you point to even one other thread where the mention of another micro generates this kind of controversy? If indeed all Leon had done was attach a Propeller to an XMOS chip, I doubt anyone would have minded. The problem is less with the XMOS chip and more with Leon's repeated and inappropriate XMOS advocacy in other threads.
If you go to a friend's for dinner and spend the evening talking about the much tastier meal you had somewhere else, you shouldn't be surprised if they get annoyed with you. Even if what you're saying is true, it's insulting and rude, and they're going to wonder why you even bothered to come in the first place.
That's pretty much the situation with Leon. To a lot of folks, Leon's constant XMOS advocacy is reason to wonder about his real motives for this Propeller-XMOS project. It's not like they're reflexively getting their panties in a bunch just because some non-Propeller chip is being used; they feel that there's plenty of evidence that Leon has an XMOS chip on his shoulder.
That being said, I would suggest to those who suspect Leon of being an XMOS agent provocateur that they give him the benefit of the doubt. It seems to me that Leon actually likes the Propeller and believes the Propeller and XMOS serve two completely separate markets, so when he talks up the XMOS, he does not mean it as Propeller bashing. It's not a zero-sum game.
However, Leon should hopefully realize that the Parallax forums are not the best place for blatant XMOS rah-rah rhetoric. It rubs a lot of people the wrong way and generates more heat than light.
On the other hand, this thread, which directly involves a Propeller and the challenges of communicating with another processor, should be of interest to all on its technical merits. If in the process of exploring new possibilities for the Propeller some of us learn something about a different chip, so much the better.
Sorry to be so wordy, but I was very troubled by the tone of some of the posts here. There's no reason for discourtesy and name-calling among friends. I don't expect to change any minds, but I do fervently hope that anyone who's tempted to cast aspersions in this thread will take a moment, consider that the other guy might just have a point (even if you don't agree with it), realize that most folks just want to stay on-topic, and let it go.
Well said, and exactly why I don't consider this avenue of discussion a bother at all. Comparisons equating the two in a competitive way are annoying, but I don't see that here.
Hooking Propellers up to stuff is a good thing overall. The more the merrier, I say.
Here is the early stages of an attempt at creating the xlink protocol for the Prop in PASM.
Currently this only:
1) Implements the 4 wire serial interface.
2) Has a Tx COG that transmits an ever increasing token value from a LONG consisting of bits 0-7 as data and bit 9 as the control token flag.
3) Has an Rx COG that is receiving tokens on the same pins as the transmitter COG, as a loop back test, and dumping them to a long in HUB. Checks for parity errors.
4) The main Spin displays the received value every second using FullDuplexSerial to the BST terminal.
5) Requires BST to compile due to the use of @@@
There is a nice symmetry to the Tx and RX code in PASM, they both use exactly 4 instructions per bit. That's 5Mbits per second for an 80MHz Prop or 6.5536Mbits per second on my board.
Transmitting a bit looks like:
test ttoken, #%0_01000000 wz 'Get data bit 6 into carry
if_nz mov out_1, wire_1 'To toggle wire 1...
if_z mov out_1, wire_0 '...or wire 0
xor outa, out_1 'Toggle selected wire
This could be shrunk to 3 instructions but then there would be jitter on the output edges and I can't get the Rx to run faster anyway.
Receiver uses waitpne to sync with the first bit and then receiving each bit looks like
mov in_1, ina 'Get wires from P0 and P1
xor in_0, in_1 'Get wire changes
test in_0, #%1000 wz 'Test for wire 1 change
if_nz or rtoken, #%0_01000000 'Wire 1 change so set data bit 6
Next up I will add Tx add Rx FIFOs to this and try to write a version of the xmoslink_avr code. Initially in Spin I think.
I don't have any "chips that will be unnamed" to test this against yet so I only only have it running COG to COG on the same Prop. So presuming xlinks can be convinced to run at 5Mbits/second it would be nice if someone could try and test this.
I'd like to understand more of the higher level protocol before proceeding.
Edit: Currently the pins are hard coded to P2 and P3.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'll see if I can try it later on. I don't have an XLink on my XProp prototype connector so I'll have to bodge something with one of the other connectors and a Proto Board. I might even make a new PCB for the Propeller, connected by ribbon cable to the XC-1.
How does that 5 Mbit/s rate compare with other techniques for Prop-Prop comms?
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Not sure how the speed compares to other Prop-Prop solutions. But we are using 4 pins instead of a normal 2 for full duplex serial system.
I think I've pretty much written off the idea of implementing the parallel xlink with 5 wires in each direction. Firstly because that's a lot of our precious Prop pins. Secondly because it needs a lot more code to encode/decode the symbols Checking for 00, 01, 10, 11 in the output bit stream and then toggling one of five pins. It looks like it won't give enough speed gains to be worth the sacrifice of pins. Might even be better to run two 4 wire links in parallel than one 10 wire link. Have to investigate that a bit more.
I though about combining Tx and Rx into a single COG using coroutines like FullDuplexSerial does. So far I'm not keen on the idea as the speed will be less than half and because the whole idea is to export some USB, serial, whatever, functionality to the "chip that cannot be named" therefore the loss of a COG is a good trade off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Pardon me for this question but ...
Are the XMOS anywhere near $8 a piece, and is it possible for me to write an XMOS assembler and programmer in Spin or Femtobasic or PASM or all of these, using the XMOS datasheets, and save it on an SD card, and strictly entirely without using Windows? It does make some sense to me to add an alien technology "extra Cog" to my Propeller that is faster enough to do something that otherwise can't be done, if its that easy to solve such a problem.
I used to write assemblers in BASIC and program ICs through parallel ports when the eval/devel kits were very expensive.
Prices range form 7.50 to 31.30. But minimum order is two pieces. They do have a online shop.
A assembler should be doable if it isn't your first. Their assembler is a free donload, so you do have a reference.
Only talking theoretically, still waiting for my kits. :-(
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
VIRAND. Those questions are better asked on the forum appropriate for that device xmoslinkers.org but in short yes, yes, yes, yes and yes. With the proviso that you have a good deal of skill and free time to pull off such a feat.
As to "alien technology...fast enough...otherwise can't be done if it's that easy..."
that's the question we are searching an answer to. For example can we bolt Ethernet or fast USB functions onto the Prop in a way that is: economical, efficient, easy and without the end user having to invest a huge amount of time and effort into learning an alien technology to make use of?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I can't beleive people are still going on about "Leon's hidden agenda to convert the world to XMOS" give it a break people. Have you decided since Dr. Jim is not blackening are computer screens any more that you would pick someone new to attack? Until he declares that a handful of XMOS chips and $900(er $40) worth of RAM will let you talk to your Robot intelligibly lets cut him a break.
Leon:. "How does that 5 Mbit/s rate compare with other techniques for Prop-Prop comms?"
You may have noticed that Bobb Fwed has a Prop-Prop serial ink transferring LONGS at a claimed 8.8Mbits/sec for an 80MHz Prop. Only one wire in each direction. OBEX number 456. Perhaps this is a quicker way to talk to "the chip that will remain unnamed" at the expense of a thread at the other end.
mctrivia: I'm just waiting to get the same treatment over on the forum of the "chip that shall remain unnamed" now that I have mentioned the Propeller over there[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm coming to this thread late but it all looks very interesting. I have my 'technical filter glasses' on so any of the 'my chip is better than your chip' stuff is not visible to me. (If it is there at all).
I love the possibilities of hybrids.
The after-hours medical clinic is quieter than normal tonight so I might have some time to research the xmos chip. Meanwhile, I hope this isn't off topic, but may I ask, Leon, what breed is your cat?
That 8.8 MHz link looks interesting, I'll try it. Generally speaking, XMOS threads are used just like Propeller Cogs; an ordinary UART takes one thread. Here's some code for one:
/*
============================================================================
Name : xc1-uart.xc
Description : Simple UART code for the XC-1 board
============================================================================
*/
#include <platform.h>
#define BIT_RATE 115200
#define BIT_TIME XS1_TIMER_HZ / BIT_RATE
void txByte(unsigned char);
unsigned char rxByte(void);
out port TXD = PORT_UART_TX;
in port RXD = PORT_UART_RX;
int main()
{
unsigned char c;
while (1)
{
c = rxByte();
txByte(c);
}
return 0;
}
unsigned char rxByte(void)
{
unsigned data = 0, time;
int i;
unsigned char c;
// wait for start bit
RXD when pinseq (0) :> int _ @ time;
time += BIT_TIME + (BIT_TIME >> 1);
// sample each bit in the middle.
for (i = 0; i < 8; i += 1)
{
RXD @ time :> >> data;
time += BIT_TIME;
}
// reshuffle the data.
c = (unsigned char) (data >> 24);
return {c};
}
void txByte(unsigned char c)
{
unsigned time, data;
data = c;
// get current time from port with force out.
TXD <: 1 @ time;
// Start bit.
TXD <: 0;
// Data bits.
for (int i = 0; i < 8; i += 1)
{
time += BIT_TIME;
TXD @ time <: >> data;
}
// two stop bits
time += BIT_TIME;
TXD @ time <: 1;
time += BIT_TIME;
TXD @ time <: 1;
}
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Leon: I think we should avoid posting hint's, tips and code for the "chip that shall remain unnamed" on this thread. Many will consider it "bad form" or at least off topic.
Having said that, Bobb's high speed link sure looks like something to consider. Of course why not use a regular UART interface?. Only that I now have fascination with getting that external link protocol implemented on the Propeller and the fact that it looks like doing so saves wasting a thread at the other end which might be important when wanting to use the cheapest devices.
I'm still not sure if it actually does save a thread there or not, to be determined.
Also I was hoping that the xlink would support multiple end points. Such that, say, three threads in three COGS on the Prop end could be communicating with three respective threads on the other end. All being multiplexed through the xlink with the multiplexing being taken care of by the driver at the Prop end and transparently by the xlink hardware at the other end.
Perhaps I expect to much. I don't really understand the protocol yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
From start I'm not liked THIS thread .... It was more as REKLAME for others IC.
Now I'm started change my mind tha it start be wery interesting Co-Processor alternative to both Propeller I ... and in Time ... Propeller II.
Hi. heather . I don't know what Chip like ..... BUT I have not any problems with code snipets that help understanding --- Co-Procesing betwen Propeller and other IC's as long as this not like PROMOTION of that IC.
Happy to see we are changing your mind. I don't want to entice anyone away from the Prop. What I want to do is:
1) Solve an interesting protocol problem on the Prop, just as an another challenge.
2) Hopefully be able to bolt Ethernet and USB and whatever onto ZiCog with a minimal cost/hardware complexity.
3) Enable others to do like wise for their pet projects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What variety of "the devices that cannot be named" do you have?
I have almost completed a PASM/Spin version of the AVR xlink code. I don't have anything to test it against.
It requires an L device on the other end. The G links have a slightly different protocol and work much faster.
Actually studying the documentation I find that for any given link clock speed it is possible to set the number of clocks between tokens much bigger on the L devices than the G devices. The Prop needs a good long delay between incoming tokens in order to put the token into a buffer and work out what it should do next. This might lead to the odd situation that we have to run the G links at a slower bit rate for the Prop than the L links despite the fact that G links are designed to be quicker.
I will order myself a dev board with an L device so that I can run the exact same XC code on it as in the AVR example. In the mean time I wondered if you had anything to test the Prop implementation against.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Leon, Heater,
Discussions about 4/32 XMOS technology in relation to the 8/8+ Propeller chip are welcome in my opinion. I think the info/debate on the details of your projects (I only found them recently) are very helpfull for people who work with both chips - as my ratio of frequenting the Parallax forum compared to the XMOS forum is 100:1. The discussion adds the value of the Parallax forums in general (in my opinion) - as I was shocked to learn this summer that XMOS really is sort of INMOS 2.0 and that that XC is related to Occam (The transputer was before my time) - thank you UK.
I recently started working in parallel on both chips mostly on concurrent designs that require simple integer cores/alu's - as I am not interested in single/dual core microcontrollers any more and do not do a lot of traditional device interfacing except of course a lot of LED's. I sort of skipped the 1-core/8-thread XS1-L1 chip in my XK-1 kit and went directly to the 4-core/32-thread XS1-G4 with an integrated switch because of the ability to work with the switch channels on chip using my XC-1A and my XC-2 I just received yesterday.
The propeller chip is still the primary vehicle for exploration via ease of use and ability to use breadboards (I know, I know parasitic capacitance aside - a lot can be done at low freq on 10's of boards). Some mesh applications require as many cores as possible but the cores only need to be glorified ALU's even down to 1-bit processors (again in my case). Anyway for projects requiring more than 2 chips - I primarily work with Parallax DIP processors in quantity at this point and the G4 does not come (or cannot due to the pin count) in a DIP. For work that involves single dev boards, lets face it there are a lot to choose from. I think it is good to get exposure to as much breadth as possible (Parallax, XMOS, Xilinx, Altera, Actel, I don't have a SparkFun board yet) - but concentrate on a few.
For example the new Parallax Spinneret W5100 based embedded web server is a very interesting alternative to the XC-2. Both boards solve the same issues in different ways.
Comments
Carry on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Ok - I've had my say, and will not contribute any more (stop cheering, dammit!).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
did you have a go at the xlink in the propeller ?. I got my FPGA boards so I'll try o implement the xlink there. Let's see.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Walt, that is a totally unfair characterization. Can you point to even one other thread where the mention of another micro generates this kind of controversy? If indeed all Leon had done was attach a Propeller to an XMOS chip, I doubt anyone would have minded. The problem is less with the XMOS chip and more with Leon's repeated and inappropriate XMOS advocacy in other threads.
If you go to a friend's for dinner and spend the evening talking about the much tastier meal you had somewhere else, you shouldn't be surprised if they get annoyed with you. Even if what you're saying is true, it's insulting and rude, and they're going to wonder why you even bothered to come in the first place.
That's pretty much the situation with Leon. To a lot of folks, Leon's constant XMOS advocacy is reason to wonder about his real motives for this Propeller-XMOS project. It's not like they're reflexively getting their panties in a bunch just because some non-Propeller chip is being used; they feel that there's plenty of evidence that Leon has an XMOS chip on his shoulder.
That being said, I would suggest to those who suspect Leon of being an XMOS agent provocateur that they give him the benefit of the doubt. It seems to me that Leon actually likes the Propeller and believes the Propeller and XMOS serve two completely separate markets, so when he talks up the XMOS, he does not mean it as Propeller bashing. It's not a zero-sum game.
However, Leon should hopefully realize that the Parallax forums are not the best place for blatant XMOS rah-rah rhetoric. It rubs a lot of people the wrong way and generates more heat than light.
On the other hand, this thread, which directly involves a Propeller and the challenges of communicating with another processor, should be of interest to all on its technical merits. If in the process of exploring new possibilities for the Propeller some of us learn something about a different chip, so much the better.
Sorry to be so wordy, but I was very troubled by the tone of some of the posts here. There's no reason for discourtesy and name-calling among friends. I don't expect to change any minds, but I do fervently hope that anyone who's tempted to cast aspersions in this thread will take a moment, consider that the other guy might just have a point (even if you don't agree with it), realize that most folks just want to stay on-topic, and let it go.
Hooking Propellers up to stuff is a good thing overall. The more the merrier, I say.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Currently this only:
1) Implements the 4 wire serial interface.
2) Has a Tx COG that transmits an ever increasing token value from a LONG consisting of bits 0-7 as data and bit 9 as the control token flag.
3) Has an Rx COG that is receiving tokens on the same pins as the transmitter COG, as a loop back test, and dumping them to a long in HUB. Checks for parity errors.
4) The main Spin displays the received value every second using FullDuplexSerial to the BST terminal.
5) Requires BST to compile due to the use of @@@
There is a nice symmetry to the Tx and RX code in PASM, they both use exactly 4 instructions per bit. That's 5Mbits per second for an 80MHz Prop or 6.5536Mbits per second on my board.
Transmitting a bit looks like:
test ttoken, #%0_01000000 wz 'Get data bit 6 into carry if_nz mov out_1, wire_1 'To toggle wire 1... if_z mov out_1, wire_0 '...or wire 0 xor outa, out_1 'Toggle selected wireThis could be shrunk to 3 instructions but then there would be jitter on the output edges and I can't get the Rx to run faster anyway.
Receiver uses waitpne to sync with the first bit and then receiving each bit looks like
mov in_1, ina 'Get wires from P0 and P1 xor in_0, in_1 'Get wire changes test in_0, #%1000 wz 'Test for wire 1 change if_nz or rtoken, #%0_01000000 'Wire 1 change so set data bit 6Next up I will add Tx add Rx FIFOs to this and try to write a version of the xmoslink_avr code. Initially in Spin I think.
I don't have any "chips that will be unnamed" to test this against yet so I only only have it running COG to COG on the same Prop. So presuming xlinks can be convinced to run at 5Mbits/second it would be nice if someone could try and test this.
I'd like to understand more of the higher level protocol before proceeding.
Edit: Currently the pins are hard coded to P2 and P3.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 12/3/2009 12:37:36 PM GMT
How does that 5 Mbit/s rate compare with other techniques for Prop-Prop comms?
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
I think I've pretty much written off the idea of implementing the parallel xlink with 5 wires in each direction. Firstly because that's a lot of our precious Prop pins. Secondly because it needs a lot more code to encode/decode the symbols Checking for 00, 01, 10, 11 in the output bit stream and then toggling one of five pins. It looks like it won't give enough speed gains to be worth the sacrifice of pins. Might even be better to run two 4 wire links in parallel than one 10 wire link. Have to investigate that a bit more.
I though about combining Tx and Rx into a single COG using coroutines like FullDuplexSerial does. So far I'm not keen on the idea as the speed will be less than half and because the whole idea is to export some USB, serial, whatever, functionality to the "chip that cannot be named" therefore the loss of a COG is a good trade off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Are the XMOS anywhere near $8 a piece, and is it possible for me to write an XMOS assembler and programmer in Spin or Femtobasic or PASM or all of these, using the XMOS datasheets, and save it on an SD card, and strictly entirely without using Windows? It does make some sense to me to add an alien technology "extra Cog" to my Propeller that is faster enough to do something that otherwise can't be done, if its that easy to solve such a problem.
I used to write assemblers in BASIC and program ICs through parallel ports when the eval/devel kits were very expensive.
A assembler should be doable if it isn't your first. Their assembler is a free donload, so you do have a reference.
Only talking theoretically, still waiting for my kits. :-(
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
As to "alien technology...fast enough...otherwise can't be done if it's that easy..."
that's the question we are searching an answer to. For example can we bolt Ethernet or fast USB functions onto the Prop in a way that is: economical, efficient, easy and without the end user having to invest a huge amount of time and effort into learning an alien technology to make use of?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Graham
I have to say things move a little more slowly over there than we are used to here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
You may have noticed that Bobb Fwed has a Prop-Prop serial ink transferring LONGS at a claimed 8.8Mbits/sec for an 80MHz Prop. Only one wire in each direction. OBEX number 456. Perhaps this is a quicker way to talk to "the chip that will remain unnamed" at the expense of a thread at the other end.
mctrivia: I'm just waiting to get the same treatment over on the forum of the "chip that shall remain unnamed" now that I have mentioned the Propeller over there[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I love the possibilities of hybrids.
The after-hours medical clinic is quieter than normal tonight so I might have some time to research the xmos chip. Meanwhile, I hope this isn't off topic, but may I ask, Leon, what breed is your cat?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I asked him the same question.
He changed the photo recently.
Nick, owned by two cats.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
James Moxham. Owned by 3 cats.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
That 8.8 MHz link looks interesting, I'll try it. Generally speaking, XMOS threads are used just like Propeller Cogs; an ordinary UART takes one thread. Here's some code for one:
/* ============================================================================ Name : xc1-uart.xc Description : Simple UART code for the XC-1 board ============================================================================ */ #include <platform.h> #define BIT_RATE 115200 #define BIT_TIME XS1_TIMER_HZ / BIT_RATE void txByte(unsigned char); unsigned char rxByte(void); out port TXD = PORT_UART_TX; in port RXD = PORT_UART_RX; int main() { unsigned char c; while (1) { c = rxByte(); txByte(c); } return 0; } unsigned char rxByte(void) { unsigned data = 0, time; int i; unsigned char c; // wait for start bit RXD when pinseq (0) :> int _ @ time; time += BIT_TIME + (BIT_TIME >> 1); // sample each bit in the middle. for (i = 0; i < 8; i += 1) { RXD @ time :> >> data; time += BIT_TIME; } // reshuffle the data. c = (unsigned char) (data >> 24); return {c}; } void txByte(unsigned char c) { unsigned time, data; data = c; // get current time from port with force out. TXD <: 1 @ time; // Start bit. TXD <: 0; // Data bits. for (int i = 0; i < 8; i += 1) { time += BIT_TIME; TXD @ time <: >> data; } // two stop bits time += BIT_TIME; TXD @ time <: 1; time += BIT_TIME; TXD @ time <: 1; }Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 12/4/2009 1:38:16 PM GMT
Having said that, Bobb's high speed link sure looks like something to consider. Of course why not use a regular UART interface?. Only that I now have fascination with getting that external link protocol implemented on the Propeller and the fact that it looks like doing so saves wasting a thread at the other end which might be important when wanting to use the cheapest devices.
I'm still not sure if it actually does save a thread there or not, to be determined.
Also I was hoping that the xlink would support multiple end points. Such that, say, three threads in three COGS on the Prop end could be communicating with three respective threads on the other end. All being multiplexed through the xlink with the multiplexing being taken care of by the driver at the Prop end and transparently by the xlink hardware at the other end.
Perhaps I expect to much. I don't really understand the protocol yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
From start I'm not liked THIS thread .... It was more as REKLAME for others IC.
Now I'm started change my mind tha it start be wery interesting Co-Processor alternative to both Propeller I ... and in Time ... Propeller II.
Hi. heather . I don't know what Chip like ..... BUT I have not any problems with code snipets that help understanding --- Co-Procesing betwen Propeller and other IC's as long as this not like PROMOTION of that IC.
Regards
Christoffer J
Happy to see we are changing your mind. I don't want to entice anyone away from the Prop. What I want to do is:
1) Solve an interesting protocol problem on the Prop, just as an another challenge.
2) Hopefully be able to bolt Ethernet and USB and whatever onto ZiCog with a minimal cost/hardware complexity.
3) Enable others to do like wise for their pet projects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What variety of "the devices that cannot be named" do you have?
I have almost completed a PASM/Spin version of the AVR xlink code. I don't have anything to test it against.
It requires an L device on the other end. The G links have a slightly different protocol and work much faster.
Actually studying the documentation I find that for any given link clock speed it is possible to set the number of clocks between tokens much bigger on the L devices than the G devices. The Prop needs a good long delay between incoming tokens in order to put the token into a buffer and work out what it should do next. This might lead to the odd situation that we have to run the G links at a slower bit rate for the Prop than the L links despite the fact that G links are designed to be quicker.
I will order myself a dev board with an L device so that I can run the exact same XC code on it as in the AVR example. In the mean time I wondered if you had anything to test the Prop implementation against.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I should be able to to test virtually anything.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Discussions about 4/32 XMOS technology in relation to the 8/8+ Propeller chip are welcome in my opinion. I think the info/debate on the details of your projects (I only found them recently) are very helpfull for people who work with both chips - as my ratio of frequenting the Parallax forum compared to the XMOS forum is 100:1. The discussion adds the value of the Parallax forums in general (in my opinion) - as I was shocked to learn this summer that XMOS really is sort of INMOS 2.0 and that that XC is related to Occam (The transputer was before my time) - thank you UK.
I recently started working in parallel on both chips mostly on concurrent designs that require simple integer cores/alu's - as I am not interested in single/dual core microcontrollers any more and do not do a lot of traditional device interfacing except of course a lot of LED's. I sort of skipped the 1-core/8-thread XS1-L1 chip in my XK-1 kit and went directly to the 4-core/32-thread XS1-G4 with an integrated switch because of the ability to work with the switch channels on chip using my XC-1A and my XC-2 I just received yesterday.
The propeller chip is still the primary vehicle for exploration via ease of use and ability to use breadboards (I know, I know parasitic capacitance aside - a lot can be done at low freq on 10's of boards). Some mesh applications require as many cores as possible but the cores only need to be glorified ALU's even down to 1-bit processors (again in my case). Anyway for projects requiring more than 2 chips - I primarily work with Parallax DIP processors in quantity at this point and the G4 does not come (or cannot due to the pin count) in a DIP. For work that involves single dev boards, lets face it there are a lot to choose from. I think it is good to get exposure to as much breadth as possible (Parallax, XMOS, Xilinx, Altera, Actel, I don't have a SparkFun board yet) - but concentrate on a few.
For example the new Parallax Spinneret W5100 based embedded web server is a very interesting alternative to the XC-2. Both boards solve the same issues in different ways.
thank you
/Michael O'Brien
I looked at that chip (which it would appear one should not mention) for a project some time back.
Keep it coming............