If you are using the XDK, you can use the UART with the MRAA library. First, I suggest you to use the latest image and latest XDK. The XDK should be the 2571 (upper right corner of the XDK IDE) and the image is 159.devkit (run configure_edison --version in the Terminal Console).
Once you open the XDK you can choose one of the templates there, select the one named (UART) Serial Read/Write, that one will give you an idea on how to start. You could test it by wiring the Tx and Rx pins.
You can more information here:
Thanks for the response! Well, that's exactly what I'm doing. I'm using the latest XDK and the MRAA library, wired the device to the Edison board TX/RX pins but apparently no data is being sent by the Edison board. I'm supposed to send a hex value requesting for a data stream (using write) and then listen for the response. However there's no response from the car's ECM.
All this is about reading a car's ECM data stream. May be I should ensure data is coming out the Edison pins in the first place. How can I do that?
Which expansion board are you using?
Which pins are you using?
Also, is the example that I mentioned before working?
You can check the output of the Edison by using a Logic Analyzer or an oscilloscope. You can also wire the Rx to the Tx of the Edison Module in order to check the output of the Edison
Thank you for the response.
>>Which expansion board are you using?
Arduino expansion board.
>>Which pins are you using?
0 and 1. Labeled RX and TX respectively.
>>Also, is the example that I mentioned before working?
Well, I noticed there's a template for UART usage, however how do I check if something is actually sent, That's part of the problem. It's possible to do some sort of loopback to check that? or how how can I check? Some simple resistor and led can do the trick? is the pin activation (via shell scripting) required?
You wrote: It's possible to do some sort of loopback to check that?
That's exactly what Mata_Intel meant by "You can also wire the Rx to the Tx of the Edison Module in order to check the output of the Edison"
I highly suggest you take this one step at a time. Verify there's an output on the Edison on the pin you expect, then if that makes it to the correct pin on the Arduino, etc.
One fundamental question: Is the physical interface between the car and the Arduino the same level? "Real" RS-232 (swings from -V to +V), or some variant?
Yep, you're both (Mata_Intel) right, I'll place a jumper to bridge those two pins together and check if something is coming out of them. I'll also build a small logic tester to check when everything is installed on the car.
>>Is the physical interface between the car and the Arduino the same level? "Real" RS-232 (swings from -V to +V), or some variant?
Well, it's supposed to be. The car's ALDL port is wired to a Maxim's 233 chip to convert to RS232 levels.
Stay tuned please, I'll try the loopback test after work.
I don't know how much you know about RS-232 so please bear with me.
RS-232 seems simple, but there are a lot of things to get correct.
- Baud rate
- Bits/parity/Stop bits (usually identified as "8N1", which means eight data bits, no parity bit, one stop bit)
- Flow control
- The physical layer (crossing the streams), see below:
(Hopefully I have all the details correct)
True RS-232 idles at negative voltage. With no data, a TXD line should sit at -3 to -8V or so.
So with your Arduino and the car NOT hooked up, you should be able to measure (with a scope or DVM) each RS-232's TXD pin and see that voltage. If the voltage is bouncing around it's possible the device is not "idle" and is instead, actively transmitting.
When you then properly connect one device's TXD (output) to the other's RXD (input), that negative voltage should remain.
One common problem with RS-232 is getting the TXD and RXD crossed (sometimes the manufacturer's labels are, ahem, misleading). If this connection is mixed up, you will not see that negative voltage on both interconnections. In fact, in this case (of miswiring) the two connected TXDs will show -V and the two connected RXDs will be floating (or some other unknown state).
(Note: In my experience, it's unlikely to have caused any harm by the way, to have them mixed up. It just won't work.)
Another experimental option would be to use a PC and terminal program to see if you can successfully identify the data. In this case pay particular attention to the flow control setting.
It's on the Internet so it must be true. LOL
I would like to know if you tried the loopback test and if you looked into the information provided for Mike.
Also, does the device/car you have use a specific communication protocol?
Yes, did the loopback test and it works! Used the UART template inside the XDK and just wired the Tx,Rx pins. The callback returns the data sent. Following Mike advice, I'm taking this a step at a time and performing tests as I go forward. Now that the Edison is sending and receiving data I'll test the RS232 circuit by sending the same data and checking if it goes out.
Next, will try to cmmunicate with th car's ECM. That will require a bit of trial and error since all I know is the ECM expects a string of hex values (something like F5400B8A1C) to start sending a stream of engine and transmission sensor data.(64 bytes ) however I don't know if it is necessary to send F5 first then 00, then B8, etc...
Stay tuned and will post the results next week.
Checked the RS232 circuit and a stream of data is going out. Not sure if the correct data or in the correct RS232 format (No access to oscilloscope) but something is going out as evidenced by a logic probe. Did receive data back, apparently not the one I expected to see but at least the car is communicating with the Edison board.
I'm going to analyse the received data to see if it is meaningful or if it is only random data. All I know is it looks like trouble codes, not sensor data stream. I'll keep experimenting and researching how to properly send the data stream request to the car PCM and in the proper format (hex required) as well as how to properly decode it back.
Will update the post in the following days.
Thank you all, and Happy 2016!!
You might get some help from an inexpensive RS232-USB adapter. I've bought several on eBay for under US$10.
Then you could use a PC (laptop) to capture the data and mess around with baud rates and other settings more easily.
GL and NY 2016!
The discussion is really interesting because I also tried using the UART and got a strange behaviour:
-Loopback works fine
-Tried using a Lora Module (First step in LoRa land – microchip RN2483 test » disk91.com – technology blog)
-->Lora Module did not work so tried several things, the conclusion is:
-the Intel Edison does not receive anything if send something to the module
-the Edison receives data if the commands are sent to the Lora Module from terminal (Realterm)
-a deeper analysis showed that the intel edison first sents an "FF" at the TX Pin?! (Maybe a problem with the Uart Init?!)
So refering to the topic it would be interesting to know if the UART works in your application
If not I suppose that your first received data is an error because the UART-Command is unknown
Unfortunately I had not time to fix the UART problem with the Lora module...
Have a nice day
about RN2383 and Edison:
- may you provide a circuit diagram you use?
- do you use pull-up resistors (external or embedded) ?
- do you use RESET pin of RN2383?
- may you measure a voltage on Rx and Tx pins when there is no data transmission?
Wow! Hope not having such issues. It turns out the RS232 serial interface output was connected on the wrong pin on the ALDL connector, Going to try again on a different pin after work and post the results.