Re: poe, serial communication and "half-duplex"

This sort of thing can be hard, with or without POE. I have dealt with similar issues in my home automation system which is based on POE. Check it out, you might also find some examples for doing general binary stream IO and parsing.  http://www.seanadams.com/ha/automogator/

One of my Wheels you might look at is Elk.pm, for my alarm system, which has an RS232 port that does not support flow control. You have to wait for each command to acknowledge before sending the next. That's basically the same problem as waiting for character echoes. I simply have a command queue where the next command is popped off the queue as soon as the previous one is acknowledged. You would do the same thing on a per-cahracter basis. Note that I was sloppy here and did not put my queue, among other things, in the heap as I should have. Also I planned on eventually having to deal with the case where I get an unexpected response, or no response, but that turned out not to be an issue. In your case the bus may be unreliable so you'll probably need to do something when you don't get the expected echo, eg delay and try again.

I also talk to Aprilaire thermostats which use a shared RS485 bus but again not exactly the scheme you're describing. These have specific timing characteristics because they use time division multiplexing to coordinate their responses, based on the address of each unit. Similar issues here, and these devices are really slow so I also use a command queue (I did put everything properly in the heap for this module). In this case though the outgoing command timing is driven by a fixed delay (command_queue_timer), because I know that the response will either come in the expected slot or not at all.

Before I learned about POE I have also done this sort of thing the old fashioned way with non-multitasking block/timeout. In some cases that can be simpler if you have a single task and don't need to respond to any other events. I have also rolled my own properly multitasking event loops but I wouldn't recommend reinventing that. POE makes it relatively easy to do the queue and also provides the timer feature that you'll probably need to handle errors/timeouts. 

On May 8, 2010, at 5:53 AM, e.waelde wrote:

> Hello,
> 
> I found out about poe only recently. I have tried to build a data-collector application,
> which queries a number of microcontrollers hidden behind one serial port, connected via
> rs485 half-duplex connections. Only modest success was achieved ...
> 
> It seems to me that I have stumbled across the fact, that the rs485 network is half-duplex.
> The wheel/filter combination needs to wait for the echoed characters during transmission
> (allthough that could be changed to no-echo), and after that needs to read up until one
> of two prompts appear in the response stream. In other words, sending and receiving data
> is coupled at the wheel/filter level. Every transaction needs to be secured with retry/
> timeout operations in order not to get stuck. Finally, the controllers are "quiet" unless
> they receive the correct address byte. Communication must be initiated with a special byte,
> on the perl side this goes as normal data (still 8 bit).
> 
> 
> Questions:
> 1. Has anyone tried something similar before?
> 2. Is it a good idea to implement such a system in POE at all?
> 3. How should I go about writing a "serial-half-duplex" wheel/filter?
> 4. are there other/better ways to setup a poe application? Probably yes.
> 
> Any ideas, pointers are highly appreciated.
> 
> Cheers,
> Erich