Protocol j1587

[chipfryer27]

Hi

Just reading through the posts and catching up.

I assume you are referencing the above file.

So if I've caught up correctly, you now have the chip connected to the bus and you have 221 displayed, meaning the programme has successfully interrupted. If so that's good.

In the file, you branch to the ISR if data appears on the Rx pin, and in the ISR you set a value for variable Is_Sim to 1. In the Main loop you branch if this variable is set at 1 and display 221.

As you have 221 displayed then your interrupt is working as the variable Is_Sim is only set to 1 inside the ISR.

Martin's advice regarding IsSim is very helpful when debugging / simulating but you have implemented it incorrectly. I'm guessing because of license restrictions you have tried to make a workaround. Don't worry about that, it's no longer needed as your above chart proved the interrupts occur. There are a few things needed to "tidy up" your chart however I think you have over complicated it now and should return to the one you posted earlier(1587_v2 posted at 9:59 today) as it's easy to get caught up in a few things when testing / developing especially if concept is a little unfamiliar.

So we now know your hardware is good and you can interrupt, so referencing your earlier chart only 241 was displayed, not 221 as hoped. You will only branch to display 221 if, and only if the first byte captured is 128. Therefore it is safe to say 128 wasn't the first byte captured (or no bytes were captured).

You are hoping to capture 128 084 000 190 etc but your logic analyser data is confusing.

The "trace" displays 128 84 0 190 starting around 66mS but the side bar shows data of -128 84 0 -66 starting at 81.5xxmS. Is this just due to the screen grab?

I would now concentrate on establishing what is actually being captured at the port. You could modify your chart to display the string captured in your ISR, then you have a good starting point.

Regards

[bios33]

Hi all!
I apologize for the long absence due to PC problems.
Still, I managed to get this program to work. The display shows the water temperature and oil pressure, but the turbine boost pressure is 0, I can’t understand why, and it all works very slowly.
As I understand it, you need to correctly catch the beginning of the line. here is a sample

[mnfisher]

Try:

Interrupt handler just capture one character (using GetChar - rather than GetByteArray) - don't attempt to process the data in the interrupt handler.
Also - don't disable the interrupt in the handler - it should get called once per character (don't re-enable it in the loop in main either)
You could also just save the data to char[] Have a variable 'pos' (initial value = 0)
Then in the interrupt handler:

.c = GetChar(20) (sorry on my phone - can't remember if this is GetByte)
if (.c != 255) && !flag // Check for time out (are you using 8 or 16 bit?) - and don't save if haven't handled previous data
char[pos] = .c
pos = (pos + 1) % 20 // Loop if we overwrite end of string (assumed 20 byte buffer here)
// check for end of data - set a flag (flag = (.pos == required_length_of_data) or .c = end_of_data_char)


In the main loop

Loop
If flag
Process data
Clear flag
pos = 0
Do other things...

Martin

[chipfryer27]

Hi

Well done on getting it working.

Following on from Martin above, your engine is constantly sending out a data dump containing many values that are of no interest to you and you will be processing these too, hopefully rejecting, but you will still be processing everything that is coming in. I don't know the frequency of this dump but if it was every second then you would only get your data of interest every second (approx).

Is updating your display slowing you down? I haven't used the Nextion but can it use a faster speed? 9600 Baud seems quite slow.

Regards

[bios33]

LCD Nextion has its own graphics processor, it works very quickly, and it does not affect the display speed.
Here is an example of a message stream with the timing of each message

[chipfryer27]

Hi

Okay, never having played with the Nextion it seemed something to rule out, which you have, so that's good.

Looking at your chart, in addition to Martin's comments about getting rid of certain components, I am a bit confused (easily done).

What it seems you want to do is:-

You interrupt to capture a string of twenty characters, then convert the first character to a numerical value and if the value of the first character is 128 you then fill the array with the remaining characters before exiting.

Then if the value of the 14th character is 110 you branch to further process the 15th character and display.
If 14th isn't 110 you then test character 6 in the same way, then character 16.

So basically you check if character zero is 128 then if character 14 equals 110 you process, if character 6 is 100 you process and if character 16 is 102 you process.

Using your screen grab as an example, the first time characters 0 and 14 match requirements is at time 0.913
When 0 and 6 match it is at time 0.108
When 0 and 16 match it is again at 0.108.

The next time characters match for 0 and 14 isn't shown
The next time 0 and 6 match it is 0.402
The next time 0 and 16 match it is 0.711 however at this time 0 and 6 also match.

In your chart you branch if certain characters match and if so process for that specific match and if found ignore the rest of the capture.

So once you initially branch for 0 and 14 if found it will not process anything else in the string. However as both "0 and 6" and "0 and 16" both appear in the same string, after you find 0 and 6 and process you effectively ignore 0 and 16.

Now the confusing part.

It looks like you are capturing string values separated by some value (possibly a space) as your screen grab shows for first line

"128 129 017 194 033 004 107 166 002 070 181 002 105 163 002 172 163 002 174 163 008"

You then convert the first character to a byte value. As the above is a string the first character is 1, the second 2, the third 8,the fourth space(?) etc so I don't understand how you are branching. I may have misunderstood something.

Regards

[bios33]

Hello!
This is one of the attempts that at least somehow worked .
I spend a lot of time playing with this task, but it doesn’t occur to me how to do it.
And unfortunately, the component in FC10 Pro, the external UART, does not work for me. It would be much easier with him

[RGV250]

Hi,
As chipfryer says you are using individual caracters for comparison where the value in the message is 3 characters for a decimal so I cannot see how it will ever work.
I the example I originally posted it took the 3 characters as a string and then converted that to the deciamal value.

Bob

[chipfryer27]

Hi

Just remembered you are actually receiving dump of Hex (I think), so in your main loop, test for each "match" sequentially instead of going to the end of the loop after a match is found.

So have a decision for Char 14 and in the"yes" branch, process.

Then after the above, have another decision branch for 6 and process.

Then after the above have another decision branch for 16 etc.

That should give you the values.

Decisions Decisions Decisions.JPG (25.76 KiB) Viewed 842 times

I can understand it being slow but once you can capture all your required data we can look at how to improve.

Regards

[bios33]

This is what happened - all the parameters are on the screen.
I just can’t understand the engine speed (PID190), there are 2 bytes of data, how can I convert them to Uint? It works very slowly.
I believe that it is difficult for the controller to catch the beginning of the line (128)...