Prev: Pic very basic C18 question
Next: Beginner Embedded Linux in c
From: Tilmann Reh on 16 Mar 2010 04:10
djordj schrieb:

> On Mar 15, 6:30 pm, Tim Wescott <t...(a)seemywebsite.now> wrote:
>> djordj wrote:
>> So why not use the J1708 scheme? From Wiki (master of the infoverse,
>> dispenser of all knowledge, first in every Google search) pedia on their
>> J1708 page*:
>>
> This is exactly the solution we're about to try.

But take care that even if you implement it that way (or with any other
dom/rec scheme), the system will still hang if one of the devices stucks
with TX active at dominant state.

To maintain bus control by the master, you'd need a four wire bus
(RS-422), so that a collision on the master TX lines is impossible
(since there are only device receivers connected to it). If a device
stucks at TX active, the master still can send commands to all devices,
trying to gain control again.

Another approach would be a hardware watchdog at each device, forcing
the transmitter off if it's active for a too long time.

Tilmann
From: djordj on 16 Mar 2010 04:45
On Mar 16, 9:10 am, Tilmann Reh <usenet2007nos...(a)autometer.de> wrote:
> But take care that even if you implement it that way (or with any other
> dom/rec scheme), the system will still hang if one of the devices stucks
>  with TX active at dominant state.
That's right, but at least transceivers are saved...

> To maintain bus control by the master, you'd need a four wire bus
> (RS-422), so that a collision on the master TX lines is impossible
> (since there are only device receivers connected to it). If a device
> stucks at TX active, the master still can send commands to all devices,
> trying to gain control again.
Right again, but for mechanical reasons we can't use a 4-wire bus...
don't ask me why......

> Another approach would be a hardware watchdog at each device, forcing
> the transmitter off if it's active for a too long time.
Or a sort of current sensing on transceiver supply.

Thanks!
From: Meindert Sprang on 16 Mar 2010 07:40
"djordj" <grgmeda(a)gmail.com> wrote in message
news:95a1ded9-39d0-45a6-b6e1-6566631c761c(a)e7g2000yqf.googlegroups.com...
On Mar 15, 6:13 pm, Tilmann Reh <usenet2007nos...(a)autometer.de> wrote:

> The network is a single-master bus, but I have to face problems
> deriving from faulty devices.
> What about if a slave get stuck in transmitting mode after its reply
> has been sent?

Design your slave such that after a reset, the DE is inactive and use a
watchdog timer. End of problem.

Meindert


From: Tim Wescott on 16 Mar 2010 12:46
djordj wrote:
> On Mar 15, 6:13 pm, Tilmann Reh <usenet2007nos...(a)autometer.de> wrote:
>
>> RS-485 is pure single master and not capable of a dom/rec scheme. The
>> drivers are push-pull, you can't even predict what the other devices on
>> the bus will receive during the collision.
> The network is a single-master bus, but I have to face problems
> deriving from faulty devices.
> What about if a slave get stuck in transmitting mode after its reply
> has been sent?
> The next time the master get bus control we have two transceivers in
> TX mode, and that's a problem.
>
That's a problem that you face with just about any practical networking
choice. Given careful design of the slave, it becomes equivalent to
"what if a customer takes a hatchet to the main circuit board?" -- i.e.,
a truly fatal problem, but one that isn't likely.

Design your slave so that it doesn't get stuck. A suggestion has
already been mooted for unsticking a hard-stuck slave; consider taking
that, then design the _rest_ of your slave's hardware and software with
a goal of never having it land in that particular safety net.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
From: Jim Stewart on 16 Mar 2010 13:39
Tim Wescott wrote:
> djordj wrote:
>> On Mar 15, 6:13 pm, Tilmann Reh <usenet2007nos...(a)autometer.de> wrote:
>>
>>> RS-485 is pure single master and not capable of a dom/rec scheme. The
>>> drivers are push-pull, you can't even predict what the other devices on
>>> the bus will receive during the collision.
>> The network is a single-master bus, but I have to face problems
>> deriving from faulty devices.
>> What about if a slave get stuck in transmitting mode after its reply
>> has been sent?
>> The next time the master get bus control we have two transceivers in
>> TX mode, and that's a problem.
>>
> That's a problem that you face with just about any practical networking
> choice. Given careful design of the slave, it becomes equivalent to
> "what if a customer takes a hatchet to the main circuit board?" -- i.e.,
> a truly fatal problem, but one that isn't likely.
>
> Design your slave so that it doesn't get stuck. A suggestion has
> already been mooted for unsticking a hard-stuck slave; consider taking
> that, then design the _rest_ of your slave's hardware and software with
> a goal of never having it land in that particular safety net.

The only think I'd add is use a watchdog
and write your TX driver very carefully.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Pic very basic C18 question
Next: Beginner Embedded Linux in c