Uart baud rates Topic is solved

If you have a simple question and just want an answer.
keno
Member++
Posts: 16
Joined: Tue Jul 10, 2018 4:49 pm

Uart baud rates

Postby keno » Sun Jul 29, 2018 6:41 pm

Hi,
After having read XMOS Programming guide, lib_uart and gpio documentation, I am missing an important point. Where do I tell lib_uart where my incoming clock is and what frequency it is? Or do I just configure my uart IO pins to use a clock block based on max baud rate? What do I divide my 1.8432 MHZ down to that lib_uart will understand?
Thanks,
View Solution
User avatar
mon2
XCore Legend
Posts: 1254
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Sun Jul 29, 2018 7:35 pm

Hi. You will first need to define the baud rates you wish to support for your product. Then review if the clock available for your UART IP is suitable for accurate framing. You may be able to hit your baud rates with close enough precision which is often +-5% is acceptable in the UART world.

From past reviews found that for PC standard baud rates, you must supply an external clock source of 1.8432 Mhz @ 3v3 swing being fed into a single bit port to define the input clock for the UART IP.

If you are not sure of the baud rates or wish to be flexible then consider to apply an external I2C driven PLL like the Si5351A from Silabs. We use them all the time in a mix of designs. Using this PLL, the clock restriction is no longer a factor since you can dial up any value of your choice.

Here is the source code to program the Si5351A with XMOS:

viewtopic.php?f=44&t=4647&start=10

Review some of the UART projects such as:

https://www.xmos.com/support/boards?ver ... art&page=7

https://www.xmos.com/support/boards?product=15828
* based on an external 1.8432 Mhz (industry std clock) for PC compatible baud rates
* NB: XMOS is able to support higher baud rates but is all dependent on the MIPs rating and have seen 10 Mbps being available

https://github.com/xmos/lib_uart

http://www.xmos.com/tw/support/boards?v ... 081&page=0

https://www.xmos.com/published/multi-ua ... rt-guide-0

Hope this helps.
keno
Member++
Posts: 16
Joined: Tue Jul 10, 2018 4:49 pm

Postby keno » Mon Jul 30, 2018 1:59 pm

Thank you mon2!
Could I have been using the wrong software package? lib_uart v3.1?

Your link https://www.xmos.com/support/boards?ver ... art&page=7 has the MultiUART module usage manual, which I hadn't previously found. It appears to be referencing software different from lib_uart v3.1 and from the examples on github: https://github.com/xmos/lib_uart . EX: the run_multi_uart_rxtx() comand found on page 13 of MultiUART module usage manual isn't in lib_uart 3.1.

Where can I find the software referenced in the MultiUART module usage manual?
Is there similar software for the audio slice board XA-SK-AUDIO 1V1 ?
I have a core-200 slice Kit with the Audio and MultUART cards and have struggled getting them going.
Thanks again.
User avatar
mon2
XCore Legend
Posts: 1254
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Mon Jul 30, 2018 7:16 pm

Hi. Going from memory here but believe that the older multi-uart code was a module based IP. That is, XMOS was for a long time, supporting stand alone building blocks of canned s/w IPs to bit-bang out whatever you wanted (ie. UART, Ethernet, TCP/IP, LCD display, etc.). Then the shift was made to the library model and the 3.1.0 is the current UART library IP and also is maintained by XMOS staff.

https://www.xmos.com/support/libraries/lib_uart


However, if the older code is practical for your usage, by all means proceed. The older XMOS processors were the XS1 core and the XCORE-200 series is backwards compatible with XS1 but with more features.

On the multi-uart IP:

http://xcore.github.io/sc_multi_uart/index.html


https://github.com/xcore/sc_multi_uart


Details of the required packages are posted here:

http://xcore.github.io/sc_multi_uart/Ex ... stallation


Now on the issues you are facing in technically using the older slice boards with the newer XCORE-200 platform:

a) it should be possible to use the referenced boards but do pay attention to the graphic symbols on the main slice kit and also your slice boards. For example, if the small slice board features a square and triangle graphic (just some random symbols for this discussion) then you can ONLY use the respective PCI Express edge connector on your slice kit with these graphics. Then you must apply the respective pins that are only present for that graphic for your project source code. Hope this makes sense - write back if it does not.

b) do note that some of the PCIe slots may be bonded to Tile # 0 (ie. X0 prefix) vs. Tile # 1 (ie. X1 prefix) for the port names. This can be a real life sucking experience if you miss this critical detail. As a sanity check, consider to pulse a port pin of your liking that is bonded to the PCIe slot you plan to use @ 1 Hz or so. Then run and look for this pulsing pin on the PCIe slot. Proceed only if you can confirm this operation else you are shooting blanks :)

We are not audio developers (yet) but rather communication guys so may be wrong here but believe the audio IP you are after for your audio slice testing is posted here:

https://github.com/xcore/hw_slicekit_sy ... A-SK-AUDIO


Here is the main link for the older XS1 based SliceKit which we have here in the lab (we do not yet own the XCORE-200 slice kit):

https://github.com/xcore/hw_slicekit_system

https://github.com/xcore/hw_slicekit_system


Hope this helps. Write back if you have other questions and will try to assist where possible.
keno
Member++
Posts: 16
Joined: Tue Jul 10, 2018 4:49 pm

Postby keno » Thu Aug 02, 2018 3:58 pm

Thanks, The github references helped a lot.
Im trying to run the lib_uart example for multi_uart_demo from https://github.com/xmos/lib_uart/tree/master/examples/
and I get:
xrun: Program received signal ET_ILLEGAL_INSTRUCTION, Unable to decode instruction.
[Switching to tile[0] core[2] (dual issue)]
uart_rx_loop_8 () at C:/Users/k.osburn/workspace/lib_uart/src/multi_uart_rx_8chan.S:49

49 entsp STACK_SIZE
Current language: auto; currently asm
The file isn't obviously corrupt, and STACK_SIZE was previously defined as:
#define STACK_SIZE 12

Any help will be much appreciated!
User avatar
mon2
XCore Legend
Posts: 1254
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Aug 02, 2018 4:05 pm

Courtesy of Thomas:

https://xcore.com/viewtopic.php?f=47&t= ... f58#p25903


I suspect the problem is that xCORE-200 is in dual issue mode when your function is called.
Because you are using the 16-bit version of entsp, the next 16-bit in memory are half of a 32-bit instruction.
16-bit aligned 32-bit instructions are not allowed in dual issue mode so this caused ET_ILLEGAL_INSTRUCTION.

Try using the 32 bit version of entsp: ENTSP_lu6

This should not cause ET_ILLEGAL_INSTRUCTION and change to single issue mode.
Then the rest of the assembly function should execute in single issue mode as normal.

Further Infos about Single/Dual issue are in Chapter 5.2 Single and Dual Issue in
http://www.xmos.com/published/xs2-isa-specification

Who is online

Users browsing this forum: No registered users and 21 guests