Justin Richards wrote:
> I often look at other peoples code and admire what appears to me to be
> an elegant solution for various tasks.

Keep in mind that much code out there is crap too.  There are far more
examples of how not to do things out there than good examples.

> I am trying to implement a State Machine for sending UDP packets.

Do you mean you are trying to implement a app that uses UDP to send packets
or are trying to implement the UDP layer of a network stack?  If the latter=
,
you can look at my 18F code, or possibly take the whole network stack.  The
network stack is made up of source modules with "net" in their name in the
SOURCE > PIC directory after intalling PIC Development Tools release at
http://www.embedinc.com/pic.

> So now I have a state machine where I need to call the function 5
> times with the same message to be sent to ensure the correct message
> is sent. Called at least 5 times in the hope that it transition thru
> all states to at least send msg.

Huh?  This isn't making any sense.  Are you sending the message 8 times to
increase its chance of delivery?  Does that mean you are expecting the
network to drop packets frequently?  If so, maybe you should be using TCP
instead of UDP.  If you're sending data 5 times, it seems you are defeating
the advantages of UDP but still not getting what TCP would give you and use
less network traffic in the process.

Or, are you saying your packet sending code is so bad you call it 5 times i=
n
the hope that it accidentally works once!?  That would be very bad with the
obvious answer to write the code properly.  It's really not clear what you
are saying.

> This is not elegant.  So I question what is a good way to signal the
> UDP state machine that a message needs to be sent.

The UDP layer of your network stack should have a way for your app to build
and send a packet, and this should be reliable at least up to your own
network interface.  The UDP layer may be implemented as a state machine
inside, but that should be transparent to the app.

Again it's not clear what exactly you are trying to do, but often I find a
state machine becomes easy to implement when you give it its own task.  Thi=
s
is particularly useful when the state depends on previously received
asynchronous input, like when interpreting a communication stream.  The PC
becomes the state variable.  The code looks like it goes out and gets the
next input, when in fact the input comes in when something external feels
like sending it.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.