Slicekit port of xSOFTip derived app_uart_fast?

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
User avatar
Chendy
Active Member
Posts: 46
Joined: Tue Nov 02, 2010 4:53 pm

Slicekit port of xSOFTip derived app_uart_fast?

Post by Chendy »

Hi all,

Trying to get my head around the app_uart_fast demo with my new slicekit. It compiles fine, but seems to be set up for the target 'SK-1500'. I have noticed that for demos made specifically for the slicekit (and that work correctly), the target is 'XK-SK-L2' in the makefile (I have changed the target in the makefile). I have also deleted the SX-1500.xn and replaced with SLICEKIT-L16.xn.

What needs to be changed to set app_uart_fast up for the slicekit? (if anything)

What else should I be aware of?

What should I read to learn to set up a project from scratch?
- xTIMEcomposer-User-Guide(X3766A).pdf?

What should I make sure I read in general given that I am starting off with XMOS? There seems to be alot of information about, but organisation/structure of the various resources is far from perfect IMHO. I have done the tutorials available in xTIMEcomposer.

Any help appreciated

Senthil

Edit: I should mention that the demo doesn't work. I am connecting between X0D0 TRIANGLE and X0D1 STAR (XS1_PORT_1A, XS1_PORT_1B). The clock used is 'XS1_CLKBLK_REF', which I am not sure is correct?


User avatar
dan
Experienced Member
Posts: 102
Joined: Mon Feb 22, 2010 2:30 pm

Post by dan »

Hi Senthil,

Looks like you turned up a few wrinkles here. We're looking into it - stay tuned.

With regard to getting started with project creation, is your preference for the GUI or command line environment?

Best,

Dan
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

Chendy wrote:Hi all,

Trying to get my head around the app_uart_fast demo with my new slicekit. It compiles fine, but seems to be set up for the target 'SK-1500'. I have noticed that for demos made specifically for the slicekit (and that work correctly), the target is 'XK-SK-L2' in the makefile (I have changed the target in the makefile). I have also deleted the SX-1500.xn and replaced with SLICEKIT-L16.xn.

What needs to be changed to set app_uart_fast up for the slicekit? (if anything)
That is the right thing to do if you have the slicekit. The .xn file describes the system including number of cores/tiles, crystal speed, PLL settings and boot flash, and so is hardware specific. The XK-1500.xn file is a file that describes the XK-1A kit, which uses an 8-core 500MHz XS1-L08A device with a 20MHz, which is what this app was tested on. Slicekit is 25MHz, 16-core etc.. So the target in the makefile did need to change.
Chendy wrote: What else should I be aware of?
The only thing you may want to change is the port mapping. You need to explicitly state which ports you are using with XMOS, but I see your edit below where you are looping back between XS1_PORT_1A, XS1_PORT_1B. That’s fine. No point in sending the signal via the transceiver on the GPIO slice as this example runs at 10Mbps, which is way faster than am RS232 transceiver can handle.

Hopefully this should get things working. If not, could you check the pins to see if anything is waggling? Let me know how you get on!
Chendy wrote: What should I read to learn to set up a project from scratch?
- xTIMEcomposer-User-Guide(X3766A).pdf?

What should I make sure I read in general given that I am starting off with XMOS? There seems to be alot of information about, but organisation/structure of the various resources is far from perfect IMHO. I have done the tutorials available in xTIMEcomposer.
Section B3 of the xTIMEcomposer guide gives guidance for getting started and there are lots of sections showing you how to import, create run configurations etc. However, you’ve got a fair point – I don’t see a section for setting up a project from scratch. I’ll talk to the guys internally about that.
It's not difficult file->new->xtime composer project..set name and target then finish.. However we should have that neatly documented.

What we have tried to do is to integrate the tutorials into the tools (so you just have the one app that includes everything you need, including docs in the developer column). In addition, we aim to have quickstart guides for everything such as examples and kits, so you can get something working quickly, which can then be modified/played with.

I’m glad you’ve made it through the tutorials. I’d be interested in your thoughts on the usefulness/ease of use for these (and which ones you completed).

Looking at the code for this example, it can be tidied up. We'll look at making it clearer and targeting the slicekit..

Chendy wrote: Any help appreciated

Senthil

Edit: I should mention that the demo doesn't work. I am connecting between X0D0 TRIANGLE and X0D1 STAR (XS1_PORT_1A, XS1_PORT_1B). The clock used is 'XS1_CLKBLK_REF', which I am not sure is correct?
As per above, ports choices you made are sensible. The clock block (which is a block that allows you to prescale the internal ref clock and use/output them, or use an input port to generate an internal clock synchronous to an external source) doesn’t need changing. Actually in this example it’s not really needed as you could just run straight off the 100MHz ref clock. The XS1_CLKBLK_REF' is passing the ref clock straight through.

Page 40-> of the “XC-Programming guide” doc shows some pictures of how clock blocks and ports can work together, if you’re interested in writing your own interfaces. If not, hopefully our IP library gives you what you need.
User avatar
Chendy
Active Member
Posts: 46
Joined: Tue Nov 02, 2010 4:53 pm

Post by Chendy »

Hi Dan and infiniteimprobability,

Thanks for the replys. I was worried my problems were too basic and my blabbering irrelevant.

My 'how to setup new projects' has been answered now. Thanks

@ infiniteimprobability

I think that the ports I mentioned above are bad choices: I have wrote a simple test function to toggle those ports and nothing happened. I have now, converted it from the (old?) single core style to the multi-tile style (using 'on tile[0]') and repeated the 'toggle port test': it still doesn't working with XS1_PORT_1A, XS1_PORT_1B (assuming they indeed relate to X0D0 TRIANGLE, X0D1 STAR), but the 'toggle port test' works when using 1A & 1B on tile[1]. So now its working with a glitch I'm trying to get my head around. When I 'produce' the number 0 to 15 it returns 255, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 (theres a rouge 255 sent from somewhere, shouldn't be hard to track done). Heres my code below:

Code: Select all

#include <platform.h>
#include <xs1.h>
#include "uart_rx.h"
#include "uart_tx.h"
#include <print.h>

//:: Port declarations
on tile[1]: clock refClk = XS1_CLKBLK_REF;

in port rx = on tile[1]:XS1_PORT_1A;
out port tx = on tile[1]:XS1_PORT_1B;
//::

void wait(unsigned wait_cycles) {
  timer tmr;
  unsigned t;

  // read the current time
  tmr :> t;
  // event will occur wait_cycles * 10ns in the future
  tmr when timerafter (t+wait_cycles) :> void;
}

void flash(){
	while(1){
		tx <: 0;
		printuintln(0);
		wait(100000000);
		tx <: 1;
		printuintln(1);
		wait(100000000);
	}
}

//:: Producer function
void produce(streaming chanend c) {
	wait(10000000);

    for(int i = 0; i < 16; i++) {
        c <: (unsigned char) i;
    }
}
//::

//:: Consumer function
void consume(streaming chanend c) {
    unsigned char buf[256];

    for(int i = 0; i < 16; i++) {
      c :> buf[i];
      //printuintln(buf[i]);
    }
    //printstrln(" ");
    for(int i = 0; i < 16; i++) {
      printuintln(buf[i]);
    
    }
}
//::

static inline x() {
    set_thread_fast_mode_on();
}

void burn() {
    x();
    while(1);
}

void uart_tx_fast_complete(streaming chanend c){
	configure_out_port_no_ready(tx, refClk, 1);
	while (1){
		uart_tx_fast(tx, c, 10);
	}
}

void uart_rx_fast_complete(streaming chanend c){
	configure_in_port_no_ready(rx, refClk);
	clearbuf(rx);
	while(1){
		uart_rx_fast(rx, c, 10);
	}
}

//:: Main program
int main(void) {
    streaming chan c, d;

    //

    par {
    	//on tile[0]: {flash();}
        on tile[1]: {x(); produce(d);}
        on tile[1]: {x(); uart_tx_fast_complete(d);}
        on tile[1]: {x(); uart_rx_fast_complete(c);}
        on tile[1]: {x(); consume(c);}
        on tile[0]: {burn();}
        //burn();
        //burn();
        //burn();
    }
    return 0;
}
//::
Also the 'Multi-UART PC Com Port Demo Application' doesn't seem to be set up for the slicekit. However it seems to work fine without any modification, I guess because they are both using the '"XS1-L2A-QF124'?


I'm trying to intergrate the fast_uart with the multi_uart module, with the view of receiving a single fast channel of serial and distributing it at lower rates using the 8x multi_uart channels. Any reason this won't work? Any tips appreciated

Thanks again

Senthil
User avatar
pstnotpd
XCore Addict
Posts: 161
Joined: Sun Jun 12, 2011 11:47 am

Post by pstnotpd »

@XMOS

If you're going to review the project setup documentation I'd appreciate a description/cookbook on how to do this properly using command line only.

At the moment I create a project using the IDE and then drop to the command line from there.

I'm sure there must be some other way to do this, but I can't find it.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

@Chendy

Firstly, you should be confident that you are getting the hang of this stuff. The changes you made to the code, including playing with tile placement, are sensible.

I took your code and run it on my slice kit, and well, it all works fine. 0..15 printed out if a loopback is present, 0 printed if not.

Even if I change everything to tile 0, it still works fine. (Which is a relief as I made my comment about sensible port choice without trying in hardware). This suggests something different about your hardware..

- XD0 and XD1 on tile 0 are muxed with SPI but will automatically get assigned to normal I/O after boot, until X0D43/42 (P8D7/6 on core 0) are driven to latch the mux back to SPI. However your code doesn't do anything with Port 8 so XD0 and XD1 should be as I/O as expected.
- There is a slice card in the triangle or star slots. Bit of an obvious one this, but worth checking.

Either that or perhaps you missed changing all references to tile 0?

Regarding this
Also the 'Multi-UART PC Com Port Demo Application' doesn't seem to be set up for the slicekit. However it seems to work fine without any modification, I guess because they are both using the '"XS1-L2A-QF124'?
Actually the multi-UART was one of the initial slicekit demos. So it absolutely should work on the slicekit - I just checked the makefile and it says

Code: Select all

TARGET ?= SLICEKIT-L2
I'm trying to intergrate the fast_uart with the multi_uart module, with the view of receiving a single fast channel of serial and distributing it at lower rates using the 8x multi_uart channels. Any reason this won't work? Any tips appreciated
Sounds like a reasonable thing to do, and the sort of thing XMOS is really good at. One thing you might need to be aware of is that the fast UART and Multi UART expect optimisation to be on to hit 10Mbps - so make sure -O3 is selected (which it is by default in both apps' makefiles)

Did you get the multi-uart demo running OK first?
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

@pstnotpd

Using the IDE as a starting point (or even modifying some of our code examples) makes a lot of sense, but shouldn't be a substitute for documentation.

Setting up projects at the command line is mostly based around setting up makefiles. Section 10 of the xTIMEcomposer user guide https://www.xmos.com/download/public/xT ... 66A%29.pdf "Using XMOS Makefiles" has details on that. What sort of thing did you have in mind over that?
User avatar
pstnotpd
XCore Addict
Posts: 161
Joined: Sun Jun 12, 2011 11:47 am

Post by pstnotpd »

infiniteimprobability wrote:What sort of thing did you have in mind over that?
Thanks for the pointer:

1. Can I "import" xSOFTip components from the command line?
2. If I want to use modules which are not in a xSOFTip, how do I properly set them up. Does the USED_MODULES entry properly resolve to the project structures shown?
3. Where and how to include the makefile.common.
4. How to facilitate simultaneous IDE and command line development
5. How to use GIT repositories.

Granted, generating a project from the IDE mostly shows how it is supposed to be configured, but a tutorial on how to set up a command line only project would be nice.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

OK - my mistake!

When I said
- XD0 and XD1 on tile 0 are muxed with SPI but will automatically get assigned to normal I/O after boot, until X0D43/42 (P8D7/6 on core 0) are driven to latch the mux back to SPI. However your code doesn't do anything with Port 8 so XD0 and XD1 should be as I/O as expected.
What I meant was, they need to be manually assigned back to normal I/O after boot! For some reason, my board (which has fought a few battles) is broken in this respect and doesn't behave as per the manual.

XD0, XD1 on tile 0 are OK to use *only* if you switch the I/O back on. So either use:

Code: Select all

on tile[0]: out port enable_ports = XS1_PORT_8D; //Port controlling mux for SPI vs IO for XD0,1,10,11
enable_ports <: 0x80; //Send one to DFF
enable_ports <:0xc0;  //Latch one into DFF to disable SPI but enable ports
Or just choose other 1b ports on tile 0 - such as XS1_PORT_1E & XS1_PORT_1F (aka XD12 and XD13)

Hope this helps and sorry for the confusion.
User avatar
Chendy
Active Member
Posts: 46
Joined: Tue Nov 02, 2010 4:53 pm

Post by Chendy »

Thanks infiniteimprobability,

I was just going to ask about that because it wasn't working. All 1b ports on tile[0] flashing happily now : )