I was hoping to ... I guess I'll have to do that by hand.
That sounds a little whiny. You're programming a microcontroller in C now, dude - the sport of kings. There's no room for that kind of talk here.
The goal is to convert a series of ASCII hexadecimal characters, along with some whitespace, into an array of bytes. A low-level way to do it is to examine each character in turn, and decide whether or not it's a hex digit. If it's not, ignore it; if it is, then convert it to binary. A low-level way to convert it to binary is to examine it to find out whether it's a decimal digit, and convert it in an appropriate fashion; if it's not, it's a hex digit, and it gets converted a different way. When the first half of a byte is converted, stash it in some temporary place, get the second half of the byte, and combine them into one byte. Do that until all the characters are gone. Voila - 408 bytes.
... this is a learning thing for me.
That's good to know. It means that you don't want us to write your code for you.
A few things could go wrong. If you collect the whole reply, and then start to process, you've burned almost a kilobyte of RAM - half of the RAM in the Arduino. If you then store 408 bytes someplace else, that's around 70% of your RAM gone, before you start processing data. I see a couple of ways to manage this:
- Process the serial data on the fly, as it becomes available. The Megasquirt 3 appears to support baud rates up to 115200. Guessing ten bytes per character, that means that a byte comes in in about 87 microseconds, or about 1388 machine cycles. That sounds like more than enough time to process the incoming bytes in to an array
- Store the whole message, and then store the data bytes right on top of it. Each data byte comes from an average of more than two characters, so the data won't overrun the message. It looks like you don't need to keep both things in memory at once, so that could work. If you want to fetch new data while still using old data, though, this plan isn't the right one.
If you process on the fly, and something else takes too long, it could be tricky to troubleshoot. But it sure leaves a lot more RAM available, and I can't see a good reason for keeping the ASCII around once the byte array exists. Running out of RAM is tricky to troubleshoot, too.
Because this is a learning thing for you, here's a treat: you might find the meaning of the additional bytes in array at this url: http://www.msextra.com/doc/ms3/files/release/
. A portion of the file "ms3.ini" seems to describe it in a way that I can't fully fathom. But, it sure looks a lot like something that somebody did "text to columns" on in Excel to get the map you showed us, and it maps out to 408 bytes. Extracting it may be a bit of a challenge.