8051 Serial port

What sort of application needs that?

Alex

J1587/J1708 communication bus with collision detection.

No, you do not need to cancel a J1708 byte transmission, just stop transmitting after the first byte is gone. The collision detection takes care of the rest.

It works for me

Erik

Thanks Erik,

We already do that, but we would like to increase the bandwidth and minimize the risk of collision when more than one module try to use the network.

I do hope you have Rx and an int pin tied together to detect other activity before a full byte is sent.

Erik

Yes, we have an other CPU who constantly verify the activity on the bus.

That is not what I ment. If a J1708 device depend on the Rx serial interrupt to determine if it is OK to start a transmission you will have collisions all over the place. You need to tie Rx to an interrupt pin to detect the start of a byte.

Erik

I am prety shure that we do approximatively the same thing with a small cpu who detect if the bus is idle and send these two kind of interrupt:

-int ready to transmit (depend on
priority)
-int end of mesage

to the CPU who have to send on tx.

The main problem is:

- a bus ready to transmit,
- we send a byte (sbuf = ucByteTx),
- and after that, it do exactly what is
shown in data sheet.

It may take a bit time or more before
a start bit is send on the bus.

This is exactly the time when the
collisions occur. To prevent this,
we would like to close the window as
close as it possible. I think that
agood solution may be to stop the
transmission by a way that we don't
know ??

How about disabling the baud rate generator and/or disabling the UART? I'd expect stopping the BRG to halt transmission, though it would pick up where it left off unless you also reset the UART as well. And of course putting the UART into reset would make it hard for it to keep transmitting.

The 8051 UART interface is pretty minimal, so I doubt there's a specific "abort byte in progress" command.

I DO assume that your question relates to "kill the byte in the UART"

This is exactly the time when the collisions occur. To prevent this, we would like to close the window as close as it possible. I think that agood solution may be to stop the transmission by a way that we don't know ??

It does not matter ONE IOTA when you stop. Once the collision happens, the device you collide with will anyhow send the whole byte. Once a collision has happened neither transmission will be OK.

The only thing you need to worry about is that it is the start bit, not the stop bit from another source that keep you from starting the transmission.

There is, of course, the possibility that your question is "how do I stop byte 2 from going out". If that is the case please clarify.

Erik

here is the two questions

-how to "abort byte in progress".
-how to minimize the delay between write to SBUF and the start bit on tx.

-how to "abort byte in progress".
-how to minimize the delay between write to SBUF and the start bit on tx.
1) you can't (of course a couple of gates between Tx and the transciever could do it). However I have done J1708 for 500+ units/month for years with no problems and never done this.
2) If there is one, what derivative do you use, mine have no delay beyond a few us

Erik

-how to "abort byte in progress".

-how to minimize the delay between write to SBUF and the start bit on tx.

1) That cannot be done on a std 8051. A power off, reset or TR1 = 0; would maybe do something like that and debugging would not be a funny task at all.

2) Create your own 8051. ( faster XTAL? )


Alex

a "funny" (rather sad) story about J1708 and the pseudorandom "int rand(void);"

The J1708 specification specify that after a collision a random delay is to be invoked before the transmission is attempted.

Two devices, both using the Keil "int rand(void);" collided and since the random delay was the same for the two every time they just kept colliding.

WARNING:
When doing J1708 do not rely on pseudorandom use a true random. I have a free running timer that save the value at the end of each transmission from the individual device and this seems to work.

Erik