kster59: Yes the XDE is just a tool. Like a hammer. And operating systems are like the workshops I work in. Let's fly with that analogy:
1) I don't want to have to post dollars to anyone just to use my new hammer.
2) I don't want to be restrained to only using my new hammer in a special workshop that I have to buy or build and then maintain especially for hammering.
3) I don't want to be reliant on any single supplier for workshops or hammers for that matter.
I don't have a downer on Windows as such or Microsoft. I do have a downer on the fact that the whole worlds computing infrastructure has been dependent on a single supplier. That is a seriously crazy situation for the worlds people, companies, governments and other organizations to be in.
So, at the end of the day, XMOS officially only supports one Linux distribution and the XDE has a few problems on other distros. Given the nature of the Linux universe that is quite natural. No one has the resources to support all distros and it's not the fault of XMOS if Ubunto screws up their USB drivers. Others have had problems with this, for example http://www.fnarfbargle.com/bst.html
These little niggles generally get worked out soon enough.
Next up I want all my tools to work on the ARM architecture so that we can tackle the world wide dependence on Intel....
Xmos kits and linux
Hey, you can use AMD if you want :DHeater wrote:Next up I want all my tools to work on the ARM architecture so that we can tackle the world wide dependence on Intel....
Skoe: "...you can use AMD if you want"
Yes indeed. I have done so and I'm very glad there is such an option. However I have dreams of migrating my "workshop" to something like this: http://beagleboard.org/
It's small, it's cheap, its low power, it doesn't make any noise. ARMs are available from multiple sources around the world. I hope it will have descendents that bring ARM platforms up to the scale of modern PCs. I'm sure that little board and its kind can already do most of what I would like to day to day.
Yes indeed. I have done so and I'm very glad there is such an option. However I have dreams of migrating my "workshop" to something like this: http://beagleboard.org/
It's small, it's cheap, its low power, it doesn't make any noise. ARMs are available from multiple sources around the world. I hope it will have descendents that bring ARM platforms up to the scale of modern PCs. I'm sure that little board and its kind can already do most of what I would like to day to day.
OT, sorry:
Once they were, and even faster than a 80486 at that time. I used Archimedes 310, 3010 and later a RiscPC for several years - the dawn of ARM :) (http://en.wikipedia.org/wiki/Acorn_Archimedes, http://en.wikipedia.org/wiki/Risc_PC)Heater wrote:I hope it will have descendents that bring ARM platforms up to the scale of modern PCs.
I remember the advertising for the Archie well. Always lusted after one. I'd still would love to get my hands on one. Sorry, more OT.
-
Folknology
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
- Contact:
kster59 you really have no idea what you are missing on the dark side, come over to the light side and feel the true power of the source
http://www.opencollector.org/summary.php
That doesn't include the rich GNU tools set on which which virtually every embedded linux chain is based, from my workstation here I can cross compile to my AVR's, Arms,Mips,PowerPC, Intel just about all of them. Xmos tools themselves are based on the very same tool chain as well as new emergent opensource tools like LLVM.
It also doesn't include the best network toolkit in the world, tools for peeking into ethernet communications, sockets and proxies, network analysis, network testing and tweeking essential in todays networked devices.
Why would I possibly want to give up the best electronics and development platform in the world for a second hand, second rate buggy office system, I am an engineer not a freaking office typist ;-)
Regards
Al
http://www.opencollector.org/summary.php
That doesn't include the rich GNU tools set on which which virtually every embedded linux chain is based, from my workstation here I can cross compile to my AVR's, Arms,Mips,PowerPC, Intel just about all of them. Xmos tools themselves are based on the very same tool chain as well as new emergent opensource tools like LLVM.
It also doesn't include the best network toolkit in the world, tools for peeking into ethernet communications, sockets and proxies, network analysis, network testing and tweeking essential in todays networked devices.
Why would I possibly want to give up the best electronics and development platform in the world for a second hand, second rate buggy office system, I am an engineer not a freaking office typist ;-)
Regards
Al
I think you confuse again my statements. This is not a debate of Windows vs Linux, etc.
All I said was that if I could buy a $200 Windows box and it would save me hours of headaches, I would do it. Same thing if I could buy a $200 Linux box to run some specific linux software that I needed then I would do it.
During my PhD I had to run all my high performance computing code on 250+ core super computers which all used Unix OS. I never complained about it. I liked Visual Studio as my source editor as I didn't like emacs so I wrote my C++ in Visual Studio and ssh it over to the Unix supercomputer. I scaled it on my 2 processor core using MPI to 250+ cores no problem. C/C++ is easy to cross compile if it isn't graphical or hardware based.
When there was unix code that I needed to run (usually some compilicated bash scripts), I could have complained about why it didn't compile easily in Windows but instead I just installed Vmware and ran SuLinux in a Window.
I'm not asking you to change religions. If there is a more efficient way to do something then just do it. Buying a $200 Windows box was a suggested solution. Before XMOS put out the 64bit Windows fix, I ran all my code/simulations on my $350 intel atom netbook and it worked fine. Or you could just pay $100 for Windows and put it in a Vmware session (not sure about USB support under VMWare on Linux).
For a small company like XMOS, I would like for them to concentrate on fixing obvious bugs before implementing something non-essential like cross platform.
1) The command line tools seem fine in Windows but the choice to go with Eclipse and a Java Virtual Machine runtime was a poor one. For example, I had to SEVERAL times (more than 10) completely delete the configuration file in /workspace because Eclipse crashed and corrupted the entire database. After I deleted the configuration file I had to reimport each of the projects one by one. This was a known bug when you did something with the simulator in the wrong order. I have never seen this happen in Visual Studio. When I write C++ code, I will compile it in Visual Studio then write a wrapper on the XMOS device. For Xc, I just stick with the buggy Eclipse.
2) Another huge bug was that several times Eclipse will not report Xc compile errors so I had to open a command prompt and run the command line tools to figure out what line the code had an error.
3) My first XMOS dev kits were 2x XK1 because they were supposed to have USB and flash. Then I realized the Windows USB UART drivers were not available so I couldn't write GUI programs to interface with my embedded apps. I had to wait around until they released the XC-1A which used the FTDI chip (which I use only with D2xx).
Hopefully these problems are fixed but if they aren't I would put those at higher priority than supporting cross platform.
All I said was that if I could buy a $200 Windows box and it would save me hours of headaches, I would do it. Same thing if I could buy a $200 Linux box to run some specific linux software that I needed then I would do it.
During my PhD I had to run all my high performance computing code on 250+ core super computers which all used Unix OS. I never complained about it. I liked Visual Studio as my source editor as I didn't like emacs so I wrote my C++ in Visual Studio and ssh it over to the Unix supercomputer. I scaled it on my 2 processor core using MPI to 250+ cores no problem. C/C++ is easy to cross compile if it isn't graphical or hardware based.
When there was unix code that I needed to run (usually some compilicated bash scripts), I could have complained about why it didn't compile easily in Windows but instead I just installed Vmware and ran SuLinux in a Window.
I'm not asking you to change religions. If there is a more efficient way to do something then just do it. Buying a $200 Windows box was a suggested solution. Before XMOS put out the 64bit Windows fix, I ran all my code/simulations on my $350 intel atom netbook and it worked fine. Or you could just pay $100 for Windows and put it in a Vmware session (not sure about USB support under VMWare on Linux).
For a small company like XMOS, I would like for them to concentrate on fixing obvious bugs before implementing something non-essential like cross platform.
1) The command line tools seem fine in Windows but the choice to go with Eclipse and a Java Virtual Machine runtime was a poor one. For example, I had to SEVERAL times (more than 10) completely delete the configuration file in /workspace because Eclipse crashed and corrupted the entire database. After I deleted the configuration file I had to reimport each of the projects one by one. This was a known bug when you did something with the simulator in the wrong order. I have never seen this happen in Visual Studio. When I write C++ code, I will compile it in Visual Studio then write a wrapper on the XMOS device. For Xc, I just stick with the buggy Eclipse.
2) Another huge bug was that several times Eclipse will not report Xc compile errors so I had to open a command prompt and run the command line tools to figure out what line the code had an error.
3) My first XMOS dev kits were 2x XK1 because they were supposed to have USB and flash. Then I realized the Windows USB UART drivers were not available so I couldn't write GUI programs to interface with my embedded apps. I had to wait around until they released the XC-1A which used the FTDI chip (which I use only with D2xx).
Hopefully these problems are fixed but if they aren't I would put those at higher priority than supporting cross platform.
I am sorry you are having this kind of trouble. Any specific information about these problems you can provide to us, especially if the issue is reproducable, will help getting it fixed. The best thing is to file a ticket at http://www.xmos.com/support.Hopefully these problems are fixed but if they aren't I would put those at higher priority than supporting cross platform.
I must say the XMOS staff has done a great job responding to bug fixes/requests.
All the issues I mentioned above have workaround so I am pretty happy for now. Even the USB Uart thing is solved as the solution was to spend $100 and buy the new XC-1A for development and throw away my XK1 (well I kept the XTAG2 for programming my own boards).
My products are almost at commericial production level now and I could have only reached this stage so quickly with XMOS devices.
My biggest problem is finding outside help with qualified consultants which leaves me to do everything myself. I don't have this problem with ARM, PIC, AVR, Xilinx/Altera but no one knows Xc which is quite different from VHDL or interrupt programming.
I would really like for the SODIMM or other XMOS G4 module to become available to breakout all the IO pins without spending a lot of money on prototypes when I'm more of a programmer than a board designer.
All the issues I mentioned above have workaround so I am pretty happy for now. Even the USB Uart thing is solved as the solution was to spend $100 and buy the new XC-1A for development and throw away my XK1 (well I kept the XTAG2 for programming my own boards).
My products are almost at commericial production level now and I could have only reached this stage so quickly with XMOS devices.
My biggest problem is finding outside help with qualified consultants which leaves me to do everything myself. I don't have this problem with ARM, PIC, AVR, Xilinx/Altera but no one knows Xc which is quite different from VHDL or interrupt programming.
I would really like for the SODIMM or other XMOS G4 module to become available to breakout all the IO pins without spending a lot of money on prototypes when I'm more of a programmer than a board designer.
larry wrote:I am sorry you are having this kind of trouble. Any specific information about these problems you can provide to us, especially if the issue is reproducable, will help getting it fixed. The best thing is to file a ticket at http://www.xmos.com/support.Hopefully these problems are fixed but if they aren't I would put those at higher priority than supporting cross platform.
-
Folknology
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
- Contact:
I could be wrong but I would imagine the Xmos tools are first built on a Unix like platform given the toolchain on which they are based, then ported to non-unix platforms like Windows so if this was the case it would mean not supporting windows, that seems a little harsh. Also the Windows install has a number of extra overheads like the windows specific installer, contrast this to the linux install which is purely an untar!Hopefully these problems are fixed but if they aren't I would put those at higher priority than supporting cross platform.
The problem by the way was not their tools per se it was how the USB is implemented on Linux, changes in the kernel have meant FTDI drivers for instance do not operate with the newer scheme. All that changes with the non-FTDI XTag2 is that a different installation procedure is required. What makes it tricky is that the installation required depends on kernel version. This is also slightly Ironic given your preference for the FTDI based Xmos kits as Xmos is held up by the FTDI vendor a non Xmos overhead..
As for you comments around Eclipse, well why not just use the command line tools and notepad as you state hereThe command line tools seem fine in Windows but the choice to go with Eclipse and a Java Virtual Machine runtime was a poor one.
Certainly I am not a huge fan of Eclipse, I tend to prefer Emacs and the command line tools, but still use Eclipse occasionally and I'm sure it makes it more approachable to a greater audience. Its worth noting that many vendors of development boards in this sector use Eclipse as their IDE, this in turn helps others coming from those backgrounds get up to speed by providing them with a familiar environment .If there is a more efficient way to do something then just do it
As for writing a native IDE for windows rather than using a multiplatform IDE like Eclipse that really would only make it harder for Xmos, good luck waiting for all of the time that would likely take. I would rather they concentrate on making the basic tools and drivers reliable along with the new opensource XC LLVM toolchain.
Not sure what the 'religion' thing is getting at, but as far as I can see Linux is the most efficient way of doing it period, I don't see how windows could possible help given your experience with it and Xmos so far!
regards
Al
Last edited by Folknology on Fri May 21, 2010 7:27 pm, edited 1 time in total.