Greetings everyone. It seems I am late to the party.
I have not made this site part of my usual watchlist, perhaps I'll change that in the future.
I'll start on topic, and may wander from there.
I'd like top start by saying that I am impressed with the accuracy of the discussion so far. Certainly some people are a bit more pessimistic than I am, but at least MOST of the "facts" are true.
One slight correction I'd liketo make:
....
http://www.os4depot.net/index.phpfunction=showfile&file=utility/hardware/nemo_led_p31.lha
Nemo_led_p31 allows user control of an "extra" LED header on the Nemo board.
It also allows access by low level code, such as interrupt handlers. As such I have found it very handy when troubleshooting code, but it has nothing to do with the Xena chip. no connection, no relation..
I take no offense to it being described as "Nothing productive", though I would personally disagree with that assessment.
The Xena chip has some very unique capabilities. It also has a few obstacles to be overcome. I will gladly discuss those here as long as I feel the time is well spent. If it becomes more of an argument than a discussion you can expect my continued participation to end. Frankly I have too much to do to spend time arguing with anyone.
Onward.. In addition to coding for OS4 I also have some embedded experience, using small chips that can run code directly without any "OS" to speak of.. I have designed, built, and programmed some unique audio hardware, some stuff used for home automation, and some devices that I used at previous employers to enhance the performance of their equipment. So I have at least _some_ experience with small processors like the XMOS devices.
The XMOS chips like Xena are quite unique.. Unlike most devices it actually has completely separate processing units that run with a fixed speed, completely independent of each other. These threads and cores are linked by a switching fabric that is quite flexible in how things are connected. All of this is an offshoot of an older project called "transputers" that were designed from the ground up to do things differently than classic Von-Neumann architectures.
As with most anything, these chips have certain strengths, and some weaknesses. Each X-Series motherboard has a chip with two cores, each core carrying eight independent threads. (note: The advertising geniuses at XMOS have renamed "cores" as "tiles" and have renamed "threads" as "Cores", so any reference is now muddled by their marketing ingenuity.) Anyway.. the eight threads on each core share a common block of RAM, but under normal circumstances RAM is NEVER shared between cores. (Yes, there are ways around it, but that would betray the language design).. These threads are designed for processing streams of data, and they do so with exceptional speed.. But without sharing RAM, there has to be a very fast way of moving data around.. So "Links" were implemented. Links come in 2 wire and 5 wire varieties, and they are NOT clocked at a fixed rate.. they can basically accellerate to whatever speed that both the sender and receiver can support.. (within reason) The "fabric" that joins these threads and cores can also be brought out to external links, so that multiple XMOS chips can be joined into larger arrays.. so the end-user can build paralell processing arrays of as many cores/tiles as they choose. In fact the dual core Xena chip appears to the programmer as two separate single core devices.. interesting.
Note: The Xorro board has all the necessary connections to support this.. so the ability to expand this array is available to us.
Now, trying to get back on track.. What these chips do well is serialized data processing, and they can do it with guaranteed maximum response times. This is unique among all the chips and devices that I am familiar with so far. Another neat property is that the "code", the program they run, is loaded dynamically. Nothing is burned to ROM, so the chip, and all the links that configure it, can be stopped, re-programmed with new code, and re-started on demand.. completely "software configurable".
Note" All this programming is done by JTAG, and the other 98% of XMOS users require either a JTAG interface or a USB to JTAG device to play with their chips. The X1000 and Cyrus have these interfaces built right in to the motherboard, so we can safely assume that ALL machines of those two types are "ready to go" with no other stuff required. And yes, the JTAG loop is also brought out on the Xorro card, so additional XMOS chips can be added easily.
I can see that Hans has studied these chips.. the idea of direct control of stepper motors is a good example of what these chips might be very good at. The task is broken down into individual threads, with some consideration for the timing and speed requirements that the task needs. At least the hardware support for CNC control would be a walk in the park for a Xena chip.. the logical needs would still be up to the programmer.
Another project that was mentioned, and one I am much more familiar with, is the idea of adding a SDCard and using Xena to catch and store the debug stream. One thread captures the incoming serial data, one handles writing to the memory card.. but the data comes in one char at a time, and the SD card manager writes in blocks, so a "buffer" thread is placed in between..
Now on a "normal" processor, the problem comes when the chip goes off to write a block of data to the card.. the whole time that takes, the incoming serial is being ignored.. unless you have a chip with a built in hardware buffer, or a separate processor.. but with the XMOS chips you just give each thread it's own part of the larger job, and join them all together with links however you'd like. Also of note is the LARGE community of XMOS enthusiasts, and the public repository of free code.. combining bits of other peoples code is MUCH easier when each bit is running in a separate thread.. so this is really good for hobbyist programmers! A complete SD card read/write package, WITH DOS INCLUDED! serial port code in a few varieties, code for simple audio effects, IR Remote control recording/playback, some serialized data processing stuff.. there is a LOT of code ready to be re-combined into new projects.
I did a short demo of the above serial data logger project, not quite completed in time for the 2012 AmiWest show. If you're really into geeky stuff you can find it on YouTube.
But let me leave the tech stuff aside for a moment to talk about why so little has happened. There have been a few things that have slowed it all down. Mostly my own schedule. Put quite simply, I have been busy working on other stuff. Just before AmiWest 2012 I was able to complete the JTAG programmer that lets us program the Xena chip from the command line. This is not "sexy" stuff, but it's necessary before much else happens.
The initial "flashing LEDs" demo video from the board manufactrurer clearly shows that they plugged in an external JTAG programmer.. that's how everyone else does it. With the JTAG tools (and the supporting code written by Segher) we can do it from the command line.
My next big task was the compiler suite. The "XC" language preferred for these chips is NOT available freely. It is developed and maintained by XMOS, and the code is not public. They have an Eclipse based tool suite that runs on Windows or _SOME_ types of Linux. Sadly enough, only x86 platforms are supported. Recognizing that this would be a hindrance to many Amiga owners, I have tried a variety of ways to get around this. I have asked for support from XMOS, I have discussed this in their forums (which are suprisingly well managed by the company). I have tried a couple emulators under AmigaOS, but I was never able to properly emulate a 32 bit x86 system (16 bit systems will not work).
I tried more advanced emulators, but frankly emulators are not my cup of tea, and my experience on the "other side" is not so strong anyway. I even considered running a bigger emulator under Debian, but jumping back and forth between AmigaOS and Debian for every loop of development would be insane.
I managed to strip the actual command-line tools needed from their "XDE" toolchain, and could write basic makefiles that run well on my netbook. I added FTP scripts on both the netbook and my X1000. I worked out a system where simply typing "make" from the project directory on my Amiga would pack up all project related files, FTP them over to the netbook, which would then compile the project, recording all messages from the compiler and linker, then it zips up the result and sends it all back to the Amiga by FTP, complete with a return code. Slow? Sure. But faster than any other option I could find.
I then set out to make this available to everyone. I tried to set up an EMail account that would process the comile jobs just like my FTP scripts do.. so that Amiga users anywhere could type "make" and actually export the job to an old windows machine standing by for that purpose. I worked on that a long time. I almost got it working. I could gather up the project, LHArc it, email it over, and then process it properly. but I could never quite figure out how to receive mail on an Amiga. I tried Python, I tried a few other things.. but after all that work I simply gave up. My networking skills are not up to the task.
So, end result? Developing for Xena REQUIRES a windows or Linux box. I am sure that there MAY be ways around it, but I am done trying.
Ideally, I know that MANY others in our community are much smarter than I am.. hopefully one will step up to the job. I'll donate an old windows box and the network connection, as long as it won't impede the security of my home network.
Note: Post too long.. continued in next reply.
