Is XC a realistic choice for real world applications?

[Heater]

Andy,

It makes no sense to talk xcore vs "ARM". There are so many different ARMs.

Berni said "What i found is that xmos is really great for interfacing stuff but when you want to do ethernet, large displays, serious number crunching etc its best to just take an ARM."

Well if that ARM is a little STM32 you might be right. If its an OMAP3530 as found on a Beagle board I suspect Berni is right.

[Andy]

Sorry, I just assumed that it was a fair test and by "ARM" he meant those processors at a similar price / performance point as an XCore. If we're seriously comparing an XCore with an OMAP then we might as well start a thread discussing the benefits of the Intel Pentium over an L1.

[Heater]

Andy,

I think the OMAP/xcore comparison stands up (better than OMAP/Intel Pentium) because:

1) An OMAP3530 can be had from the likes of Mouser for about the cost of a 4 core XMOS. ~40 Euros.

2) Size compares

3) Power consumption compares.

So if you need ethernet, large displays, serious number crunching then it's a valid option.

Of course if your needs are for a lot of real time I/O interfacing xcore will be preferable.

[Andy]

1) An OMAP3530 can be had from the likes of Mouser for about the cost of a 4 core XMOS. ~40 Euros.

A quick look on Digikey tells me that the OMAP part is around $60 which is twice the price of the $30 G4.

(The Pentium comparison was a joke by the way)

[Berni]

Well a lot of these things can be done on the xmos but it would take way too long to get it working. Nobody is willing to make the effort in porting there own TCP/IP stack and optimize it. So its best to change to a different chip that can get you up and running faster.

Sadly there is no perfect CPU out there. Some are excellent for certain tasks where others suck and vice versa. The task that xmos is the best at is interfacing, since you can stick almost anything to it and make it talk no mather how strange and nonstandard its interface is.

It a bit like comparing a mobile phone and a hammer. A harmer does a great job of getting a nail in and it could be done with a mobile phone too but not very well or very fast, while calling someone with a hammer might prove quite difficult. Use the right tool for the right job.

[Andy]

Well a lot of these things can be done on the xmos but it would take way too long to get it working. Nobody is willing to make the effort in porting there own TCP/IP stack and optimize it. So its best to change to a different chip that can get you up and running faster.

I don't understand the big fuss over getting a networking stack up and running. For my Wi-Fi project I ported uIP to a single thread and it took a couple of hours to get it working. You still have to use their 'Protothreads' to set up the protocol but the received data is streamed out over a channel.

[russf]

I'd rather not turn this into another discussion about the deficiencies of xtcp.

Well, I am on a bit of a roll, regarding that topic, but it *is* a concrete example. Had I made a hand-wave towards some supposed or theoretical problem, I could have justifiably been accused of not being specific.

Looking at the alternative to xtcp, for a second, one could pickup a lot of concrete and well-tested examples of network-aware code for a linux arm platform that would let you get a prototype working very fast.

I look forward to hearing from Bernie.

--r.

[russf]

Well a lot of these things can be done on the xmos but it would take way too long to get it working. Nobody is willing to make the effort in porting there own TCP/IP stack and optimize it. So its best to change to a different chip that can get you up and running faster.

I don't understand the big fuss over getting a networking stack up and running. For my Wi-Fi project I ported uIP to a single thread and it took a couple of hours to get it working. You still have to use their 'Protothreads' to set up the protocol but the received data is streamed out over a channel.

I had not realized you had done this. What data rate can you get?

Part of my obvious personal frustration on my pet topic of last week (the protocol stack that I shall not name), is that when some code is posted on a credible forum (xmos.com), one expects that the smart thing is to go and use it. Now that I have a few days learning behind me, I realize that even here, caveat downloader applies.

[Folknology]

I don't understand the big fuss over getting a networking stack up and running. For my Wi-Fi project I ported uIP to a single thread and it took a couple of hours to get it working. You still have to use their 'Protothreads' to set up the protocol but the received data is streamed out over a channel.

Well getting uIP or LwIP on an embedded processor with a built in MAC for example ARM cortex M3 MCUs from TI (stellaris),ST stm32 and NXP 17/1800 is very straight forward using C/C++ and is relatively low cost. For your wifi project on Xmos I assume you used 'C' rather than pure XC. Did you use xtcp or another method? And what would happen if your project needed Ethernet rather than wifi?

Which returns me to my original questions and brings this thread back around to its initial purpose..

1) So am I being stupid or is it possible to write pure XC based TCP/IP applications?
2) Why has Xtcp been written in such a way that makes writing TCP/IP apps more complex than the uIP examples?

Both 1 and 2 are exhibited from the examples provided in the stack (1v3).
...

3) Thus I believe a real world application like Mii Ethernet interfacing (quite common) cannot be solved with Xmos finest XS1 and XC. rather one has to resort to some unintelligible gobbledegook code as illustrated in the current Ethernet part of the networking stack. I feel quite dirty having spent significant time inside that code..

QED XC is not a realistic choice for real world applications, courtesy of Xmos's own large body of networking code..

And the later question

So the question is can an complete Mii/Ethernet/TCP/IP+Telnetd written in XC fit into a single core L1?

I still would value answers and opinions on these questions.

regards
Al

[MuellerNick]

An uneducated question in between:
I would need BSD sockets.
Does that work, would that work? And if yes, how much memory would it consume? It wouldn't make too much sense to use 60k of memory and leave no room for the application (talking about the 64k XMOS).

Nick