Prop to Prop problem

rixter

Hello,

I am very new to the Propeller, so newbie issues may be obvious here. I am trying to get a simple communication between two Propellers (a Propeller Demo Board and a PE Kit). I am using the FullDuplex Serial object to send a series of bytes from one Prop to the other and display using the Parallax Serial Terminal object. I've succeeded in most respects, but I'm having a frustrating time figuring out some extraneous (and or dropped) characters at the receiving Prop. My suspicion was improper buffering or timing. I've tried all kinds of insertion of delays on the sending and receiving sides to remedy the issue, but those attempts make the situation worse. The Transtest.spin and Rectest2.spin listings are attached. What I get on the Parallax Serial Terminal display are a sequence of Hello! lines and random lello! or Hello1 as shown below. Any hints or clues as to what I am missing are greatly appreciated.
Rick

Hello!
Hello!
Hello!
Hello!
Hello!
Hello!
Hello1
Hello!
Hello1
Lello1
Hello!
Hello!

Clock Loop

Two things, make sure you have pull up or down resistors on your tx/rx lines. All of the props I/O flail wildly due to no internal resistors.

Another thing, use .rxtime(1) mode, and program your .tx to only send every .75ms or so.
This prevents the rx loop from catching data in the middle of a tx loop.

The rx loop needs time to return to getting more data, so does the tx loop. The rx loop needs more time to return, this info and more is in in the fullduplexserial file

Wait a minimum amount of time before every tx, to let the rx loop process and copy the data into ram.

I found that using transmit "keys" also helps align serial transmission.
Basically, you begin your data with a known "key" that you use to not only align transmissions, but this also acts as a kind of crc, if the first byte of data isn't the "key" then you know that your misaligned, and need to wiat for the first key byte.

Cluso99

Sorry clockloop, but resistors are not necessary. The problem is not that.

rixter: Your problem sounds like the buffer is overflowing. When characters are not taken out of the receive buffer quick enough, a block of 16 will get lost as the buffer wraps around and begins to overwrtite the previous block. I suspect your spin code timing (I presume you are doing this in spin) is too slow. Just to prove this, lower your transmission rate to half that of the rate of the serial to the PST terminal. If you have a TV or VGA connected, it will be even easier to prove this is the problem.

In the OBEX is a FullDuplexSerial_RR004? of mine which allows you to have a much bigger buffer (up to 256 in powers of 2). Try this with a big buffer size and likewise you will see a different dropping of characters.

Humanoido

Clock Loop, you might want to put some code examples into Rixter's posted code and he can see if it works better.

Rixter, the circuit is very important along with the software. Some considerations are pull up, pull down, duplex, stop bits, parity, power, and the choice of resistor values. Also you need protection resistors on the pins. You could make a circuit hand sketch and photo it and post the photo. I posted a hand sketch of some useful interfaces for prop to prop communication here for a type of simple serial. See post #112.

Humanoido

Cluso is right - here's a list with his larger buffer serial driver and numerous others, depending on the functions you need.

MagIO2

Yep, newbie-problem! ;o)

In transtest you send in full speed, in rec test you receive and the do debug transmissions to the terminal. This of course slows down the receiver loop ending up in a full buffer as cluso99 said. If you want to debug this you should propably use a different protocol. The sender waits for a ready to receive from the receiver before it sends new data, if possible. If not you could also start another COG for the debugging.

rixter

Thanks all. I have a few things to try now.To answer a few poster inquiries, I am using Spin, I do not have any pullup or pulldown resitors in the circuit. I do have an inline resistor to protect the Prop pin in use. I have a "start" byte that I use at the beginning of the sequence of bytes being sent. It's the $ sign. My thought was that I could have the first Prop (the Demo board in my case), repeatedly sending a sequence of bytes... starting with a $ symbol... a value that would not normally be in my data. The receiving Prop was to loop reading bytes until seeing the $, then it would proceed to grab the next sequence of bytes representing the true data being sent. I got this concept from the GPS_IO_Mini code from the "Programming and Customizing" Propeller book. My thought was that a constant stream of bytes arriving at the receiving pin of a Prop could "synch" when reading the $ and rapidly grab the next bytes... 6 in my case, as one would do when reading GPS data. Of course this scheme DOES work, albeit not consistently in my case. So I presumed I was almost there. I got wacky results earlier on when I tried to slow the baud rate down from the 57600... garbage characters. I had also tried inserting short delays after each TX byte and also after sending the string of characters, but again, worse results. That lead me to believe I needed to have delays put in that made some sense with respect to the timing of the Propeller, not just inserting experimental pauses. What is interesting is that the junk characters coming across are generally the same. So I wouldn't call that random junk characters, but something that should be a clue as to what is happening. Earlier versions of this for example had me sending a sequence of decimal bytes to the Serial Terminal (numbers in my data), and a decimal 60 kept coming up. That is the ">" character, which is not in my data sequence. In this latest version I keep getting the "1" character... also not in my data sequence. It should be sending and receiving "Hello!". It may do that 20 times correctly then stick a junk one in. Or two good, two bad, 10 good one bad, etc.
Rick

Ravenkallen

Like others said. There could be quite a few problems. You should check connections, make sure the wire is not to long, lower the baud rate, check for stray emf.... Another test that i do, when i am dealing with serial communications, is to get a serial lcd of some sort. I then place that lcd on the serial line to see if the transmitting device is actually working. That test can prove a lot, especially when dealing with wireless communications...

rixter

I was finally able to solve the problem, although it would be nice for someone to explain the reasoning behind what the issue was. I hooked up a serial LCD as suggested by Ravenkallen because I was wanting to be sure the transmitting Prop was successfully sending all of the characters properly. I wanted to take the Serial Terminal out of the equation. But I still had the problem. By the way, I am unplugging and re-plugging the USB programming connection as I am fiddling with two spin programs, one in each Prop. Because I don't require the connection for the Serial Terminal purposes for the second Prop, I found myself one time forgetting to plug it back in. When I did that, everything cleared up. To experiment, I plugged it back in.... garbage characters. Unplug it.... clears right up. So even though the receiving Prop wasn't using Serial Terminal and that object was removed from my new spin program, having that programming connection in place is causing the Prop to lose characters intermittently. Obviously the Prop interacts with the programming port when something is plugged there and it's enough to throw off timing.

Thank you all for the suggestions and help.
Rick

Cluso99

Aha - there is an issue when the propplug is plugged into the pcb and not the usb (pc) end. The prop repowers at random because the output pin from the prop is powering the ftdi sort of. There is a thread somewhere that deals with this issue.

Clock Loop

In addition to the two wires for serial, are the Propeller Demo Board and PE Kit both using the same ground? How are you powering both?

rixter

My test connection is only using a single 22 gauge single strand wire between the two Props and I am not using a common ground. Today I used a length of Cat 5E wire (one strand of it), that is about 10-12 feet long and am running with total accuracy at 115200 baud.

The main thing I can't understand is why a dropping of the baud rate, while keeping all other code settings the same, can cause problems. So I can run fine at any speed from 38600 to 115200, but dropping to 19200 or lower causes problems. I had figured lower would also work better, albeit slower. Apparently when you slow the baud down enough, you have to fiddle with timing somewhere to compensate. Someone suggested rxtime(1) mode in Full DuplexSerial Object, but I had less success with that than using rx.

Rick

Clock Loop

You need a common ground for the communications to work properly.

The reason it works sometimes is because of capacitance and static charge, but that will be very unreliable. Even if it works at certain baud, eventually that will fail or get disrupted by sun spots, power grid spikes, your neighbor turning on their microwave, etc...

The amount of RF, EMI, heck, even the movement of your neighbor walking across their carpet, generating static electricity will reak havok on your communications when you have no common ground.

(electrons always need a way back to the source)

High voltage is one exception, but even then the electrons are jumping off into the air, or into other objects, albeit with very little current, limiting the baud rates that can be used with this type of high voltage no ground method of data communication (your basically talking about radio then)

rixter

Clock Loop,

I appreciate the advice. It will be well taken in this project. While I ended up getting reliable communications in my final experiment in that phase of my project, I realize I need to implement sound principles in the future to assure success in conditions less than what may have been just an ideal sampling.

Thanks again for the contribution.
Rick