Searching \ for 'UDP/SLIP for PIC' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'UDP/SLIP for PIC'.

Truncated match.
PICList Thread
'UDP/SLIP for PIC'
1999\08\10@120632 by Nicholas Uloth

flavicon
face
You havent told us what the protocol requirments are, any scheduling
problem is a balance between fairness,
latency, throughput and complexity which is why different protocols are
still being invented.

I'm looking to implement a RS422 multidrop protocol soon too so your ideas
were interesting.

At 11:05 AM 10/08/99 -0400, you wrote:
>I've been thinking over the last week or so that internet connected PIC
>projects would be an excellent idea. Instead of having to write a host
>application interface everytime you can just use an existing IP stack. Also
>you get internet routing for free....




Nicholas Uloth
Industrial Software Partners Ltd
6 The Promenade
Mt Pleasant, Perth, WA 6153
Australia

Phone:  xxx-61-0418-902-724
Fax:    xxx-618-9481-7202
eMail:  spam_OUTniculothTakeThisOuTspamiohk.com
ICQ:    21812719


1999\08\11@095906 by Byron A Jeff

face picon face
>
> You havent told us what the protocol requirments are, any scheduling
> problem is a balance between fairness,
> latency, throughput and complexity which is why different protocols are
> still being invented.

Honestly the protocol requirements are KISS.

- No collisions on the data channel.
- No starvation for any member.
- 100% data channel utilization as long as there is a member that needs to
 xmit.

That's it. Latency is clearly a function of the number of members present
on the channel. Throughput should max out at 100% utilization and not be
less that ChannelBandwidth/N where N is the number of members present.

Mutual exclusivity of the data channel is the primary concern. Fairness
follows. Minimization of the slot selecion is the final criteria. That's what
this protocol targeted.

Comments?

BAJ

1999\08\11@133035 by tmariner

flavicon
face
How about CSMA/CD?
>
> It's funny. I thought of this on vacation. So I'll be in and
> out as time
> permits. Amazing what hours and hours of driving comes up with...
>
> Let me know what you think.
>
> BAJ
>

1999\08\12@110506 by Byron A Jeff

face picon face
>
> How about CSMA/CD?

It's not clear if the physical layer of RS-485 allows for multiple transmitters
or what happens if multiple transmitters transmit different bits.

Essentially I'm doing the multiple access part because even with ethernet there
is only a single transmitter on the channel at any point in time. This protocol
handles channel selection on a separate channel using TDM on the slot channel.
So there are no collisions because there is guranteed not to be multiple
transmitters.

I guess it would be possible to implement an ethernet type collision detector on
the second channel if RS-485 allows for multiple transmitters...

Any commentary on the UDP/SLIP part of it? The responses I've seen have been
physical layer only which isn't a relavent as the protocols on top of that
layer.

BAJ

1999\08\12@170010 by Martin Darwin
flavicon
face
On Thu, 12 Aug 1999, Byron A Jeff wrote:

> >
> > How about CSMA/CD?
>
> It's not clear if the physical layer of RS-485 allows for multiple transmitter
s
> or what happens if multiple transmitters transmit different bits.

If you are doing half-duplex RS-485, you just tie the UART tx line
(inverted) to the RS-485 driver's R/W pin and tie the tx pin on the driver
to ground. That way, the driver will only transmit when it wants to send a
0. A collision is defined when one transmitter is sending a 0 and another
transmitter wants the line to be floating (i.e. it is sending a 1). There
is an appnote on this somewhere (National Semi i think). Collisions can be
detected in hardware with by: UART framing error, UART missing stop bit,
UART parity error or in SW with CRC errors in the frames.

> Essentially I'm doing the multiple access part because even with
> ethernet there is only a single transmitter on the channel at any
> point in time. This protocol handles channel selection on a separate

Well, there is only one transmitter sending error free data. When there
are two transmitters (which is possible in ethernet) a jam signal is
generated and both transmitters backoff.

> Any commentary on the UDP/SLIP part of it? The responses I've seen have been
> physical layer only which isn't a relavent as the protocols on top of that
> layer.

Only problem with UDP is that there is no guarentee that the data will get
there correctly so if your physical layer is not error free you have to
add a CRC field the data section of your UDP packet.

Slip/UDP is cool but in the end there just isn't enough processing
power/memory in a low end PIC to really make it worth while. You would
probably be better off using a custom protocol and then have one big PIC
convert from this custom protocol into Slip/UDP.

my $0.02

MD

1999\08\12@182214 by paulb

flavicon
face
Byron A Jeff wrote:

> The traditional way of doing it: polling, can end up being very slow.
> So I was thinking of new ways to manage multiple stations.  What I
> came up with is adding a separate collision channel to manage the
> multiple hosts.  Essentially it's another faster form of polling.

 I think that the progressive binary tree polling used in the Dallas
One Wire Protocol is the way to go.  One channel does all, I'm sure it
does it just as fast as any other scheme you may propose.

 Rather than attempt to explain it all over again, I suggest you read
it from their website and then discuss it.
--
 Cheers,
       Paul B.

1999\08\13@111331 by Byron A Jeff

face picon face
>
> On Thu, 12 Aug 1999, Byron A Jeff wrote:
>
> > >
> > > How about CSMA/CD?
> >
> > It's not clear if the physical layer of RS-485 allows for multiple transmitt
ers
{Quote hidden}

Wire-OR. That's an interesting idea. I'd be interested in the latency between
my scheme and true collisions.

{Quote hidden}

UDP already has a CRC field for the entire packet. Individual nodes would have
to manage sequencing, dropped packages, and I guess even the rare duplicate.

>
> Slip/UDP is cool but in the end there just isn't enough processing
> power/memory in a low end PIC to really make it worth while. You would
> probably be better off using a custom protocol and then have one big PIC
> convert from this custom protocol into Slip/UDP.

This is what I want to explore. IP and UDP are extremely simple if you are
not a router. Just specify the IP number and port number of the target and
package up your data. SLIP, unlike PPP, is just dropping raw IP packets on the
serial line with 2 characters out of 256 escaped. Most of both the IP and the
UDP packet is fixed (all the source, could fix the target port) with the
only variable part being the target IP and the data.

I agree that TCP is too much to handle. But UDP's simplicity of just wrapping
the data in a simple envelope should be simple enough to put in a 12CXX part.

BAJ

1999\08\13@112003 by Adam Davis

flavicon
face
Is this a project you are doing profesionally?  ie, will you have the
opportunity to release your final design, or enough of it to be useful to
others?

-Adam

Byron A Jeff wrote:
{Quote hidden}

1999\08\13@114239 by Scott Dattalo

face
flavicon
face
On Fri, 13 Aug 1999, Byron A Jeff wrote:

> > On Thu, 12 Aug 1999, Byron A Jeff wrote:
> >
> > > >
> > > > How about CSMA/CD?
> > >
> > > It's not clear if the physical layer of RS-485 allows for multiple transmi
tters
{Quote hidden}

That's what I (almost) did. In my case, the physical layer also performed
arbitration (some of the datalink layer trickled down). After the last
byte of a message was transmitted, the active master would enter an
arbitration mode. This consisted of extending the stop bit for a
pre-defined interval and then asserting an 'arbitration edge'. All
potential masters monitored this edge with a hardware input-capture pin.
After the edge was initiated, the active master would relinquish control
by tri-stating its transmitter. The RS-485 termination resistors, which
are necessary for reliable long-distance communications, were configured
such that they would also passively maintain the DC level of the RS-485
differential pair in the 'active low' state or the state to which the
arbitration edge drove the bus.

Now each master was preassigned an ID. This ID was used to determine an
'arbitration slot' or a time period that the masters would wait after the
arbitration edge to attempt arbitration. An output compare module was
programmed to generate the "I want the bus" edge. Finally, a master
ascertained whether it had won arbitration by comparing when it sent the
bus request to when the bus really went active. If the bus went active due
to his request, then he was the winner. If the bus went active before his
request then another master won.

The comm rate was 38.4k baud, the arbitration slots were about 20uS, there
were upto 32 nodes. This schem worked reliably for more than 300 meters of
copper and 1500 meters of fiber. If it weren't for propogation delays
through opto-couplers (the RS485 bus was optically isolated) the distances
could be extended even more...

1999\08\13@114457 by Byron A Jeff

face picon face
>
> Is this a project you are doing profesionally?  ie, will you have the
> opportunity to release your final design, or enough of it to be useful to
> others?

Sure I can release it. I've been working with the author of a new open
source license, the IPL. Basically the source is released and commercial
folks pay royalties to use. Just a small bit of protection from taking
code and making a bucketfull of money without compensating the authors.
I expect to make exactly nothing from it.

You can take a look at:

http://www.sci.usq.edu.au/staff/house/ipl/ipl.htm

But honestly everything I'm using has open specifications. TCP/IP and SLIP
are well and publicly defined. Should be easy to implement from the specs.
In fact I plan to test just point to point. Only the multipoint protocol is
new.

Anyone can implement it directly from the specs.

BAJ

1999\08\14@112717 by Byron A Jeff

face picon face
>
> On Fri, 13 Aug 1999, Byron A Jeff wrote:
>
> > > On Thu, 12 Aug 1999, Byron A Jeff wrote:
> > >
> > > > >
> > > > > How about CSMA/CD?
> > > >
> > > > It's not clear if the physical layer of RS-485 allows for multiple trans
mitters
{Quote hidden}

Scott, I'm unclear on one thing. This seems to be almost the same scheme I
came up with originally (which makes me happy because now I know it'll work).
But how do the UARTS react to channel activity? Also how did you prevent
starvation? It seems the lower ID'ed masters could swamp the channel. That's
why I went to a primary/secondary ID where after successfull transmission
a station went to its secondary ID until either it got the slot or until
no other primaries wanted to transmit.

BAJ
>

1999\08\14@115701 by Scott Dattalo

face
flavicon
face
On Sat, 14 Aug 1999, Byron A Jeff wrote:

> Scott, I'm unclear on one thing. This seems to be almost the same scheme I
> came up with originally (which makes me happy because now I know it'll work).
> But how do the UARTS react to channel activity? Also how did you prevent
> starvation? It seems the lower ID'ed masters could swamp the channel. That's
> why I went to a primary/secondary ID where after successfull transmission
> a station went to its secondary ID until either it got the slot or until
> no other primaries wanted to transmit.
>

Well, there were masters and there were Masters. Actually the network
consisted of up to 8 'Masters' and up to 32 nodes capable of assuming
control of the network. The 'Masters' had two arbitration slots. If they
had something really urgent to say then they could arbitrate in slots 0-7.
Otherwise, they would always arbitrate in slots 40-47. So if no nodes had
anything to say, then the highest priority master would win arbitration by
default. It would just transmit a 'sustaining' message and the whole
process would repeat. So like your case, the 'Masters' had a primary and
secondary ID. This idea could be extended to make all nodes "Masters'. The
one with the highest priority would just have a little extra work keeping
the network active.

A state machine kept track of the state communication channel. The UARTs
were programmed according to the state of the network: idle, listen, talk.
As long as a nod maintained sync with the network, there was no problem
for its UART to monitor the activity.

Scott

1999\08\14@143416 by - KITS EDUCACIONAIS NACIONAIS

flavicon
face
Scott Dattalo wrote:
{Quote hidden}

I think that this camera has a close protocol!

Miguel

1999\08\15@045017 by White Horse Design

flavicon
face
<x-flowed>At 16:04 12/08/1999 , Byron A Jeff wrote:
> >
> > How about CSMA/CD?
>
>It's not clear if the physical layer of RS-485 allows for multiple
>transmitters
>or what happens if multiple transmitters transmit different bits.
>
>Essentially I'm doing the multiple access part because even with ethernet
>there
>is only a single transmitter on the channel at any point in time. This
>protocol
>handles channel selection on a separate channel using TDM on the slot channel.
>So there are no collisions because there is guranteed not to be multiple
>transmitters.
>
>I guess it would be possible to implement an ethernet type collision
>detector on the second channel if RS-485 allows for multiple transmitters...

You could steal the CAN bus method where a priority mechanism kicks in
giving the bus to the higher priority message.

>Any commentary on the UDP/SLIP part of it? The responses I've seen have been
>physical layer only which isn't a relavent as the protocols on top of that

I am implementing IP at the lowest layer, and TCP / UDP on top. May well
dispense with TCP or use a highly cut down version. Intended to use PPP on
top of that but memory constraints ...

Check out Guy Lancaster's uCIP, TCP/IP/PPP for use with uCOS. http://www.ucos-ii.com.
There's a listserver for it too.

Regards

Adrian
---
WWW    WWW   Adrian Gothard
WWW WW WWW   White Horse Design
WWWWWWWWWW   +44-385-970009 (Mobile/SMS), +44-118-962-8913/4 (voice/fax)
WWWW  WWWW   .....whdKILLspamspam@spam@zetnet.co.uk, http://www.users.zetnet.co.uk/whd
---
Developers of GPS satellite-based tracking systems for vehicles/helicopters

</x-flowed>

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...