segher wrote:
Heh. Great to hear it works well for you now.
What programs do you use? runxe (or "bare" run)? All the rest is for debug
(which is, erm, very useful :-) )
Promise not to laugh? None at all, yet. I have not even successfully created
an XCore project.
When the manufacturer made the first run of our motherboard, they plugged
an XTAG programming device in to the socket, plugged a "protoboard" with
about 32 LED drivers into the Xorro slot, and "proved" the design with a
short program they downloaded from their laptop. So my first design goal
was to get access from an AmigaOS command line. Just today I requested
the project code they used for that demo, so that I can load it from these
new utilities. We also have a built-in LED off each core on the motherboard,
and the next step is to modify that project to flash those internal LEDs.
So, if I have appeared to be inexperienced, then you are VERY correct.
segher wrote:
LyleHaze wrote:Then I'll have to try to figure out if there is a command-line XCORE assembler that could be ported.
There is none available as far as I know. Maybe XMOS can open source it if you smile
sweetly ;-)
Actually the project leader went looking today and found the code for the comand line compiler and utils.
It looks like a big project to port over. Since this new Amiga also runs Debian, we may just
use the available tools there for a while.
What I do intend is to add OS level support for resource allocation, to prevent multiple tasks from using the XMOS chip at the same time. Then adding the ability to "run" or "runxe" code into the device just by double-clicking the icon on the executable. This will make different apps more user-friendly. Finally, I'll probably write a GUI window that offers an animated color view of the pins and registers, both as a debugging tool and as eye-candy.
segher wrote:
Or someone could port binutils, perhaps. That would be nice to have!
At this time I could only guess what utils you might have or need.. Complete newbie.
segher wrote:
I can perhaps merge your changes back, btw. Let me know if you'd like that.
Right this second It's all too messy. I need to clean up my edits.
But I think it's worth doing. I have already been asked if these tools can be used by other
Amigas that don't have an onboard XMOS chip, so support for our own usb.device would be
the third option to merge in.
I have more questions (of course). But these will probably sort themselves out as I get in to the
dev SDK on windows.. The code can scan regs, sregs, pregs, psregs, WTF?
I could GUESS that some are registers, some are the states of I/O pins, possibly some are tri-state status or force options.. More will be revealed as I begin to study.
I'll need to figure out how to create a project without the SDK actually scanning the device, since I will NOT be adding a XTAG adapter to my windows machine.. I know it's an XS1-L2, but there are a few to choose from when creating a project. Again, this will be easier if/when I get the original demo project code here.
Interesting, when they designed this XS1-L2 into the motherboard, they set it up for a very FAST link to the CPU. It has a 16 bit data bus direct to the CPU local bus, as well as a few other lines. I believe it is supposed to appear as RAM to the processor. It passes most of the other signals off to an "XMOS Expansion Slot" (we call it Xorro for historical purposes). So it appears the designers envision the builtin core as a very fast interface between the CPU and additional XCores. Have you seen something like this before? I'm wondering (1) if we have existing designs to learn from, and (2) if this will give us a performance advantage over USB linked devices. I attached a simple diagram of our connection setup a few messages back.
I still have a steep learning curve ahead of me, but having working tools on the native machine is already a great help.
Sleep, I REALLY need sleep. ;)
LyleHaze