Thanks for your interest in the Intel® Edison platform.
It is a strange behavior and we would like to know if you have checked the RX and TX signals using a logic analyzer or oscilloscope in order to know how those signals are behaving while you are writing and reading data from your Edison to your device. Doing that will help us in troubleshooting this issue.
I think we may have seen something like that too (on the oscilloscope too). Have you tried powering off the edison and then back on (If I remember correct pressing the reset button was not enough).
I do have what you need for the input to Edison (RX) from the device I'm working with.
I have no issues with the transmission itself.
This effect of receiving a sequence of 0xFF for a read, executed after a write, only occurs when I work with a specific device (namely, a Nextion display).
It's important to note that Nextion does not send these strange bytes and they are not on the wire (see diagram).
I should also mention that this device emits a HIGH signal in idle mode.
It might be worth mentioning that when I start a program on Edison, I get a 0xFC byte on the TX of UART0.
Also, upon initializing any GPIO port, I likewise get a 0xFC byte on the TX of UART0. The initialization is done with the mraa_gpio_init() function of the mraa library.
cyrillicsoft it's coming back to me now. I think we had the problem when we were building with the sdk, which links to mraa 0.7.2. We fixed that by overriding the initialization in main.c by the code in hs_serial.c see GitHub - htot/hs_uart .
I think I read that this has been fixed in later versions of mraa. But instead I will be working to remove the dependency on mraa, so that this code will run on vanilla kernels as worked on by Andy Shevshenko GitHub - andy-shev/linux at eds
Thanks for the information provided. We would like to investigate a little bit more and as soon as we have useful information we’ll let you know. We’ll appreciate your patience during the meantime.
Additionally, Could you please try FerryT’s suggestions and keep us abreast of your results?
What FerryT has suggested is more or less what the "Using MRAA to Abstract Platform I/O Capabilities" book describes (this is a book by Integrated Computer Solutions, ics.com). I have already tried realizing this but it didn't help.
I found it a bit strange that the book recommended using the C read and write functions while working with the UART and not mraa_uart_read and mraa_uart_write functions...
Nevertheless, I took hs_serial.c and used it to initialize the UART port. But nothing changed.
I should reiterate the strange behavior I have been getting:
If I make sequential reads off RX, then all the data is read correctly.
If I transmit data through TX, then the following read will return a sequence of 0xFF followed by the expected data.
The amount of these 0xFF bytes is always a little larger than the amount of bytes I sent through TX. For example, the write sends 42 bytes and the read immediately after that returns 47 bytes. Moreover, I cannot see any mathematical dependency.
In addition, I find it strange that I would receive a 0xFC on TX after starting a program and after every mraa_gpio_init() call.
cyrillicsoft It is not that I am recommending to use mraa, in fact I will try to remove mraa dependencies from my code as soon as I can.
We found that when using mraa 0.7.2 we had similar problems to yours: with tx looped back to rx, we were receiving many 0xFF chars, so many in fact that the received buffer overflows and eventually the Edison reboots (we were transmitting 2kB). BTW my colleague remembers it differently, he says the problems was caused *because* we were overflowing the tx buffer. Anyway, the 0xFF chars were actually transmitted and visible on the oscilloscope.
As we did not have that manually initializing the serial port, we fall back to the routine in hs_serial.c (and increased the tx output buffer in the kernel from 2kB to 4 kB).
BTW our GitHub - htot/hs_uart transmits data periodically and the period needs to be set longer than the time to actually send the data.
In most other protocols you would only transmit the next message after the receiver confirms reception. Or use XON/XOFF, or HW flow control.
mraa_uart_read does not do much special.
0xFC is probably generated by toggling the TRI_STATE_ALL signal (is controlled by GPIO 214). This is done when setting up gpio (but also during uart init). Then this triggers a UART start bit causing a spurious char reception. So you need to setup all io's uart etc, open the uart and flush the buffer. But not change pin configuration after that point.
My case is undoubtedly very similar to yours and I did find a software solution to it as I have done for the 0xFC issue which I handled just as you suggest.
Using XON/XOFF also solves all problems but it does demand that the device support the protocol.
Unfortunately, the Nextion display I'm working with does not have that capability and I really don't want to put it aside as it really simplifies the process of creating GUIs and works on just two wires.
The guys in China have sure made a very ingenious and handy device.
Concerning mraa, I didn't really choose it, it was recommended by Intel and since I've been familiar with it's products since '87, I've grown quite close to it. It would be upsetting if they do indeed disappoint...
I hold that it's easier to simply fix all of the weaknesses and flaws in mraa because there is nothing that you can't improve or correct. I hope Intel think likewise.
I'd also like to wait for Intel's reply on my issue.
Have you tried upgrading mraa to a more recent version? I think the uart initialization problems have been solved in a later commit.
My version is 1.5.1. Intel considers this to be the most suitable for Intel System Studio IoT.
We did some tests using two Edisons and communicating them through the UART interface, the first Edison sent two messages to the second one and waited for a response, the second one received those messages and then sent the response to the first one. We checked the UART signals using a Logic analyzer and we have received the data successfully, we didn’t receive any 0xFFs.
This is the code we used: uart_sender.py and uart_receiver.py, we know that you are using C++ and in this code we are using Python, however, you could use them to test your Edison’s UART to discard any issues. Additionally, you can use that code as a reference to write your C++ code.
You might want to try doing the same with a message length > 2048 bytes (that is in one write).
Thanks for the time that you have put aside to help me.
Of course, there is no difference whether I use Python or C++ because everything is eventually carried out by the OS.
Your tests were always going to be successful because if they weren't, you'd have been flooded with questions similar to mine from other users about a faulty UART.
My question was about Edison's behavior in a special case i.e. when it communicates with a Nextion display unit. In other words, these 0xFF bytes don't appear in ANY case you can think of, but in my specific setup (and maybe there are other possibilities).
Obviously, you might not be able to check Edison's behavior with this device, I wasn't hoping that you would try to go to such lengths. I thought that just by describing my issue, using your experience, you might be able to advise me on what to do next and where the issue might possibly lie.
If there are no concrete ideas, I'd like to ask this: what signal does Edison expect to receive while in idle mode? HIGH or LOW?