Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: ATU on December 10, 2019, 11:00:07 AM
-
I am using the StreamIn instruction in a stage to read serial ASCII data from a test device. Problem is that I don't always get the End of Transmission character, but I do know when the device has finished the test. In the stage I break the power flow to the instruction before jumping out of the stage, but I still get this error "Device instruction terminated before completion @00000332 (STREAMIN at CirrusSerialScan@51)" Is there a way to prevent that ?
-
I am using the StreamIn instruction in a stage to read serial ASCII data from a test device. Problem is that I don't always get the End of Transmission character, but I do know when the device has finished the test. In the stage I break the power flow to the instruction before jumping out of the stage, but I still get this error "Device instruction terminated before completion @00000332 (STREAMIN at CirrusSerialScan@51)" Is there a way to prevent that ?
I personally don't enable a STREAMIN until I know the data is there waiting, so I rarely use the timeout terminator. If I expect a terminator, I would enable with the terminator and the max number of bytes in .InQueue.
-
In the stage before the StreamIn, I check IntSerial.InQueue . Infact, I copy that value to another location. StreamIn looks for either a 0x0A or 0xFE as a delimiter. When I see IntSerial.InQueue go non zero I jump to that stage with the StreamIn instruction. No Timeout or byte limit. The strings come in delimited by 0x0A then at the end I get 1 character in, and its only the 0xfe and it just sits in that stage. Could it be that its looking for data and a delimiter? On the tester if I make it pass, it sends a "Passed" followed by an 0xfe and no problem. Seems only if a single character delimiter is sent, it waits.
To get around it, I put a timer on a single character InCount If the number of characters in the queue are greater than 1, it jumps to a stage with a StreamIn looking for the delimiters. If the count in the queue stays at 1 for 100ms, then I jump to a different StreamIn stage looking only for 1 character. Then it doesn't hang. I think it shouldn't hang on 1 character, if the character is one of the delimiters.
-
May be a bug. Lemme dig in a bit.
-
I Switched the 1st and 2nd Delimiters. It did the same thing.
-
Looks like a day 1 bug. Very specific to "any one of" terminators.
-
I am very appreciative that Host takes the the time to fix even the small bugs. Not always the case with other software packages. Makes my job easier when things work the way they should.
-
I am very appreciative that Host takes the the time to fix even the small bugs. Not always the case with other software packages. Makes my job easier when things work the way they should.
I am sorry it wasn't right to start with.
-
I am very appreciative that Host takes the the time to fix even the small bugs. Not always the case with other software packages. Makes my job easier when things work the way they should.
Nowhere do I read that they fixed it! :P
Just kidding, I also admire their description of found bugs, and the repair of such bugs when possible. If only more software companies did so.
-
Nowhere do I read that they fixed it! :P
Just kidding, I also admire their description of found bugs, and the repair of such bugs when possible. If only more software companies did so.
I prefer to be transparent (it can help users with workarounds), but I'm certain that if we were larger there would be those who would twist it into trouble. It would be easy enough to say "we'll look at it" and then the fix show up in the errata of the next release, but as long as it doesn't become trouble to us, we'll continue to interact with users on our forum. ADC reasonably has different guidelines for their forum and we try to respect those. Sometimes I forget where I am though...sorry guys. :o
Just an FYI, if you hear us use the phrase "day 1 bug", that generally means that it appears to have always been broken. We always find those interesting for a variety of reasons.