The description for cserial looks good, except its not written in C. It's written in Spin. It's part of the CLIB object, which provides C-like functions for Spin programs. However, cserial itself does not have any C attributes.
The description for cserial looks good, except its not written in C. It's written in Spin. It's part of the CLIB object, which provides C-like functions for Spin programs. However, cserial itself does not have any C attributes.
Dave, now it makes sense. I have changed the title of the section. It's good to have C-like functions just like we have BASIC Stamp-like function for Spin.
I had need for receiving infrequent but unpredictable packets of data at 115200 baud, with the hitch that the system had to operate at low current. That means clkfreq=5MHz if possible. The attached program rxSerial_ta_10.spin works for this. It is receive-only with an intrinsic current drain of 1 mA.
Other programs that I tried, even those that were not rx-only, would not reach 115200 for general purpose buffering to hub ram at clkfreq=5MHz.
Most talk has been about high speed, not low current. The problem is really the same as receiving at 1.8 megabaud with an 80MHz clkfreq (I = 16 mA).
The trick was to rearrange the stuff that has to happen during the 1.5 bit times between the middle of the last data bit and the end of the stop bit, 65 clock ticks at 5MHz/115200baud.
I hope this will be useful to others, and of course constructive comments are welcome.
I had need for receiving infrequent but unpredictable packets of data at 115200 baud, with the hitch that the system had to operate at low current. That means clkfreq=5MHz if possible. The attached program rxSerial_ta_10.spin works for this. It is receive-only with an intrinsic current drain of 1 mA. Other programs that I tried, even those that were not rx-only, would not reach 115200 for general purpose buffering to hub ram at clkfreq=5MHz. Most talk has been about high speed, not low current. The problem is really the same as receiving at 1.8 megabaud with an 80MHz clkfreq (I = 16 mA). The trick was to rearrange the stuff that has to happen during the 1.5 bit times between the middle of the last data bit and the end of the stop bit, 65 clock ticks at 5MHz/115200baud. I hope this will be useful to others, and of course constructive comments are welcome.
Tracy Allen:
This RX is highly useful for some experiments, particularly those involving communications between multi-prop systems with the requirement of very low power drain and non-crystal operations. Going from 16mA to only 1mA is remarkable! I wonder if you have worked with the TX side of things?
Transmit is easier than receive. Most of the pasm tx routines should reach pretty high baud rates. For example JonnyMac's JM_txserial.
I modified the demo for my rxSerial_ta_10. Now it can run on a single prop, with one cog sending the test data to the receiving cog under test. The transmitter is dedicated to sending a fixed string of characters pulled from cog memory over and over at the selected baud rate and at a selected interval. You can try mismatched baud rates. The rx and tx pins on the Prop are tied together and the debugging data goes out the p31 system port. This tx routine transmits with very close to one stop bit without extra for pulling the next byte from memory, and easily does 115200 on a 5MHz clock. Routines that transmit a string from spin always add a little extra time between bytes, so they are not as challenging to the receiver.
I've been testing also with a logic analyzer, to visualize the event positions. You can see the position of the ready-for-start pulse wander depending on how the routine hits the hub access. It has to stay within a margin of the stop bit. rsSerial_ta_10 cut off one hub access by storing the head pointer in the cog, writing but not reading it.
Transmit is easier than receive. Most of the pasm tx routines should reach pretty high baud rates. For example JonnyMac's JM_txserial.
I modified the demo for my rxSerial_ta_10. Now it can run on a single prop, with one cog sending the test data to the receiving cog under test. The transmitter is dedicated to sending a fixed string of characters pulled from cog memory over and over at the selected baud rate and at a selected interval. You can try mismatched baud rates. The rx and tx pins on the Prop are tied together and the debugging data goes out the p31 system port. This tx routine transmits with very close to one stop bit without extra for pulling the next byte from memory, and easily does 115200 on a 5MHz clock. Routines that transmit a string from spin always add a little extra time between bytes, so they are not as challenging to the receiver.
I've been testing also with a logic analyzer, to visualize the event positions. You can see the position of the ready-for-start pulse wander depending on how the routine hits the hub access. It has to stay within a margin of the stop bit. rsSerial_ta_10 cut off one hub access by storing the head pointer in the cog, writing but not reading it.
Tracey Allen:
Great work! The arrangement to transmit a data cache from one cog and receive in another is the exact configuration needed for a type of Propeller array that uses a multiplicity of cogs directly as data communication processors. With this code, it would be possible to interact and talk to specific cogs throughout a Propeller array at these high speed data rates. So maybe each prop could have four channels.
If the exact clock speed is not critical, and of no concern from one prop to the next, and the transmitting and receiving takes place as a pair inside each prop, one would presume the system could run at a set RC clock without a prop crystal. Is this correct?
Tracey Allen:
If the exact clock speed is not critical, and of no concern from one prop to the next, and the transmitting and receiving takes place as a pair inside each prop, one would presume the system could run at a set RC clock without a prop crystal. Is this correct?
Humanoido, the exact clock speed is quite important to this kind of communication. It won't make a difference from one cog to another within one prop, but the RC clocks can vary substantially between two props. A scheme of that sort (with RC clocks) would require an auto-baud scheme for reception. That is not too hard and could be added to the rxSerial program. For example, the transmitter would have to preface each message with a fixed character such as $80, which consists of 8 bit times low (start bit plus 7 data bits). The software uses that to determine the timing factor, and then can receive a message of considerable length. The message has to have a unique termination character, such as ascii null, $00. To avoid a total lockup, a minimum baud rate can be defined, so that a long low level will be interpreted as a BREAK instead of an autobaud command.
Comments
Tim Moore's pcFullDuplexSerial4FC with larger rx buffer by Duane Degn
Send information to a computer using the FullDuplexSerial object
Thread by Mlanting
Other programs that I tried, even those that were not rx-only, would not reach 115200 for general purpose buffering to hub ram at clkfreq=5MHz.
Most talk has been about high speed, not low current. The problem is really the same as receiving at 1.8 megabaud with an 80MHz clkfreq (I = 16 mA).
The trick was to rearrange the stuff that has to happen during the 1.5 bit times between the middle of the last data bit and the end of the stop bit, 65 clock ticks at 5MHz/115200baud.
I hope this will be useful to others, and of course constructive comments are welcome.
Tracy Allen:
This RX is highly useful for some experiments, particularly those involving communications between multi-prop systems with the requirement of very low power drain and non-crystal operations. Going from 16mA to only 1mA is remarkable! I wonder if you have worked with the TX side of things?
I modified the demo for my rxSerial_ta_10. Now it can run on a single prop, with one cog sending the test data to the receiving cog under test. The transmitter is dedicated to sending a fixed string of characters pulled from cog memory over and over at the selected baud rate and at a selected interval. You can try mismatched baud rates. The rx and tx pins on the Prop are tied together and the debugging data goes out the p31 system port. This tx routine transmits with very close to one stop bit without extra for pulling the next byte from memory, and easily does 115200 on a 5MHz clock. Routines that transmit a string from spin always add a little extra time between bytes, so they are not as challenging to the receiver.
I've been testing also with a logic analyzer, to visualize the event positions. You can see the position of the ready-for-start pulse wander depending on how the routine hits the hub access. It has to stay within a margin of the stop bit. rsSerial_ta_10 cut off one hub access by storing the head pointer in the cog, writing but not reading it.
Tracey Allen:
Great work! The arrangement to transmit a data cache from one cog and receive in another is the exact configuration needed for a type of Propeller array that uses a multiplicity of cogs directly as data communication processors. With this code, it would be possible to interact and talk to specific cogs throughout a Propeller array at these high speed data rates. So maybe each prop could have four channels.
If the exact clock speed is not critical, and of no concern from one prop to the next, and the transmitting and receiving takes place as a pair inside each prop, one would presume the system could run at a set RC clock without a prop crystal. Is this correct?
Humanoido, the exact clock speed is quite important to this kind of communication. It won't make a difference from one cog to another within one prop, but the RC clocks can vary substantially between two props. A scheme of that sort (with RC clocks) would require an auto-baud scheme for reception. That is not too hard and could be added to the rxSerial program. For example, the transmitter would have to preface each message with a fixed character such as $80, which consists of 8 bit times low (start bit plus 7 data bits). The software uses that to determine the timing factor, and then can receive a message of considerable length. The message has to have a unique termination character, such as ascii null, $00. To avoid a total lockup, a minimum baud rate can be defined, so that a long low level will be interpreted as a BREAK instead of an autobaud command.
When looking at the serial4fc object, I see that the RTS pin is never set to an output. Once I set it, the RTS pin seems to be working properly.
Anyone have any thoughts if this is the correct fix?
http://forums.parallax.com/showthread.php?135029-VMUSIC2-RTS-CTS-flow-control-using-pcFullDuplexSerial4FC&p=1042139&viewfull=1#post1042139
Ron talks about Tim's fix there.