Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
2,226 Views

Can't get UART1 thru Arduino board

No matter what I do ... I see no UART1 activity.

What are the exact steps to get UART1 to get to an Arduino shield?

tried echo mode1 on both gpio 130 and 131.

Thanks!

0 Kudos
19 Replies
Highlighted
Community Manager
12 Views

Hi Closet_Rambo,

 

 

Thanks for contacting us!

 

 

We'll love to help you to use the Edison's UART1. First, we would like to let you know that according to /message/247139# 247139 Using Serialx on Edison, the UART1 is /dev/ttyMFD1 (Linux name), so, in order to work with that UART, you can use different methods:
  • Using MRAA library: You can try the MRAA example for the UART, here you can find the example: https://github.com/intel-iot-devkit/mraa/blob/master/examples/uart.c https://github.com/intel-iot-devkit/mraa/blob/master/examples/uart.c, it should configure the UART and send data. To test this example, you have to create a file.c with that code, then compile it (you can use this command gcc -o -lmraa), and ./ to run the example.
  • Using Linux commands: You can use echo and cat commands to send and receive data from the UART1, please take a look at this link for more details: /message/270979# 270979 How to get the UART1 working for Linux beginners (we know that it refers to Edison mini breakout board, however, the commands apply for Arduino expansion board too)
  • Arduino IDE: the SerialEvent code is a good example to test the UART, however, you have to change the "Serial" object by "Serial1". This example can be found in the Arduino IDE under File>Examples>Communication>SerialEvent

 

Hope you find this information helpful, however, if you any question, please let us know, we're here to help you.

 

 

Have a nice day!

 

 

Regards,

 

-Yermi A.

 

0 Kudos
Highlighted
Beginner
12 Views

Thanks Yermi ... this is good info ... but my problem is the bidirectional level shifters on the Arduino board.

cat /sys/kernel/debug/gpio_debug/gpio130/current_pinmux

cat /sys/kernel/debug/gpio_debug/gpio131/current_pinmux

... show mode 1 but nothing is getting thru.

I have an Arduino wireless SD shield which has a voltage follower op amp driving LED's for TX and RX.

There is nothing getting out from the Edison side when I send data thru ... the LED does not light.

https://www.arduino.cc/en/Main/ArduinoWirelessShield Arduino - ArduinoWirelessShield

0 Kudos
Highlighted
Community Manager
12 Views

Hi Closet_Rambo,

 

 

We would like to know more information in order to help you, could you please provide us the steps you have followed to communicate with Arduino wireless SD shield? Are you trying to do something like this: http://www.instructables.com/id/Arduino-Wireless-SD-Shield-Tutorial/?ALLSTEPS Arduino Wireless SD Shield Tutorial with the Edison board?

 

 

We'll be waiting for your reply.

 

 

Regards,

 

-Yermi A.

 

0 Kudos
Highlighted
Beginner
12 Views

At this point I am trying to get the Edison Arduino board to allow UART1 (ttyMFD1) to connect to the shield interface TX and RX pins.

After extensive research it looks like the Edison GPIO pins must be de-muxed to allow the internal UART1 TX and RX out of the Edison SoC.

In addition ... U34 (PCAL9555) must be commanded thru I2C to set directions correctly on U33 and U31 bi-directional level shifters.

Mraa will not build on UbiLinux but I see there is a command line method to set this up.

Several people have done this:

echo mode1 > /sys/kernel/debug/gpio_debug/gpio130/current_pinmux

echo mode1 > /sys/kernel/debug/gpio_debug/gpio131/current_pinmux

... the remaining issue is that U34 defaults to set all digital level shifters from the shield inbound to the Edison.

The default registers of U34 seem to be set:

root@ubilinux:~# i2cdump -f -y 1 35

No size specified (using byte-data access)

0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef

00: 00 00 ff ff 00 00 ff ff XX XX XX XX XX XX XX XX ........XXXXXXXX

10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

40: ff ff ff ff 00 00 ff ff ff ff ff ff 00 00 XX 00 ..............X.

50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

... register 06 must be changed from FF, to FD in order to allow TX out from the Edison.

I can always use I2C tools to do so but ...

... how should this be correctly set in the first place?

0 Kudos
Highlighted
Community Manager
12 Views

Hi Closet_Rambo,

 

 

Thanks for the information provided. We would like to let you know that UbiLinux is out of our support scope and the issue could be related to this OS, however, we'll investigate a little bit more this case in order to try to help you.

 

 

Regards,

 

-Yermi A.

 

0 Kudos
Highlighted
Beginner
12 Views

I loaded the latest Yocto Edison image.

Here is the I2C dump for the same chip:

0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef

00: 00 c0 ff ff 00 00 ff 3f XX XX XX XX XX XX XX XX .?.....?XXXXXXXX

10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

40: ff ff ff ff 00 00 ff ff ff ff ff ff 00 00 XX 00 ..............X.

50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

... the only difference is 0x01 (C0 vs 00) ...

... and 0x07 (3F vs FF)

Did the Edison Arduino board ever work?

How would one configure the Yocto image to get UART1 thru to the shield pins?

0 Kudos
Highlighted
Community Manager
12 Views

Hi Closet_Rambo,

Thanks for your patience, we have been investigating and we would like to recommend you to set up the correct pin multiplexing to use the UART1 following these steps:

echo 214 > /sys/class/gpio/export

 

echo 130 > /sys/class/gpio/export

 

echo 131 > /sys/class/gpio/export

 

echo 248 > /sys/class/gpio/export

 

echo 249 > /sys/class/gpio/export

 

echo 216 > /sys/class/gpio/export

 

echo 217 > /sys/class/gpio/export

 

echo low > /sys/class/gpio/gpio214/direction

 

echo low > /sys/class/gpio/gpio248/direction

 

echo high > /sys/class/gpio/gpio249/direction

 

echo in > /sys/class/gpio/gpio216/direction

 

echo in > /sys/class/gpio/gpio217/direction

 

echo mode1 > /sys/kernel/debug/gpio_debug/gpio130/current_pinmux

 

echo mode1 > /sys/kernel/debug/gpio_debug/gpio131/current_pinmux

 

echo high > /sys/class/gpio/gpio214/direction

Please let us know your results. We'll be waiting for your reply.

Regards,

 

-Yermi A.
0 Kudos
Highlighted
Beginner
12 Views

I see the transmit LED flash now ... not sure why the additional commands were needed.

Thanks!

0 Kudos
Highlighted
New Contributor I
12 Views

Hi,

Regarding all of those echo commands ...

I've been looking at

http://www.intel.com/content/dam/support/us/en/documents/edison/sb/edisonarduino_hg_331191007.pdf http://www.intel.com/content/dam/support/us/en/documents/edison/sb/edisonarduino_hg_331191007.pdf

Looking at Table 3, on page 9, for rx = io0 = gpio130 I see where gpio248 and gpio216 get involved.

and for tx = io1 = gpi131 see where gpio249 and gpio217 get involved.

And maybe the "SoC pin modes, 1" column explains:

echo mode1 > /sys/kernel/debug/gpio_debug/gpio130/current_pinmux

echo mode1 > /sys/kernel/debug/gpio_debug/gpio131/current_pinmux

I determined this from the examples in section 11 on page 26.

The bottom of table 3 mentions 214.

The beginning of Section "11 Shield pin configuration" sort of explains the theory but is not as clear as it should be.

I am going to spend more time studying to try and figure out the details that seem to be missing.

I believe that 50% of a project, in this case Edison, is getting things to work, 50% is creating the external interface and 50% is creating great documentation ... hmm that doesn't add up, does it. And that is management's fault.

Regards,

Bill

0 Kudos
Highlighted
Beginner
12 Views

Good info Bill ... thanks!

0 Kudos
Highlighted
Community Manager
12 Views

Hi guys,

 

 

We would like to add some more information to what Bill has mentioned according to set up the correct pin multiplexing:

 

  • Refer to Table 2 for the GPIO numbers, the GPIO number for IO0 (UART1_RXD) and IO1 (UART1_TX) are GP130 and GP131, respectively.
  • Refer to Table 4, GP130 and GP131 must be selected to "mode1" to enable UART functionality
  • Refer to Table 7, GPIO248 must be set to 0 to disable the output direction and GPIO249 must be set to 1 to enable the output direction.
  • Refer to Table 7, GPIO216 and GPIO217 must be set as high-impedance inputs to disable the pullup resistors.
  • According to Table 6, the TRI_STATE_ALL signal is controlled by GPIO214, and before setting up any muxing, set this GPIO to low and at the end set it to high.

 

Please refer to the http://www.intel.com/content/dam/support/us/en/documents/edison/sb/edisonarduino_hg_331191007.pdf Intel® Edison Kit for Arduino* for extra details. Hope you find this information helpful. Also, Closet_Rambo, we're glad to know your UART1 port is working correctly.

 

 

Have a nice day!

 

 

Regards,

 

-Yermi A.

 

0 Kudos
Highlighted
New Contributor I
12 Views

Hi Closet_Rambo,

Question: did the pcal955a data sheet give you the clue about i2c and hence using i2cdump?

Question: how did you know how to interpret the i2cdump output so you could then come to the conclusion: "register 06 must be changed from FF, to FD in order to allow TX out from the Edison."

Regards,

Bill

0 Kudos
Highlighted
Beginner
12 Views

Bill,

The pcal9555a and 74lvc1t45 data sheets ... and the schematic for the Intel_Arduino_base_board were helpful.

It looked like all I needed was to set the bi directional level shifters (74lvc1t45) to the correct direction ...

... as well as setting up the internals of the Edison to get the UART1 out on the Edison pins in the first place.

Based on the defaults UbiLinux setup for the pcal9555a ... I worked out that the two registers, I had manually set, should make the bi-directional level shifters for TX and RX correct ... but it still did not work.

I assumed that the official Yocto image must have been set to allow UART1 out ... but I realize now that was a dangerous assumption.

Since the Arduino shield interface has many configuration for D0 and D1 (ala the ATMEL CPU's) ...

... there really was no way to know what default initial config Intel would place this in.

If I were Intel ... I would have wanted to place them in the most popularly used mode but I honestly don't know how to find out what that should be.

With this new info ... I will have to look over the docs more to see how this really works.

0 Kudos
Highlighted
New Contributor I
12 Views

Closet_Rambo,

I, too, have been struggling with my experiments using UART1 on Edison (pin 0 (rx, gpio130) and pin 1 (tx, gpio131)), and connecting it to an Arduino Uno. I have to do more testing before I ask a question.

I was wondering if I had to do the following at the command line before using Serial1.print:

cat /sys/kernel/debug/gpio_debug/gpio130/current_pinmux and for 131

To test that, I used a short Arduino script and some linux commands:

Serial.begin(9600);

wait while I executed: cat /sys/kernel/debug/gpio_debug/gpio130/current_pinmux ... and for 131

then Serial1.print(9600)

wait while I executed: cat /sys/kernel/debug/gpio_debug/gpio130/current_pinmux ... and for 131

What I saw was that before Serial1.print(9600), current_pinmux = mode0.

After Serial1.print(9600) current_pinmux = mode1.

Therefore I can ignore some of that gory echo stuff if I am using the Arduino IDE. I'll have to try a similar experiment with python and c with mraa.

I had accidentally had LEDs connected to pin 0 and pin 1. Nothing happened with the pin 0 LED but as soon as Serial1.print was executed, the pin 1 led, which is also TX, lite up. This was confirmed by:

cat /sys/class/gpio/gpio249/direction = out

cat /sys/class/gpio/gpio249/value = 1

cat /sys/class/gpio/gpio217/direction = in

cat /sys/class/gpio/gpio217/value = 1

For those new readers wondering where 249 and 217 came from, the short story is start your journey at Table 3 in:

http://www.intel.com/content/dam/support/us/en/documents/edison/sb/edisonarduino_hg_331191007.pdf http://www.intel.com/content/dam/support/us/en/documents/edison/sb/edisonarduino_hg_331191007.pdf

:

Question: what is your objective that requires that you understand the echo details and have to look at the pcal9555a and 74lvc1t45 data sheets, and the schematic (though that was a fun detour for me:) )?

Regards,

Bill

0 Kudos
Highlighted
Beginner
12 Views

Bill,

I just wanted to setup the Edison Arduino shield interface to use an Xbee.

It is an overly complicated affair.

Maybe someone from Intel will get the hint and make a Windows (and perhaps Linux) command line utility.

Create the command line interface from an Atmel Uno perspective such that you setup command line parameters for a pin on the shield interface you want to set.

0 Kudos
Highlighted
New Contributor I
12 Views

Closet_Rambo,

Ahhh, Xbee, something else to learn about.

I did a quick search and found the following. I don't understand Xbee and therefore don't know if it contains any useful information for you: https://learn.adafruit.com/xbee-radios/download?view=all https://learn.adafruit.com/xbee-radios/download?view=all

If you get things working and have nothing else to do, update this discussion with

Regards,

Bill

0 Kudos
Highlighted
New Contributor I
12 Views

Hi Yermi,

Regarding your comments on March 1st and the tables:

"Refer to Table 7, GPIO248 must be set to 0 to disable the output direction and GPIO249 must be set to 1 to enable the output direction."

I'm thinking we can't use 0 or 1 but instead must use in or out. To verify this I tried a few echos:

Looking at: /sys/class/gpio/gpio248

# ls -l

total 0

-rw-r--r-- 1 root root 4096 Mar 18 09:41 active_low

lrwxrwxrwx 1 root root 0 Mar 18 09:41 device -> ../../../1-0023

-rw-r--r-- 1 root root 4096 Mar 18 09:42 direction

drwxr-xr-x 2 root root 0 Mar 18 09:41 power

lrwxrwxrwx 1 root root 0 Mar 18 09:41 subsystem -> ../../../../../../../class/gpio

-rw-r--r-- 1 root root 4096 Mar 17 16:45 uevent

-rw-r--r-- 1 root root 4096 Mar 17 16:45 value

#

# the current value of gpio248's direction after booting

#

# cat direction

out

#

# using 0 or 1 results in an error

#

# echo 0 > direction

-sh: echo: write error: Invalid argument

# echo 1 > direction

-sh: echo: write error: Invalid argument

#

# in and out seem to work

#

# echo out > direction

root@edison00:/sys/class/gpio/gpio248# cat direction

out

# echo in > direction

root@edison00:/sys/class/gpio/gpio248#

root@edison00:/sys/class/gpio/gpio248# cat direction

in

# echo out > direction

root@edison00:/sys/class/gpio/gpio248#

root@edison00:/sys/class/gpio/gpio248#

root@edison00:/sys/class/gpio/gpio248# cat direction

out

#

# however, low and high don't generate an error message

# but both result in a direction of out

#

# the direction file is being changed because it's time stamp is changing

# but its value remains "out"

#

# echo low > direction

-rw-r--r-- 1 root root 4096 Mar 18 10:09 direction

root@edison00:/sys/class/gpio/gpio248# cat direction

out

# echo high > direction

root@edison00:/sys/class/gpio/gpio248# cat direction

out

#

# I see similar results for gpio216

# high and low both result in "out"

# but "in" results in "in" and out results in "out"

#

Question: should be therefore not use 0, 1, "low", or "high" and only use "in" and "out".

0 Kudos
Highlighted
Community Manager
12 Views

Hi Bill,

 

 

Thanks for asking it, please let me clarify that since it could be a little bit confusing. When I mentioned that those GPIO's must be set to 0 or 1, I'm referring to "low" or "high", and as you have checked using 0 or 1 directly is not a valid argument. I also used "low" and "high" in the code shared previously, these terms are used in the http://www.intel.com/content/dam/support/us/en/documents/edison/sb/edisonarduino_hg_331191007.pdf shield pin configuration examples as well. Now, I tested it and I have the same behavior as you have mentioned, so you could use "in" and "out" instead of "low" and "high" and it should work too.

 

 

Hope this information helps.

 

 

Regards,

 

-Yermi A.

 

0 Kudos
Highlighted
New Contributor I
12 Views

Hi Yermi,

Thanks for confirming what I found. This is another example of the documentation not matching reality and that costs you time.

When people run out of things to do, 331191007.pdf could use some changes:

Section 2:

talk about these directories

/sys/class/gpio

/sys/kernel/debug/gpio_debug

Where appropriate, any text that only mentions "low" or "high" should be changed to "in" or "out", for example:

table 3

table 4

Section 11:

for the echos involving /sys/class/gpio/gpio# /direction

not use 0 or 1

not use low or high

not use input or output

only in and out work.

Regards,

Bill

0 Kudos