Xmos kits and linux

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

I will write it up but unfortunately one also needs an FTDI patch which isn't yet publicly available, you have to request an unofficial temporary tools patch via an Xmos support ticket.

If you are using an Xtag2 based product rather than xtag/ftdi products you can just apply the changes explained (more clearly) in the knowledge base article I linked to above.

Not everyone will need this as it depends upon kernel versions from Ubuntu updates etc..

It will be interesting to see what Skoe's experience is using 10.04, I am unlikely to move up until I know for sure having now got it working on 9.10!!

regards
Al


User avatar
XMatt
XCore Addict
Posts: 147
Joined: Tue Feb 23, 2010 6:55 pm

Post by XMatt »

Folknology wrote:I will write it up but unfortunately one also needs an FTDI patch which isn't yet publicly available, you have to request an unofficial temporary tools patch via an Xmos support ticket.

If you are using an Xtag2 based product rather than xtag/ftdi products you can just apply the changes explained (more clearly) in the knowledge base article I linked to above.

Not everyone will need this as it depends upon kernel versions from Ubuntu updates etc..

It will be interesting to see what Skoe's experience is using 10.04, I am unlikely to move up until I know for sure having now got it working on 9.10!!

regards
Al
The same process you have used to make it work with 9.10 works fine with 10.04 (It is the kernel version not the distribution version which is important) I have a machine here I have tested it on. We hope to resolve the ftdi library issue with an official solution from them as soon as possible until then we will have to do it via the support ticket system. Last contact I had with ftdi they had not tested beyond the 2.6.31 kernel and so had not come across this issue.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

You use

Code: Select all

mount --bind /dev/bus/usb /proc/bus/usb
Is that step required given that usb isn't supported in that way with those kernels my ubuntu didn't have /proc/bus/usb for example?
User avatar
XMatt
XCore Addict
Posts: 147
Joined: Tue Feb 23, 2010 6:55 pm

Post by XMatt »

Folknology wrote:You use

Code: Select all

mount --bind /dev/bus/usb /proc/bus/usb
Is that step required given that usb isn't supported in that way with those kernels my ubuntu didn't have /proc/bus/usb for example?
If you do not have /proc/bus/usb this step will not help, it is only for kernels where the mount point exists. The ftdi library only looks in /proc/bus/usb for devices, this allows the standard library to work without having to install the patched version we have created. The whole linux USB subsystem across distributions and kernel versions is a bit of a minefield im afraid, unfortunately that is what we have to work with.
kster59
XCore Addict
Posts: 162
Joined: Thu Dec 31, 2009 8:51 am

Post by kster59 »

Honestly I don't really see why XMOS tries to support multi platforms. I'd rather have a single stable platform and work with that.

Sure it'd be nice but you can just buy a brand new dedicated Windows machine for <$200US for development which makes it a non-issue.

The number of commercial Linux/Mac users that insist on not buying a $200 Windows machine but willing to buy more than $10,000 in chips from XMOS must be tiny...
Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Post by Heater »

kster59: There are a hundred reasons why I and many others don't want a dedicated Windows machine around or Windows around at all. None of them have got anything to do with the required $200. I have not had to use a Windows machine for professional or other projects since 1997.

However since you have mentioned it. What you are proposing is that every developer in the world who wants to work with XMOS devices should have to pay something to Microsoft for the privilege. This is clearly not acceptable.

I don't want to start an anti-MicroSoft rant here but will leave you with this:

>> "The number of commercial Linux/Mac users that insist on not buying a $200 Windows machine
>> but willing to buy more than $10,000 in chips from XMOS must be tiny..."

Perhaps but inside Nokia where all our development was done with GCC on Unix my project manager said "I don't want any more of Bill Gates fingers in my project than is absolutely necessary".

Nokia certainly does spend a lot on chips.
User avatar
skoe
Experienced Member
Posts: 94
Joined: Tue Apr 27, 2010 10:55 pm
Contact:

Post by skoe »

Same in our company. We used to develop on Sun and switched to Linux in the past few years. All of our tools and production environments are "Unix"-based. Development tools for Windows only would simply not fit into our environment. And no, cygwin is not acceptable for large projects.

btw: I saw that also other companies prefer the RedHat distribution. Seems to be kind of a industry standard. I wonder why. I don't like RedHat, too small and old code base. But maybe this is the reason :) I use Ubuntu.

P.S. Okay, only one platform for development tools is okay. But I think it should not be Windows, hehe :)
kster59
XCore Addict
Posts: 162
Joined: Thu Dec 31, 2009 8:51 am

Post by kster59 »

I completely understand your choice for not using Windows for a general operating system.

However, this is just a tool. I wouldn't use a drill when I need a hammer. I wouldn't use Linux if it is buggy compared to Windows for an XMOS dev tool. It's nice that's multi platform but I would really prefer if they didn't use the 32-bit Java virtual machine and instead compile a native application. Maybe switch to Qt.

The tool is also a cheap one at $200 for a new basic machine (look for a low power Intel Atom with preinstalled Windows XP) just to run the free XMOS software. I think it would be advantageous to have a dedicated machine so you don't mess up your main machine if you are worried about it. Of course you could run Vmware but not sure how well the USB would work.

Obviously XMOS should support the most widely used operating system first (which is of course Windows at 92.2% of all computers according to a google search).

Anything else would just be bad business.

I haven't played with 10.4 enough but 9.9.2 had a ton of bugs in that IDE that I hated. Hopefully those should be fixed but if they are not then most people would prefer if they fixed the Windows one first.
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm
Contact:

Post by jonathan »

Hmm, disagree with lots of this.
kster59 wrote:However, this is just a tool. I wouldn't use a drill when I need a hammer. I wouldn't use Linux if it is buggy compared to Windows for an XMOS dev tool. It's nice that's multi platform but I would really prefer if they didn't use the 32-bit Java virtual machine and instead compile a native application. Maybe switch to Qt.
OK, so now every chip/silicon/software vendor picks their own "supported" OS - a vast variety of Windows, Linux and Mac distributions, and I have to buy a $200 machine and find somewhere to put it, keep it up to date, etc? Plus I can't use various of the software/hardware components together, because I need a pile of different "supported" configs/OSes/machines etc? It's not feasible for anyone - hobbyist or company.
The tool is also a cheap one at $200 for a new basic machine (look for a low power Intel Atom with preinstalled Windows XP) just to run the free XMOS software. I think it would be advantageous to have a dedicated machine so you don't mess up your main machine if you are worried about it. Of course you could run Vmware but not sure how well the USB would work.
Ahem - for "very basic usage" a $200 Atom laptop/PC might *might* cut it. But trust me, it doesn't for any analysis or simulation. Whilst XMOS has worked hard to try to remove the super-polynomials from its algorithms, you simply can't expect to run the IDE in all its glory - timing analyser, simulator, waveform viewer and in some cases even the mapper :oops: etc on a $200 machine.

So what do I then do, once I'm beyond a text editor?
Obviously XMOS should support the most widely used operating system first (which is of course Windows at 92.2% of all computers according to a google search).
That's nonsense, the only statistic that matters if you're going to make this argument is the most widely used operating system amongst embedded software developers with the potential to become important XMOS customers. And then you need to define "important" (something everyone finds hard!). Find me that stat please!
Anything else would just be bad business.
Nope, what XMOS have done is to make it possible to use the XMOS IDE and tools and just plug in to whatever your existing flow/platform etc is. That is *good business*.
I haven't played with 10.4 enough but 9.9.2 had a ton of bugs in that IDE that I hated. Hopefully those should be fixed but if they are not then most people would prefer if they fixed the Windows one first.
That's a big claim. Who are these most people? :-)

It's pretty inexcusable for XMOS to leave bugs in the IDE/tools whilst wasting time developing a live syntax spellchecker (admirable though it is), so like you I hope the bugs have been fixed. But I don't agree with most of your conclusions about "good business" etc.

Unnecessary hurdles = bad business, whoever you are.
Image
User avatar
skoe
Experienced Member
Posts: 94
Joined: Tue Apr 27, 2010 10:55 pm
Contact:

Post by skoe »

kster59, seems you don't take into account integrated make environments which compile 1000s of source codes for different CPUs in a larger software project. Our makefiles don't ask a windows machine which stands somewhere in the corner :)

So at least the toolchain is needed to run in the native environment. And llvm seems to be a great choice IMHO (Which is cross-platform *and* natively compiled.

You are right that the GUI is not sooo important to run on several platforms. But Eclipse is a very flexible, mature framework with lots of plugins (*) for other development tools like bug trackers and VCS's. So why not the cross-platform Eclipse? Sure, you have to spend $200 for a faster machine, so you don't notice the Java performance loss. But I think you'll have these $200 :)

(*) Which have to be installed manually at the moment. But it works.

The only disadvantage I see in the XMOS tools is that they didn't go a 100% standard way with the XTAG adapter. Would have been nice to see it in a real OpenOCD. This could save poor students to spend 50 bucks for an XTAG2 because they simple could re-use their ARM equipment or whatever. But I also unterstand why they did it (e.g. performance), and in professional environments 50 bucks are nothing.

Regards,
Thomas

Edit: I agree with jonathan, in the embedded world not so many people develop on Windows. At least not in companies I know. Completely different from private and office world, where Windows is the marked leader for sure.
Post Reply