One problem with the relatively slow speed of execution of the PICAXE interpreter is that it is often unable to keep up with transmissions from serial devices which send multiple characters back-to-back, especially if the program has to read one character at a time because the data is not in fixed format or of variable length.
I know that background reception of serial data is not going to happen at any time in the near future, if at all, but there is an easier way to resolve the problem in some cases ...
Many serial devices, and particularly a PC, have a Clear To Send line which can be used to allow and prevent data being sent, but this cannot be used by a PICAXE because the line needs to be asserted when a SERIN is ready, and de-asserted during the reception of each data byte, not after it, which is the only place it could be done in a user's program.
Without messing with the SERIN command syntax, could a 'SERCTS <outputpin>' command not be added which would assert an output pin used as the CTS line whenever a SERIN starts and de-asserted as soon as the start bit is read in ?
That seems an elegant way to overcome the problem for serial devices which do support CTS, and would also add in-built handshaking within PICAXE networks themselves, without breaking existing code or complicating the syntax.
It shouldn't be necessary to add a 'mode' parameter, as what logic levels are asserted and de-asserted should be determinable from the Nxxxx/Txxxx baud rate specifier used within the SERIN command itself.
Unwanted interaction with SERTXD ( which probably uses the same low-level interpreter code ) can be avoided by having every SERIN disable SERCTS functionality until a further SERCTS is issued. It would mean having to put a SERCTS before every SERIN, but that's a small price to pay for a massive functionality improvement.
Although it won't solve the problem for GPS data stream reading etc if the sender doesn't support CTS handshake signalling, many devices do, and it would be a real benefit for programs which receive data from a PC which currently have to use involved and complicated schemes such as waiting for an echoed character before sending another, or checking user asserted CTS lines.
I know that background reception of serial data is not going to happen at any time in the near future, if at all, but there is an easier way to resolve the problem in some cases ...
Many serial devices, and particularly a PC, have a Clear To Send line which can be used to allow and prevent data being sent, but this cannot be used by a PICAXE because the line needs to be asserted when a SERIN is ready, and de-asserted during the reception of each data byte, not after it, which is the only place it could be done in a user's program.
Without messing with the SERIN command syntax, could a 'SERCTS <outputpin>' command not be added which would assert an output pin used as the CTS line whenever a SERIN starts and de-asserted as soon as the start bit is read in ?
That seems an elegant way to overcome the problem for serial devices which do support CTS, and would also add in-built handshaking within PICAXE networks themselves, without breaking existing code or complicating the syntax.
It shouldn't be necessary to add a 'mode' parameter, as what logic levels are asserted and de-asserted should be determinable from the Nxxxx/Txxxx baud rate specifier used within the SERIN command itself.
Unwanted interaction with SERTXD ( which probably uses the same low-level interpreter code ) can be avoided by having every SERIN disable SERCTS functionality until a further SERCTS is issued. It would mean having to put a SERCTS before every SERIN, but that's a small price to pay for a massive functionality improvement.
Although it won't solve the problem for GPS data stream reading etc if the sender doesn't support CTS handshake signalling, many devices do, and it would be a real benefit for programs which receive data from a PC which currently have to use involved and complicated schemes such as waiting for an echoed character before sending another, or checking user asserted CTS lines.