Manual

• 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.

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

• 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.

app_touch_controller_lib_demo

app_touch_controller_server_demo

app_touch_controller_lib_demo

app_touch_controller_server_demo

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)

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

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

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 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

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.

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.

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.

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

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.

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.

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 application() function on a single logical core.
3. Find the sdram_buffer_write function within application(). There are 4 SDRAM I/O commands: sdram_buffer_write, sdram_buffer_read, sdram_full_page_write, sdram_full_page_read. They must all be followed by a sdram_wait_until_idle before another I/O command may be issued. When the sdram_wait_until_idle returns then the data is now at it destination. This functionality allows the application to be getting on with something else whilst the SDRAM server is busy with the I/O.
4. There is no need to explictly refresh the SDRAM as this is managed by the sdram_server.

After completing this demo there are two more application to try:

1. app_sdram_benchmark benchmarks the performance of the module. It does no correctness testing but instead tests the throughput of the SDRAM server.
2. app_sdram_regress this demo runs a series of regression tests of increasing difficulty, beginning from using a single core for the sdram_server with one core loaded progressing to all cores being loaded to simulate an XCore under full load.

To try these repeat the procedure in “Import and Build the Application” but with either app_sdram_benchmark or app_sdram_regress.

There are two other siognificant application demos which utilise this component.

• The Display Controller Demo combines the SDRAM Slice with the XA-SK-SCR480 LCD Slice Card to create a fully functioning 480×272 display controller, with the SDRAM actig as the framebuffer.
• The Audio Reverb Demo utilises the SDRAM component to store enough audio samples to create large audio delay lines, which are a required component of various audio effects. In this case, a reverberation effect is demonstrated.

The SDRAM component has the following features:

• Configurability of

  • SDRAM geometry,
  • clock rate,
  • refresh properties,
  • server commands supported,
  • port mapping of the SDRAM.

• Supports

  • buffer read,
  • buffer write,
  • full row(page) read,
  • full row(page) write,
  • refresh handled by the SDRAM component itself.

• Requires a single core for the server.

  • The function sdram_server requires just one core, the client functions, located in sdram.h are very low overhead and are called from the application.

The achievable effective bandwidth varies according to the available XCore MIPS. This information has been obtained by testing on real hardware.

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) plus XA-SK-SDRAM plus XA-SK-XTAG2 (Slicekit XTAG adaptor)

This application serves as a software regression to aid implementing new SDRAM interfaces and verifying current ones. The demo runs a series of regression tests of increasing difficulty, beginning from using a single core for the server and a single core for the sdram_server progressing to all cores being loaded to simulate an XCore under full load.

• Package: sc_sdram_burst
• Application: app_sdram_regress

This application benchmarks the performance of the module. It does no correctness testing but instead tests the throughput of the SDRAM server.

• Package: sc_sdram_burst
• Application: app_sdram_benchmark

This application demonstrates how the module is used to accesses memory on the SDRAM.

• Package: sc_sdram_burst
• Application: app_sdram_demo

This combination demo employs this module along with the module_lcd LCD driver and the module_framebuffer 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-SDRAM plus XA-SK-LCD480 plus XA-SK-XTAG2 (Slicekit XTAG adaptor)
• Package: sw_display_controller
• Application: app_graphics_demo

When overriding one of these defines a suffix of _IMPL needs to be added. For example, to override SDRAM_CLOCK_DIVIDER to 2 for the PINOUT_V1_IS42S16100F target add the line:

#define SDRAM_CLOCK_DIVIDER_PINOUT_V1_IS42S16100F 2

to sdram_conf.h.

SDRAM_REFRESH_MS

This specifies that during a period of SDRAM_REFRESH_MS milliseconds a total of SDRAM_REFRESH_CYCLES refresh instructions must be issued to maintain the contents of the SDRAM.

SDRAM_REFRESH_CYCLES

As above.

SDRAM_ACCEPTABLE_REFRESH_GAP

This define specifies how long the sdram_server can go between issuing bursts of refreshes. The SDRAM server issues refreshes in bursts when it is not servicing a read/write command. The number of refresh commands for a burst is automatically calculated, hence, if a read or write command is being serviced when a refresh burst should start then it will wait until the service is over then increase its burst size appropriately. If set above SDRAM_REFRESH_CYCLES then the SDRAM will fail. The default is (SDRAM_REFRESH_CYCLES/8). The unit is given in refresh periods. For example, the value would mean that the SDRAM is allowed to go SDRAM_REFRESH_MS/SDRAM_REFRESH_CYCLES*N milliseconds before refreshing. The larger the number (up to SDRAM_REFRESH_CYCLES) the smaller the constant time impact but the larger the overall impact.

SDRAM_CMDS_PER_REFRESH

This defines the minimum time between refreshes in SDRAM Clk cycles. Must be in the range from 2 to 4 inclusive.

SDRAM_EXTERNAL_MEMORY_ACCESSOR

This defines if the memory is accessed by another device(other than the XCore). If not defined then faster code will be produced.

SDRAM_CLOCK_DIVIDER

Set SDRAM_CLOCK_DIVIDER to divide down the reference clock to get the desired SDRAM Clock. The reference clock is divided by 2*SDRAM_CLOCK_DIVIDER.

SDRAM_MODE_REGISTER

This defines the configuration of the SDRAM. This is the value to be loaded into the mode register.

These are implementation specific.

SDRAM_ROW_ADDRESS_BITS

This defines the number of row address bits.

SDRAM_COL_ADDRESS_BITS

This defines the number of column address bits.

SDRAM_BANK_ADDRESS_BITS

This defines the number of bank address bits.

SDRAM_COL_BITS

This defines the number of bits per column, i.e. the data width. This should only be changed if an SDRAM of bus width other than 16 is used.

These are non-implementation specific.

SDRAM_ENABLE_CMD_WAIT_UNTIL_IDLE

Enable/Disable the wait until idle command.

SDRAM_ENABLE_CMD_BUFFER_READ

Enable/Disable the buffer read command.

SDRAM_ENABLE_CMD_BUFFER_WRITE

Enable/Disable the buffer write command.

SDRAM_ENABLE_CMD_FULL_ROW_READ

Enable/Disable the full row read command.

SDRAM_ENABLE_CMD_FULL_ROW_WRITE

Enable/Disable the full row write command.

These defines switch commands on and off in the server and client. Set to 0 for disable, set to 1 for enable. Disabling unused commands will cause a code size decrease.

The port config is given in \IMPL\sdram_ports_IMPL.h and is implementation specific.

A typical SDRAM application will have at least three top level directories. The application will be contained in a directory starting with app_, the sdram module source is in
the module_sdram directory and the directory module_xcommon contains files required to build the application.

app_[my_app_name]/
module_sdram/
module_xcommon/

Of course the application may use other modules which can also be directories at this level. Which modules are compiled into the application is controlled by the USED_MODULES define in the application Makefile.

The following header file contains prototypes of all functions required to use use the SDRAM
module. The API is described in SDRAM API
.

A typical SDRAM application will have at least three top level directories. The application will be contained in a directory starting with app_, the sdram module source is in
the module_sdram directory and the directory module_xcommon contains files required to build the application.

app_[my_app_name]/
module_sdram/
module_xcommon/

Of course the application may use other modules which can also be directories at this level. Which modules are compiled into the application is controlled by the USED_MODULES define in the application Makefile.

The following header file contains prototypes of all functions required to use use the SDRAM
module. The API is described in SDRAM API
.

1. Plug the XA-SK-SDRAM 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. Open app_sdram_demo.xc and build it.
5. run the program on the hardware.

The output produced should look like:

0   0
1   1
2   2
3   3
4   4
5   5
SDRAM demo complete.

• There are 4 SDRAM I/O commands: sdram_buffer_write, sdram_buffer_read, sdram_full_page_write, sdram_full_page_read. They must all be followed by a sdram_wait_until_idle before another I/O command may be issued. When the sdram_wait_until_idle returns then the data is now at it destination. This functionality allows the application to be getting on with something else whilst the SDRAM server is busy with the I/O.
• There is no need to explictly refresh the SDRAM as this is managed by the sdram_server.

1. Plug the XA-SK-SDRAM 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. Open app_sdram_regress.xc and build it.
5. run the program on the hardware.

The output produced should look like:

Test suite begin
8 threaded test suite start
Begin sanity_check
...

1. Plug the XA-SK-SDRAM 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. Open app_sdram_benchmark.xc and build it.
5. run the program on the hardware.

The output produced should look like:

Cores active: 8
Max write: 70.34 MB/s
Max read : 66.82 MB/s
Cores active: 7
Max write: 71.47 MB/s
Max read : 68.08 MB/s
...

The following tools should be installed on the host system in order to run this application

• For Win 7: Hercules Setup Utility by HW-Group
  http://www.hw-group.com/products/hercules/index_en.html
• For MAC users: SecureCRT7.0
  http://www.vandyke.com/download/securecrt/
• For Linux Users: Try cutecom (http://cutecom.sourceforge.net/
  ) or try sudo apt-get install cutecom

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 XA-SK-GPIO Slice Card to the XP-SKC-L2 Slicekit Core board using the connector marked with the SQUARE.
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. Switch on the power supply to the Slicekit Core board.
5. Connect a null serial cable to DB-9 connector on XA-SK-GPIO Slice Card. The cable will need a cross over between the UART RX and TX pins at each end.
6. Connect other end of cable to Host DB-9 connector slot. If the Host does not have an DB-9 Connector slot then use USB-UART cable for the demo. We used the BF-810 USB to Uart adapter (See http://www.bafo.com/products_bf-810_S.asp
   (Part number : BF-810). Any other usb to uart bridge should do just as well.
7. Identify the serial (COM) port number provided by the Host or the USB to UART adapter and open a suitable terminal software for the selected serial port (refer to the Hercules or SecureCRT documentation above).
8. Configure the host terminal console program as follows: 115200 baud, 8 bit character length, even parity, 1 stop bit, no hardware flow control. The Transmit End-of-Line character should be set to CR (other options presented will probably be LF and CRLF).
9. Connect XA-SK-GPIO Slice Card to the XP-SKC-L2 Slicekit Core board.
10. Connect the XTAG Adapter to Slicekit Core board, XA-SK-XTAG2 connector(xtag slice) and connect XTAG-2 to the adapter.
11. Connect the XTAG-2 to the computer running xTIMEcomposer.
12. Switch on the power supply to the Slicekit Core board.
13. Open the serial device on the host console program

1. Open xTIMEcomposer, then open the edit perspective (Window->Open Perspective->XMOS Edit).
2. Locate the 'Slicekit COM Port GPIO 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_i2c_master, module_uart_rx and module_uart_tx) to be imported as well.
3. Click on the Slicekit COM Port GPIO 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.

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 generic UART Receiver component in the xSOFTip Browser, and you will see its description together with links to more documentation for this component. Once you have briefly explored this component, you can return to this quickstart guide by re-selecting 'Slicekit COM Port GPIO Demo' in the xSOFTip Browser and clicking once more on the Quickstart link for the Slicekit Com Port GPIO Demo Quickstart.

1. Click on the Run icon (the white arrow in the green circle). A dialog will appear asking which device to cvonnect to. Select XMOS XTAG2.
2. Look at the configured terminal client application console on the Host.
3. If the terminal is configured correctly, it should display the following message: WELCOME TO GPIO DEMO (**ECHO DATA MODE ACTIVATED**). In this mode any character typed in from the key board is echoed back. Verify this by typing characters in the terminal console on the host. The typed characters should be echoed back.
4. When ready, enter command mode by typing >cmd (note, be sure to also type the ‘>’ character). The Console will then show COMMAND MODE ACTIVATED.
5. Type help in the console window. The help menu will be displayed as sown in the figure below.

Look at the Code

More complex Serial Bridging Applications

This application has the following features:

• module_i2c_master from the xSOFt ip library is used to access the external ADC, which is equipped with an external linearised thermistor circuit for temperature sensing.
• simple code to print the recorded temperature to the XDE debug console on the press of one of the Slice Card buttons
• simple code to cycle through the 4 LEDs each time the other button is pressed.
• demonstrates use of XC select statements for handling multiple concurrent inputs
• demonstrates basic usage of XCore ports

This application extends the simple demo to provide the following functionality (all options are dynamically reconfigurable via the APIs for app_slicekit_com_demo application):

• Uart RX and TX Using the generic Uart RX and TX xSOFTip components

  • Baud Rate: 150 to 115200 bps
  • Parity: None, Mark, Space, Odd, Even
  • Stop Bits: 1,2
  • Data Length: 1 to 30 bits (Max 30 bits assumes 1 stop bit and no parity)

• Cycles Through LEDs on button Press
• Displays temperature value and button press events on the terminal console of a host PC via the UART

• XA-SK-E100 Ethernet Slice Card is additionally required for this demo

This application extends the GPIO com port demo to utilize Ethernet and XTCP components in order to host a web page to

• Turn GPIO Slice Card LEDs on and off
• Display GPIO Slice Card button press status
• Read the room temperature via the onboard ADC and display on the web page

• XA-SK-WIFI Slice Card is additionally required for this demo

This application extends the GPIO com port demo to utilize Wi-Fi component in order to host a web page to

• Turn GPIO Slice Card LEDs on and off
• Display GPIO Slice Card button press status
• Read the room temperature via the on-board ADC and display on the web page

All of the files required for operation are located in the app_sk_gpio_simple_demo/src directory. The files that are need to be included for use of this component in an application are:

• void app_manager(chanend c_uartTX, chanend c_chanRX, chanend c_process, chanend c_end)

  Polling uart RX and push button switches and send received commands to process_data thread.

  Parameters

  • c_uartTX

    Channel to Uart TX Thread

  • c_chanRX

    Channel to Uart RX Thread

  • c_process

    Channel to process data Thread

  • c_end

    Channel to read data from process thread

• int linear_interpolation(int adc_value)

  Calculates temperatue based on linear interpolation.

  Parameters

  • adc_value

    int value read from ADC

  Returns

  Returns linear interpolated Temperature value

• int read_adc_value()

  Read ADC value using I2C.

  Returns

  Returns ADC value

The port declaration for the LEDs, Buttons and I2C are declared as below. LEDs and Buttons use 4 bit ports and I2C uses 1 bit port for SCL(I2c Clock) and SDA (I2C data).

on stdcore[CORE_NUM]: out port p_led=XS1_PORT_4A;
on stdcore[CORE_NUM]: port p_PORT_BUT_1=XS1_PORT_4C;
on stdcore[CORE_NUM]: struct r_i2c i2cOne = {
		XS1_PORT_1F,
		XS1_PORT_1B,
		1000
 };

The app_manager API writes the configuration settings information to the ADC as shows below.

	i2c_master_write_reg(0x28, 0x00, data, 1, i2cOne); //Write configuration information to ADC

The select statement in the app_manager API selects one of the two cases in it, checks if there is IO event or timer event. This statement monitors both the events and executes which ever event is occurred first.
The select statement in the application is listed below. The statement checks if there is button press or not. If there is button press then it looks if the button state is same even after 20msec. If the buton state is same then it recognises as an valid push.

		select
		{
			case button => p_PORT_BUT_1 when pinsneq(button_press_1):> button_press_1: //checks if any button is pressed
				button=0;
				t:>time;
				break;

			case !button => t when timerafter(time+debounce_time):>void: //waits for 20ms and checks if the same button is pressed or not
				p_PORT_BUT_1:> button_press_2;
				if(button_press_1==button_press_2)
				if(button_press_1 == BUTTON_PRESS_VALUE) //Button 1 is pressed
				{
					printstrln("Button 1 Pressed");
					p_led<:(led_value);
					led_value=led_value<<1;
					led_value|=0x01;
					led_value=led_value & 0x0F;
					if(led_value == 15)
					{
						led_value=0x0E;
					}
				}
				if(button_press_1 == BUTTON_PRESS_VALUE-1) //Button 2 is pressed
				{
					data1[0]=0;data1[1]=0;
					i2c_master_rx(0x28, data1, 2, i2cOne); //Read ADC value using I2C read 
					printstrln("Reading Temperature value....");
					data1[0]=data1[0]&0x0F;
					adc_value=(data1[0]<<6)|(data1[1]>>2);
					printstr("Temperature is :");
					printintln(linear_interpolation(adc_value));
				}

				button=1;
				break;
		}

After recognising the valid push then it checks if Button 1 is pressed or Button 2 is pressed. IF Button 1 is pressed then, the application reads the status of LEDs and shift the position of the LEDs to left by 1.
If Button 2 is pressed, then the applciation reads the contents of ADC register using I2C read instruction and input the ADC value to linear interpolation function as shown below.

int linear_interpolation(int adc_value)
{
	int i=0,x1,y1,x2,y2,temper;
	while(adc_value<TEMPERATURE_LUT[i][1])
	{
		i++;
	}
//::Formula start
	//Calculating Linear interpolation using the formula y=y1+(x-x1)*(y2-y1)/(x2-x1)
//::Formula
	x1=TEMPERATURE_LUT[i-1][1];
	y1=TEMPERATURE_LUT[i-1][0];
	x2=TEMPERATURE_LUT[i][1];
	y2=TEMPERATURE_LUT[i][0];
	temper=y1+(((adc_value-x1)*(y2-y1))/(x2-x1));
	return temper;//Return Temperature value
}

The linear intepolation function calculates the linear interpolation value using the following formula and returns the temperature value from temperature look up table.

	//Calculating Linear interpolation using the formula y=y1+(x-x1)*(y2-y1)/(x2-x1)

int TEMPERATURE_LUT[][2]= //Temperature Look up table
{
		{-10,850},{-5,800},{0,750},{5,700},{10,650},{15,600},{20,550},{25,500},{30,450},{35,400},
		{40,350},{45,300},{50,250},{55,230},{60,210}
};

All of the files required for operation are located in the app_slicekit_simple_demo/src directory. The files that are need to be included for use of this component in an application are:

• void app_manager(chanend c_uartTX, chanend c_chanRX, chanend c_process, chanend c_end)

  Polling uart RX and push button switches and send received commands to process_data thread.

  Parameters

  • c_uartTX

    Channel to Uart TX Thread

  • c_chanRX

    Channel to Uart RX Thread

  • c_process

    Channel to process data Thread

  • c_end

    Channel to read data from process thread

• void process_data(chanend c_process, chanend c_end)

  process received data to see if received data is valid command or not Polling switches to see for button press

  Parameters

  • c_process

    Channel to receive data from app manager Thread

  • c_end

    Channel to communicate to app manager thread

• void uart_tx_string(chanend c_uartTX, unsigned char message[100])

  Transmits byte by byte to the UART TX thread for an input string.

  Parameters

  • c_uartTX

    Channel to receive data from app Uart TX Thread

  • message

    Buffer to store array of characters

• int linear_interpolation(int adc_value)

  Calculates temperatue based on linear interpolation.

  Parameters

  • adc_value

    int value read from ADC

  Returns

  Returns linear interpolated Temperature value

• int read_adc_value()

  Read ADC value using I2C.

  Returns

  Returns ADC value

The port declaration for the LEDs, Buttons, I2C and UART are declared as below. LEDs and Buttons uses 4 bit ports, UART uses 1 bit ports both for Transmit and Receive and I2C uses 1 bit port for SCL(I2c Clock) and SDA (I2C data).

#define CORE_NUM 1
#define BUTTON_PRESS_VALUE 2
on stdcore[CORE_NUM] : buffered in port:1 p_rx =  XS1_PORT_1G;
on stdcore[CORE_NUM] : out port p_tx = XS1_PORT_1C;
on stdcore[CORE_NUM]: port p_led=XS1_PORT_4A;
on stdcore[CORE_NUM]: port p_button1=XS1_PORT_4C;
on stdcore[CORE_NUM]: struct r_i2c i2cOne = {
		XS1_PORT_1F,
		XS1_PORT_1B,
		1000
 };

The app_manager API writes the configuration settings information to the ADC as shows below.

	i2c_master_write_reg(0x28, 0x00, i2c_register, 1, i2cOne); //Configure ADC by writing the settings to register

The select statement in the app_manager API selects one of the three cases in it, checks if there is IO event or timer event or any event on the Uart Receive pin. This statement monitors all the events and executes which ever event is occurred first.
The select statement in the applciation is listed below. The statement checks if there is button press or availability of data on the Uart Receive pin. If there is button press then it looks if the button state is same as even after 200msec. If the buton state is same then it recognises as a valid push.
If there is data on the Uart Receive pin the it echoes the data back to the uart Transmit pin until > character is received in the input data.

		select
		{
			case c_end:>data:
				c_end:>data;
				if(data == BUTTON_1) //Cycle LEDs on button 1 press
				{
					printstrln("Button 1 Pressed");
					p_led<:(led_value);
					led_value=led_value<<1;
					if(led_value == 16) //If LED value is 16 then assigns LED value to 1 which cycles LEDs by button press
					{
						led_value=0x01;
					}
				}
				if(data == BUTTON_2) //Displays Temperature on console if Button 2 is pressed
				{
					adc_value=read_adc_value();
					data_arr[0]=(linear_interpolation(adc_value));
					printstr("Temperature is :");
					printint(linear_interpolation(adc_value));
					printstrln(" C");
				}
				break;
			case uart_rx_get_byte_byref(c_uartRX, rxState, buffer):
//::Command start
				if(buffer == '>') //IUF received data is '>' character then expects cmd to endter into command mode
				{
					j=0;
					uart_rx_get_byte_byref(c_uartRX, rxState, buffer);
					cmd_rcvbuffer[j]=buffer;
					if((cmd_rcvbuffer[j] == 'C' )|| (cmd_rcvbuffer[j] =='c')) //Checks if received data is 'C' or 'c'
					{
						j++;
						uart_rx_get_byte_byref(c_uartRX, rxState, buffer);
						cmd_rcvbuffer[j]=buffer;

						if((cmd_rcvbuffer[j] == 'm' )|| (cmd_rcvbuffer[j] =='M')) //Checks if received data is 'M' or 'm'
						{
							j++;
							uart_rx_get_byte_byref(c_uartRX, rxState, buffer);
							cmd_rcvbuffer[j]=buffer;
							if((cmd_rcvbuffer[j] == 'D' )|| (cmd_rcvbuffer[j] =='d'))//Checks if received data is 'D' or 'd'
							{
								uart_tx_send_byte(c_uartTX, '\r');
								uart_tx_send_byte(c_uartTX, '\n');
								uart_tx_string(c_uartTX,CONSOLE_MESSAGES[0]);
								COMMAND_MODE=1; //activates command mode as received data is '>cmd'
								uart_tx_send_byte(c_uartTX, '\r');
								uart_tx_send_byte(c_uartTX, '\n');
								uart_tx_send_byte(c_uartTX, '>'); //displays '>' if command mode is activated
							}
							else
							{
								uart_tx_send_byte(c_uartTX, '>');
								for(int i=0;i<3;i++)
									uart_tx_send_byte(c_uartTX, cmd_rcvbuffer[i]); // if received dta is not 'c' displays back the received data
							}
						}
						else
						{
							uart_tx_send_byte(c_uartTX, '>'); //if received data is not 'm' displays the received data
							for(int i=0;i<2;i++)
								uart_tx_send_byte(c_uartTX, cmd_rcvbuffer[i]);
						}
					}
					else
					{
						uart_tx_send_byte(c_uartTX, '>');
						uart_tx_send_byte(c_uartTX, cmd_rcvbuffer[j]);
						j=0;
					}
				}
				else
				{
					uart_tx_send_byte(c_uartTX,buffer); //Echoes back the input characters if not in command mode
				}
//::Command
				while(COMMAND_MODE) //Command mode activated
				{
					j=0;
					skip=1;
					while(skip == 1)
					{
//::Send to process start					
						select
						{
							case uart_rx_get_byte_byref(c_uartRX, rxState, buffer):
								cmd_rcvbuffer[j]=buffer;
								if(cmd_rcvbuffer[j++] == '\r')
								{
									skip=0;
									j=0;
									while(cmd_rcvbuffer[j] != '\r')
									{
										c_process<:cmd_rcvbuffer[j]; //received valid command and send the command to the process_data theread
										uart_tx_send_byte(c_uartTX, cmd_rcvbuffer[j]);
										j++;
									}
									cmd_rcvbuffer[j]='\0';
									c_process<:cmd_rcvbuffer[j];
									for(int inc=0;inc<20;inc++) //Clears the command buffer
										cmd_rcvbuffer[inc]='0';
									j=0;
								}
								break;
//::Send
							case c_end:>data:
								if(data!=EXIT && data!=INVALID )
								{
									uart_tx_string(c_uartTX,CONSOLE_MESSAGES[3]); //Displays COmmand Executed Message on Uart
								}
//::State machine
								switch(data)
								{
									case EXIT: //Exit from command mode
										COMMAND_MODE=0;
										skip=0;
										uart_tx_string(c_uartTX,CONSOLE_MESSAGES[1]);
										uart_tx_string(c_uartTX,CONSOLE_MESSAGES[13]);
										break;

									case SET_LED_1: //Read port Value and Set LED 1 ON
										p_led:>data;
										data=data | 0xE;
										p_led<:data;
										break;

									case CLEAR_LED_1://Read port Value and Set LED 1 OFF
										p_led:>data;
										p_led<:data&0x1;
										break;

									case SET_LED_2: //Read port Value and Set LED 2 ON
										p_led:>data;
										p_led<:data | 0xD;
										break;

									case CLEAR_LED_2: //Read port Value and Set LED 2 OFF
										p_led:>data;
										p_led<:data&0x2;

										break;

									case SET_LED_3: //Read port Value and Set LED 3 ON
										p_led:>data;
										p_led<:data | 0xB;
										break;

									case CLEAR_LED_3: //Read port Value and Set LED 3 OFF
										p_led:>data;
										p_led<:data&0x4;
										break;

									case SET_LED_4: //Read port Value and Set LED 4 ON
										p_led:>data;
										p_led<:data | 0x7;
										break;

									case CLEAR_LED_4: //Read port Value and Set LED 4 OFF
										p_led:>data;
										p_led<:data&0x8;

										break;

									case CLEAR_ALL: //sets all four LEDs OFF
										p_led<:0xF;
										break;

									case SET_ALL: //sets all four LEDs ON
										p_led<:0x0;
										break;

									case BUTTON_PRESSED: //Checks if button is pressed
										c_end:>button;
										if(button == BUTTON_1) //Prints Button 1 is pressed on the Uart
										{
											CONSOLE_MESSAGES[4][9]='1';
											uart_tx_string(c_uartTX,CONSOLE_MESSAGES[4]);
											button1_press=1;
										}
										if(button == BUTTON_2) //Prints Button 2 is pressed on Uart
										{
											CONSOLE_MESSAGES[4][9]='2';
											uart_tx_string(c_uartTX,CONSOLE_MESSAGES[4]);
											button2_press=1;
										}
										break;
									case HELP: //Displays help messages on Uart
										uart_tx_string(c_uartTX,CONSOLE_MESSAGES[14]);
										uart_tx_string(c_uartTX,CONSOLE_MESSAGES[7]);
										uart_tx_string(c_uartTX,CONSOLE_MESSAGES[8]);
										uart_tx_string(c_uartTX,CONSOLE_MESSAGES[9]);
										uart_tx_string(c_uartTX,CONSOLE_MESSAGES[10]);
										uart_tx_string(c_uartTX,CONSOLE_MESSAGES[15]);
										uart_tx_string(c_uartTX,CONSOLE_MESSAGES[11]);
										uart_tx_send_byte(c_uartTX, '\r');
										uart_tx_send_byte(c_uartTX, '\n');
										break;
									case READ_ADC: //Displays temperature value on the Uart
										adc_value=read_adc_value();
										data_arr[0]=(linear_interpolation(adc_value));
										uart_tx_string(c_uartTX,CONSOLE_MESSAGES[12]);
										uart_tx_send_byte(c_uartTX, (data_arr[0]/10)+'0');
										uart_tx_send_byte(c_uartTX, (data_arr[0]%10)+'0');
										uart_tx_send_byte(c_uartTX, 32);
										uart_tx_send_byte(c_uartTX, 'C');
										break;
									case INVALID: //Displays command input is invalid command on the Uart
										uart_tx_string(c_uartTX,CONSOLE_MESSAGES[2]);
										break;
									case CHK_BUTTONS: //Checks if button are pressed and displays on the Uart
										if(button1_press)
										{
											CONSOLE_MESSAGES[4][9]='1';
											uart_tx_string(c_uartTX,CONSOLE_MESSAGES[4]); //Displays Button 1 is pressed
										}
										if(button2_press)
										{
											CONSOLE_MESSAGES[4][9]='2';
											uart_tx_string(c_uartTX,CONSOLE_MESSAGES[4]); //Dipslays Button 2 is pressed
										}
										if( !button1_press && !button2_press)
										{
											uart_tx_string(c_uartTX,CONSOLE_MESSAGES[5]); //Displays No Buttons are pressed
										}
										button1_press=0;
										button2_press=0;
                                                                                break;
								}
								if(data != EXIT) //Exits from command mode
								{
									uart_tx_send_byte(c_uartTX, '\r');
									uart_tx_send_byte(c_uartTX, '\n');
									uart_tx_send_byte(c_uartTX, '>');
								}
								break;
						}//select
//::State
					}//skip
					j=0;
				}//command mode
				break;
		}//main select

If the received data is > character the it waits to see if the next received successive bytes are c, m and d. If the successive received data is >cmd then the application activates comman mode otherwise the data is echoed back to the Uart Transmit pin. The part of code which explains about the command mode is as blow.

				if(buffer == '>') //IUF received data is '>' character then expects cmd to endter into command mode
				{
					j=0;
					uart_rx_get_byte_byref(c_uartRX, rxState, buffer);
					cmd_rcvbuffer[j]=buffer;
					if((cmd_rcvbuffer[j] == 'C' )|| (cmd_rcvbuffer[j] =='c')) //Checks if received data is 'C' or 'c'
					{
						j++;
						uart_rx_get_byte_byref(c_uartRX, rxState, buffer);
						cmd_rcvbuffer[j]=buffer;

						if((cmd_rcvbuffer[j] == 'm' )|| (cmd_rcvbuffer[j] =='M')) //Checks if received data is 'M' or 'm'
						{
							j++;
							uart_rx_get_byte_byref(c_uartRX, rxState, buffer);
							cmd_rcvbuffer[j]=buffer;
							if((cmd_rcvbuffer[j] == 'D' )|| (cmd_rcvbuffer[j] =='d'))//Checks if received data is 'D' or 'd'
							{
								uart_tx_send_byte(c_uartTX, '\r');
								uart_tx_send_byte(c_uartTX, '\n');
								uart_tx_string(c_uartTX,CONSOLE_MESSAGES[0]);
								COMMAND_MODE=1; //activates command mode as received data is '>cmd'
								uart_tx_send_byte(c_uartTX, '\r');
								uart_tx_send_byte(c_uartTX, '\n');
								uart_tx_send_byte(c_uartTX, '>'); //displays '>' if command mode is activated
							}
							else
							{
								uart_tx_send_byte(c_uartTX, '>');
								for(int i=0;i<3;i++)
									uart_tx_send_byte(c_uartTX, cmd_rcvbuffer[i]); // if received dta is not 'c' displays back the received data
							}
						}
						else
						{
							uart_tx_send_byte(c_uartTX, '>'); //if received data is not 'm' displays the received data
							for(int i=0;i<2;i++)
								uart_tx_send_byte(c_uartTX, cmd_rcvbuffer[i]);
						}
					}
					else
					{
						uart_tx_send_byte(c_uartTX, '>');
						uart_tx_send_byte(c_uartTX, cmd_rcvbuffer[j]);
						j=0;
					}
				}
				else
				{
					uart_tx_send_byte(c_uartTX,buffer); //Echoes back the input characters if not in command mode
				}

After the command mode is active the applicaion receives all the input commands and send to the process_data API using a channel.The part of the code is shown below.

						select
						{
							case uart_rx_get_byte_byref(c_uartRX, rxState, buffer):
								cmd_rcvbuffer[j]=buffer;
								if(cmd_rcvbuffer[j++] == '\r')
								{
									skip=0;
									j=0;
									while(cmd_rcvbuffer[j] != '\r')
									{
										c_process<:cmd_rcvbuffer[j]; //received valid command and send the command to the process_data theread
										uart_tx_send_byte(c_uartTX, cmd_rcvbuffer[j]);
										j++;
									}
									cmd_rcvbuffer[j]='\0';
									c_process<:cmd_rcvbuffer[j];
									for(int inc=0;inc<20;inc++) //Clears the command buffer
										cmd_rcvbuffer[inc]='0';
									j=0;
								}
								break;

The process_data thread checks if any button is pressed or checks if there is any command from app_manager thread. If there is button press then the thread sends instructions to the app_manager thread about the button or if command is received, then it send instructions about teh command received.
The details in the process_data thread is as shown below.

Process_data thread send instructions to the app_manager thread about the command received. The app_manager thread then implementys the state machine according to the instructions received from the process_data thread. The state machine of app_manager thread is as below.

All the files required for operation are located in the app_sk_gpio_eth_combo_demo/src directory. The files to be included for use of the dependent components are:

doxygenfunction: Cannot find function “app_handler” in doxygen xml output

doxygenfunction: Cannot find function “process_web_page_data” in doxygen xml output

doxygenfunction: Cannot find function “get_web_user_selection” in doxygen xml output

The port declaration for Ethernet, LEDs, Buttons and I2C are declared as below:

• Ethernet uses ethernet_board_support.h configuration
• I2C uses 1 bit port for SCL(I2C Clock) and SDA (I2C data)
• LEDs and Buttons uses 4 bit ports

The app_manager API writes the configuration settings to the ADC as shows below

The select statement in the app_handler API selects either I/O events to check for any valid button presses or uses channel events to detect any commands from web page requests. Valid web page commands are either to set or reset LEDs and check button press state since last check request.

Whenever there is a change in values of the button ports, a flag is used to kick start a timer for debounce interval, and port value is sampled to identify which button is pressed. The code is as shown below

Every time a web page request is received, app_handler records current ADC value and button press status and sends it to web page.
Button check statuses are reset immediately after the web page request.

Makefile in app_sk_gpio_eth_combo_demo folder should include the following line:

WEBFS_TYPE = internal

This value indicates sc_website component to use program memory instead of FLASH memory to store the web pages.

As a next step, create web folder in app_sk_gpio_eth_combo_demo

In order to include any images to be displayed on the web page, create images folder as follows
app_sk_gpio_eth_combo_demo/web/images

For this application, we have created index.html web page using html script. This page uses XMOS logo from images folder. We have defined desired GPIO controls for LEDs in this web page.

APIs that are required to be executed by the demo application should be enclosed between the tags {% and %}. These are to be defined in web_page_functions.c file.
For example, index.html contains
<p>{% read_temperature(buf, app_state, connection_state) %}</p>

This indicates read_temperature is a function executed by the program and result is returned to the web page. After execution, sc_website component replaces this function as
<p>”Temperature recorded from onboard ADC: <b>NA </b>^oC”</p>

All the files required for operation are located in the app_sk_gpio_wifi_tiwisl_combo_demo/src directory. The files to be included for use of the dependent components are:

doxygenfunction: Cannot find function “app_handler” in doxygen xml output

doxygenfunction: Cannot find function “process_web_page_data” in doxygen xml output

doxygenfunction: Cannot find function “get_web_user_selection” in doxygen xml output

The port declaration for Wi-Fi (SPI), LEDs, Buttons and I2C are declared as below:

• Wi-Fi control uses

  • 1 four-bit port for nCS(Chip Select) and Power enable
  • 1 one-bit port for nIRQ(interrupt)

• SPI uses 3 one-bit ports for MOSI, CLK and MISO
• I2C uses 1 bit port for SCL(I2C Clock) and SDA (I2C data)
• LEDs and Buttons use 4 bit ports

The app_manager API writes the configuration settings to the ADC as shows below

The select statement in the app_handler API selects either I/O events to check for any valid button presses or uses channel events to detect any commands from web page requests. Valid web page commands are either to set or reset LEDs and check button press state since last check request.

Whenever there is a change in values of the button ports, a flag is used to kick start a timer for debounce interval, and port value is sampled to identify which button is pressed. The code is as shown below

Every time a web page request is received, app_handler records current ADC value and button press status and sends it to web page.
Button check statuses are reset immediately after the web page request.

Makefile in app_sk_gpio_wifi_tiwisl_combo_demo folder should include the following line:

WEBFS_TYPE = internal

This value indicates sc_website component to use program memory instead of FLASH memory to store the web pages.

As a next step, create web folder in app_sk_gpio_wifi_tiwisl_combo_demo

In order to include any images to be displayed on the web page, create images folder as follows
app_sk_gpio_wifi_tiwisl_combo_demo/web/images

For this application, we have created index.html web page using html script. We have defined desired GPIO controls for LEDs in this web page.

APIs that are required to be executed by the demo application should be enclosed between the tags {% and %}. These are to be defined in web_page_functions.c file.
For example, index.html contains
<p>{% read_temperature(buf, app_state, connection_state) %}</p>

This indicates read_temperature is a function executed by the program and result is returned to the web page. After execution, sc_website component replaces this function as
<p>”Temperature recorded from on-board ADC: <b>NA </b>^oC”</p>