Search Results for: xta

Enable USB drivers on Linux

The XMOS tools interface to development boards using USB debug adapters.
USB driver support is provided natively on Linux, but in some cases, the
driver must be enabled. The method required to enable the driver depends
on the Linux distribution you are using and the kernel version.

Linux distributions known to provide USBFS support include:

  • Ubuntu 9.04 or older
  • Ubuntu 9.10 with kernel 2.6.31-19-server
  • CentOS 4.8 and 5.4
  • Generally, any distribution with kernel version < 2.6.32

Linux distributions known to not provide USBFS support include:

  • Ubuntu 10.04
  • Generally, any distribution with kernel version >= 2.6.32

Enable USB driver on system with USBFS support

If your distribution provides USBFS support, use the following command to
enable the Linux driver:

mount -t usbfs none /proc/bus/usb -o devmode=0666

To automatically enable the driver on boot, add the following line to the file /etc/fstab:

none /proc/bus/usb usbfs defaults,devmode=0666 0 0

Enable USB driver on system without USBFS support

If you distribution does not provide USBFS support, you must configure
udev to recognise the device. To configure udev, follow
these steps:

  1. Create a file /etc/udev/rules.d/99-xmos.rules with the following contents:
SUBSYSTEM!="usb|usb_device", GOTO="xmos_rules_end"
ACTION!="add", GOTO="xmos_rules_end"

# 20b1:f7d1 for xmos xtag2
ATTRS{idVendor}=="20b1", ATTRS{idProduct}=="f7d1", MODE="0666", SYMLINK+="xtag2-%n"

# 0403:6010 for XC-1 with FTDI dual-uart chip
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0666", SYMLINK+="xc1-%n"

LABEL="xmos_rules_end"

The ATTRS, MODE and SYMLINK stanzas must be all on one line, as each rule can only be on one line.

  1. Enter the following command:

service udev reload

  1. Unplug and re-plug the USB cable.

    This allows udev to recognise the device with the new rules.

    Alternatively, you can trigger a re-plug in udev by entering either the command
    udevadm trigger or udevtrigger,
    depending on the version of udev provided with your Linux distribution.

Additional notes for FTDI/XTAG debug adapters

  1. The FTDI library requires that the USB device files are available
    from /proc/bus/usb and does not support /dev/bus/usb as a location for these files.
  2. If your Linux distribution does not support USBFS but does have an empty /proc/bus/usb
    directory, you can use the following command as a workaround:

    mount –bind /dev/bus/usb /proc/bus/usb

  3. If your distribution does not support USBFS and does not have a
    /proc/bus/usb directory (this is the case on newer kernels, from approximately 2.6.32 onwards),
    you may contact XMOS for an unofficial patched version of the device library.

    To request the library, send us a support ticket with “Linux FTDI Library Request”
    in the Subject field.

How to specify loop iterations in nested loops

  • version

    1.1.1

  • scope

    Example.

    This code is provided as example code for a user to base their code on.

  • description

    How to specify loop iterations in nested loops

  • boards

    Unless otherwise specified, this example runs on the SliceKIT Core Board, but can easily be run on any XMOS device by using a different XN file.

In many cases the XTA will know the number of iterations for a given loop.
However, in some cases, this information cannot be deduced by the tools so
you must supply it.

This example describes some options for setting loop iterations for
nested loops, and introduces the concept of the loop scope.

For example, compile the following code:

int f() {
  int i, j, k = 0;
  for (i = 0; i < 5; ++i) {
    #pragma xta label "outer_loop"
    for (j = 0; j < i; ++j) {
      #pragma xta label "inner_loop"
      k += i + j;
    }
  }
  return k;
}

int main() {
  f();
  return 0;
}

By default, the tool assumes that the iterations for loops are relative,
meaning that the iterations for an inner loop will be multiplied by the
iterations of enclosing loops. However this is not sufficient to describe all
loop structures. If this assumption is not correct (as is the case in the above
code) a loop count can be set to absolute. The iteration count set on an
absolute loop is not multiplied up by the iterations set on enclosing loops.
For example, in this case, if you set the inner loop to have an absolute scope,
and a loop count of 10, then this will correctly capture the behavior of the
code.

Setting a global loop scope

Load the resulting executable into the XTA then click the
‘Add define’ button in the toolbar. In the dialog, switch to
the Loop Scope tab, enter ‘inner_loop’ in the reference
section and check the make scope absolute box. Now, any
iterations set on ‘inner_loop’ will be treated as absolute.

To add a global loop scope using the command line XTA, or from
an XTA script/embedded source command, the following can be used:

add loopscope inner_loop a

Setting a local loop scope

Load the resulting executable into the XTA then time the
function ‘f’. This will create the route. Right-click in the
left hand side border of the editor on the source line inside
the loop (k += j + i) and select ‘Set loop scope’. In the
resulting dialog check the make scope absolute box.

To add a local loop scope using the command line XTA, or from
an XTA script/embedded source command, the following can be used:

set loopscope 0 inner_loop a

This will set a the inner loop for the route with an id of 0 to have
a scope of absolute.

How to specify loop iterations for specific paths in a loop

  • version

    1.1.1

  • scope

    Example.

    This code is provided as example code for a user to base their code on.

  • description

    How to specify loop iterations for specific paths in a loop

  • boards

    Unless otherwise specified, this example runs on the SliceKIT Core Board, but can easily be run on any XMOS device by using a different XN file.

A loop may contain multiple paths through it. When a loop iteration count has
been set the tool assumes that all iterations will take the worst-case path of
execution through the loop. This is not always the case, and a more realistic
worst-case can be established by specifying the number of iterations on
individual paths through the loop.

For example, compile the following code:

int f() {
  int x = 0;
  for (unsigned int i = 0; i < 10; ++i) {
    #pragma xta label "loop_label"
    if ((i & 1) == 0) {
      #pragma xta label "if_label"
      ++x;
    }
  }
  return x;
}

int main() {
  f();
  return 0;
}

Setting global loop path iterations

Load the resulting executable into the XTA then click the
‘Add define’ button in the toolbar. In the dialog, On
the Loop tab, enter 10 iterations using loop_label as the
reference. Next switch to the Loop Path tab and enter 5
iterations using ‘if_label’ as the reference. Any future routes
containing this loop will now correctly assign five iterations to
each side of the conditional in the loop.

To add a global loop scope using the command line XTA, or from
an XTA script/embedded source command, the following can be used:

add loop loop_label 10
add looppath if_label 5

Setting a local loop scope

Load the resulting executable into the XTA then time the
function ‘f’. This will create the route. Right-click in the
left hand side border of the editor on the source line inside
the conditional (++x) and select ‘Set loop iterations’. In the
resulting dialog, set the number of iterations to 10. Now right-click
on the same line and select ‘Set loop path iterations’, and this time
enter 5 in the dialog.

To add a local loop scope using the command line XTA, or from
an XTA script/embedded source command, the following can be used:

set loop 0 loop_label 10
set looppath 0 if_label 5

This will set a the loop iterations for the route with an id of 0.

Note: There are some rules that need to be followed when setting loop path iterations:

  • In a nested loop, the outer loop iterations need to be set first.
  • The sum of the loop path iterations set must be less than or equal to the loop
    iterations set on the enclosing loop.
  • If the loop path iterations set are less than that of the
    enclosing loop, then there must exist another path within
    the loop without its iterations set to which the remaining
    iterations can be allocated.

Slicekit GPIO and Ethernet Combo Demo Quickstart Guide

sw_gpio_examples GPIO and Ethernet demo : Quick Start Guide

This example demonstrates the use of two Slice Cards, XA-SK-GPIO and XA-SK-E100 together with the xSOFTip components for Ethernet, XTCP, I2C and WebServer to provide access to the GPIO slice features via a simple embedded webserver.

A webpage served from the sliceKIT and accessed in a browser on a host PC has the following demo functions:
  • Turn GPIO Slice Card LEDS on and off
  • Read the room temperature via the onboard ADC and display on the web page
  • Display GPIO Slice Card button press status

Hardware Setup

The XP-SKC-L2 Slicekit Core board has four slots with edge conectors: SQUARE, CIRCLE, TRIANGLE and STAR.

To setup up the system refer to the figure and instructions below

  1. Connect the XA-SK-E100 Slice Card to the XP-SKC-L2 Slicekit Core board using the connector marked with the CIRCLE.
  2. Connect the XA-SK-GPIO Slice Card to the XP-SKC-L2 Slicekit Core board using the connector marked with the SQUARE.
  3. Connect the XTAG Adapter to Slicekit Core board, and connect XTAG-2 to the adapter.
  4. Connect the XTAG-2 to the host PC. Note that an Ethernet cable is not provided with the Slicekit starter kit.
  5. Connect one end of the Ethernet cable to XA-SK-E100 Slice Card and the other end to the RJ45 jack of your host PC.
  6. Switch on the power supply to the Slicekit Core board.
  7. Ensure the activity LEDs on the XA-SK-E100 Slice Card and the host PC’s Ethernet Jack are toggling.
Hardware Setup for the GPIO and Ethernet Application Demo

/files/images/16450/9/hardware_setup.png

Import and Build the Application

  1. Open xTIMEcomposer, then open the edit perspective (Window->Open Perspective->XMOS Edit).
  2. Locate the 'Slicekit GPIO Ethernet Demo' item in the xSOFTip Broswer window and drag it into the Project Explorer window in the xTIMEcomposer. This will also cause the modules on which this application depends (in this case, module_ethernet_board_support, module_i2c_master, module_webserver) to be imported as well.
  3. Click on the Slicekit GPIO Ethernet Demo item in the Explorer pane then click on the build icon (hammer) in xTIMEcomposer. Check the console window to verify that the application has built successfully.

For help in using xTIMEcomposer, try the xTIMEcomposer tutorials, which you can find by selecting Help->Tutorials from the xTIMEcomposer menu.

Running the Demo

  1. Click on the Run icon (the white arrow in the green circle). A dialog will appear asking which device to connect to. Select XMOS XTAG2.
  2. xTIMEcomposer console displays the ip address obtained by the DHCP client (or local link if DHCP server is not accesible). Please note if the DHCP server is not available on the host PC, it may take a while to obtain the ip address.
  3. Open a web browser on the host PC and type the ip address displayed on the xTIMEcomposer console into the browser’s address bar
  4. On hitting the return key, a web page should get loaded and displayed in the browser as shown in the figure below.
Screenshot of GPIO web page

/files/images/16450/9/gpio_web_page.png

Use the web page options to perform various actions such as
  1. Switch on all the LEDS by turning them all to ‘ON’ in the browser then clicking Submit. The LEDS should light, the ADC temperature display should be updated, and the webpage will report no buttons have been pressed.
  2. Switch off two of the LEDS by turning two to ‘OFF’ in the browser then clicking Submit. Two LEDS should go out and the ADC temperature is reported again. This time also webpage will report no buttons have been pressed.
  3. Press SW1 button on the GPIO slice card and then press submit. The web page should now report that Button 1 is pressed.
  4. Press SW2 button on the GPIO slice card and then press submit. The web page should now report that Button 2 is pressed.
  5. Just hitting Submit now displays both the buttons are not pressed. LEDs state remain unchanged unless they are explicitly changed on the web page.

Next Steps

Building web pages for your applications

This application parses ethernet data to interpret web page commands. Refer to the Programming Guide section within the SliceKit GPIO Example Applications documentation linked from the front page documentation for this demo for more information on how to utilize the Embedded Webserver Function Library component in building your own custom web server applications.

Look at the Code

The application handler runs on one core. It uses I/O pins to read or write data to the LEDs, buttons and the I2C ADC to read the temperature. The web page handler executes in another core, receiving the TCP requests and processing them. It calls the functions described in the webpage (webpage includes embedded function calls into the application code), processing the requests and sending commands over the c_gpio channel to the gpio core (application handler).

  1. Examine the application code. In xTIMEcomposer navigate to the src directory under app_sk_gpio_eth_combo_demo and double click on the main.xc file within it. The file will open in the central editor window.
  2. The channel c_gpio is used between tcp handler and application handler to send web page requests to the application and to collect GPIO status from the application.
  3. In the app_handler.xc file, the API function set_gpio_state is used by the web page in order to apply web page LED settings and similarly the API function get_gpio_state is used by the web page to collect the current GPIO status containing LEDs, button presses and ADC temperature values.
  4. There is some GPIO button scan logic which monitors for value changes on the configured 4-bit button port (XS1_PORT_4C) in the application handler routine as defined in the app_handler.xc file. Whenever this port value changes, the GPIO button states are updated accordingly.
  5. Also verify that that the ADC value is read whenever there is a web page request. This value is interpolated to get a proper temerature value and is updated in the GPIO state structure before sending it to the web page.
  6. As a part of this exercise, modify the IP address settings in main.xc file to a static ip address as in the commented part of ip config, build and run the application. Open a web browser to check whether you are able to open a web page using the new ip address and able to issue LED commands from the web page.

GPIO Wi-Fi Demo Quick Start Guide

sw_gpio_examples GPIO and Wi-Fi demo : Quick Start Guide

This example demonstrates the use of two Slice Cards, XA-SK-GPIO and XA-SK-WIFI slice together with the xSOFTip components for Wi-Fi, SPI, I2C and WebServer to provide access to the GPIO slice features via a simple embedded webserver.

A webpage served from the sliceKIT and accessed in a browser on a host PC has the following demo functions:
  • Turn GPIO Slice Card LEDS on and off
  • Read the room temperature via the on-board ADC and display on the web page
  • Display GPIO Slice Card button press status

Hardware Setup

The XP-SKC-L2 Slicekit Core board has four slots with edge connectors: SQUARE, CIRCLE, TRIANGLE and STAR.

To setup up the system refer to the figure and instructions below

  1. Connect the XA-SK-WIFI Slice Card to the XP-SKC-L2 Slicekit Core board using the connector marked with the TRIANGLE.
  2. Connect the XA-SK-GPIO Slice Card to the XP-SKC-L2 Slicekit Core board using the connector marked with the SQUARE.
  3. Connect the XTAG Adapter to Slicekit Core board, and connect XTAG-2 to the adapter.
  4. Connect the XTAG-2 to the host PC.
  5. Make sure your wireless access point is switched on and configured correctly.
  6. Switch on the power supply to the Slicekit Core board.
Hardware Setup for the GPIO and Wi-Fi Application Demo

/files/images/16452/5/hardware_setup.png

Import and Build the Application

  1. Open xTIMEcomposer and then open the edit perspective (Window->Open Perspective->XMOS Edit).
  2. Locate 'Slicekit GPIO Wi-Fi Demo' item in the xSOFTip Broswer window and drag it into the Project Explorer window in xTIMEcomposer. This will also cause the modules on which this application depends (in this case, module_wifi_tiwisl, module_spi_master, module_i2c_master, module_webserver) to be imported as well.
  3. Click on the Slicekit GPIO Wi-Fi Demo item in the Explorer pane then click on the build icon (hammer) in xTIMEcomposer. Check the console window to verify that the application has built successfully.

For help in using xTIMEcomposer, try the xTIMEcomposer tutorials, which you can find by selecting Help->Tutorials from the xTIMEcomposer menu.

Running the Demo

  1. Enable offline Xscope printing in the run configurations. Run Configuration -> XScope: Select Offline [Xscope] mode.
  2. Click on the Run icon (the white arrow in the green circle). A dialog will appear asking which device to connect to. Select XMOS XTAG2.
  3. xTIMEcomposer console displays the IP address obtained by the DHCP client
  4. Open a web browser on the host PC and type the IP address displayed on the xTIMEcomposer console into the browser’s address bar
  5. On hitting the return key, a web page should get loaded and displayed in the browser as shown in the figure below.
Screenshot of GPIO web page

/files/images/16452/5/gpio_web_page.png

Use the web page options to perform various actions such as
  1. Switch on all the LEDS by turning them all to ‘ON’ in the browser then clicking Submit. The LEDS should light, the ADC temperature display should be updated, and the webpage will report no buttons have been pressed.
  2. Switch off two of the LEDS by turning two to ‘OFF’ in the browser then clicking Submit. Two LEDS should go out and the ADC temperature is reported again. This time also webpage will report no buttons have been pressed.
  3. Press SW1 button on the GPIO slice card and then press submit. The web page should now report that Button 1 is pressed.
  4. Press SW2 button on the GPIO slice card and then press submit. The web page should now report that Button 2 is pressed.
  5. Just hitting Submit now displays both the buttons are not pressed. LEDs states remain unchanged unless they are explicitly changed on the web page.

Next Steps

Look at the Code

  1. Examine the application code. In xTIMEcomposer navigate to the src directory under app_sk_gpio_wifi_tiwisl_combo_demo and double click on the main.xc file within it. The file will open in the central editor window.
  2. The channel c_gpio is used between web page handler and application handler to send web page requests to the application and to collect GPIO status from the application.
  3. In the app_handler.xc file, API set_gpio_state is used by the web page in order to apply web page LED settings and similarly API get_gpio_state is used by web page to collect the current GPIO status containing LEDs, button presses and ADC temperature values.
  4. GPIO button scan logic monitors for value changes on the configured 4-bit button port (XS1_PORT_4C) in the application handler routine as defined in the app_handler.xc file. Whenever this port value changes, GPIO button states are updated accordingly.
  5. You can also observe that the ADC value is read whenever there is a web page request. This value is interpolated to get a proper temperature value and is updated in the GPIO state structure before sending it to the web page.

Building web pages for your applications

This application parses Wi-Fi data to interpret web page commands. Refer to Programming Guide section within the SliceKit GPIO Example Applications documentation linked from the front page documentation for this demo for more information on how to utilize the Embedded Webserver Function Library component in building your own custom web server applications.

Display Controller Demo Quickstart Guide

In this demonstration we use the following hardware and software:
  • XA-SK-SCR480 Slice Card,
  • XA-SK-SDRAM Slice Card,
  • module_sdram,
  • module_lcd,
  • module_display_controller,
  • module_slicekit_support,

together to create a double buffered LCD controller. This application showcases some of the key software features and serves as an example on how to use an LCD without the real-time contraint of having to update the LCD line buffer.

Hardware Setup

The XP-SKC-L2 Slicekit Core board has four slots with edge conectors: SQUARE, CIRCLE, TRIANGLE and STAR.

To setup up the system:

  1. Connect XA-SK-SDRAM Slice Card to the XP-SKC-L2 Slicekit Core board using the connector marked with the TRIANGLE.
  2. Connect XA-SK-SCR480 Slice Card to the XP-SKC-L2 Slicekit Core board using the connector marked with the STAR.
  3. Connect the XTAG Adapter to Slicekit Core board, and connect XTAG-2 to the adapter.
  4. Connect the XTAG-2 to host PC. Note that the USB cable is not provided with the Slicekit starter kit.
  5. Set the XMOS LINK on the to OFF on the XTAG Adapter(XA-SK-XTAG2).
  6. Ensure the jumper on the XA-SK-SCR480 is bridged if the back light is required.
  7. Switch on the power supply to the Slicekit Core board.
Hardware Setup for Simple GPIO Demo

/files/images/15954/1/hardware_setup.jpg

Import and Build the Application

  1. Open xTIMEcomposer and check that it is operating in online mode. Open the edit perspective (Window->Open Perspective->XMOS Edit).
  2. Locate the 'Display Controller Demo' item in the xSOFTip pane on the bottom left of the window and drag it into the Project Explorer window in the xTIMEcomposer. This will also cause the modules on which this application depends to be imported as well.
  3. Click on the app_display_controller_demo item in the Explorer pane then click on the build icon (hammer) in xTIMEcomposer. Check the console window to verify that the application has built successfully.

For help in using xTIMEcomposer, try the xTIMEcomposer tutorial. FIXME add link.

Note that the Developer Column in the xTIMEcomposer on the right hand side of your screen provides information on the xSOFTip components you are using. Select the module_display_controller component in the Project Explorer, and you will see its description together with API documentation. Having done this, click the back icon until you return to this quickstart guide within the Developer Column.

Run the Application

Now that the application has been compiled, the next step is to run it on the Slicekit Core Board using the tools to load the application over JTAG (via the XTAG2 and Xtag Adaptor card) into the xCORE multicore microcontroller.

  1. Click on the Run icon (the white arrow in the green circle).
  2. Wait until the images have loaded over the XTAG connector from the host.
  3. There should be a series of 6 images the transition from one to another.

Next Steps

  1. Trying changing the files that are loaded form the host. To do this, produce an image of 480 by 272 pixels, save it in tga format uncompressed in “top left” format (“bottom left” will also work but the image will have to be upside-down). Save the file(s) into the app_display_controller_demo directory within your workspace.
  2. Each transition has a frame count that depecits the speed of the transition, try adjusting them and observe the results.
  3. Try writing an exciting transition effect. To do this begin with the template shown below, and refer to the Display Controller API documentation at Configuration Defines
    :
::
static void transition_exciting_impl(chanend server, unsigned next_image_fb,

unsigned image_from, unsigned image_to, unsigned line) {
//insert code here

}
unsigned transition_exciting(chanend server, unsigned frame_buf[2],

unsigned from, unsigned to, unsigned frames, unsigned cur_fb_index) {
unsigned next_fb_index;
for (unsigned frame = 0; frame < frames; frame++) {

next_fb_index = (cur_fb_index + 1) & 1;
for (unsigned line = 0; line < LCD_HEIGHT; line++)

transition_exciting_impl(server, frame_buf[next_fb_index], from, to, line);

frame_buffer_commit(server, frame_buf[next_fb_index]);
cur_fb_index = next_fb_index;

}
return cur_fb_index;

}

Ethernet Slice Simple Webserver Application Quickstart

This simple demonstration of xTIMEcomposer Studio functionality uses
the sliceKIT Ethernet Slice together with the xSOFTip TCP/IP Ethernet
component to:

  • Run a TCP/IP stack on the xCORE
  • Run a very simple HTTP server to display a “hello world” webpage

Hardware setup

The sliceKIT Core Board has four slots with edge conectors: SQUARE, CIRCLE, TRIANGLE and STAR.

To setup up the system:

  1. Connect the Ethernet Slice Card to the sliceKIT Core Board using the connector marked with the CIRCLE.
  2. Connect the xTAG Adapter to sliceKIT Core Board and connect XTAG-2 to the adapter.
  3. Connect the xTAG-2 to host PC. Note that a USB cable is not provided with the sliceKIT starter kit.
  4. Plug the power supply into the sliceKIT Core Board and turn the
    power supply on.
Hardware Setup for Simple HTTP Demo

/files/images/15952/22/slicekit_eth_setup.jpg

Import and build the application

  1. On your PC, open xTIMEcomposer. You need to be in the
    edit perspective (Window->Open Perspective->XMOS Edit).
    If the XMOS Edit option isn’t in the list, you are
    already in the edit perspective.
  2. Locate the 'Simple HTTP Demo' item in the xSOFTip pane on the
    bottom left of the window and drag it into the Project Explorer
    window in the xTIMEcomposer. This will also cause the modules on
    which this application depends to be imported as well.
  3. Click on the app_simple_webserver item in the Explorer pane then
    click on the build icon (hammer) in xTIMEcomposer. Check the
    console window to verify that the application has built successfully.

For help in using xTIMEcomposer, try the xTIMEcomposer tutorials, which you can find by selecting Help->Tutorials from the xTIMEcomposer menu.

Note that the Developer Column in the xTIMEcomposer on the right hand
side of your screen provides information on the xSOFTip components you
are using. Select the module_xtcp component in the Project
Explorer, and you will see its description together with API
documentation (reached by double clicking on the Documentation
item within the project). If you view other documentation, you can get
back to this quickstart guide by cliking the back icon in the
Developer Column until you return to this quickstart guide.

Run the application

Now that the application has been compiled, the next step is to run it
on the sliceKIT Core Board using the tools to load the application
over JTAG (via the XTAG-2 and XTAG Adaptor Card)
into the xCORE multicore microcontroller.

  1. Click on the Run icon (the white arrow in the green
    circle). The debug console window in xTIMEcomposer should then
    display the message:

    **WELCOME TO THE SIMPLE WEBSERVER DEMO**
    

    This has been generated from the application code via a call to
    the printstr() function.

  2. Connect the sliceKIT Ethernet Slice your network via an ethernet
    cable. The application is configured by default to use DHCP to
    obtain an IP address. If you wish to change this to a static IP
    address edit the main.xc file in the application (you can
    reach this via the Project Explorer in the xTIMEcomposer) and
    change the ipconfig data structure.
  3. The console window should display a message like:
    IP Address: 192.168.0.4
    

    the actual IP address will depend on your local network.

  4. From a PC connected to the same network, open a web browser and
    open the link:

    http://192.168.0.4
    

    using the IP adress printed out by the application. This should
    display a “hello world” webpage. You have now got the ethernet
    slice up and running.

Troubleshooting

If the demo does not work try the following:

  • Ensure the Ethernet Slice Card is connected to the CIRCLE
    connector of the core board.
  • Ensure the slice network cable is fully connected. There are
    activity LEDs next to the ethernet connector that should
    illuminate if connected.
  • Ensure that both the PC and Ethernet Slice card are connected to the
    same network and can route to each other. If you are using a
    dynamically allocated address, make sure your DHCP server is
    configured correctly. If using a static address, make sure your PC
    is configured to talk to that address (in Windows you need to
    check your Network Adapter TCP/IP settings).

Next steps

Look at the Code

  1. Examine the application code. In xTIMEcomposer navigate to the src directory under app_simple_webserver and double click on the main.xc file within it. The file will open in the central editor window.
  2. Find the main function and note that it runs the
    ethernet_xtcp_server() (which runs the ethernet driver and tcp
    stack) and the xhttpd() function in parallel.
  3. Look at the xhttpd.xc and httpd.xc files. These
    implement the webserver logic that connects to the TCP/IP
    stack. In particular the httpd_handle_event function that
    responds to a TCP event over an xC channel and performs the
    functions of the webserver. See the TCP/IP programming guide for
    details on how the xtcp stack works.

Look at Other Examples

For a more complex embedded wbeserver demo that allows user interaction try the Slicekit GPIO and Ethernet Combo Demo demo application which can be found under sliceKIT->Demos categroy in the xSOFTip Explorer pane within xTIMEcomposer.

Go through this code in detail

This last section is optional and walks through the main application code in detail.

The toplevel main of this application sets up the different components
running on different logical cores on the device. It can be found in the
file main.xc.

First the TCP/IP server is run on the tile given by the define
ETHERNET_DEFAULT_TILE (supplied by the
ethernet_board_support.h header which gives defines for common
XMOS development boards.). It is run via the function
ethernet_xtcp_server()
. The server runs both the ethernet code to
communicate with the ethernet phy and the tcp server on two logical cores.

on ETHERNET_DEFAULT_TILE:
   ethernet_xtcp_server(xtcp_ports,
                        ipconfig,
                        c_xtcp,
                        1);



The client to the TCP/IP server is run as a separate task
and connected to the TCP/IP server via the first element c_xtcp
channel array. The function xhttpd implements the web server.

on tile[0]: xhttpd(c_xtcp[0]);


The webserver mainloop

The webserver is implemented in the xhttpd function in
xhttpd.xc. This function implements a simple loop that just
responds to events from the TCP/IP server. When an event occurs it is
passed onto the httpd_handle_event handler.

void xhttpd(chanend tcp_svr)
{
  xtcp_connection_t conn;
  printstrln("**WELCOME TO THE SIMPLE WEBSERVER DEMO**");
  // Initiate the HTTP state
  httpd_init(tcp_svr);

  // Loop forever processing TCP events
  while(1)
    {
      select
        {
        case xtcp_event(tcp_svr, conn):
          httpd_handle_event(tcp_svr, conn);
          break;
        }

    }
}


The webserver event handler

The event handler is implemented in httpd.c and contains the main
logic of the web server. The server can handle several connections at
once. However, events for each connection may be interleaved so the
handler needs to store separate state for each one. The
httpd_state_t structures holds this state:

typedef struct httpd_state_t {
  int active;      //< Whether this state structure is being used
                   //  for a connection
  int conn_id;     //< The connection id
  char *dptr;      //< Pointer to the remaining data to send
  int dlen;        //< The length of remaining data to send
  char *prev_dptr; //< Pointer to the previously sent item of data
} httpd_state_t;

httpd_state_t connection_states[NUM_HTTPD_CONNECTIONS];

The http_init function is called at the start of the
application. It initializes the connection state array and makes a
request to accept incoming new TCP connections on port 80 (using the
xtcp_listen()
function):

void httpd_init(chanend tcp_svr)
{
  int i;
  // Listen on the http port
  xtcp_listen(tcp_svr, 80, XTCP_PROTOCOL_TCP);

  for ( i = 0; i < NUM_HTTPD_CONNECTIONS; i++ )
    {
      connection_states[i].active = 0;
      connection_states[i].dptr = NULL;
    }
}

When an event occurs the httpd_handle_event function is
called. The behaviour of this function depends on the event
type. Firstly, link status events are ignored:

void httpd_handle_event(chanend tcp_svr, xtcp_connection_t *conn)
{
  // We have received an event from the TCP stack, so respond
  // appropriately

  // Ignore events that are not directly relevant to http
  switch (conn->event)
    {
    case XTCP_IFUP: {
      xtcp_ipconfig_t ipconfig;
      xtcp_get_ipconfig(tcp_svr, &ipconfig);

#if IPV6
      unsigned short a;
      unsigned int i;
      int f;
      xtcp_ipaddr_t *addr = &ipconfig.ipaddr;
      printstr("IPV6 Address = [");
      for(i = 0, f = 0; i < sizeof(xtcp_ipaddr_t); i += 2) {
        a = (addr->u8[i] << 8) + addr->u8[i + 1];
        if(a == 0 && f >= 0) {
          if(f++ == 0) {
            printstr("::");
           }
        } else {
            if(f > 0) {
              f = -1;
            } else if(i > 0) {
                printstr(":");
            }
          printhex(a);
        }
      }
      printstrln("]");
#else
      printstr("IP Address: ");
      printint(ipconfig.ipaddr[0]);printstr(".");
      printint(ipconfig.ipaddr[1]);printstr(".");
      printint(ipconfig.ipaddr[2]);printstr(".");
      printint(ipconfig.ipaddr[3]);printstr("\n");
#endif
      }
      return;
    case XTCP_IFDOWN:
    case XTCP_ALREADY_HANDLED:
      return;
    default:
      break;
    }


For other events, we first check that the connection is definitely an
http connection (is directed at port 80) and then call one of several
event handlers for each type of event. The is a separate function for
new connections, receiving data, sending data and closing connections:

  if (conn->local_port == 80) {
    switch (conn->event)
      {
      case XTCP_NEW_CONNECTION:
        httpd_init_state(tcp_svr, conn);
        break;
      case XTCP_RECV_DATA:
        httpd_recv(tcp_svr, conn);
        break;
      case XTCP_SENT_DATA:
      case XTCP_REQUEST_DATA:
      case XTCP_RESEND_DATA:
          httpd_send(tcp_svr, conn);
          break;
      case XTCP_TIMED_OUT:
      case XTCP_ABORTED:
      case XTCP_CLOSED:
          httpd_free_state(conn);
          break;
      default:
        // Ignore anything else
        break;
      }
    conn->event = XTCP_ALREADY_HANDLED;
  }

The following sections describe the four handler functions.

Handling Connections

When a XTCP_NEW_CONNECTION event occurs we need to
associate some state with the connection. So the connection_states
array is searched for a free state structure.

void httpd_init_state(chanend tcp_svr, xtcp_connection_t *conn)
{
  int i;

  // Try and find an empty connection slot
  for (i=0;i<NUM_HTTPD_CONNECTIONS;i++)
    {
      if (!connection_states[i].active)
        break;
    }


If we don’t find a free state we cannot handle the connection so
xtcp_abort`() is called to abort the connection.

  if ( i == NUM_HTTPD_CONNECTIONS )
    {
      xtcp_abort(tcp_svr, conn);
    }

If we can allocate the state structure then the elements of the
structure are initialized. The function
xtcp_set_connection_appstate()
is then called to associate the
state with the connection. This means when a subsequent event is
signalled on this connection the state can be recovered.

  else
    {
      connection_states[i].active = 1;
      connection_states[i].conn_id = conn->id;
      connection_states[i].dptr = NULL;
      xtcp_set_connection_appstate(
           tcp_svr,
           conn,
           (xtcp_appstate_t) &connection_states[i]);

When a XTCP_TIMED_OUT, XTCP_ABORTED or
XTCP_CLOSED event is received then the state associated
with the connection can be freed up. This is done in the
httpd_free_state function:

void httpd_free_state(xtcp_connection_t *conn)
{
  int i;

  for ( i = 0; i < NUM_HTTPD_CONNECTIONS; i++ )
    {
      if (connection_states[i].conn_id == conn->id)
        {
          connection_states[i].active = 0;
        }
    }
}

Receiving Data

When an XTCP_RECV_DATA event occurs the httpd_recv
function is called. The first thing this function does is call the
xtcp_recv()
function to place the received data in the
data array. (Note that all TCP/IP clients must call
xtcp_recv()
directly after receiving this kind of event).

void httpd_recv(chanend tcp_svr, xtcp_connection_t *conn)
{
  struct httpd_state_t *hs = (struct httpd_state_t *) conn->appstate;
  char data[XTCP_CLIENT_BUF_SIZE];
  int len;

  // Receive the data from the TCP stack
  len = xtcp_recv(tcp_svr, data);


The hs variable points to the connection state. This was recovered
from the appstate member of the connection structure which
was previously associated with application state when the connection
was set up. As a safety check we only proceed if this state has been
set up and the hs variable is non-null.

  if ( hs == NULL || hs->dptr != NULL)
    {
      return;
    }


Now the connection state is known and the
incoming data buffer filled. To keep things simple, this server makes
the assumption that a single tcp packet gives us enough information to
parse the http request. However, many applications will need to
concatenate each tcp packet to a different buffer and handle data after
several tcp packets have come in. The next step in the code is to call
the parse_http_request function:

  parse_http_request(hs, &data[0], len);


This function examines the incoming packet and checks if it is a
GET request. If so, then it always serves the same page. We signal
that a page is ready to the callee by setting the data pointer
(dptr) and data length (dlen) members of the connection state.

void parse_http_request(httpd_state_t *hs, char *data, int len)
{
  // Return if we have data already
  if (hs->dptr != NULL)
    {
      return;
    }

  // Test if we received a HTTP GET request
  if (strncmp(data, "GET ", 4) == 0)
    {
      // Assign the default page character array as the data to send
      hs->dptr = &page[0];
      hs->dlen = strlen(&page[0]);
    }
  else
    {
      // We did not receive a get request, so do nothing
    }
}

The final part of the receive handler checks if the
parse_http_request function set the dptr data pointer. If so,
then it signals to the tcp/ip server that we wish to send some data on
this connection. The actual sending of data is handled when an
XTCP_REQUEST_DATA event is signalled by the tcp/ip server.

  if (hs->dptr != NULL)
    {
      // Initate a send request with the TCP stack.
      // It will then reply with event XTCP_REQUEST_DATA
      // when it's ready to send
      xtcp_init_send(tcp_svr, conn);
    }

Sending Data

To send data the connection state keeps track of three variables:

Name

Description

dptr

A pointer to the next piece of data to send

dlen

The amount of data left to send

prev_dptr

The previous value of dptr before the last send

We keep the previous value of dptr in case the tcp/ip server asks
for a resend.

On receiving an XTCP_REQUEST_DATA,
XTCP_SENT_DATA or XTCP_RESEND_DATA event the
function httpd_send is called.

The first thing the function does is check whether we have been asked
to resend data. In this case it sends the previous amount of data
using the prev_dptr pointer.

  if (conn->event == XTCP_RESEND_DATA) {
    xtcp_send(tcp_svr, hs->prev_dptr, (hs->dptr - hs->prev_dptr));
    return;
  }


If the request is for the next piece of data, then the function first
checks that we have data left to send. If not, the function
xtcp_complete_send()
is called to finish the send transaction
and then the connection is closed down with xtcp_close()

(since HTTP only does one transfer per connection).

  if (hs->dlen == 0 || hs->dptr == NULL)
    {
      // Terminates the send process
      xtcp_complete_send(tcp_svr);
      // Close the connection
      xtcp_close(tcp_svr, conn);
    }

If we have data to send, then first the amount of data to send is
calculated. This is based on the amount of data we have left
(hs->dlen) and the maximum we can send (conn->mss). Having
calculated this length, the data is sent using the xtcp_send()

function.

Once the data is sent, all that is left to do is update the dptr,
dlen and prev_dptr variables in the connection state.

  else {
    int len = hs->dlen;

    if (len > conn->mss)
      len = conn->mss;

    xtcp_send(tcp_svr, hs->dptr, len);

    hs->prev_dptr = hs->dptr;
    hs->dptr += len;
    hs->dlen -= len;
  }

Display Controller Component

The display controller component is used to drive a single graphics LCD screen up to 800 * 600 pixels incorporating a managed double buffer.

Features

  • Non-blocking SDRAM management.
  • Real time servicing of the LCD.
  • Touch interactive display
  • Image memory manager to simplify handling of images.
  • No real time constraints on the application.

Memory requirements

Resource

Usage

Stack

6198 bytes

Program

11306 bytes

Resource requirements

Resource

Usage

Channels

3

Timers

0

Clocks

0

Threads

1

Performance

The achievable effective bandwidth varies according to the avaliable XCore MIPS. The maximum pixel clock supported is 25MHz.

Slicekit

This module may be evaluated using the Slicekit Modular Development Platform, available from digikey. Required board SKUs are:

  • XP-SKC-L2 (Slicekit L2 Core Board)
  • XA-SK-SCR480 plus XA-SK-XTAG2 (Slicekit XTAG adaptor)

Demonstration Applications

Display Controller Application

  • Package: sw_display_controller
  • Application: app_display_controller

This combination demo employs the module_lcd along with the module_sdram, module_touch_controller_lib, module_i2c_master and the module_display_controller framebuffer framework component to implement a 480×272 display controller.

Required board SKUs for this demo are:

  • XP-SKC-L2 (Slicekit L2 Core Board) plus XA-SK-XTAG2 (Slicekit XTAG adaptor)
  • XA-SK-SDRAM
  • XA-SK-SCR480 (which includes a 480×272 color touch screen)

To build a project including the module_display_controller the following components are required:
  • component: sc_sdram_burst which handles the SDRAM
  • component: sc_lcd which handles the LCD

The below section details the APIs in the application. For details about the LCD and SDRAM APIs please refer to the respective repositories.

Configuration Defines

The module_display_controller can be configured via the header display_controller_conf.h. The module requires nothing to be additionally defined however any of the defines can be overridden by adding the header display_controller_conf.h to the application project and adding the define that needs overridding. The possible defines are:

DISPLAY_CONTROLLER_MAX_IMAGES

This defines the storage space allocated to the display controller for it to store image metadata. When an image is registered with the display controller its dimensions and location in SDRAM address space are stored in a table. The define specifies how many entries are allowed in that table. Note, there is no overflow checking by default.

DISPLAY_CONTROLLER_VERBOSE

This define switches on the error checking for memory overflows and causes verbose error warnings to be emitted in the event of an error.

API

The“module_display_controller“ functionality is defined in
  • display_controller_client.xc
  • display_controller_internal.h
  • display_controller.xc
  • display_controller.h
  • transitions.h
  • transitions.xc

The display controller handles the double buffering of the image data to the LCD as a real time service and manages the I/O to the SDRAM as a non-real time service.

The display controller API is as follows:
.. doxygenfunction:: display_controller
.. doxygenfunction:: image_read_line
.. doxygenfunction:: image_read_line_p
.. doxygenfunction:: image_write_line
.. doxygenfunction:: image_write_line_p
.. doxygenfunction:: image_read_partial_line
.. doxygenfunction:: image_read_partial_line_p
.. doxygenfunction:: register_image
.. doxygenfunction:: wait_until_idle
.. doxygenfunction:: wait_until_idle_p
.. doxygenfunction:: frame_buffer_commit
.. doxygenfunction:: frame_buffer_init

The transition API is as follows:
.. doxygenfunction:: transition_wipe
.. doxygenfunction:: transition_slide
.. doxygenfunction:: transition_roll
.. doxygenfunction:: transition_dither
.. doxygenfunction:: transition_alpha_blend

The transitions use the display controller API.

Source code structure

Project structure

Project

File

Description

module_display_controller

display_controller.h

Header file containing the APIs for the display controller component.

 

display_controller.xc

File containing the implementation of the display controller component.

 

display_controller_client.xc

File containing the implementation of the display controller client functions.

 

display_controller_internal.h

Header file containing the user configurable defines for the display controller component.

 

transitions.h

Header file containing the APIs for the display controller transitions.

 

transitions.xc

File containing the implementation of the display controller transitions.

Executing The Project

The module by itself cannot be built or executed separately – it must be linked in to an application. Once the module is linked to the application, the application can be built and tested for driving a LCD screen.

The following should be done in order to link the component to the application project
  1. The module name module_display_controller should be added to the list of MODULES in the application project build options.
  2. The module name module_lcd should be added to the list of MODULES in the application project build options.
  3. The module name module_sdram should be added to the list of MODULES in the application project build options.
  4. The module name module_touch_controller_lib should be added to the list of MODULES in the application project build options.
  5. The module name module_i2c_master should be added to the list of MODULES in the application project build options.
  6. Now the module is linked to the application and can be used directly

Software Requirements

The module is built on XDE Tool version 12.0
The module can be used in version 12.0 or any higher version of xTIMEcomposer.

This tutorial describes the demo applications included in the XMOS Display Controller software component. Recommended Hardware
describes the required hardware setup to run the demos.

app_display_controller_demo

This application demonstrates how the lcd_module is used to write image data to the LCD screen whilst imposing no real time constraints on the application. The purpose of this demonstration is to show how data is passed to the display_controller. This application also demonstrates an interactive display using touch_controller module.

Application Notes

Getting Started

  1. Plug the XA-SK-LCD Slice Card into the ‘TRIANGLE’ slot of the Slicekit Core Board
  2. Plug the XA-SK-SDRAM Slice Card into the ‘STAR’ slot of the Slicekit Core Board
  3. Open app_display_controller_demo.xc and build the project.
  4. run the program ensuring that it is run from the project directory where the tga images are.

The output produced should look like a series of images transitioning on the LCD when the screen is touched.

LCD Demo Quickstart Guide

This simple demonstration of xTIMEcomposer Studio functionality uses the XA-SK-SCR480 Slice Card together with the xSOFTip module_lcd to demonstrate how the module is used to write to an LCD screen.

Hardware Setup

The XP-SKC-L2 Slicekit Core board has four slots with edge conectors: SQUARE, CIRCLE, TRIANGLE and STAR.

To setup up the system:

  1. Connect XA-SK-SCR480 Slice Card to the XP-SKC-L2 Slicekit Core board using the connector marked with the STAR.
  2. Connect the XTAG Adapter to Slicekit Core board, and connect XTAG-2 to the adapter.
  3. Connect the XTAG-2 to host PC. Note that the USB cable is not provided with the Slicekit starter kit.
  4. Set the XMOS LINK to OFF on the XTAG Adapter.
  5. Ensure the jumper on the XA-SK-SCR480 is bridged if the back light is required.
  6. Switch on the power supply to the Slicekit Core board.
Hardware Setup for LCD Demo

/files/images/15937/2/hardware_setup.jpg

Import and Build the Application

  1. Open xTIMEcomposer and check that it is operating in online mode. Open the edit perspective (Window->Open Perspective->XMOS Edit).
  2. Locate the 'Slicekit LCD Demo' item in the xSOFTip pane on the bottom left of the window and drag it into the Project Explorer window in the xTIMEcomposer. This will also cause the modules on which this application depends (in this case, module_lcd) to be imported as well.
  3. Click on the app_lcd_demo item in the Explorer pane then click on the build icon (hammer) in xTIMEcomposer. Check the console window to verify that the application has built successfully.

For help in using xTIMEcomposer, try the xTIMEcomposer tutorial. FIXME add link.

Note that the Developer Column in the xTIMEcomposer on the right hand side of your screen provides information on the xSOFTip components you are using. Select the module_lcd component in the Project Explorer, and you will see its description together with API documentation. Having done this, click the back icon until you return to this quickstart guide within the Developer Column.

Run the Application

Now that the application has been compiled, the next step is to run it on the Slicekit Core Board using the tools to load the application over JTAG (via the XTAG2 and Xtag Adaptor card) into the xCORE multicore microcontroller.

  1. Click on the Run icon (the white arrow in the green circle). The output produced should look like a bouncing “X” on the LCD screen.

Next Steps

  1. Trying changing the int x=20, y=0, vx=1, vy=2; variables, they represent: initial x coord, initial y coord, x velocity and y velocity respectivly.
  2. In the sub() function what would you expect to see if the line: buffer[i] = BACK_COLOUR; was changed to buffer[i] = 0x12345678;?

Look at the Code

  1. Examine the application code. In xTIMEcomposer navigate to the src directory under app_sdram_demo and double click on the app_sdram_demo.xc file within it. The file will open in the central editor window.
  2. Find the main function and note that it runs the demo() function on a single logical core.

Try the Full Display Controller Demo

These applications are necessarily limited since there is no external memory available for a proper framebuffer, and the internal memory of an XCore Tile is too small to buffer a full screen colour image. The Display Controller demo combines the functionality of this LCD module with the SDRAM Controller component and SDRAM Slice Card to implement a fully functioning LCD Display Controller by adding the memory controller and a component that takes care of framebuffer management.

Once you have both the XA-SK-SDRAM< and XA-SK-SCR480 slices you can try the Display Controller demo by

???

LCD component

LCD component

The LCD component is used to drive a single graphics LCD module up to 800 * 600 pixels with pixel clocks of up to 25MHz.

Features

  • Standard component to support different LCD displays with an RGB interface.
  • Different color depths 32 bpp, 16 bpp, etc. based on user configuration.
  • Resolution of up to 800 * 600 pixels.
  • Outputs to a CMOS interface.
  • Configurability of
    * LCD pixel dimensions,
    * clock rate,
    * horizontal and vertical timing requirements,
    * port mapping of the LCD.
  • Requires a single core for the server.
    * The function lcd_server requires just one core, the client functions, located in lcd.h are very low overhead and are called from the application.

Memory requirements

Resource

Usage

Stack

92 bytes

Program

2168 bytes

Resource requirements

Resource

Usage

Channels

1

Timers

0

Clocks

1

Logical Cores

1

Performance

The achievable effective bandwidth varies according to the available xCORE MIPS. The maximum pixel clock supported is 25MHz.

Touch screen component

The touch screen component is used to read the touch coordinates from the touch screen controller AD7879-1.

Features

  • Standard components to support touch screen controller with I2C serial interface
  • Supports 4-wire resistive touch screens of different sizes
  • Resolution of 4096 * 4096 points
  • Pen-down interrupt signal supported
  • Outputs touch coordinates
  • module_touch_controller_lib requires a single core while module_touch_controller_server requires an additional core for the server.

Memory requirements

app_touch_controller_lib_demo

Resource

Usage

Stack

304 bytes

Program

3160 bytes

app_touch_controller_server_demo

Resource

Usage

Stack

420 bytes

Program

3576 bytes

Resource requirements

app_touch_controller_lib_demo

Resource

Usage

Channels

0

Timers

3

Clocks

1

Logical Cores

1

app_touch_controller_server_demo

Resource

Usage

Channels

1

Timers

3

Clocks

1

Logical Cores

2

sliceKIT

This module may be evaluated using the sliceKIT Modular Development Platform, available from digikey. Required board SKUs are:

  • XP-SKC-L2 (sliceKIT L16 Core Board) plus XA-SK-SCR480 plus XA-SK-XTAG2 (sliceKIT XTAG adaptor)

Demonstration applications

LCD Demo Application

The LCD demo application shows how a buffer of image data can be written to the 480×272 LCD screen that is supplied with the XA-SK-SCR480 Slice Card.

  • Package: sc_lcd
  • Application: app_lcd_demo

Touch screen demo application

The touch screen demo application shows how a touch event is processed and the touch coordinates are fetched from the touch screen controller chip fitted on the XA-SK-SCR480 Slice Card.

  • Package: sc_lcd
  • Applications: app_touch_controller_lib_demo

Display controller application

This combination demo employs the module_lcd along with the module_sdram and the module_display_controller framebuffer framework component to implement a 480×272 display controller.

Required board SKUs for this demo are:

  • XP-SKC-L2 (sliceKIT L16 Core Board) plus XA-SK-XTAG2 (sliceKIT XTAG adaptor)
  • XA-SK-SCR480 for the LCD
  • XA-SK-SDRAM for the SDRAM
  • Package: sw_display_controller
  • Application: app_display_controller

The component sc_lcd includes the modules module_lcd, module_text_display and module_touch_controller_lib.

module_lcd

Configuration defines

The module_lcd includes device support defines, each support header, located in the devices directory defines a number of parameters. It is sufficient for the user to specify which device to support in the lcd_conf.h for the device to be correctly supported. To do this lcd_conf.h must include the define:
::
#define LCD_PART_NUMBER p

where p is the part the user requires support for. lcd_conf.h must be located in the application project and not the module. Currently, support is provided for:
  • AT043TN24V7
  • K430WQAV4F
  • K70DWN0V1F

Implementation specific defines

It is possible to override the default defines when a part number is selected. The defines available are:

LCD_WIDTH

This define is used to represent the width of the LCD panel in pixels.

LCD_HEIGHT

This define is used to represent the height of the LCD panel in pixels.

LCD_BITS_PER_PIXEL

Count of bits used to set a pixels RGB value, i.e. if the screen was wired for rgb565 then the LCD_BITS_PER_PIXEL would be 16, rgb888 would be 24. This is independant of the actual bit depth of the lcd.

LCD_HOR_FRONT_PORCH

The horizontal front porch timing requirement given in pixel clocks.

LCD_HOR_BACK_PORCH

The horizontal back porch timing requirement given in pixel clocks.

LCD_VERT_FRONT_PORCH

The vertical front porch timing requirement given in horizontal time periods.

LCD_VERT_BACK_PORCH

The vertical back porch timing requirement given in horizontal time periods.

LCD_HOR_PULSE_WIDTH

The horizontal pulse width timing requirement given in pixel clocks. This is the duration that the hsync signal should go low to denote the start of the horizontal frame. Set to 0 when hsync is not necessary.

LCD_VERT_PULSE_WIDTH

The vertical pulse width timing requirement given in vertical time periods. This is the duration that the vsync signal should go low to denote the start of the vertical frame. Set to 0 when vsync is not necessary.

LCD_FREQ_DIVIDEND

The defines FREQ_DIVIDEND and FREQ_DIVISOR are used to calculate the frequency of the clock used for LCD. The frequency configured = (FREQ_DIVIDEND / FREQ_DIVISOR) in MHz

LCD_FREQ_DIVISOR

The defines FREQ_DIVIDEND and FREQ_DIVISOR are used to calculate the frequency of the clock used for LCD. The frequency configured = (FREQ_DIVIDEND / FREQ_DIVISOR) in MHz

LCD_FAST_WRITE

The define enables a faster LCD write function, however, it produces more code. Use when a 25MHz pixel clock is required. It cannot be used with LCD_HOR_PULSE_WIDTH > 0 or LCD_VERT_PULSE_WIDTH > 0 as horizontal and veritcal sync signals are not supported in LCD_FAST_WRITE mode.

API

The LCD display module functionality is defined in
  • lcd.xc
  • lcd.h
  • lcd_defines.h
  • lcd_assembly.S
  • /devices

where the following functions can be found:

  • void lcd_init(chanend c_lcd)

    LCD init function.

    This sets the lcd into a state where it is ready to accept data.

    Parameters

    • c_lcd

      The channel end connecting to the lcd server.

  • static void lcd_req(chanend c_lcd)

    Receives the request for data from the LCD server.

    Parameters

    • c_lcd

      The channel end connecting to the lcd server.

  • static void lcd_update(chanend c_lcd, unsigned buffer[])

    LCD update function.

    This sends a buffer of data to the lcd server to to sent to the lcd.

    Note, no array bounds checking is performed.

    Parameters

    • c_lcd

      The channel end connecting to the lcd server.

    • buffer[]

      The data to be emitted to the lcd screen, stored in rgb565.

  • static void lcd_update_p(chanend c_lcd, unsigned buffer)

    C interface for LCD update function.

    This sends a buffer of data to the lcd server to to sent to the lcd.

    Note, no array bounds checking is performed.

    Parameters

    • c_lcd

      The channel end connecting to the lcd server.

    • buffer

      A pointer to data to be emitted to the lcd screen, stored in rgb565.

  • void lcd_server(chanend c_client, lcd_ports &ports)

    The LCD server thread.

    Parameters

    • c_client

      The channel end connecting to the client.

    • ports

      The structure carrying the LCD port details.

module_touch_controller_lib

The device-specific configuration defines and user defines are listed in touch_lib_conf.h.

Configuration defines

TOUCH_LIB_LCD_WIDTH

This define is used to represent the width of the LCD panel in pixels.

TOUCH_LIB_LCD_HEIGHT

This define is used to represent the height of the LCD panel in pixels.

TOUCH_LIB_TS_WIDTH

This define is used to represent the width of the touch screen in points.

TOUCH_LIB_TS_HEIGHT

This define is used to represent the height of the touch screen in points.

API

The touch screen module functionality is defined in
  • touch_controller_lib.xc
  • touch_controller_lib.h
  • /AD7879-1

where the following functions can be found:

  • void touch_lib_init(touch_controller_ports &ports)

    The touch controller initialisation.

    Parameters

    • ports

      The structure containing the touch controller port details.

  • void touch_lib_get_touch_coords(touch_controller_ports &ports, unsigned &x, unsigned &y)

    Get the current touch coordinates from the touch controller.

    The returned coordinates are not scaled.

    Parameters

    • ports

      The structure containing the touch controller port details.

    • x

      The X coordinate of point of touch.

    • y

      The Y coordinate of point of touch.

  • select touch_lib_touch_event(touch_controller_ports &ports)

    A select function that will wait until the touch controller reports a touch event.

    Parameters

    • ports

      The structure containing the touch controller port details.

  • void touch_lib_get_next_coord(touch_controller_ports &ports, unsigned &x, unsigned &y)

    This function will block until the controller reports a touch event at which point it will return the coordinates of that event.

    The coordinates are not scaled.

    Parameters

    • ports

      The structure containing the touch controller port details.

    • x

      The X coordinate of point of touch.

    • y

      The Y coordinate of point of touch.

  • void touch_lib_scale_coords(unsigned &x, unsigned &y)

    The function to scale coordinate values (from the touch point coordinates to the LCD pixel coordinates).

    Parameters

    • x

      The scaled X coordinate value

    • y

      The scaled Y coordinate value

This section provides information on how to program applications using the LCD module.

Source code structure

Project structure

Project

File

Description

module_lcd

lcd.h

Header file containing the APIs for the LCD component

 

lcd.xc

File containing the implementation of the LCD component

 

lcd_defines.xc

Header file containing the user configurable defines for the LCD

 

lcd_assembly.S

Assembly file containing the fast_write functionality for the LCD.

 

/devices

Folder containing header files of configurations for LCDs

Additional files

Additional files

File name

Description

generate.pl

Perl file for generating a fast write function body for LCD screens of arbitrary width.

How to select the LCD target

The module has been designed to support multiple LCD targets. Each target has a specific configuration and have been provided
with the component int the /devices directory. The module only supports a single LCD target per xCORE.

To select the target the following should be done:

If the required target is the part AT043TN24V7 LCD display then,
  • Create a header in the application project called lcd_conf.h
  • In the lcd_conf.h add the define #define LCD_PART_NUMBER AT043TN24V7. This will include the “lcd_defines_AT043TN24V7.h” required for the selected target.
  • Any specific overrides should be added to the lcd_conf.h. For example, to override the LCD_HEIGHT to 600 pixels add the line #define LCD_HEIGHT 600.
  • The application should also include the port mapping for the LCD as per the hardware used. A variable of the type structure lcd_ports should be created and must include the port information

Example:
In the application file

struct lcd_ports lcd_ports = {
        XS1_PORT_1G,
        XS1_PORT_1F,
        XS1_PORT_16A,
        XS1_PORT_1B,
        XS1_PORT_1C,
        XS1_CLKBLK_1
};

The declared variable lcd_ports is used by the LCD server call to address these ports. A core should have the lcd_server running on it and it should be connected by a channel to the application, for example:

chan c_lcd;
par {
      lcd_server(c_lcd, lcd_ports);
      application(c_lcd);
}

Executing the project

The module by itself cannot be built or executed separately. It must be linked in to an application which needs LCD display. Once the module is linked to the application, the application can be built and tested for driving a LCD screen.

The following should be done in order to link the component to the application project
  1. The module name module_lcd should be added to the list of MODULES in the application project build options.
  2. Now the module is linked to the application and can be directly used

Software requirements

The module is built on XDE Tool version 12.0
The module can be used in version 12.0 or any higher version of xTIMEcomposer.

This section provides information on how to program applications using the touch controller module.

Source code structure

Project structure

Project

File

Description

module_touch_controller_lib

touch_controller_lib.h

Header file containing the APIs for interfacing touch controller component

 

touch_controller_lib.xc

File containing the implementation of APIs

 

/AD7879-1

Folder containing files for the implementation of touch controller component

 

touch_controller_impl.h

Header file containing the APIs for implementing touch controller component

 

touch_controller_impl.xc

File containing the implementation of touch controller component

module_touch_controller_server

touch_controller_server.h

Header file containing the APIs for interfacing touch controller component

 

touch_controller_server.xc

File containing the implementation of APIs

 

/AD7879-1

Folder containing files for the implementation of touch controller component

 

touch_controller_impl.h

Header file containing the APIs for implementing touch controller component

 

touch_controller_impl.xc

File containing the implementation of touch controller component

How to develop an application

The modules have been designed to support two types of interfacing with the touch screen controller; one for direct interfacing and the other for interfacing through a server. Only one of these two modules should be used by the application program.

To use a module,
  • Create a header file in the application project called touch_lib_conf.h or touch_server_conf.h.
  • In the header file, add the defines for conditional compilation and device-specific parameters.
  • The application should also include the port mapping for the touch screen controller. A variable of the type structure touch_controller_ports should be created and must include the port information.

Example:
In the application file

struct touch_controller_ports ports = {
        XS1_PORT_1E,
        XS1_PORT_1H,
        1000,
        XS1_PORT_1D
};

When module_touch_controller_server is used, a core should have the touch_controller_server running on it and it should be connected by a channel to the application, for example:

chan c;
par {
      touch_controller_server(c, ports);
      app(c);
}

Executing the project

The touch controller module by itself cannot be built or executed separately. It must be linked into an application. The application also depends on I2C module. Once the modules are linked to the application, the application can be built and run.

The following should be done in order to link the modules to the application project.
  1. The module name module_touch_controller_lib or module_touch_controller_server should be added to the list of MODULES in the application project build options.
  2. The module name module_i2c_master should also be added.
  3. Now the modules are linked to the application and can be directly used

Software requirements

The modules are built on XDE Tool version 12.0
The modules can be used in version 12.0 or any higher version of xTIMEcomposer.

This section provides information on how to program applications using the LCD module.

Source code structure

Project structure

Project

File

Description

module_lcd

lcd.h

Header file containing the APIs for the LCD component

 

lcd.xc

File containing the implementation of the LCD component

 

lcd_defines.xc

Header file containing the user configurable defines for the LCD

 

lcd_assembly.S

Assembly file containing the fast_write functionality for the LCD.

 

/devices

Folder containing header files of configurations for LCDs

Additional files

Additional files

File name

Description

generate.pl

Perl file for generating a fast write function body for LCD screens of arbitrary width.

How to select the LCD target

The module has been designed to support multiple LCD targets. Each target has a specific configuration and have been provided
with the component int the /devices directory. The module only supports a single LCD target per xCORE.

To select the target the following should be done:

If the required target is the part AT043TN24V7 LCD display then,
  • Create a header in the application project called lcd_conf.h
  • In the lcd_conf.h add the define #define LCD_PART_NUMBER AT043TN24V7. This will include the “lcd_defines_AT043TN24V7.h” required for the selected target.
  • Any specific overrides should be added to the lcd_conf.h. For example, to override the LCD_HEIGHT to 600 pixels add the line #define LCD_HEIGHT 600.
  • The application should also include the port mapping for the LCD as per the hardware used. A variable of the type structure lcd_ports should be created and must include the port information

Example:
In the application file

struct lcd_ports lcd_ports = {
        XS1_PORT_1G,
        XS1_PORT_1F,
        XS1_PORT_16A,
        XS1_PORT_1B,
        XS1_PORT_1C,
        XS1_CLKBLK_1
};

The declared variable lcd_ports is used by the LCD server call to address these ports. A core should have the lcd_server running on it and it should be connected by a channel to the application, for example:

chan c_lcd;
par {
      lcd_server(c_lcd, lcd_ports);
      application(c_lcd);
}

Executing the project

The module by itself cannot be built or executed separately. It must be linked in to an application which needs LCD display. Once the module is linked to the application, the application can be built and tested for driving a LCD screen.

The following should be done in order to link the component to the application project
  1. The module name module_lcd should be added to the list of MODULES in the application project build options.
  2. Now the module is linked to the application and can be directly used

Software requirements

The module is built on XDE Tool version 12.0
The module can be used in version 12.0 or any higher version of xTIMEcomposer.

This section provides information on how to program applications using the touch controller module.

Source code structure

Project structure

Project

File

Description

module_touch_controller_lib

touch_controller_lib.h

Header file containing the APIs for interfacing touch controller component

 

touch_controller_lib.xc

File containing the implementation of APIs

 

/AD7879-1

Folder containing files for the implementation of touch controller component

 

touch_controller_impl.h

Header file containing the APIs for implementing touch controller component

 

touch_controller_impl.xc

File containing the implementation of touch controller component

module_touch_controller_server

touch_controller_server.h

Header file containing the APIs for interfacing touch controller component

 

touch_controller_server.xc

File containing the implementation of APIs

 

/AD7879-1

Folder containing files for the implementation of touch controller component

 

touch_controller_impl.h

Header file containing the APIs for implementing touch controller component

 

touch_controller_impl.xc

File containing the implementation of touch controller component

How to develop an application

The modules have been designed to support two types of interfacing with the touch screen controller; one for direct interfacing and the other for interfacing through a server. Only one of these two modules should be used by the application program.

To use a module,
  • Create a header file in the application project called touch_lib_conf.h or touch_server_conf.h.
  • In the header file, add the defines for conditional compilation and device-specific parameters.
  • The application should also include the port mapping for the touch screen controller. A variable of the type structure touch_controller_ports should be created and must include the port information.

Example:
In the application file

struct touch_controller_ports ports = {
        XS1_PORT_1E,
        XS1_PORT_1H,
        1000,
        XS1_PORT_1D
};

When module_touch_controller_server is used, a core should have the touch_controller_server running on it and it should be connected by a channel to the application, for example:

chan c;
par {
      touch_controller_server(c, ports);
      app(c);
}

Executing the project

The touch controller module by itself cannot be built or executed separately. It must be linked into an application. The application also depends on I2C module. Once the modules are linked to the application, the application can be built and run.

The following should be done in order to link the modules to the application project.
  1. The module name module_touch_controller_lib or module_touch_controller_server should be added to the list of MODULES in the application project build options.
  2. The module name module_i2c_master should also be added.
  3. Now the modules are linked to the application and can be directly used

Software requirements

The modules are built on XDE Tool version 12.0
The modules can be used in version 12.0 or any higher version of xTIMEcomposer.

This tutorial describes the demo applications included in the XMOS LCD software component.
Recommended Hardware
describes the required hardware setups to run the demos.

app_lcd_demo

This application demonstrates how the module is used to write image data to the LCD screen. The purpose of this application is to show how data is passed to the lcd_server

Application notes

  1. lcd_server requires a single logical core.
  2. lcd_init must be called before lcd_update_p or lcd_update are called. This puts the LCD server into a state ready to accept data.
  3. lcd_update and lcd_update_p are used to send an array of pixel data to the LCD server. There is a real-time requirement that this function is called often enough to maintain the display. lcd_update_p is the C interface to the LCD server, it takes a pointer to an array rather than the array itself.
  4. lcd_req is a function (also a select handler) that acknowledges the LCDs request for the next line of pixel data.
  5. The LCD server does no buffering of pixel line arrays, therefore, for every lcd_req there must be only one lcd_update or lcd_update_p. Likewise for every lcd_update or lcd_update_p there must be only one lcd_req.
  6. The pixel array must be on the same tile as the lcd_server.

Getting started

  1. Plug the XA-SK-LCD Slice Card into the ‘STAR’ slot of the sliceKIT Core Board
  2. Plug the XA-SK-XTAG2 Card into the sliceKIT Core Board.
  3. Ensure the XMOS LINK switch on the XA-SK-XTAG2 is set to “off”.
  4. Ensure the jumper on the XA-SK-SCR480 is bridged if the back light is required.
  5. Open app_lcd_demo.xc and build the project.
  6. Run the program

The output produced should look like a bouncing “X” on the LCD screen.

app_touch_controller_lib_demo

This application demonstrates how the module module_touch_controller_lib is used to fetch the touch coordinates from the touch screen controller.

Application notes

  1. touch_lib_init must be called before calling touch_lib_req_next_coord or/and touch_lib_req_next_coord_timed.
  2. touch_lib_req_next_coord and touch_lib_req_next_coord_timed wait for touch event and then read the touch coordinates stored in the result registers of touch screen controller. touch_lib_req_next_coord_timed computes the time delay in touch event from the function call.

Getting started

  1. Plug the XA-SK-LCD Slice Card into the ‘TRIANGLE’ slot of the sliceKIT Core Board
  2. Plug the XA-SK-XTAG2 Card into the sliceKIT Core Board.
  3. Click on the app_touch_controller_lib_demo and build the project.
  4. Run the demo.
Scroll to Top