Another SERIN hang question - On a 28X1 w/ Timeout!

[GDSever]

I have a 08M sending information to a 28X1 using SEROUT / SERIN, and the timeout setting works great - so long as the two picaxes stay connected. As soon as the connection is broken (unplugging one from the other) the 28X1 hangs, due to what I can only guess is the floating nature of the pin.

I know there are other options for dealing with this scenario such as using the hserin to the scratchpad or setting an interrupt, etc- but is there some other way to keep it from hanging? Maybe a 10k pulldown resistor (using N1200) or something that will keep the pin from floating and registering serial communication that isn't really present?

 

[BeanieBots]

I think you've answered your own question. Just add a pull-down (or pull-up depending on your polarity) resistor. This is good practice anyway if there are sections which can be seperated.

 

[GDSever]

I'm using inverted, so I assumed I wanted it to idle low (hence the pull-down). "True" (like T2400 or T4800) would require a pull-up, right?

Thanks for the advice! If I get this solved then I can focus on why 1200 baud works great and 2400 is a disaster.... CALIBFREQ may be in my near future...

 

[hippy]

Nxxxx baud rates idle low, active high, so need a pull-down R

Txxxx baud rates idle high, active low, so need a pull-up R

If slower baud rates work but higher baud rates don't there are two issues to look at first -

The slew rate of the connection. If the signal rises or falls slowly what gets read is not always what was sent. This usually occurs where there is a long connection between the two or capacitance on the line. Also where serial out passes through a diode and there's no pull-up or pull-down ( such as when diode-mising two serial streams ).

The rate of data being sent / the speed at which data is received. Not how quickly each byte is sent ( baud rate ), but how much time there is between bytes. SERIN will only receive correct data when it has been executed prior to SEROUT being executed. As the baud rate increases a receiver has less time to get ready for the next byte sent.

At 2400, slew rate shouldn't usually be an issue so data rate is one thing to check for. Add pauses between sending bytes to see how that affects things.

 

[GDSever]

Thanks for the advice on where to look first... should be helpful in diagnosing the issues.

The 08M only sends data. It checks some digital inputs (level float switches), reads a LM34 temperature sensor, then sends the information serially using 4 data bytes. The actually transmission is "UUUUU<G>____" where the ____ are the 3 bytes representing float switches and temperature and a checksum byte... I used the UUUUU to help balance the communication with 1s and 0s, the <G> to act as a qualifier.

It travels through a twisted pair telephone cord that I've made as long as 8' before. The middle pair carries the serial transmission back to the main circuit, and the outside pair carries 5V and GND to this satellite circuit. The 08M circuit board has several capacitors on it to even out the power once it is delivered, and seems to do a very good job...

Once it hits the main 28X1 circuit, that's where the 28X1 reads in the information (provided its being sent) as part of another loop that is taking additional measurements. My hope was that if the external circuit wasn't plugged in, it would just jump past the SERIN once the timeout value was exceeded - Looks like that pulldown resistor might have been an a missing piece to the PCB design...

Based on what I described above, could the 8' of wire be a source for my 1200 vs. 2400 baud problem? I'd like to even get it up to 4800 baud, but so far 1200 is the only speed that has proven reliable...

I'm pretty new to inter-IC serial comms, so this has been a good learning experience.

 

[hippy]

The length of cable could be a problem. Easiest solution there is to try it over a short length at high baud rate and if that works but it doesn't over a longer distance, there's your answer.

There are ways to do what you want, the 08M to tell the 28X1 there is data coming so the 28X1 only enters SERIN when there is data which will arrive. There are previous discussions on he forum but the principle is -

1) Assuming the signal is idle low, nothing being sent ...

2) 08M sets the line HIGH, the 28X1 sees this as an interrupt, enters its receive handler and executes a SERIN.

3) The 08M waits long enough that the 28X1 will be executing SERIN and then executes its SEROUT.

4) Because the line is high when both SERIN and SEROUT start to execute they will need to use Txxxx bauds.

5) When the 08M has finished its SEROUT it sets the line LOW so it won't re-interrupt the 28X1 until it needs to next time.

6) When the 28X1 has finished its SERIN it waits until the serial in line has been returned low. It the exits the interrupt routine.

This basic system can be improved upon and it is even possible to have a return handshake to minimise delays and bi-directional comms can be done over a single line, but this is the basic starting point.

 

[GDSever]

thanks for the guidance, hippy.

I was trying to steer clear of the interrupt approach for this application due to the nature of the main board - ultimately I wanted to incorporate functionality to change setpoints remotely on the 28X1 through a different serial comm (with a PC), and I didn't want the 08M communication to override that one... Hence the "dumb signal" approach where the 08M was continually pushing out new data and it was up to the 28X1 to just grab it when it could....

But I will certainly consider some recoding to try out that approach as well. It wouldn't require me to change the hardware, so I could always come up with something else later when the remote setpoint functionality was a requirement.

 

[hippy]

You don't have to use an interrupt, you can poll the input line to see if it is high or not, continue or enter SERIN. The only risk is in seeing a trigger, entering SERIN and in that time finding data is already being sent which then gets corrupted, lost or hangs in SERIN until the next data is sent by the 08M.

It's all doable but can get a little complicated. It's more about dealing with errors and failures which can cause lock-up and hangs than anything else. Like expecting someone to knock on the door and say "hello", if the knock comes, you open the door and no one's there, or they say "iky", what to do next, how to recover.

 

[MPep]

Of course Manuka would advocate the HopeRF modules (wireless) in situations where the distances become too great for cables.

Stan, good article in SC.