String Compare Function not working with RS232

[Furiousbullet]

Hi all,

I have been a Flowcode user for many years and I have been stuck on an issue for several weeks now. I have tried as many things as I can think of/found on these forums to no avail, please help!

I have 2 RF modules, one is a tx and one is a rx on a separate circuit. When a button is pressed on the tx, I send a short string of data ("VB") via the rf module. The receiving product then looks for this String of data and if it receives it, it will then fire a Xenon Tube for a specified period of time based on 5 inputs been on or off.

To do this I am using an RS232 interface. It is configured and enabled then the transmitting part sends "VB" if a button is pressed. The receiving end looks for this and if "VB" is received it sends a output macro and fires the Xenon tube. I have had success doing this using the SendChar macro for the RS232 component, however its not as clean or as fast as a String, its also very susceptible to radio noise so it is not ideal. I have also had success doing this by just sending 1's and 0's in a pattern as outputs, but obviously this also is not very good with regards to noise filtering either. This is where I would like to use a String, the data is very clean and very fast on my oscilloscope on both the Tx and Rx circuits.

I have successfully set up the programs to send and receive the String. This is clear in my oscilloscope, the transmitting radio module is sending the String when the button is pressed and the receiving circuit is receiving the exact same string. My issue is the Compare$ function just is not working, no matter what I do.

I am using a decision with $compare (Str1, "VB", 0) == 0 as a decision block to trigger the event, however it never works.

I have a test LED wired up to my output port and it never blinks and the Xenon tube never fires. The data the receiving Rx module is receiving is the exact same data the Tx module is transmitting on my oscilloscope, so I really do not understand why this is not working as the compare output should be 0. I have tried the compare string as a calculation to a variable as well before a decision block to no avail. I have also tried a numerical String such as "1024", but this also has the same problem. I have tried using the UART channel 1 on the IC as well as the digital channel on Flowcode for the RS232, both with the same result.

I have attached my flowcode files, I really hope someone can help me.

I am currently using the Trial version of Flowcode 8 with the intention of buying a full licence at the end of the trial period once I resolve this issue. I have been a Flowcode 5 user for several years and thought it was time to try the latest version.

Thank you in advance!

[medelec35]

Hi Furiousbullet,
Welcome to Matrix TSL forums.
Reason for the RX not to work is you will need to use UART RXINT0 interrupt.
Using the loop instead of UART RXINT0 interrupt you got next to no chance of capturing UART TX data.

Try the above suggestion and if still not working, I can assist you further.

Also make sure the one second flash test is working.

[seokgi]

This is the rs-232 program I use.
I hope it helps.

[Furiousbullet]

Hi Furiousbullet,
Welcome to Matrix TSL forums.
Reason for the RX not to work is you will need to use UART RXINT0 interrupt.
Using the loop instead of UART RXINT0 interrupt you got next to no chance of capturing UART TX data.

Try the above suggestion and if still not working, I can assist you further.

Also make sure the one second flash test is working.

Hello and thank you for the kind welcome.

I have added an interrupt on UART RSINT0 and it's still behaving very strangely. I have attached the revised files.

I can now get it to fire, but I have to hold the button down for about 10 seconds before it matches and fires the Xenon tube, I need it to fire within 5ms. There is still something not right happening with the compare function. The compare should be instant as my oscilloscope is showing me, the "VB" comes into the receiving end instantly when I press the button.

Any other ideas?

Thanks.

[medelec35]

Hi Furiousbullet,

thank you for the kind welcome.

You're welcome.
One serious issue with your flowchart is you are calling an call function within your interrupt.
you must never do that.
An interrupt must be allowed to exit normally than exiting via a call to a macro.
Also, if there is a fair bit of data then the circular buffer is ideal to use in combination with UART.
I have made a minor modification to your receiver.
I have enabled the console & data injector for UART.
So if you have the debug add on, then you can enter the UART values for simulation in the RX queue like this:

UART char injection.png (18.54 KiB) Viewed 5598 times

Then you can see if compare function is working within decision branch:

Test Compare function.png (79.89 KiB) Viewed 5598 times

Note: IsSim function is used to determine if simulation is running or actual hardware.
Only if simulation is running the IsSim variable will be true.

[mnf]

You could test if it is the string compare by comparing str[0] to 'V' and str [1] to 'B' instead of using the compare function.
Do you add a 0 terminator to the string received? It might be comparing more memory than you expect?

Martin

[Furiousbullet]

Hi Furiousbullet,

thank you for the kind welcome.

You're welcome.
One serious issue with your flowchart is you are calling an call function within your interrupt.
you must never do that.
An interrupt must be allowed to exit normally than exiting via a call to a macro.
Also, if there is a fair bit of data then the circular buffer is ideal to use in combination with UART.
I have made a minor modification to your receiver.
I have enabled the console & data injector for UART.
So if you have the debug add on, then you can enter the UART values for simulation in the RX queue like this:UART char injection.png
Then you can see if compare function is working within decision branch:Test Compare function.png
Note: IsSim function is used to determine if simulation is running or actual hardware.
Only if simulation is running the IsSim variable will be true.

Thanks very much, this has solved the string compare and I am now able to fire the Xenons looking for "VB"in hardware.

My new issue is still speed. I can only get a camera shutter to work reliably with it up to 1/80second (12ms). I cannot push the baud rate any higher than 9600 on 16MHZ so I am receiving a "VB" every 2200us. I notice when the button is pressed I still get 2 parts of "1" data before the "VB" data comes through, using even more precious time. I thought a String would solve this issue but it hasn't. I dont understand why it's so slow, 3ms is very slow for software.

I need to get this to work at within 3ms so 1/200s will work with a camera.

I have attatched the latest programs.

Thank you for all of your help so far, I really appreciate it.

[MJU]

I haven't read the whole post, but I recall a problem with RS232 in V8 too.
In this thread: viewtopic.php?f=76&t=21964&p=100362#p100362 there are remainders..

I made the flowchart that I was working on in V7 and this worked well.
I promised to share that V8 file later but I've never finished it..

Maybe this can be a trigger to look further in the RS232 component or the interrupt macro again?

[Benj]

Hello,

Try this and hopefully it should work better for you. You still had a timeout in your receive interrupt which hopefully I have removed for you now as well as the overhead of processing and comparing the string.

Receiver_03.fcfx

(21.69 KiB) Downloaded 171 times

Higher baud rates should work ok at 16MHz. certainly 19200, you should also be able to push to the higher bauds such as 57600 or 115200. You can also make the device run at 32MHz using this line of C code, remember to change your clock speed in the project options too. This will certainly get you those faster baud rates and should also help with the latency.

Code: Select all

OSCCON = 0xF0;

[Furiousbullet]

Hello,

Try this and hopefully it should work better for you. You still had a timeout in your receive interrupt which hopefully I have removed for you now as well as the overhead of processing and comparing the string.


Receiver_03.fcfx


Higher baud rates should work ok at 16MHz. certainly 19200, you should also be able to push to the higher bauds such as 57600 or 115200. You can also make the device run at 32MHz using this line of C code, remember to change your clock speed in the project options too. This will certainly get you those faster baud rates and should also help with the latency.

Code: Select all

OSCCON = 0xF0;

Thanks for this, I'll give it a whirl this afternoon.

Just do double-check, can I leave my transmitter code sending a string of "VB" whilst the receiving code look for the Chars "V" and "B"?

Many thanks!

[Benj]

Yes transmitter is as was and the receiver looks for the characters "VB".

[Furiousbullet]

Thanks for this and everyone’s help so far on this thread.

The code is now working pretty well. My final question is when the button is pressed, I get an overlap of the “1” data, which uses up precious time before “VB” comes through, Is there a way to avoid this?

Please see my attachment of the receiving data on the oscilloscope. The blue data is the bytes been received and the yellow line represents the button been pressed. I have marked with 2 red lines the overlap phase before “VB” comes through.

Thanks.

[Benj]

Hello,

You're very welcome.

This should help. It waits until the last byte is sent before checking the status of the switch and should get rid of that extra "1" being sent.

Emitter_02.fcfx

(10.17 KiB) Downloaded 189 times