Searching \ for '[PIC] RS485 multi-master protocol + transceiver qu' 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/ios.htm?key=rs485
Search entire site for: 'RS485 multi-master protocol + transceiver qu'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] RS485 multi-master protocol + transceiver qu'
2009\05\11@171318 by solarwind

picon face
Hey all. I just got 10 samples of MAX485 (half duplex RS485
transceiver) today. I want to try and make a simple multi master
network using RS485 and PICs with hardware UARTs. Can anyone recommend
where I can get started in terms of the protocol?

I need a protocol driver for PICs or at least some information on how
to implement my own. I have a general idea on how to send data between
PICs but the largest concern is collision. I don't know how to
implement collision detection/avoidance. How do you check if the line
is busy anyway?

Also, the MAX485 has a receiver enable and driver enable pins. This is
what the data sheet says:

---
RE: Receiver Output Enable. RO [sends data INTO the PIC] is enabled
when RE is low; RO is
high impedance when RE is high.

DE: Driver Output Enable [sends data OUT from the PIC]. The driver
outputs, Y and Z, are enabled
by bringing DE high. They are high impedance when DE is low. If
the driver outputs are enabled, the parts function as line drivers.
While they are high impedance, they function as line receivers if
RE is low.
---

So does this mean that the receiver and the driver should be kept in
high impedance when I'm not doing anything? If it does, then how do I
know when I should enable the receiver?

-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\05\11@183511 by Bob Axtell

face picon face
The way I use that transceiver is to allow only ONE master to issue
commands, and
everyone on the  network listens. Then the INTENDED slave (ONLY)
answers. So sometimes
a slave may not be interrogated for hours.

My communications protocol is simple: the first byte is the
DESTINATION (intended slave) ,
the next byte is the COMMAND, and data pertaining to that data
follows. To make sure the
slaves received the command correctly, there is a CHECKSUM byte (or
bytes) sent that represent a simple sum of all characters in the
message (except the checksum chars themselves). All slaves monitor the
checksum, and if they receive a bad checksum, they must IGNORE the
message because its data was corrupted. It might sound difficult, but
in fact it is very simple to implement. Even a better checksum scheme,
such as CRC8 or CRC16 can be used to improve reliability; with CRC16
you can send data on telephone lines for 1000 meters or more with very
few repeats(if the slave fails to respond, you REPEAT the command).

--Bob A




On Mon, May 11, 2009 at 2:12 PM, solarwind <spam_OUTx.solarwind.xTakeThisOuTspamgmail.com> wrote:
{Quote hidden}

> -

2009\05\11@193726 by Harold Hallikainen

face
flavicon
face
I typically tie the receiver enable (active low) and the transmitter
enable (active high) together, then drive them with one pic pin. Connect a
pull-up resistor on the receiver output. Then, when you transmit, you
won't hear your own data. This cuts down on the amount of work your pic
needs to do, since it will then not need to interpret and throw out its
own data.

I generally form a packet and use a simple state machine to receive it.
Packets are of the form:

0xaa55 - flag start of packet
LengthByte - How many bytes follow this
CRC or Checksum
PacketType
data

It is more common to put the CRC or checksum at the end, but I find it
easier to find at a fixed location. I just use a union of structures to
take the packet apart. When caculating the crc or checksum, I set that
field to 0, then calculate, then save the value. On receive, I pull the
checksum or crc out, set the field to zero, then calculate. If it matches,
I've got a good packet.

Packet Type tells me which structure in the union of structures to use in
interpreting the data.

One trick on sending the data, is I enable the transmitter, then send
0xff, then my packet (aa55, etc.). I follow the packet with another 0xff,
then turn off the transmitter. This is because the uart is double
buffered. If you turn the transmitter during the interrupt after you put
in your last byte, the last byte will be lost, since it is then moving
from the holding register to the shift register and has not yet been
shifted out.

Good luck!

Harold




--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2009\05\11@194426 by Brent Brown

picon face
On 11 May 2009 at 17:12, solarwind wrote:
> ---
> RE: Receiver Output Enable. RO [sends data INTO the PIC] is enabled
> when RE is low; RO is
> high impedance when RE is high.
>
> DE: Driver Output Enable [sends data OUT from the PIC]. The driver
> outputs, Y and Z, are enabled
> by bringing DE high. They are high impedance when DE is low. If
> the driver outputs are enabled, the parts function as line drivers.
> While they are high impedance, they function as line receivers if
> RE is low.
> ---
>
> So does this mean that the receiver and the driver should be kept in
> high impedance when I'm not doing anything? If it does, then how do I
> know when I should enable the receiver?

No point in keeping both disabled, enable the receiver when you want to receive,
enable the transmitter when you want to transmit. As the two enable lines use
opposite logic it is quite common to tie the two enable lines together so you only
need one control line from the micro... that way receiver is disabled when
transmitting, and when transmit is done you go back to listening to the bus. Easiest
protocols have one master, slaves are not allowed to transmit until they are
addressed and commanded to by the master.
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: +64 27 433 4069
eMail:  .....brent.brownKILLspamspam@spam@clear.net.nz


2009\05\11@195510 by Gerhard Fiedler

picon face
solarwind wrote:

> I need a protocol driver for PICs or at least some information on how
> to implement my own. I have a general idea on how to send data
> between PICs but the largest concern is collision. I don't know how
> to implement collision detection/avoidance.

I don't remember who that was, but on one of the recent threads about
this issue that you started, someone posted a list of 4 methods which
seemed reasonably complete. Find that message before you continue...

Gerhard

2009\05\11@201735 by Richard Prosser

picon face
2009/5/12 Brent Brown <brent.brownspamKILLspamclear.net.nz>:
{Quote hidden}

One way to slightly simplify reception is to use a checksum that is
the 2's complement of the sum of the bytes sent. That way, on receive
you just keep adding the bytes and if the total equals zero at the
end, then then it's OK.  (In this case the checksum is included in the
calculation).

As Brent says, it's common to tie the transmit and receive lines
together and run as a common "transmit enable" control. You need to
make sure that you don't disable the transmit side until all the bits
have been shuffled out.

It is possible to have a circuit to control this driven off the
transmit data but at high speeds it gets a bit tricky to not loose
part of the start bit.
If you connect the enable line directly to the transmit signal (as
suggested elsewhere) you loose either the pull-down or pull-up
capability and are likely to get more bit errors.

In theory you can keep the receiver enabled during transmit and use
this to check on data corruption due to collisions & noise, but I've
never had much success with getting this to work properly. We just
either control transmit and receive together or just control the
transmitter and ignore any data received while transmitting.

RP

2009\05\11@221015 by solarwind

picon face
Thank you very much to EVERYONE who posted. You all have been very helpful.

@Bob Axtell, Harold Hallikainen:
This is exactly how I imagined the single master bus would work. Now I
gotta impliment the multi master protocol. Your ideas are really
helpful. Thank you.

@Brent Brown: That logic is awesome. Into my circuit it goes.

@Gerhard: I'll find it :)

@Richard Prosser: Thanks. I'll avoid using the circuitry though, until
I get more proficient with "that kind" of electronics.

-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\05\11@224602 by Xiaofan Chen

face picon face
On Tue, May 12, 2009 at 5:12 AM, solarwind <EraseMEx.solarwind.xspam_OUTspamTakeThisOuTgmail.com> wrote:
> I need a protocol driver for PICs or at least some information on how
> to implement my own. I have a general idea on how to send data between
> PICs but the largest concern is collision. I don't know how to
> implement collision detection/avoidance. How do you check if the line
> is busy anyway?

I think the easier way is not to use RS485 and invent your own
multi-master protocol. For example, in the previous threads,
CAN or Ethernet are both recommended.

It is possible to make RS485 multi-master but the hassle may not
be worth the efforts. One example here:
http://www.keil.com/forum/docs/thread8794.asp

--
Xiaofan http://mcuee.blogspot.com

2009\05\11@225750 by solarwind

picon face
On Mon, May 11, 2009 at 10:46 PM, Xiaofan Chen <xiaofancspamspam_OUTgmail.com> wrote:
> I think the easier way is not to use RS485 and invent your own
> multi-master protocol. For example, in the previous threads,
> CAN or Ethernet are both recommended.

What do you mean? Isn't RS485 the physical layer specification? I'm
going to write my protocol over RS485.

> It is possible to make RS485 multi-master but the hassle may not
> be worth the efforts. One example here:
> http://www.keil.com/forum/docs/thread8794.asp

It was done with CAN via a twisted pair half duplex line, so I want to
try to do it over RS485. For hobby purposes and low speeds, I should
be able to cook something up.

2009\05\12@003237 by Xiaofan Chen

face picon face
On Tue, May 12, 2009 at 10:57 AM, solarwind <@spam@x.solarwind.xKILLspamspamgmail.com> wrote:
> On Mon, May 11, 2009 at 10:46 PM, Xiaofan Chen <KILLspamxiaofancKILLspamspamgmail.com> wrote:
>> I think the easier way is not to use RS485 and invent your own
>> multi-master protocol. For example, in the previous threads,
>> CAN or Ethernet are both recommended.
>
> What do you mean? Isn't RS485 the physical layer specification? I'm
> going to write my protocol over RS485.

I mean it is more difficult to define your own collision detection/avoidence
protocol for multi-master RS485 than to switch to CAN/Ethernet.

>> It is possible to make RS485 multi-master but the hassle may not
>> be worth the efforts. One example here:
>> http://www.keil.com/forum/docs/thread8794.asp
>
> It was done with CAN via a twisted pair half duplex line, so I want to
> try to do it over RS485. For hobby purposes and low speeds, I should
> be able to cook something up.



--
Xiaofan http://mcuee.blogspot.com

2009\05\12@004621 by Xiaofan Chen

face picon face
On Tue, May 12, 2009 at 7:55 AM, Gerhard Fiedler
<RemoveMElistsTakeThisOuTspamconnectionbrazil.com> wrote:
> solarwind wrote:
>
>> I need a protocol driver for PICs or at least some information on how
>> to implement my own. I have a general idea on how to send data
>> between PICs but the largest concern is collision. I don't know how
>> to implement collision detection/avoidance.
>
> I don't remember who that was, but on one of the recent threads about
> this issue that you started, someone posted a list of 4 methods which
> seemed reasonably complete. Find that message before you continue...
>

This one from Harold Hallikainen?

On Sun, May 10, 2009 at 4:34 AM, Harold Hallikainen
<spamBeGoneharoldspamBeGonespamhallikainen.org> wrote:
{Quote hidden}

--
Xiaofan http://mcuee.blogspot.com

2009\05\14@161950 by solarwind

picon face
This looks really cool:

http://www.bdmicro.com/code/robin/

What I really like is the idea on the bottom of the page for multi
master collision detection.

Now the only thing left is to detect if the line is busy or not... Hmm...

2009\05\14@164642 by solarwind

picon face
On Thu, May 14, 2009 at 4:19 PM, solarwind <TakeThisOuTx.solarwind.xEraseMEspamspam_OUTgmail.com> wrote:
> This looks really cool:
>
> http://www.bdmicro.com/code/robin/
>
> What I really like is the idea on the bottom of the page for multi
> master collision detection.
>
> Now the only thing left is to detect if the line is busy or not... Hmm...

Also found this: http://bacnet.sourceforge.net/

Token ring based

2009\05\15@023151 by Ruben Jönsson

flavicon
face
> This looks really cool:
>
> http://www.bdmicro.com/code/robin/
>
> What I really like is the idea on the bottom of the page for multi
> master collision detection.
>
> Now the only thing left is to detect if the line is busy or not... Hmm...

There is a problem with the collision detection method on an RS485 bus where
the sender also controlls if there was a collision with it's own receiver. As I
wrote in another thread, when I tried this I found that the receiver often just
sees the transmitted data from the closest transmitter, especially if they are
on the same board (and chip) and there are some distance between the two
colliding transmitters. Also having transient protection components on the
board for the bus makes this harder. This means that both senders can see their
message as valid and ignore the collision backoff.

This may work fine if you set the bus up to have one dominant state and one
recessive state by clamping the bus to the recessive state and just activate
the transmitter when it is transmitting the dominant state. You can do this by
connecting the transmitter enable signal to the uart tx signal and hard clamp
the data input for the transmitter to the level that gives the dominant state.

This method may however degrade EMI performance, reduce maximum cable length
and reduce maximum data rate since one of the transmitted states is now
passively pulled with resistors instead of actively driven with the driver.

/Ruben


==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
RemoveMErubenspamTakeThisOuTpp.sbbs.se
==============================

2009\05\15@064143 by Dario Greggio

face picon face
Ruben Jönsson ha scritto:
> There is a problem with the collision detection method on an RS485 bus where
> the sender also controlls if there was a collision with it's own receiver. As I
> wrote in another thread, when I tried this I found that the receiver often just
> sees the transmitted data from the closest transmitter, especially if they are
> on the same board (and chip) and there are some distance between the two
> colliding transmitters. Also having transient protection components on the
> board for the bus makes this harder. This means that both senders can see their
> message as valid and ignore the collision backoff.

same here, as I probably already wrote.

But I found I can almost live with it.

2009\05\15@064815 by Dario Greggio
face picon face
solarwind ha scritto:
> This looks really cool:
>
> http://www.bdmicro.com/code/robin/
>
> What I really like is the idea on the bottom of the page for multi
> master collision detection.

I read this with interest.
I have gone kind of deep in developing a 485 multi master protocol,
since 1997 or so. I started with some ideas of mine, then took a look
and 220V network modems, and CAN, and Ethernet, and else. I basically
wanted something useful for home automation (i.e. not-so-high data
rate), scalable (meaning 220V, 485, or wireless), low overhead etc.

What I am currently up to, "skynet" (I published it @ Microchip forum
here & there) is very similar to the above.

I wanted to place a question for you all. I can't see a "frame id" i.e.
a counter in the above protocol: I found it mandatory to deal with
repeated packets and retransmission.

What do you think about this?

thanks
Dario

2009\05\15@075752 by olin piclist

face picon face
"Ruben Jönsson" wrote:
> This may work fine if you set the bus up to have one dominant state and
> one recessive state by clamping the bus to the recessive state and just
> activate the transmitter when it is transmitting the dominant state.
> You can do this by connecting the transmitter enable signal to the uart
> tx signal and hard clamp the data input for the transmitter to the
> level that gives the dominant state.
>
> This method may however degrade EMI performance, reduce maximum cable
> length and reduce maximum data rate since one of the transmitted states
> is now passively pulled with resistors instead of actively driven with
> the driver.

Yes, using passive pull ups/downs to one state with lower impedence active
drive to the other state does limit the top speed compared to active drive
in both directions, but you can still get very useful results.  CAN does
exactly this and can go to 1Mbit/S.  The NMEA2000 spec defines a CAN
implementation for ships that runs at 200Kbit/S.  With fully active drivers
and dedicated point to point connections, like ethernet, you can get a lot
faster than that, but a few 100 Kbit/S is quite usable in a lot of local
telemetry applications.

RS-485 is so 1990s.  I haven't seen a new design with RS-485 in quite a
while.  I don't get why so many here are intent on riding the old dinosaur
instead of using a modern replacement like CAN.  The low level electrical
layer is essentially the same if you want multi-master and collision
detection.  RS-485 ends there.  CAN continues and defines collision
detection, retry, packetizing, checksum, and message ID or address in the
protocol with various silicon implementations cheaply available and
accessible.  With a 18F4580 both the hardware and software is simpler with
CAN than RS-485.  If anyone is afraid of CAN because they have to (gasp)
read the data sheet carefully and think that using the peripheral is somehow
complicated, they've got a rude surprise coming when they start trying to
implement all that functionality in firmware.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\15@083950 by solarwind

picon face
2009/5/15 Ruben Jönsson <rubenEraseMEspam.....pp.sbbs.se>:
> There is a problem with the collision detection method on an RS485 bus where
> the sender also controlls if there was a collision with it's own receiver. As I
> wrote in another thread, when I tried this I found that the receiver often just
> sees the transmitted data from the closest transmitter, especially if they are
> on the same board (and chip) and there are some distance between the two
> colliding transmitters. Also having transient protection components on the
> board for the bus makes this harder. This means that both senders can see their
> message as valid and ignore the collision backoff.
>
> This may work fine if you set the bus up to have one dominant state and one
> recessive state by clamping the bus to the recessive state and just activate
> the transmitter when it is transmitting the dominant state. You can do this by
> connecting the transmitter enable signal to the uart tx signal and hard clamp
> the data input for the transmitter to the level that gives the dominant state.
>
> This method may however degrade EMI performance, reduce maximum cable length
> and reduce maximum data rate since one of the transmitted states is now
> passively pulled with resistors instead of actively driven with the driver.

That sounds really cool and useful, but I have no idea what you're
saying. At this point, the level you're talking at is probably too
high for me.

2009\05\15@090619 by Gerhard Fiedler

picon face
Dario Greggio wrote:

{Quote hidden}

I think they leave that up to the application; the frame id would have
to be part of the <data> payload and handled one level up for the cases
where it is needed.

Gerhard

2009\05\15@091708 by Dario Greggio

face picon face
Gerhard Fiedler ha scritto:

> I think they leave that up to the application; the frame id would have
> to be part of the <data> payload and handled one level up for the cases
> where it is needed.


I see, well, this makes sense too.

thank you Gerhard

2009\05\16@050749 by sergio masci

flavicon
face
part 1 3393 bytes content-type:TEXT/PLAIN; charset=UTF-8 (decoded quoted-printable)



On Fri, 15 May 2009, Olin Lathrop wrote:

{Quote hidden}

Baby steps!

It's easy for old timers like us who have already aquired low level experience to progress to more complicated stuff like CAN. Going the low level RS232 and RS485 is kind of like starting on assembler before moving up to 'C'. You get to understand what's happening, laying down solid foundations of knowledge to build on so that you can debug the more complcated stuff.

>  The low level electrical
> layer is essentially the same if you want multi-master and collision
> detection.  RS-485 ends there.  CAN continues and defines collision
> detection, retry, packetizing, checksum, and message ID or address in the
> protocol with various silicon implementations cheaply available and
> accessible.  With a 18F4580 both the hardware and software is simpler with
> CAN than RS-485.  If anyone is afraid of CAN because they have to (gasp)
> read the data sheet

And pray that device works exactly as described (including the reference code in the app notes)...

> carefully and think that using the peripheral is somehow
> complicated, they've got a rude surprise coming when they start trying to
> implement all that functionality in firmware.

Yes but when you've got a black box running really fast (your CAN peripheral) doing all the magic without (or minimal) intervension it gets really hard to debug stuff unless you are really experienced and even then you sometimes need to use expensive kit like logic analysers and storage scopes. Doing it the hard way using firmware lets you slow things down even simulate them if you need to and best of all it gives you an appriciation of what the "black box" is doing when it comes time to migrate up to it.

Regards
Sergio Masci

part 2 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2009\05\16@051715 by sergio masci

flavicon
face


On Fri, 15 May 2009, Dario Greggio wrote:

{Quote hidden}

Yes I also belive it should be mandatory. For one thing it helps
acknowledgement of packets that arrive out of sequence.

For multi master collision detection, have you considered sending back the
CRC as part of the ACK. If two masters have both sent packets and have not
seen a collision and a slave has also seen a valid packet from one of the
masters, sending back the CRC will inform (probably) one of the masters
that there was a collision. Maybe include the ID of the node that the ACK
is intended for?

Regards
Sergio Masci

2009\05\16@072934 by Dario Greggio

face picon face
sergio masci ha scritto:
>> I wanted to place a question for you all. I can't see a "frame id" i.e.
>> a counter in the above protocol: I found it mandatory to deal with
>> repeated packets and retransmission.
>>
>> What do you think about this?
>
> Yes I also belive it should be mandatory. For one thing it helps
> acknowledgement of packets that arrive out of sequence.

Yep, I've been about this in the night, and actually Gerhard reply,
saying that it can be placed at a higher level in the Protocol, makes
sense. In my case it's not like this, at the moment. of course the
overall result is the same, just a matter of cleanness of protocol and
level.


> For multi master collision detection, have you considered sending back the
> CRC as part of the ACK. If two masters have both sent packets and have not
> seen a collision and a slave has also seen a valid packet from one of the
> masters, sending back the CRC will inform (probably) one of the masters
> that there was a collision. Maybe include the ID of the node that the ACK
> is intended for?

Not sure what you mean here , Sergio.
In my case, the ACK is a message on its own and not barely a flag in the
Frame. If 2 masters send a packet to the same slave, there will be
either a collision or the slave may receive only one of them and miss
the other. In the 1st case, both masters will retry (maybe after a
random delay - though often the devices will send packets after a human
event, say a button press, which is random inherently), with the same
FrameID and will wait for ACK again; in the 2nd case, the 1st master
will be ok and the second will retry and, then, get a reply.

So, yes, the replied ACK includes the destination ID (the master who
sent the command in first place).


Dario

2009\05\16@074240 by Gerhard Fiedler

picon face
sergio masci wrote:

> Baby steps!

> [...]

>> [...] and think that using the peripheral is somehow complicated,
>> they've got a rude surprise coming when they start trying to
>> implement all that functionality in firmware.
>
> Yes but when you've got a black box running really fast (your CAN
> peripheral) doing all the magic without (or minimal) intervension it
> gets really hard to debug stuff unless you are really experienced and
> even then you sometimes need to use expensive kit like logic
> analysers and storage scopes. Doing it the hard way using firmware
> lets you slow things down even simulate them if you need to and best
> of all it gives you an appriciation of what the "black box" is doing
> when it comes time to migrate up to it.

There's no need to run CAN fast. I agree that setting up a CAN module is
quite a bit more challenging than setting up a UART, but once you are at
implementing a multi-master configuration, you're way past baby steps. I
don't think Olin advocated for a complete beginner to implement his
first single peer-to-peer connection with CAN.

Gerhard

2009\05\16@080149 by Marechiare

picon face
>> This looks really cool:
>>
>> http://www.bdmicro.com/code/robin/
>>
>> What I really like is the idea on the bottom of the page for multi
>> master collision detection.
>>
>> Now the only thing left is to detect if the line is busy or not... Hmm...
>
> Also found this: http://bacnet.sourceforge.net/
>
> Token ring based


Another token-passing bus:

"ARCNET, The Engineer's Secret Weapon "
http://electronicdesign.com/Articles/Index.cfm?AD=1&ArticleID=7702

>From the article:

"ARCNET is one of the best-kept secrets in the world of embedded systems."

"So if you're looking for a networking solution that's simpler to use
than Ethernet and has higher performance than CAN, ARCNET is the
answer. The secret is out."

:-)

2009\05\16@094612 by sergio masci

flavicon
face


On Sat, 16 May 2009, Dario Greggio wrote:

{Quote hidden}

I am not contradicting Gerhard here. Yes the packet ID could be placed at
a higher level in the protocol stack but so could many other things.
Personally I'd push it way down and have fewer layers. I would justify
this by saying: if every packet has X, Y and Z components and these
components can be easily maintained by a low level layer then why bother
extracting one of these componets into a higher layer. When talking about
tiny MCUs more layers tends to equal more cost (code and variable space).

{Quote hidden}

Many protocols I have encountered simply involve sending a packet from
node A to node B and node B responds with a simple ACK or NACK (or
sometimes just times out) and then node A retransmits or proceads with the
next packet. I've even seen this where multiple nodes can start talking at
the same time.

> If 2 masters send a packet to the same slave, there will be
> either a collision or the slave may receive only one of them and miss
> the other. In the 1st case, both masters will retry

As has already been mentioned, neither master might see the collision.

> (maybe after a
> random delay - though often the devices will send packets after a human
> event, say a button press, which is random inherently), with the same
> FrameID and will wait for ACK again; in the 2nd case, the 1st master
> will be ok and the second will retry and, then, get a reply.
>
> So, yes, the replied ACK includes the destination ID (the master who
> sent the command in first place).

So we think the same here. Does the ACK include the packet ID of
the packet being ACKed?

Regards
Sergio Masci

2009\05\16@095458 by sergio masci

flavicon
face


On Sat, 16 May 2009, Gerhard Fiedler wrote:

{Quote hidden}

I disagree. Getting point to point working is trivial compared with a
multi master network. Once you get PtP working yes you have some
experience which will help you with the network but getting the network
working also requires baby steps.

> I
> don't think Olin advocated for a complete beginner to implement his
> first single peer-to-peer connection with CAN.

My mistake, this is exactly what I thought Olin was advocating.

Regards
Sergio Masci

2009\05\16@101249 by Dario Greggio

face picon face
sergio masci ha scritto:
>
> I am not contradicting Gerhard here. Yes the packet ID could be placed at
> a higher level in the protocol stack but so could many other things.
> Personally I'd push it way down and have fewer layers. I would justify
> this by saying: if every packet has X, Y and Z components and these
> components can be easily maintained by a low level layer then why bother
> extracting one of these componets into a higher layer. When talking about
> tiny MCUs more layers tends to equal more cost (code and variable space).

Yep, same thought as mine - at least in the past years.
Now that I've been dealing with MiWi, which means bigger PICs and mor
horsepower (and also more knowledge by my side :)
I *could* go with more levels etc.

{Quote hidden}

ok

>> If 2 masters send a packet to the same slave, there will be
>> either a collision or the slave may receive only one of them and miss
>> the other. In the 1st case, both masters will retry
>
> As has already been mentioned, neither master might see the collision.

Yep, this is true, in fact I'm not relying on that. ACK/NACK is the only
thing that matters.


>> So, yes, the replied ACK includes the destination ID (the master who
>> sent the command in first place).
>
> So we think the same here. Does the ACK include the packet ID of
> the packet being ACKed?

No, not yet at least. In fact I believe that it would be useful - also
because the FrameID in an ACK packet (as it is now) is almost useless,
and could be replaced by the Original (master's) Frame ID.


Dario

2009\05\16@134258 by solarwind

picon face
On Sat, May 16, 2009 at 12:01 PM, Marechiare <EraseMEmarechiarespamgmail.com> wrote:
> Another token-passing bus:
>
> "ARCNET, The Engineer's Secret Weapon "
> http://electronicdesign.com/Articles/Index.cfm?AD=1&ArticleID=7702
>
> >From the article:
>
> "ARCNET is one of the best-kept secrets in the world of embedded systems."
>
> "So if you're looking for a networking solution that's simpler to use
> than Ethernet and has higher performance than CAN, ARCNET is the
> answer. The secret is out."

That looks awesome. But where do I get this "ARCNET"?

2009\05\16@134406 by solarwind

picon face
On Fri, May 15, 2009 at 10:48 AM, Dario Greggio <RemoveMEadpm.toEraseMEspamEraseMEinwind.it> wrote:
> What I am currently up to, "skynet" (I published it @ Microchip forum
> here & there) is very similar to the above.

I searched on the microchip forums for "skynet" and I didn't find anything.

Here's my search:
http://search.microchip.com/searchapp/searchhome.aspx?q=skynet&id=43

Can you please link me to it?

2009\05\16@203617 by Xiaofan Chen

face picon face
On Sun, May 17, 2009 at 1:43 AM, solarwind <RemoveMEx.solarwind.xspam_OUTspamKILLspamgmail.com> wrote:
> Here's my search:
> http://search.microchip.com/searchapp/searchhome.aspx?q=skynet&id=43
>
> Can you please link me to it?

Google now works with Microchip forum.
Using google "skynet site:http://www.microchip.com/forums" and you
will get quite some hits.

--
Xiaofan http://mcuee.blogspot.com

2009\05\16@203948 by Dario Greggio

face picon face
solarwind ha scritto:
>
> I searched on the microchip forums for "skynet" and I didn't find anything.
>
> Here's my search:
> search.microchip.com/searchapp/searchhome.aspx?q=skynet&id=43
>
> Can you please link me to it?

http://www.microchip.com/forums/tm.aspx?m=221869&mpage=2

(5th or so hit using Google)

2009\05\16@205603 by solarwind

picon face
On Sat, May 16, 2009 at 8:39 PM, Dario Greggio <RemoveMEadpm.toTakeThisOuTspamspaminwind.it> wrote:
> http://www.microchip.com/forums/tm.aspx?m=221869&mpage=2

Hmm. All that's on that thread is an image. Do you have any code?

Also, what kind of protocol is it? (Is it token ring type, for example)?

2009\05\16@210715 by Russell McMahon

face
flavicon
face
> What I am currently up to, "skynet" ...

Are you with Cyberdyne corporation*?


 Russell


* Gargoyle knows.

2009\05\16@210838 by Dario Greggio

face picon face
Xiaofan Chen ha scritto:
> On Sun, May 17, 2009 at 1:43 AM, solarwind <EraseMEx.solarwind.xspamspamspamBeGonegmail.com> wrote:
>> Here's my search:
>> search.microchip.com/searchapp/searchhome.aspx?q=skynet&id=43
>>
>> Can you please link me to it?
>
> Google now works with Microchip forum.
> Using google "skynet site:http://www.microchip.com/forums" and you
> will get quite some hits.
>


thank you Xiaofan :)

2009\05\16@213440 by Xiaofan Chen

face picon face
On Sun, May 17, 2009 at 9:05 AM, Russell McMahon
<RemoveMEapptechKILLspamspamparadise.net.nz> wrote:
>> What I am currently up to, "skynet" ...
>
> Are you with Cyberdyne corporation*?

Thanks. Now I know why Dario names the protocol "skynet". ;-)
And he is indeed with Cyberdyne corporation according to his
profile in the web. He must be a terminator movie fan. ;-)
http://en.wikipedia.org/wiki/Cyberdyne_Systems


--
Xiaofan http://mcuee.blogspot.com

2009\05\16@215246 by Xiaofan Chen

face picon face
On Sun, May 17, 2009 at 9:08 AM, Dario Greggio <adpm.toSTOPspamspamspam_OUTinwind.it> wrote:
>> Google now works with Microchip forum.
>> Using google "skynet site:http://www.microchip.com/forums" and you
>> will get quite some hits.
>>
> thank you Xiaofan :)

I think your picgoogle still works. But I am not so sure if you need to
change a bit the codes now that Microchip forum is located at
http://www.microchip.com/forums instead of http://forum.microchip.com.
http://cyberdyne.homeip.net/picgoogle.html

Picyahoo does not work well now. Searching skynet returns only
one hit.
http://cyberdyne.homeip.net/picyahoo.html


--
Xiaofan http://mcuee.blogspot.com

2009\05\17@063455 by Dario Greggio

face picon face
Xiaofan Chen ha scritto:
> On Sun, May 17, 2009 at 9:05 AM, Russell McMahon
> <spamBeGoneapptechSTOPspamspamEraseMEparadise.net.nz> wrote:
>>> What I am currently up to, "skynet" ...
>> Are you with Cyberdyne corporation*?
>
> Thanks. Now I know why Dario names the protocol "skynet". ;-)
> And he is indeed with Cyberdyne corporation according to his
> profile in the web. He must be a terminator movie fan. ;-)
> http://en.wikipedia.org/wiki/Cyberdyne_Systems

Yep, I'm a long time Terminator fan, since 1985 :)

I used to belong in a company named "ADPM" for 17 years, last year we
broke up and I went on my own with "Cyberdyne" :)

That Skynet thing was born in 1992 with my first experimenting with a
wired home automation network.

Dario

2009\05\17@070358 by Dario Greggio

face picon face
solarwind ha scritto:
> On Sat, May 16, 2009 at 8:39 PM, Dario Greggio <KILLspamadpm.tospamBeGonespaminwind.it> wrote:
>> www.microchip.com/forums/tm.aspx?m=221869&mpage=2
>
> Hmm. All that's on that thread is an image. Do you have any code?
>
> Also, what kind of protocol is it? (Is it token ring type, for example)?

It's a Multi-Master RS485 network. It's not a token ring, rather a
CSMA-CD (ethernet like).
Every node can transmit as wished. There is a network collision method
(unfortunately, not working soooo good on 485 as others stated), and
then a robust ACK/NACK and retransmission mechanism).

8bytes max data payload, currently implemented @250Kbaud over several
installations with up to 400-500mt of cable (CAT-5). It seems to be
rather tolerant of "stubs" and topology.
I'm also using it with Nordic and other 2.4GHz devices (and 433MHz as
well). Good for portability of code and/over devices.
Average Packets take 1mS-2mS, and the ACKs always take some 1mS. This
leads to some 1000bytes/sec of data throughput, which is good enough
even for small LCD panels.

I published the Packet format. I then have a full bunch of C++ classes
to be used on PC (that I can share if interested) - think of them as
Zigbee "classes for devices".
At the PIC's (devices') side I've gone more low-level, as I said, mostly
because this all began in Z80 assembler ad then ST6 assembler and 16F628
assembler... so there was not much room to "make it too smart" :)

Dario

2009\05\17@121337 by solarwind

picon face
On Sun, May 17, 2009 at 7:03 AM, Dario Greggio <EraseMEadpm.tospamEraseMEinwind.it> wrote:
{Quote hidden}

It sounds really cool. Could you please share your source code with
me? I would really appreciate it.

2009\05\18@083848 by Marechiare

picon face
>> "ARCNET is one of the best-kept secrets in the world of embedded systems."
>>
>> "So if you're looking for a networking solution that's simpler to use
>> than Ethernet and has higher performance than CAN, ARCNET is the
>> answer. The secret is out."
>
> That looks awesome. But where do I get this "ARCNET"?

I beleive, ARCNET is dead, but still is worth to learn to for a
student, if the doc is available.

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