Ciao, I am looking for a way with Serial to force a potential receiver to find the channel busy without having to send a byte. It is possible to achieve this manually setting one or both Serial pins temporarily?
I am looking for a way with Serial to force a potential receiver to find Serial.available() == fals
Serial.available() returns the number of bytes in the incoming buffer than have not been read, NOT true or false.
You are dreaming if you think you can force another device to dump random amounts of unread serial data.
What exactly do you want to achieve? Please explain what your project is about and what devices are involved in that communication. If PaulS is right and you want to let a device not under your control to forget about received data, that's not possible. For me it sound more that you want to simulate traffic on the serial line without actually having traffic on it. That doesn't work because the simulation is traffic anyway. If you pull the TX pin low to start a transfer the receiving side will start the reception. It will read it's RX pin in fixed time periods (defined by the baud rate). The only problem is that the stop bit is probably never received so the byte is thrown away.
Ciao I am sorry, the question was not precise as it should have been.
My actual problem is that PJON used through the serial port doesn't have a way to keep the serial busy and avoid other devices in a multi-master setup to start to transmit in the middle of a packet transmission and the synchronous acknowledge sending by receiver after correct crc computation. In SoftwareBitBang data link I have implemented a "jittering wave" generated by the packet transmitter to keep the medium busy, and permit the receiver to sync back to the last falling edge and transmit the result of the computation (also more than once if not received by transmitter). This sort of thing is obviously not possible to be implemented on serial.
All this becomes a problem when users use delays in the sketch which sum is higher than THROUGH_SERIAL_MAX_BYTE_TIME. I can set it higher, but to avoid the collision described before, I have to equally higher THROUGH_SERIAL_FREE_TIME_BEFORE_START, adding a ever present long delay before every packet transmission.
To solve it, I could transmit frequently a predefined wait character to avoid other devices starting transmission and on the other side use a "onreceive" callback to, immidiately after, transmit the result. This would let me have a lower THROUGH_SERIAL_FREE_TIME_BEFORE_START while keeping a potentially THROUGH_SERIAL_MAX_BYTE_TIME 1 second long, having a long blocking timeframe only in the case of device absence.
Your solution sounds eligible but is a work-around in my eyes. It shows that the protocol is not really multi-master enabled but leaves this to the "physical layer" or media module. As the serial interface doesn't offer such functionality you should extend your protocol to offer that service if the lower layer isn't able to provide it. The easiest is probably to make the request and the acknowledgement independent. This way it's no problem if the medium is used by another master between the request and the acknowledgement. It's then comparable to the ethernet medium where the ethernet layer is handling the physical wire avoiding collisions and every packet is transfered independently.
ciao pylon, thank you for your answer, yes as Ethernet PJON has an asynchronous acknowledgment mechanism, to have the chance make hops :) and also to have as you say, an independent or async acknowledgment of a packet, infact it is added to packet its id to give the chance to both devices to identify it. PJON offers also the sync ack mechanism that instead occurs immediately after packet reception and computation. SoftwareBitBang physical layer (in quite a unique way) has this feature, but sadly Serial doesn't offer low level pin handling and so there is no chance to reimplement the jittering wave mechanism...
How long is the serial buffer in a duemilnove?
How long is the serial buffer in a duemilnove?
On ATmega328p devices the serial buffers (RX and TX) are 64 bytes each if using the Arduino Serial library.
but sadly Serial doesn't offer low level pin handling and so there is no chance to reimplement the jittering wave mechanism...
If you do your own hardware serial implementation you theoretically can do that low level stuff you want to do but you're loosing the compatibility with other processor platforms that are Arduino compatible. And you would have to do a lot of testing because it's not clear how the hardware reacts on the jitter arriving in a unexpected speed.