PicoScope 7 Software
Available on Windows, Mac and Linux
UART decode via SDK
UART decode via SDK
Is there a feature in the SDK to programatically generate uart decode of a signal trace?
Re: UART decode via SDK
Hi eiselekd,
UPDATE 22/3/21
I have made some changes, and fleshed this answer out in a bit more detail, in response to a similar query from our Help Desk.
The SDK is for developing your own applications, and we only provide examples of basic data acquisition (as the reasons for creating your own application will be different for different people). So there is no automatic code generation in the SDK.
However, you may be able to find examples or get help with generating the code for a UART with an internet search. In the meantime, I did this in a microcontroller many years ago, and as I recall, the method used then was, after establishing the baud rate, number of data bits and number of stop bits, to look for the Preamble (where the line changes the logic state from Idle), then look for the start bit, and use the baud rate to locate the centre of the start bit. Then you identify each data bit of the payload (by one baud-rate bit spacing from the previous bit centre), and then, if parity is being used, identify the bit for that, and perform a simple parity check by eXclusive OR'ing the data bits along with the parity bit (i,e, XOR the first 2 bits, then XOR each new bit with the previous result) to check that the final XOR Logic result is the same as the parity bit. Finally, you can identify the stop bits according to how many have been used. Also, the typical data orientation for UART transmission used to be LSB first, but if this is not the case, you clearly also need to know which way around the bit orientation is. There is a useful resource that discusses a lot of this and includes tips like 'how to work out what the Baud Rate is' automatically here: https://hackaday.com/2016/06/22/what-co ... l-edition/.
Typically, for UARTs the accepted clock frequency for sampling the incoming data packets used to be 16 times the Baud rate. There is good reason for using this sample rate for a PicoScope if creating your own Serial Decoding App for asynchronous incoming data packets from a UART, as described here: https://www.maximintegrated.com/en/desi ... /2141.html.
In the example given by the reference you can see that the link budget is good for typical clock sources, and would remain so for the worst case scenario of 1 start bit, 8 data bits, 1 parity bit and 2 stop bits, i.e. a total of 12 bits in the transmitted packet This would be a good practical size limit, as extending the data length in the packet significantly beyond 8 bits could lead to errors (and is a reason why synchronous transmission protocols are preferred in those cases).
Expecting to do this in real time could be beyond what is realistically achievable, but a lot would depend upon how much real-time data you need to decode, what the baud rate is, how the packets are being spaced apart, how many packets you would be receiving before needing to move the decoded data from non-volatile memory (along with your non-volatile storage capacity) and what you intend to do with the data once it is decoded into non-volatile memory, along with the capability of the computer resources at your disposal.
Regards,
Gerry
UPDATE 22/3/21
I have made some changes, and fleshed this answer out in a bit more detail, in response to a similar query from our Help Desk.
The SDK is for developing your own applications, and we only provide examples of basic data acquisition (as the reasons for creating your own application will be different for different people). So there is no automatic code generation in the SDK.
However, you may be able to find examples or get help with generating the code for a UART with an internet search. In the meantime, I did this in a microcontroller many years ago, and as I recall, the method used then was, after establishing the baud rate, number of data bits and number of stop bits, to look for the Preamble (where the line changes the logic state from Idle), then look for the start bit, and use the baud rate to locate the centre of the start bit. Then you identify each data bit of the payload (by one baud-rate bit spacing from the previous bit centre), and then, if parity is being used, identify the bit for that, and perform a simple parity check by eXclusive OR'ing the data bits along with the parity bit (i,e, XOR the first 2 bits, then XOR each new bit with the previous result) to check that the final XOR Logic result is the same as the parity bit. Finally, you can identify the stop bits according to how many have been used. Also, the typical data orientation for UART transmission used to be LSB first, but if this is not the case, you clearly also need to know which way around the bit orientation is. There is a useful resource that discusses a lot of this and includes tips like 'how to work out what the Baud Rate is' automatically here: https://hackaday.com/2016/06/22/what-co ... l-edition/.
Typically, for UARTs the accepted clock frequency for sampling the incoming data packets used to be 16 times the Baud rate. There is good reason for using this sample rate for a PicoScope if creating your own Serial Decoding App for asynchronous incoming data packets from a UART, as described here: https://www.maximintegrated.com/en/desi ... /2141.html.
In the example given by the reference you can see that the link budget is good for typical clock sources, and would remain so for the worst case scenario of 1 start bit, 8 data bits, 1 parity bit and 2 stop bits, i.e. a total of 12 bits in the transmitted packet This would be a good practical size limit, as extending the data length in the packet significantly beyond 8 bits could lead to errors (and is a reason why synchronous transmission protocols are preferred in those cases).
Expecting to do this in real time could be beyond what is realistically achievable, but a lot would depend upon how much real-time data you need to decode, what the baud rate is, how the packets are being spaced apart, how many packets you would be receiving before needing to move the decoded data from non-volatile memory (along with your non-volatile storage capacity) and what you intend to do with the data once it is decoded into non-volatile memory, along with the capability of the computer resources at your disposal.
Regards,
Gerry
Gerry
Technical Specialist
Technical Specialist