COM port test questions
Do you close and re-open the COM port between each test cycle (providing duty cycle is less than 100)?
Does each port test run in a separate thread?
Thanks for your prompt response. I have a few more questions:
1. How long is the message transferred during each cycle?
2. Does the length vary with baud rate selection?
3. Is this a fixed pattern or random data?
4. I checked the revision history and did not see any improvements to Serial Port testing from V6 (currently running on our test unit) to V7. As far as Serial port testing is concerned do you see any benefits from switching to V7?
>1. How long is the message transferred during each cycle?
The test buffer used is 100 bytes
>2. Does the length vary with baud rate selection?
>3. Is this a fixed pattern or random data?
By default it is random. This can be changed to be a fixed user specified value with the "-E" command line parameter.
>4. I checked the revision history and did not see any improvements to Serial Port testing from V6 (currently running on our test unit) to V7. As far as Serial port testing is concerned do you see any benefits from switching to V7?
While the basic serial port test in V7.0 and V6.0 are pretty much the same, there are still some improvements that may help your testing (depending on how you use BurnInTest):
SERIAL PORT SPECIFIC CHANGES:
- The BurnInTest serial port test has been changed to configure the COM ports when run from Microsoft WinPE 3.0 so that the COM ports can be tested.
- When BurnInTest is run on WinPE 3.0, BurnInTest did not report the COM ports in the System Information section. This has been changed.
- Some minor improvements in error handling, in terms of changing the reporting level of some error information and re-ordering 'additional' error information so that the most critical part of the error comes first.
- If you script test runs, then a new scripting command for Serial port preferences has been added: SETSERIALPORTS.
- BurnInTest can now be signalled to stop (and exit) by an external application.
- More than one report type can now be automatically saved, i.e. text, HTML and the customer certificate can now all be selected.
- The trace file format can now be selected (rather than being the same format as the main report file). Specifically if the report is HTML, the trace file can be text (which is easier to analyze).
- BurnInTest 7.0 supports Windows 8 (currently developer preview).
- Improved support for not Latin (e.g. English) character sets. While BurnInTest is in English, some information collected from the system or entered by the user may now use non-Latin character sets.
- The "FAIL" definition has been changed to include critical, serious and warning events, but now exclude information level events.
- All events may now be configured to not be reported if they are not meaningful in a specific test environment (by setting to NONE in BITErrorClassifications.txt).
- Improved the look of the Results and Event log window, making it easier to review the results and events.
Tags for this Thread