Anything seems possible when you don't know what you're talking about.
-- Kevin
@tberrykev In theory it is easy, but because you are using a library you might be limited. I am just getting over covid and not back to feeling my best but maybe someone else will crawl inside the library and see if there is a way to look at two bytes.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
I've been studying the code you provided. In your code, what happens if the first byte isn't "0x42" but the second one is? It seems like in that case, these bytes have been read and when you pass through the While loop again the "0x42" that was in the second byte will have been overlooked?
That's a risk, but there didn't seem to be any occurrences in the sample you included. If you like, I can update the code to check for both separately and also use the struct you've supplied.
Something I really like about your code is that you use a While loop to stay inside readPMSdata() until your business is complete. That is how I want to set mine up. In the original code, it calls readPMSdata() to read each byte until you get the magic "0x42."
I prefer doing the whole collection in one place because it's easier to understand and use the function. Once you call it to request some data you either get a good record or you know that the instrument hasn't finished collecting its data.
And, two years from now when you're re-reading it with a mind to update it, there's onlya single line that invokes it and all the work takes place inside it.
Anything seems possible when you don't know what you're talking about.
Anything seems possible when you don't know what you're talking about.
@will @tberrykev Maybe I still have covid, but just a quick glance at the code uncovers at least the following
1. It appears to me that buffer will be empty upon entry so the tests for 0x42 ox4D will always fail.
2. There is no provision for shorter or longer 'records'
3. There is no scanning for the 0x42 0x4D after one is found. IOW, presumes perfectly formed 32 byte record.
4. The code that moves data from buffer to result I don't fully understand (it's been almost 20 years since I wrote code) but the memcopy is taking the first 30 bytes from a 32 byte variable. Intentional? Why?
I think what is needed is a multi function approach, the first being to read 1 byte at a time looking for the special pattern and filling in a valid? 32 byte read buffer. Then send buffer to be processed vis-a-vis checksum, endian conversion? etc.
Food for thought?
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
@will @tberrykev but just a quick glance at the code uncovers at least the following
1. It appears to me that buffer will be empty upon entry so the tests for 0x42 ox4D will always fail.
The buffer will always be empty upon entry, it's on the stack.
The code sets the expected value for buffer[0] and ...[1] and then tests each to make sure that it matches the desired value for that position.
So, in
( buffer[n]= ) ==
the first (bracketed) section sets the buffer value to the required value and the second section (starting with ==) tests the value read with the value which is already in the buffer.
2. There is no provision for shorter or longer 'records'
Agreed, no requirement was expressed nor implied by the supplied code.
3. There is no scanning for the 0x42 0x4D after one is found. IOW, presumes perfectly formed 32 byte record.
Agreed, either (or both) values couls occur in a valid data buffer at any pont.
4. The code that moves data from buffer to result I don't fully understand (it's been almost 20 years since I wrote code) but the memcopy is taking the first 30 bytes from a 32 byte variable. Intentional? Why?
Because I screwed up and declared "uint16_t result[16]" instead of 'uint16_t result[15]", that's why it's 30 bytes.
That memcpy command is copying the result array over to the address of the struct sent through the function interface.
I think what is needed is a multi function approach, the first being to read 1 byte at a time looking for the special pattern and filling in a valid? 32 byte read buffer. Then send buffer to be processed vis-a-vis checksum, endian conversion? etc.
Food for thought?
I guess it depends on how critical the data collection process has to be. You can describe numerous examples of where this minimal collection facility will fail.
The balance here (as I see it) is how much time and effort is it worth to make the interpretation of the data stream as bullet-proof as possible. If a life (or lives) depended on it, then I'd say it was worth days or weeks of effort and review.
That's a decision for someone else to make, I'm just offering a more compact and concise version of the original sketch segment provided, as requested.
Anything seems possible when you don't know what you're talking about.