Communicating using Display Return Protocol

LK/ELK/VK/PK/OK/MX/GLK/EGLK/GVK/GLT Series

Moderators: Henry, Mods

Post Reply
woodman120
LCD?
Posts: 5
Joined: Tue Apr 26, 2005 9:55 pm
Location: Anaheim, CA
Contact:

Communicating using Display Return Protocol

Post by woodman120 »

I am using a rabbit core module with C code to send and receive RS232 data with an LK-202-25. The display has the dallas 1-wire bridge and I purchased the 18S20 temp probe with it. I have reviewed the 1-wire tutorial posted on the forum and understand the bytes I need to transmit to the display. The question I have is how I receive the data via the DRP. After sending the transaction command to write and read the data, I can issue a read serial command but I don't know if I need to use handshaking to make sure I receive all of the data bytes. Can someone tell me how to retrieve the data correctly?

Paradigm
Matrix Orbital
Matrix Orbital
Posts: 255
Joined: Thu Sep 13, 2001 6:00 pm
Location: Calgary, Alberta, Canada

Post by Paradigm »

First off, I've never used the rabbit core, but I'm hoping that what I say is generic enough that it will apply to all microcontrollers .

RS232 handshaking (both software and hardware handshaking) was really done with a particular setup in mind. A PC talking to a slow/dumb peripheral. There really is only the ability of the peripheral to tell the PC "Stop sending information, I can't keep up!". Handshaking was never applied to the reverse direction, because it was assumed that the PC was fast enough.

With a microcontroller(MCU) in the PC role, this isn't always the case. Since flow control doesn't apply to anything the display returns, you have to make sure that your program buffers everything it can. There are a couple of options, depending on what facilities your MCU affords you: interrupt and polling.

The interrupt method is by far the best method if you can hook interrupts. You setup the interrupt to trigger whenever you get a byte of information over the RS232 port. Your interrupt handler then takes that byte and shoves it into a buffer.
Pros:
- Since interrupts preempt your code, it is assured that you'll get every byte.
- Don't have to wait for information in your code.
Cons:
- You need to be able to hook interrupts, which some MCUs don't allow.
- It's more tricky to setup.

Polling can be done on virtually any chip. When you're expecting information back you can put the MCU in a tight loop that simply checks to see if new information has been received, and then stuff it into a buffer.
Pros:
- It's very simple to setup.
- It doesn't require any functionality of the MCU.
Cons:
- Your program has to sit and wait for information.
- It also has to know when to stop waiting for information.

The DRP does allow for both methods. Since it returns the length of the packet in the header, and if there will be more information coming, you can use polling if you can't use the interrupt method. Make sure you receive 4 bytes. The third one will tell you how much more after that to receive in this packet, along with if there will be another packet coming.

1-wire also provides CRC8 checks to make sure the data you've read is valid. For instance from the tutorial an enumeration returns something like:

23 2A - #* Signature
0A - Length 10, not continued
31 - Type: 1-wire packet
00 - Status: Success
[8 bytes]
00 - CRC OK

If that last byte (CRC OK) isn't 00, something is wrong. Similarly the 18S20 will return a CRC at the end of it's scratchpad, which you can ask the display to check for. Again from the tutorial:


Receive from MX: 23 2A 0A 31 00 [9 data bytes] 00

Breakdown:
23 2A - #* signature
0A - Length: 10 Bytes
31 - Type: 1-wire command
00 - Status: success
[9 data bytes] - see the DS18S20 data sheet for the format
00 - CRC 0K

If that last byte isn't 00, again something is wrong. So you can use the CRCs in the 1-wire protocol for a further check to make sure you got every byte.

In summary, a few suggestions:

- Use interrupts if possible, it will assure that you get every byte.
- If you have to use polling, make your polling loop as tight as possible so you don't miss any information coming in.

Hope this helps.
James McTavish, P.Eng
Director of Engineering
Matrix Orbital

woodman120
LCD?
Posts: 5
Joined: Tue Apr 26, 2005 9:55 pm
Location: Anaheim, CA
Contact:

Not finding probe

Post by woodman120 »

I set up a simple program in C that seems to handle the serial communications properly. Here is the section of the code.

while (1) {
costate {
sprintf(tempstr, "%c%c%c%c%c%c%c%c", 0xfe, 0xc8, 0x01, 0x01, 0x10, 0x00, 0xcc,0x44);
printf("Wrote fe c8 01 01 10 00 cc 44\n");
nread = 0;
serCwrite(tempstr, 8);
waitfor(nread = serCread(ansstr, 39, 100));
printf("Read ");
for (i=0; i < nread; i++) printf("%x ", ansstr);
printf("\n");
}
}

The output of this program gives me the following displayed on my stdio.

Wrote fe c8 01 01 10 00 cc 44
Read 23 2a 1 31 2
Wrote fe c8 01 01 10 00 cc 44
Read 23 2a 1 31 2
Wrote fe c8 01 01 10 00 cc 44
Read 23 2a 1 31 2
...

This is telling me it doesn't see any devices but I do have a DS18S20 connected to the 1 wire connector on the display. I tried it with two different DS18S20's with the same result.
Any ideas?
Richard.

Paradigm
Matrix Orbital
Matrix Orbital
Posts: 255
Joined: Thu Sep 13, 2001 6:00 pm
Location: Calgary, Alberta, Canada

Post by Paradigm »

When you send a reset pulse to a 1-wire device, it is supposed to wait a specified time, and then pull the line low to let the host know that something is there (this is called the presence pulse if memory serves me). The display isn't seeing this pulse for this code to appear. If you have oscilloscope, it would be easy to check this out for yourself. Some other troubleshooting tips:

- only have one probe at a time (until you have it sorted out)
- double/triple check your wiring
- try a different probe, I've had a bad probe do this to me many times

Your code looks correct to setup the temperature. The other command I'd try is the 1-wire scan command: FE C8 02 and read back what IDs you have on the bus. Although it would probably return a code 02 as well. Bottom line is that I believe your problem is hardware based, and you have a problem with your wiring/probes.
James McTavish, P.Eng
Director of Engineering
Matrix Orbital

woodman120
LCD?
Posts: 5
Joined: Tue Apr 26, 2005 9:55 pm
Location: Anaheim, CA
Contact:

Debugging the 1-wire

Post by woodman120 »

I did try the FE C8 02 and got the same reply from the display. The display only has 1 connector to hook a probe up although I figure I could chain other probes together and so I have been only using one probe at a time. What I did was switch to a different probe that I bought. It still gave me the same result. There isn't much wiring to look at. Other than the rs232 wiring, there is just the connection of the probe to the dallas-1-wire connector. I don't know what wiring I can check. I have been able to write to the display without any problems.
When I send these two commands (the FE C8 02 and the FE C8 01) to the display, it should be resetting the bus, correct?
I do have an o-scope but I need some help on how to see what is going on. (I'm a programmer more than an EE or Computer Engr). Can you give me some help on that part?
Thanks,
Richard.

Paradigm
Matrix Orbital
Matrix Orbital
Posts: 255
Joined: Thu Sep 13, 2001 6:00 pm
Location: Calgary, Alberta, Canada

Post by Paradigm »

An oscilloscope, EXCELLENT :D

The data line should idle at +5v. When you send an FE C8 02 command it will perform many transcations and resets on the bus. (BTW I'm hoping that you have a digital scope, since an older analog one is kina useless here). Setup the scope to trigger with a negative going pulse at around 4v. The timebase should be somewhere around 100us/div. Move the tigger point towards the left side of the scope.

If you capture a single event (typically called "single sequence") you should see:

a low pulse over 480us, then a high section of 15-60us, then another low section of 60-240us. The second low section is the presence pulse. The presence pulse is a result of the devices pulling the bus low after a reset to let the master know that something is on the bus. It is critical that this pulse be returned. If it isn't being returned, then you've only got a few options left:

- You've wired the device wrong at some point, and fried it.
- You have the device wired wrong, double check that you have the correct pins going to the correct locations.

But I'd check it out with the scope and see what happens. If you have any questions, feel free to post pictures of the scope capture (or email them to me).
James McTavish, P.Eng
Director of Engineering
Matrix Orbital

woodman120
LCD?
Posts: 5
Joined: Tue Apr 26, 2005 9:55 pm
Location: Anaheim, CA
Contact:

+5V, Gnd Problem

Post by woodman120 »

I was about to start checking through the oscilloscope and I thought I would just double check that I was getting the voltage across the Dallas 1-wire header on the LK202-25 display. When I checked it, I found that the polarity was reversed from what the manual states. This seemed strange and there is only one way to connect the probe connector to the header. I pulled the pins out and reversed the ground and power and guess what, I got a response from the probe. The only problem was that the temp readings were all coming out wrong, so thinking that the probe was probably fried, I switched to a different probe, switched the yellow and red leads and it worked. I cycled the probe through some temp changes and it worked fine. The strange thing about this is that the board I received has the terminal wired backwards between +5 and gnd. Am I the first to notice this problem? I know that the Dallas 1-wire is a new option on the board. I wasted a probe when it wasn't even my fault. I appreciate all of your help with this. I got a lot out of your tutorial.
Thanks,
Richard.

Paradigm
Matrix Orbital
Matrix Orbital
Posts: 255
Joined: Thu Sep 13, 2001 6:00 pm
Location: Calgary, Alberta, Canada

Post by Paradigm »

I'm glad you got a lot out of my tutorial (I hope other people do too), but I'm more than a little embarrased to hear that something doesn't line up in the labeling :oops:. I'll be investigating this first thing tomorrow morning.
James McTavish, P.Eng
Director of Engineering
Matrix Orbital

woodman120
LCD?
Posts: 5
Joined: Tue Apr 26, 2005 9:55 pm
Location: Anaheim, CA
Contact:

Post by woodman120 »

It's not that the labeling is wrong. The manual shows the correct location of power and ground, however the board is incorrect. The pinouts on the board for power and ground are swapped and are not compatible with the pinouts of the dallas probe. In order for me to use the board, I have to change any probe I use to swap the yellow and red wires.

Miles
Matrix Orbital
Matrix Orbital
Posts: 1105
Joined: Mon Mar 04, 2002 4:00 pm

Post by Miles »

I apologize for any confusion regarding this matter. It appears that a small quantity of PCB's were released with the temperature probe connector incorrectly installed. Thank you for making us aware of the situation and if you have any further questions or concerns feel free to contact me direct at myer@matrixorbital.ca
Miles Y.
Head of Technical Support
Product Manager
Matrix Orbital

Post Reply