There is a difference between a null character and one that is missing its stop bit (framing error).
This answers one of my many questions about serial data. Then a continuously low line should not produce null characters. This is very good to know.
I'm guessing the way to fix this is to make sure any null character has a stop bit. (I assume this is what makes the difference between a break and a null character?) I think I mentioned earlier in this thread, the modifications I made where just at the edge of my programming abilities. I'm going to need to get up to speed on asynchronous serial communication to polish these modifications.
Well, I spent some more hours on this. The attached version gets rid of the binary size limitation. I set it at 173 bytes and used that for the name, but it can really be any value.
The current hub footprint allows for 73 bytes per buffer within the footprint itself, by recycling. The new program has a default minimum buffer size of RX_DEFAULT = 73 (might as well; it is free space) and another constant RX_EXTRA that adds extra longs for the rx buffer, beyond the hub footprint. In this version I set the value of RX_EXTRA to 100, so the buffers are 173 bytes. All this is with restart of the object allowed.
The transmit buffers are still 16 bytes each, and are referenced by name. The receive buffers are now referenced by offset instead of name.
If it doesn't add too much to the code size, my goal is to make the rx and tx buffers independently sized. Different devices have very different requirements. 100 extra bytes per buffer is 400 total, which may be a waste for some purposes, essential for others, and it is taken whether the ports are started or not.
There is some additional rearrangement and cleaning up as outlined in the object header.
I like your method of using a constant to define buffer sizes.
If the number of ports being used could also be defined as a constant instead of at run time, then it should be possible to not assign buffer space for the unused ports.
Have you figured out why using all four ports increases the speed?
It would be really nice if we could define only two ports and save half the buffer space and have the driver able to handle communication twice as fast as using four ports.
I agree it would be nice to have both the tx and rx buffers independently sized. So far, none of my projects have required a large tx buffer.
It will be pretty straightforward now to modify it for independent buffer sizes at compile time, to set aside exactly the aggregate buffer space required.
A larger tx buffer might be required in a situation where, say, you want to queue all of the data for a 100 byte XBee API packet quickly. Spin code providing the data wants to hand off the packet and get back to work on something else. The tx buffer can handle the slower process of handing off the data to the XBee. As it is, with a 16 byte buffer, the Spin code has to do a lot of waiting around.
I don't know yet about why having all four ports added decreases the jitter. Been meaning to look at it more closely with the Saleae logic probe. The thing that puzzles me in the code is the fact that the following patches to the co-routine vectors are commented out for all 4 ports:
or txmask3,#0 wz 'by changing the co-routine variable
' if_z mov txcode3,#receive
'patch all of rx routine out if not used
or rxmask3,#0 wz 'by changing the co-routine variable
' if_z mov rxcode3,txcode3 'use variable in case it has been changed
Those vanished if_z statement seem to be the only place where the patch might be made.
Looking back for documentation links, I found Tim's thread where he posted the 8/14/08 revision. I was happy to see that his correction to CTS was the same as I came up with, however, it looks like RTS was already correct and Tim mis-corrected the revision.
I'm working on a project that requires several serial ports. I'm not happy with the way one of my objects is working so I wanted to give Tracy's new objects a try.
I was surprised there wasn't a link to Tracy's thread in this thread. I'm adding it now.
I uploaded the most recent version to the end of that thread. Thanks for bringing it up!
@MacTuxLin, The threshold is only important if you are using RTS flow control. It determines how many characters have to be present in the receive buffer before the RTS output pin goes to its asserted=full state.
The threshold is only important if you are using RTS flow control. It determines how many characters have to be present in the receive buffer before the RTS output pin goes to its asserted=full state.
Comments
This answers one of my many questions about serial data. Then a continuously low line should not produce null characters. This is very good to know.
I'm guessing the way to fix this is to make sure any null character has a stop bit. (I assume this is what makes the difference between a break and a null character?) I think I mentioned earlier in this thread, the modifications I made where just at the edge of my programming abilities. I'm going to need to get up to speed on asynchronous serial communication to polish these modifications.
The current hub footprint allows for 73 bytes per buffer within the footprint itself, by recycling. The new program has a default minimum buffer size of RX_DEFAULT = 73 (might as well; it is free space) and another constant RX_EXTRA that adds extra longs for the rx buffer, beyond the hub footprint. In this version I set the value of RX_EXTRA to 100, so the buffers are 173 bytes. All this is with restart of the object allowed.
The transmit buffers are still 16 bytes each, and are referenced by name. The receive buffers are now referenced by offset instead of name.
If it doesn't add too much to the code size, my goal is to make the rx and tx buffers independently sized. Different devices have very different requirements. 100 extra bytes per buffer is 400 total, which may be a waste for some purposes, essential for others, and it is taken whether the ports are started or not.
There is some additional rearrangement and cleaning up as outlined in the object header.
If the number of ports being used could also be defined as a constant instead of at run time, then it should be possible to not assign buffer space for the unused ports.
Have you figured out why using all four ports increases the speed?
It would be really nice if we could define only two ports and save half the buffer space and have the driver able to handle communication twice as fast as using four ports.
I agree it would be nice to have both the tx and rx buffers independently sized. So far, none of my projects have required a large tx buffer.
Thank you for making and posting these changes.
A larger tx buffer might be required in a situation where, say, you want to queue all of the data for a 100 byte XBee API packet quickly. Spin code providing the data wants to hand off the packet and get back to work on something else. The tx buffer can handle the slower process of handing off the data to the XBee. As it is, with a 16 byte buffer, the Spin code has to do a lot of waiting around.
I don't know yet about why having all four ports added decreases the jitter. Been meaning to look at it more closely with the Saleae logic probe. The thing that puzzles me in the code is the fact that the following patches to the co-routine vectors are commented out for all 4 ports:
or txmask3,#0 wz 'by changing the co-routine variable ' if_z mov txcode3,#receive 'patch all of rx routine out if not used or rxmask3,#0 wz 'by changing the co-routine variable ' if_z mov rxcode3,txcode3 'use variable in case it has been changedThose vanished if_z statement seem to be the only place where the patch might be made.Tim Moore's original pcFullDuplexSerial4fc thread
Tim's OBEX object (7/24/08 version)
Update correcting polarity of flow control (8/14/08 update not in OBEX)
Juergen Buchmueller's 2 port trimmed down version
various threads about baud rates attainable, hiccups, jitter:
discussion #1
discussion #2
discussion #3
discussion #4 (jitter, PBnJ)
discussion #5
Humanoido's catalog of serial port objects
I was surprised there wasn't a link to Tracy's thread in this thread. I'm adding it now.
Link to Tracy Allen's FullDuplexSerial4portplus thread.
I have a question regarding the threshold value. May I know on what basis do I need to place a value to it?
Thanks.
@MacTuxLin, The threshold is only important if you are using RTS flow control. It determines how many characters have to be present in the receive buffer before the RTS output pin goes to its asserted=full state.
Got it. Thanks Tracy.