September 2019 Update


View the Most Recent Feature Sheet by clicking HERE!

Wednesday, August 14, 2019

Do-Overs Rock!

At almost 60, I don't sleep a lot, so I spend my time working on Grow By Wire :)

I took a break, and was sitting here smoking a joint, and having a rum and egg nog (yeah, in August) in the middle of the night, with Metallica cranked to 100% in my ear buds...

Anyhow, I've mentioned my "Thoughts" file, where I keep the text file open in Visual Studio so I can jot down ideas before the pot makes me forget them. Gotta be quick sometimes!

So as I sat here thinking of the possibilities during a Do-Over, I made these notes... 

So off I went, I usually do a proof of concept, and here it is...

The extra text for the DONE and ALLDONE lines as well as the actual CRC32 line has more than doubled the size of the payload, but it standardizes EVERY payload that will be sent back and forth.  I downloaded a CRC32 library to use, since that's a little out of my skill set, plus it is a tiny library, the .h and the .cpp each fit on the screen....  

The CRC32 is calculated on the fly, and will be done the same on the other end.

This will enable me to know with certainty that the data is good or bad and act accordingly.

Did I say a week?

Here is a link to the library I used:

Update: 11:15am

This may not work...  For some reason the library calculates a different CRC32 on the Mega than it does on the ESP. I used the same test string on both...

"This is a test to see if the ESP calculates the same CRC as the Mega"

That's gonna make it hard to validate the data is intact :)

Time to look for alternatives...

Update: 2:30pm

If I had looked closer at the results, I would have noticed something...  did you?

Mega=[    98EC]
ESP =[541198EC]

Notice now?

These lines are displayed using sprintf like so

snprintf(tmpBuffer, sizeof(tmpBuffer), "Mega=[%X]", crc_finalize());

I replaced the code with another routine to calculate crc32, and it actually came up with different values, but still they were consistent between the two boards, just the Mega was missing the first 4 digits. Both tests were done on the same string.

Mega =     [6713]
ESP  = [ABEE6713]

So I decided to print out the actual crc as an unsigned long, it's native type as well as the HEX.

Mega =     [6713] = 2884527891
ESP  = [ABEE6713] = 2884527891

So the actual crc IS calculated correctly, just not displayed correctly...

After some research, I discovered this post:
with this advice:

I modified my code to include this

snprintf(tmpBuffer, sizeof(tmpBuffer), "Mega=[%08lX]", crc_finalize());

and now get

Mega = [ABEE6713] = 2884527891
ESP  = [ABEE6713] = 2884527891


Uhm, wait, not so fast...

<TIME>2019-08-14 14:22:44</TIME>

The ESP8266 calculated the CRC on the highlighted characters, including a cr/lf at the end of each line. It calculated 9561525A, using 82 characters

The Mega 2560 on the other hand, calculated FF797376 using the same 82 Characters.

Since my "proof of concept" proves they both generate the correct CRC, I must suspect something in my code which feeds these characters into the crc calculator...

So, back to it....

Update: 4:15pm

I finally found it!

On the Mega, it counted the characters correctly, but due to the way I detect a PAYLOAD, I was "catching up" with my crc updates. I don't know that there is a PAYLOAD defined until it has real all the characters in the first line  <DATETIME>

Now it knows we need to keep a running CRC, so it actually loops through the PAYLOAD name and adds each character to the crc_update method, and update the character count for each.

In addition to the PAYLOAD name though, there is a CR/LF at the end of the line, and these were included in the character count, but not added using the crc_update method.

Skipping 2 characters when calculating the CRC will definately cause problems :)

Ok, onward we go!

No comments:

Post a Comment

Any comments deemed off topic or offensive will be removed