Trouble setting up GITHub projects in XDE

New to XMOS and XCore? Get started here.
User avatar
LyleHaze
Experienced Member
Posts: 71
Joined: Wed Apr 11, 2012 6:21 am
Contact:

Trouble setting up GITHub projects in XDE

Post by LyleHaze »

Hello all,
I'm new to XMOS, I have managed to get some code running, but so far I have not been able to get any modules from the GIThub working.

Just to make sure, I downloaded and re-installed the latest XDE (11.11.1) onto my WindowsXP netbook. (XP Home, if it makes a difference)

XDE itself installed with no troubles. It took a few tries to get it to register, but I eventually got that done too.

I have installed the common repository(xcore-xcommon-cdcfc87.zip), following instructions at
https://github.com/xcore/Community/wiki ... tory-usage. When those instructions led me to install EGit and JGit, the install failed with the following message:
error installing EGit and JGit:
Cannot complete the install because one or more required items could not be found.
Software being installed: EGit Mylyn (Incubation) 0.11.3 (org.eclipse.egit.mylyn.feature.group 0.11.3)
Missing requirement: EGit Mylyn (Incubation) 0.11.3 (org.eclipse.egit.mylyn.feature.group 0.11.3) requires 'org.eclipse.mylyn.monitor.core [3.0.0,4.0.0)' but it could not be found

I have tried in previous attempts (under 11.11.0) to manually combine and compile the UART modules (both fast and normal), and while it compiles fine, I could never get any response to incoming serial.

On the hardware side, I have wired up a MAX3232 to do the level shifting from serial to 3.3 volt levels, I am _NOT_ using an established kit board or JTAG adapter.. but I have working tools to load code into the XS1-L2 chip that is on the motherboard of my computer.

This project will require three modules:
a UART receiver, the SD_Card module, and code I have already working to interface the XS1-L2 chip with the computer.

At this point getting ANY code from the repository to run here would be a big step forward.

Are EGit and JGit necessary, or are they just saving me from downloading the modules myself?
Are there any suggestions on how I can get the "Common Repository" working, or how I can work around it?

Finally, anyone here had some experience with the xcore-sc_uart module that might be able to help me along?

Yeah, I know. I am asking a lot. I'm not really _quite_ as stupid as these questions might lead you to believe. I have experience in the C language, as well as some embedded stuff on Microchip PIC's. I _AM_ very new to the XMOS experience, and the toolchain seems to be working against me.

ANY suggestions are welcomed!
Thank You,
Lyle


User avatar
LyleHaze
Experienced Member
Posts: 71
Joined: Wed Apr 11, 2012 6:21 am
Contact:

Post by LyleHaze »

Making some progress..
I have used the high speed TX and RX to "loop back" a serial port.
I chose high speed because the app I'm using STARTS at 115200 and can take advantage of much higher speeds later.

So typing a bit of plain text through the loopback, all characters are returned as either 0xF8 or 0X80.
My first guess is a baud mismatch. Since the high speed routines take a "clocks per bit time" argument, I have tried both "BIT_TIME(115200)" and "868". In both cases I get the same result, only 0Xf8 of 0X80 returned.

Tomorrow, I'll switch over to the "normal" uart routines and try it all again.

So far the XDE environment (Eclipse) has been nothing but a headache.
When changing from the normal to the fast UART stuff, I had to create a whole new project from scratch. Otherwise it would just keep complaining about the missing routines from the older UART code, no matter what I tried to do.

I guess when you are used to working without a "managed environment", the features become hindrances. Or maybe I'm just too old. ;)

As always, I welcome any comments or suggestions.

Lyle
User avatar
Lele
Active Member
Posts: 52
Joined: Mon Oct 31, 2011 4:08 pm
Contact:

Post by Lele »

Hi,
as far as getting code from github, I usually prefer to download the package as .zip file from the github ( https://github.com/xcore ) and then use the file->import then "import existing project into workspace" to load the .zip. Then I build and see which dependecies are really necessary (xcommon?...) and import too.
For the uart first I suggest to try the example in the interactive tutorial or the pre-defined project when creating a new xde project.
And if you have the xtag connector you already have the serial port with level shifter in it.

Lele
User avatar
LyleHaze
Experienced Member
Posts: 71
Joined: Wed Apr 11, 2012 6:21 am
Contact:

Post by LyleHaze »

For the uart first I suggest to try the example in the interactive tutorial or the pre-defined project when creating a new xde project.
I assumed all the tutorials were "pre-packaged" for existing developers kits.
I will give that a try.
And if you have the xtag connector you already have the serial port with level shifter in it.
I assume you mean one of the USB to JTAG devices?
I do not. I have a XS-L2 soldered directly to the motherboard of my computer,
and I have working tools that emulate a JTAG port through a Xilinx chip on that
same motherboard. As a result, I am developing on an XP machine with no
adapter or XMOS stuff connected, then carrying the resulting .xe file over to
the X1000 on a flash drive.
It does kind of make "interactive debugging" impossible at this time.

Thanks for your help, I'll try the "interactive tutorial" as soon as I get back.
As long as it does not require a USB JTAG device I might be able to get it working.

LyleHaze

Follow Up:
Searched around a bit, the only "interactive tutorials" I found were at
http://www.xmos.com/support/tutorials. None made reference to serial or UART,
and as far as I can tell they are all for specific developer kits. (and are so named)

I noticed that the serial code at GITHub was updated two days ago.. I'll download
it all and try again.

An odd note: The "fast" uart routines (simple) claim that they only do baud rates
that are multiples of 100000000.. I assume they mean "divisors".. Now, my target
baud rate is currently 115200, The calculator says 100000000 / 868 = 115207, which
is WAY under the 2% allowable error rate..
Yet the documentation specifically says that it is NOT capable of 115200 baud!
Since I'd _like_ to run faster baud rates once this gets going.. I'd really like to be able to use the fast UART code.. not working.

Anyway, off to make a fresh project using the "fully featured" UART code to see if it fares any better.

As always, suggestions are welcomed!
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Post by segher »

I see nothing in the (TX) code that would make (almost) 115200 not work;
presumably the doc means "this is not exactly 115200".

One thing I note is that the code sends consecutive chars as fast as
possible. Depending on how smart your receiver is, it will then never
synch up, or synch up to the wrong bit if you send the same stuff all
the time. To see if this is the case (it looks like it), replace

Code: Select all

        p @ t <: 1;
        t += clocks;
        p @ t <: 1;
with

Code: Select all

        p @ t <: 1;
        t += 10*clocks;
        p @ t <: 1;
(in production code, you only want to do this once in a while, not after
every byte (should be _before_ anyway), if you want to get high speed transfers).

UARTs suck for reliable transfers.
User avatar
LyleHaze
Experienced Member
Posts: 71
Joined: Wed Apr 11, 2012 6:21 am
Contact:

Post by LyleHaze »

Segher:
Looks interesting, will give it a try immediately.

meanwhile.. I rebuilt everything using the normal,slower, fully featured modules.
I get exactly the same problem: Whatever characters I send into it, it replies with either 0xf8 OR 0X80..
I am beginning to suspect that the "default" clock is not what I have been assuming it is.

Oh, and as I'm wandering though the UART modules, I found a note that is either wrong or truly bad news. In file "uart_tx_impl.h", line 19 describes the Bits per character as "Must be less than 8".
I know that 7 bits are sometimes used for text, but considering that binary transfers are also fairly common, I am HOPING this is a typo, and not a limitation of the UART module.

My big bad magnifying glass shows a oscillator module near the XMOS chip with the numbers 25.000.. So my next question: Do these chips have a 4X PLL on the clock input, and does it have to be enabled in some way?? Please set me straight on this.. If I'm actually clocking at 1/4 the normal rate, my "other" project will be in line for a BIG speed boost!
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Post by segher »

LyleHaze wrote:meanwhile.. I rebuilt everything using the normal,slower, fully featured modules.
I get exactly the same problem: Whatever characters I send into it, it replies with either 0xf8 OR 0X80..
I am beginning to suspect that the "default" clock is not what I have been assuming it is.
You are using the RX as well? I would first try to get only the TX (that
is, xcore->host) working, if I were you; this is a) much simpler to get
working, and b) has much fewer unknowns, and then c) when you have
TX working, you have fewer unknowns for RX :-)

For your clocks... You're still using my JTAG tools, right? Run "sregs",
and see what is in switch registers 06 and 08 (and heck, 07 as well
while you're at it). On a board that uses a 13MHz clock source, I get:

Code: Select all

06: 00807a00
07: 00000000
08: 00000003
Which means:
reg 06 bits 5..0 = 00 = R
reg 06 bits 20..8 = 7a = F
reg 06 bits 25..23 = 1 = OD

This is the system clock, it is generated from the clock source by first
dividing by two, and then PLLing it by F over R, and finally dividing by OD.
Actually, all these numbers should be increased by 1, since 00 means
"divide by 1", etc. So we have:
system freq = osc freq / 2 * (123 / 1) / 2 = 13MHz * 30.75 = 399.75MHz .

(This is the default setting after reset (MODE[1:0]=00, the usual for USB-
enabled stuff)).

reg 07 is 00, so core clock is system clock / 1 (so ~400MHz); and
reg 08 is 03, so ref clock is system clock / 4 (so ~100MHz, the value
that most things assume).
My big bad magnifying glass shows a oscillator module near the XMOS chip with the numbers 25.000.. So my next question: Do these chips have a 4X PLL on the clock input, and does it have to be enabled in some way??
You specify the clocks in your XN file, in a line like

Code: Select all

<Node Id="0" InPackageId="0" Type="XS1-L1A" Oscillator="13MHz" SystemFrequency="400MHz">
You need to have MODE[1:0]=10 for a 25MHz clock source, but you
probably do, or nothing would work at all :-)

HTH,


Segher
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Post by segher »

For fun and giggles, try a bit time of 452 instead of 868 ref clocks...
If that works, it is all my fault (but at least it is easy enough to fix :-) )
User avatar
LyleHaze
Experienced Member
Posts: 71
Joined: Wed Apr 11, 2012 6:21 am
Contact:

Post by LyleHaze »

Thanks for your assistance.

I am currently using RX looped back to TX, and on the host end I just open a terminal with no local echo.
I verified the host by attaching it to another Amiga using the same terminal software and settings first.

When I became curious about whether the problem was TX or RX, I added about a dozen uart_tx_send_byte() calls before entering the copy loop, with a recognizable string. To my surprise, these characters never appeared as output, correct or scrambled. I didn't bother following this through. Probably came too soon after the init code.

SO this morning, before changing any software, I checked registers 6,7 and 8 of SRegs
06: 01001700
07: 00000000
08: 00000003
If I take it apart correctly:
R = bits 5:0 = "00 0000" +1
F = bits 20:8 = "0 0000 0001 0111"+1
OD = bits 25:23 = "01 0" + 1 (Odd that the low bit is not nibble-aligned)

Assuming a 25MHz oscillator (still awaiting confirmation)
that gives:((25MHz / 2) * 24) / 3, which gives 100 MHz.
I'd prefer 400 MHz here. ;)

I added the "Oscillator" tags to the XML file, they compiled fine, but after
loading the new project, the SRegs settings are the same.

SO.. Assuming I am running at 1/4 speed, and assuming I do not have the
boot code that would write the correct clock values into the switch regs, is it
possible for me to write these values from my .xe application?
If my math is right changing SReg 06 to 0x01005F00 should be good.

Too much math before breakfast is not good. Time to eat. ;)
Glad to be makling some progress, Thank you for your help!

Lyle
edit: Math was wrong, breakfast was good. Math is now better.
Last edited by LyleHaze on Sun Sep 23, 2012 5:51 pm, edited 1 time in total.
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Post by segher »

LyleHaze wrote:I verified the host by attaching it to another Amiga using the same terminal software and settings first.
Good plan :-)
SO this morning, before changing any software, I checked registers 6,7 and 8 of SRegs
06: 01001700
07: 00000000
08: 00000003
If I take it apart correctly:
R = bits 5:0 = "00 0000" +1
F = bits 20:8 = "0 0000 0001 0111"+1
OD = bits 25:23 = "01 0" + 1
This is the default setting for MODE[1:0]=01, that is, 48MHz..100MHz
clock source. You really should use 10 for a 25MHz clock source. But it
will _just_ work: the PLL output frequency (the whole calculation except
the OD (output divider) part) is 300MHz, so within 260MHz..1300MHz,
the specced boundaries.
(Odd that the low bit is not nibble-aligned)
I've wondered about that as well.
Assuming a 25MHz oscillator (still awaiting confirmation)
that gives:((25MHz / 2) * 24) / 3, which gives 100 MHz.
I'd prefer 400 MHz here. ;)
Yeah :-) So try a bittime of 217, to verify?
I added the "Oscillator" tags to the XML file, they compiled fine, but after
loading the new project, the SRegs settings are the same.

SO.. Assuming I am running at 1/4 speed, and assuming I do not have the
boot code that would write the correct clock values into the switch regs, is it
possible for me to write these values from my .xe application?
When you write to the PLL reg, the cores reset. When you then load
the XE file again, the chip is given an external reset, so your PLL reg is
back at the original value. Repeat ad infinitum.

This is not a problem when booting from SPI (or OTP, etc.); in that case,
the code does program the PLL for you. But when running via JTAG, it
is easiest if you program the PLL via JTAG before running as well.

And I don't yet do that in runxe, oops, sorry :-)
If my math is right changing SReg 06 to 0x01005C00 should be good.
Run "xobjdump -s" on your XE file, the program_info.txt (if I got the name right)
file gives you the value to use :-) 00801f00 perhaps?


Segher
Post Reply