Debugging USART using Saleae logic probe

[Demon]

A simple way of viewing USART transmissions when you're already using a Saleae probe.

HSEROUT [DEC5 varTimer1, DEC5 varTimer3]

Activate the serial analyser at the bottom right of the Saleae window.



In this example, 2 values are displayed at the top of channel 0. Yes, I'm embarassed to admit I just noticed this feature.

Robert

[LinkMTech]

Embarrassed? I think it's exciting to find new tools and uses!
How do you like your Saleae? I think it's money very well invested and has saved me so much time and headaches especially when it came to watching DT's interrupts at work.

[Demon]

I love it. I'd prefer the 16, but the basic 8 channel model is more than enough for the hobbyist.

I have 2 oscilloscopes. I don't use them enough to remember how to calculate the time bases to get hertzes. I take them out whenever I want to test switches and debouncing though.

I'd love a USB scope, but money is real tight so that's out of the question until I win the lottery.

Robert

[LinkMTech]

I thought about the 16 also but couldn't imagine what I would test with all those yet!
I barely hit 6 while playing around with an accelerometer + gyro, DT's INT's, test points, etc..

[Demon]

I've been doing my testing and research in the kitchen using my laptop this winter; it keeps me closer to the family.

Problem is my laptop has the wrong sex serial connector so I can't use the same cables I've been using on the desktop PC downstairs. Of course I always forget to buy an adapter and was forced to use an LCD to debug.

And this is where things got tangled with this project; all my pins are busy except RX1/TX1 which will be used for comms. No problem, I pulled out another breadboard that has an LCD and will display there. Wrong, can't figure out why data isn't sent properly.

The Saleae confirmed that the message leaves the master just fine so it's 50% solved (picture above). The data is lost as soon as I connect the slave PIC. The sad part is that I had all my breadboards talking together just fine last summer but I'm apparently too dense to figure this one out. Yes, I was using these same PIC models too, argh....

Robert

[Demon]

I spent all afternoon and then some yesterday trying to get these talking.

Had them working in 5 minutes after posting. LOL

I gave up and did the equivalent of stopping and asking for directions; I looked at my code from last summer real close and noticed this comment:

'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
'                   RX must be input or else USART disrupted                   x
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I can't remember where I got this (didn't notice in the manual if it was there), but that was the problem.

Robert


EDIT: Now I remember, it was from the datasheet:

For all modes of EUSART operation, the TRIS control
bits corresponding to the RXx/DTx and TXx/CKx pins
should be set to ‘1’. The EUSART control will
automatically reconfigure the pin from input to output, as
needed.

[ozarkshermit]

Not related totally, but I absolutely LOVE my Saleae Logic.

I just used it again today to determine some Infra Red codes from a remote transmitter. I don't use it all that often, but it has helped solve some otherwise very troublesome problems.

Ken

[Demon]

Neat. Can you provide details how you did it?

It's one of those things on my To Do Whenever list.

Robert

[ozarkshermit]

Sure - not much to it actually.

What I want to do is determine what the hand held IR remote sends to one of those programmable , scrolling led
signs that you can put in the rear window of your car, or whatever. All I I want to do is to start any already
programmed message, using a PIC instead of the hand-held remote.

I breadboarded a TSSOP type infra red receiver, and connected a single Saleae channel to the output. Then just
pushed any button on a hand-held TV remote for a moment, and captured the pattern. From there it was easy to
duplicate the pattern, using a short program turning a single output off and on, using pauseus delays to match
what the remote sends out. The PIC output pin will be connected to an IR transmitter, to "talk to" the sign.

I have written a simple test program to do this, coupling a PIC to a simple IR transmitter.

I haven't finished this project yet, still waiting for the scrolling sign. However, I have been able to easily duplicate
some transmission patterns from a TV remote, so the next step should be relatively easy. I only plan on "cloning"
a couple of different transmissions, not the entire keyboard, although with enough patience that could be done.

I know there are some perhaps simpler hardware solutions to this, to "learn" what the transmitter sends out, but
this is was a drop-dead simple answer (for me).

[Demon]

I must have several obsolete remotes lying around in the basement. What exactly do I want to scavenge out of them? Is it only that clear LED-looking-thing that is necessary?

Robert

[ozarkshermit]

Robert:

Any of the old remotes would probably work to experiment with for a transmitter. They would all have the related protocol for whatever device they were controlling, but that wouldn't matter, if you just want to prove out the method you use to capture the output on the Saleae. Yes, the LED is part of the transmitter.

You need a IR receiver as well. Some folks just use a photo transistor, I would recommend a good IR receiver, since they have additional features built in. I am using a TSSOP 32338, but there are a multitude of receivers available.

Here are a couple of good links on this subject:


http://learn.adafruit.com/ir-sensor

http://www.robotshop.com/blog/en/bui...e-decoder-4254

http://www.pic-tronics.com/IR-Transm...d-Receiver.php

If you want, I can post a couple of screen shots of my results, first a sample of an actual transmission from a TV remote, and then one of the duplicates using a PIC to output the pattern.

Ken

[Demon]

10 years later and I'm still loving my basic Saleae logic probe. It was invaluable to help me figure out what's going on with these encoders.

- noticed jitter on 2nd circuit on chinesium double encoder when I move other shaft,
- spent all day going through my code, turned out the 2nd channel is also dropping pulses.

I can't imagine life without it (top pair at PIC, bottom at encoder pins).




Pulses are inversed because I use a 74HC14 after Bourns debounce to clear up signal.

[richard]

the saleae can just as easily miss pulses as anything else if the sample rate is too low, re's need a high rate i use 12-16 Ms/S to be sure

[Demon]

Nah, I just rechecked with a setting as fast as it goes and the encoder is acting up:

- slight movement of shaft affects other circuit,
- missing pulses on 2nd circuit.

I'll have new EC11 PCBs coming in a week (silkscreen of 1st batch is wrong - D'OH! ), I'll test a few other EC11 double-shafts then.

It's not like I'm lacking tasks and chores to do until then.

[Demon]

It seems the USART analyser (Async Serial) has been updated since I last used it - the formatting has changed a bit.

Again proved invaluable to see if my data was being sent properly.

I love that feature of right-click on the red line of text, so I can quickly switch from Decimal to ASCII.