I am trying to understand a 3rd party application that is provided to update TFT images on a TFT display. The TFT is driven by a chip from the PIC24FJ256DA family.

When this 3rd party program is updating the images, it is connected via rs-232 and is writing macbinary files over the serial port.

Essentially, what I am trying to accomplish is to write a comparable program that will run on a linux environment as the 3rd party application only operates on Windows.

Is it fairly common to send data over a serial port to a PIC like this? Or is this more unique in that the firmware running on the PIC has been written to handle this serial interaction and may be hard to mimic without knowing more specifics about the PIC firmware or having source code?

 

The serial link communications part is trivial. Reverse engineering the data formats and serial protocols is the real problem.

 

Not sure if I should branch this off into another post, but it relates to what I stated I was doing in the original thread here....

I have made some good progress on my goal here...and I am currently only hung up on one aspect of the serial data that is being written to the serial port with this application I am trying to mimic. What I have found that the application is doing is, it is reading from a text file, a list of file names. It then writes hex data to the serial port which looks like the following in ascii:

;W000000008800000000000000000000000000000000XXXX....

Within that data, the ;W0000 is constant, the next 4 values increment by 0040, the 88 is constant, then there are 32 0's, and then the next 4 values vary. There is more data in the string that I have "deciphered" and understand where the data is coming from. So the next string would look like this:

;W000000408800000000000000000000000000000000XXXX....

What I am having trouble with is predicting the XXXX values. The first write, XXXX is always 0000. The second write, the XXXX value at times corresponds to the size of the file so I believe this value is an offset of some sort.

It may be a little more easier to follow what I am saying by looking at the attached text file which is the data I captured on the serial port along with my notes that annotate the file size.

Anyone have any thoughts on the XXXX? Am I looking at this wrong regarding a file size and offset?