Protocol j1587

[chipfryer27]

Hi

I think you have got yourself a little confused

Bob's project was for a Raspberry Pi and you are using an ARM STF4 series so there will be some differences. I'm not too familiar with that chip so I assume your clock settings are correct. That is always a good idea to check especially with time sensitive applications such as comms. Never just assume. It may be worthwhile running a one-second flash test which will flash an LED at one second intervals and many examples are in the forum.

In your chart you have the Display on UART Ch1 and the UART component on Ch2. In the UART component properties you have set the baud at 9600 which is I believe the correct speed for your application and seemed to work in your earlier posts. However in the chart you initialise the component but then change the speed to 19200. This step isn't necessary and can be deleted.

Next it gets a little mixed up as you are trying to do things twice but differently. In Bob's chart he didn't use interrupts he instead constantly polled the UART. In your chart you have set an Interrupt on RxINT. This branches to your ISR which is essentially doing the same thing as your Main loop.

It is a good idea to keep ISR's as short as possible. For example grab data and exit leaving the processing for later. Personally I prefer to use interrupts rather than constantly poll but it's up to you. With interrupts the processor can be doing other useful things instead of hanging around and will always be ready to receive. Also, with an interrupt as it is only branching when there is incoming data you can drastically reduce any timeouts too.

A) If you don't want to use Interrupts delete the Interrupt Enable and ISR,

B) If you do want to keep the interrupt then in the ISR delete everything after InDataString and in the Main loop delete the InDataString (first icon in loop). Now, when data arrives the processor will immediately branch and collect the string then return to process.

In Bob's chart after collecting data he then included a calculation overwriting the data with test data. A good idea when testing but remember to delete/disable afterwards. With the test data I could then see a couple of further issues.

After the calculations you branch depending on received values with the rest of the chart concerned with displaying the data. However you are assigning variables such as "x1" to the display. Is this just a test? Shouldn't it be something more appropriate using the collected data? Also you have branches with decisions such as If 77 if what = 77 ?

Regards

[RGV250]

Hi,
I probably should have removed the serial component as it was meant as just an example of how to extract the data from the incoming string. In my original application it only needed to wait for the incoming data and then process it and wait again.

Bob

[bios33]

Hi!
Here is the project with the changes made in accordance with your comments, but uart still does not work.
The display shows only the value 241; if the data had entered, it would have displayed 221. (a test of sorts)

[chipfryer27]

Hi

Looking at your program I see nothing immediately wrong (but I might have overlooked something simple) so it could be down to two things.

1) Interrupt is not being triggered
2) Data doesn't start with 128

Bob only gave an example of how you could capture and parse with some test data as an example to show program flow if received. How sure are you that each dump starts with the line you require?

Your display works so it is easy to do a further quick check.

In your ISR where you capture the incoming data, after you capture it immediately display the string then enter an endless loop. Now if triggered it will collect up to 60 bytes, display them and enter an endless loop doing nothing in it, effectively halting the program.

If you get a trigger then you will see what is captured being displayed. If no trigger then it will show your 241.

Regards

[medelec35]

Hello. I have some suggestions.
Use Human Interface injector API (see attached modified file) and add the data (e.g. Copy and paste) you expect to the Human Interface RX Queue within the console (Only availablee for professional and academic licences).

Consoles.png (8.34 KiB) Viewed 4957 times

Use IsSim to access the ISR Flowchart macro during simulation (see attached modified file).
This will not affect hardware.

Single step by pressing the F8 key.

Within project explorer, select the Variables icon (X) to view the value of each variable.

Use either UART TX, LCD or gLCD to display diagnostic data so you can observe what is assigned to the variables.
Then you can check you are receiving the correct data.

If the simulation is working as expected, then you could have an issue with hardware that either sends or receive data.

Select the Circular buffer component and select help.
There will be some examples on how to use the CB for retrieving data.
You have even state what data to look for.

[RGV250]

Hi,
I think chipfryer mentioned this in an earlier post but you have used UART1 for both the Nextion display and the serial data but defined different pins. I do not think that will work, I would add a second UART component to make sure buth channels are seperate.
Also in my opinion at this point you do not need interrupts so if it were me I would put the receive component in the loop with a bigger timeout and do as chipfryer said and sent the received string out to the display.

I do not know if FC can do this but in Positron (which i use for PIC's) it has a wait modifier for the serial so you can use it as a filter if you only want MID 128. It will reject all other messages.

Bob

[bios33]

Hi! This is what I have at the PA3 UART2 input. And if I decomment the line as in the screenshot, the trigger fires on screen 221

[bios33]

Hello. I have some suggestions.
Use Human Interface injector API (see attached modified file) and add the data (e.g. Copy and paste) you expect to the Human Interface RX Queue within the console (Only availablee for professional and academic licences).
Consoles.png

Use IsSim to access the ISR Flowchart macro during simulation (see attached modified file).
This will not affect hardware.

Single step by pressing the F8 key.

Within project explorer, select the Variables icon (X) to view the value of each variable.

Use either UART TX, LCD or gLCD to display diagnostic data so you can observe what is assigned to the variables.
Then you can check you are receiving the correct data.

If the simulation is working as expected, then you could have an issue with hardware that either sends or receive data.

Select the Circular buffer component and select help.
There will be some examples on how to use the CB for retrieving data.
You have even state what data to look for.

Yes, your example works as expected without any problems.
I tried Circular buffer too - it doesn't work.
I believe the problem is in the configuration of the STM32

[medelec35]

One other suggestion.
Test that the interrupt is working by setting a flag to 1 if ISR Flowchart macro is accessed.
Then within main a decision branch
If:Flag = 1 then send a string "ISR detected"

Have you tried:

It may be worthwhile running a one-second flash test which will flash an LED at one second intervals and many examples are in the forum.

[bios33]

Tested UART RX INT2, it responds normally to data on PA3. When the bus is on, 221 is displayed, and when there is no bus, 241 is displayed, that is, everything is ok with the hardware