IrDA Communication

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I actaully want to control IrDA from .NET using C#. It is actually not the
Compact Framework but I am posting to this forum as the CF community seem to
have a better understanding of IrDA.

I want to be able to write to and read from the IrDA port asynchonously.

I have a number of concerns about receiving data, I think this is the
possible ways of receiving from the IrDA port:-


1. I don't know if it is possible but I would like an event to be generated
when a message has been recieved. i.e. event driven message handling for
received messages. I have not seen any mention of this anywhere.


2. I do not want to poll on a received message because that would lead to
unecessary processing.


3. I could block for a received message. But that would mean that I could
not transmit data because I think it would lock out usage on the port. Can
anyone confirm this.




I think that the transmit should be pretty straight forward. I suppose I
would have to have some sort of semaphore/mutual exclusion/monitor/lock
around the accessing of the IrDA as I plan to have a thread for transmission
and another for the receive side.

Any thoughts or assistance on implementing this would be appreciated.

Thank You, B
 
1. You'll have to generate the event. There's no way to have an OS event
set when data is received. You'll have to start a thread, wait for the port
to show data (you can do this with WaitCommEvent), then set or fire whatever
you mean by your 'event' when that happens.

2. OK.

3. No, that's not the way it works. You can send data from one thread while
waiting to receive data on another thread.

I don't see any reason to have a synchronization object for the port. I
would presume that what you send is, in some way, related to what you
receive, so it seems like you can probably get by with a single thread for
most request/response processing. If you sometimes need to initiate some
operation by sending data before you receive data, do that from another
thread, by all means.

Paul T.
 
1. Is WaitCommEvent available in the .NET Framework (as opposed to the
Compact Framework)? I couldn't see it in the help section. If not is there an
alternative that I can use?

2. OK.

3. So are you saying that a blocking call then the resources are not locked
so that other threads can call it.

client = listener.AcceptIrDAClient(); // blocking call

To give an overview of the application. The vast majority of traffic will be
a receive to the device say 90% and the rest is transmit 10%. If I have a
blocking call on the receive can I still have a seperate thread that
transmits?

Do you have any thoughts on what complication I might have trying to
implement IrDA in the .NET Framework as opposed to the COmapct Framework?
 
1. I have no idea. Don't use it. It's a Win32 API call, so you could
P/Invoke it. This is just standard Win32 serial stuff, not some strange
alien programming model.

3. Yes, that's what I'm saying, in general. You can read and write to a
serial port from several threads at the same time. Of course, it's probably
not a great idea to read from several threads, since you don't really know
where the data will end up, but it's possible.

I don't know much about IrDA, so accepting connections probably can't be
done from several threads at the same time, but a little experimental work
should get you by that.

Yes, as I said before, WinCE doesn't care where the sends are coming from or
the receives are going. You have to get the port handle to each thread that
needs it, but that's not an OS problem.

Paul T.
 
net_monster

I think that it would be useful to ask some questions to clarify what is
to be implemented...

What sort of IrDA connection is to be made? What type of device are you
connecting to, and what IrDA profile(s) does it implement?

• If it truly is the IrDA suite, then you should use Peter Foot's
32feet.NET library (http://32feet.net). It implements IrDAClient and
IrDAListener etc on Win32 and WinCE.

Just in passing, the 32feet.NET implementation, unlike the CF's built in
version, provides access to the underlying Socket, and so is more
flexible, allowing IrLMP or IrCOMM modes to be set for instance.

• If it uses 'raw IR', then you'll need a serial port attached dongle,
and then it's serial port programming.

My list of IrDA 'profiles' is here,
http://www.alanjmcf.me.uk/comms/infrared/IrDA uses (brief).html.

In either case, as Paul notes too, there should be no problem with
sending and receiving on different threads, and you should move on from
Win32 APIs, as the way of doing things is different (and better) in
..NET. Once you know what scenario you are in then better advice can be
given...
--
Alan J. McFarlane
http://www.alanjmcf.me.uk/
Please follow-up in the newsgroup for the benefit of all.
 
Back
Top