Matrix user forums

Hi Martin,

Perfect!
Problem solved!
Thank you very much for supporting me in this work that was going to exasperate me. Now I can continue with the development of the rest of the firmware.
I saw how you modified the program. Small trick to solve a problem that seemed insurmountable, I honestly do not understand why it is necessary but for now it is enough for me. I'll think about it later.

Regards
castabob

Good, glad your problem is solved.

castabob wrote:Small trick to solve a problem that seemed insurmountable, I honestly do not understand why it is necessary

I have made a few small changes, which change are you referring to?
I can explain the reason behind it.

Hi Martin,
here is what is not entirely clear to me ...
first I had never used this method to intercept characters so when I used the usual system (the one you find in my first file sent) I was puzzled because in emulation it worked but not on the target.
Secondly I don't understand how you went from the first loop to the second loop without a specific instruction in the diagram.
Third I think I understand, (but I'm not sure) that the instruction added at the end of the recognition of the character received "Char_ricevuto = 255" is used for do not let the program interpret the same character for the second time (latency in the reception buffer?).

Sorry for my poor English that comes from my school reminiscences helped by google translator.

Regards
castabob

castabob wrote:first I had never used this method to intercept characters so when I used the usual system (the one you find in my first file sent) I was puzzled because in emulation it worked but not on the target.

Receiving transmitted will not work well(If at all) by just having RS232ReceiveChar within a loop.
What the chances of RS232ReceiveChar being accessed precisely on the start bit of the char being transmitted?
For that reason I placed the RS232ReceiveChar within the RS232 RX interrupt, so chars are not missed. As soon as RX line goes from +5V to 0V the RX interrupt is triggered and char is read.

castabob wrote:Secondly I don't understand how you went from the first loop to the second loop without a specific instruction in the diagram.

It is genuinely bad programming practice to have go to's (Junction points) within code.
So I removed then and used a conditional loop instead that looks for a value at the end: What this means is look at the value of at the end.
If its value is any value except zero then condition is true so exit loop.
If the value is zero then condition is false so so back to the start of the loop.
With a variable, if you don't have value e.g. then the condition is true for any vale except 0 as stated above.
So the loop will exit if or or etc.

castabob wrote:that the instruction added at the end of the recognition of the character received "Char_ricevuto = 255" is used for do not let the program interpret the same character for the second time (latency in the reception buffer?)

Yes that is exactly it.
Char_ricevuto will be assigned a value depending on the value of transmitted char e.g..
Then the decision branch needs to be accessed only once.
Since the value assigned to Char_ricevuto will not change until the next char is received, it will stay at 80 and decision branch will keep getting accessed all the time.
To stop that, as soon as decision branch has been finished with, Char_ricevutohas been forced to 255 so the decision branches are no longer accessed.

Hi,
ok it's clear to me.
Now it is also clear to me why in simulation it works: it is because the characters the simulator picks them up when they need them.
I didn't know that a loop could be conditioned. I'm not a very scrupulous student ...
Thank you very much, you have given an answer to all my questions and above all you have been able to make me understand what you have explained to me (it is not always easy to find teachers who know explain and make people understand).

Regards
castabob

castabob wrote:Now it is also clear to me why in simulation it works: it is because the characters the simulator picks them up when they need them.

That's exactly it, the simulation will be much less fussy than actual hardware.
In saying that the simulation is still great!
you just need to do a step at a time with hardware and make sure it works before carrying on.

castabob wrote:Thank you very much, you have given an answer to all my questions and above all you have been able to make me understand what you have explained to me (it is not always easy to find teachers who know explain and make people understand).

You are welcome. I try and help when I can.
Good luck with your project.

medelec35 wrote:
I have thought of a way to simulate RX interrupt using Ben's excellent Is Sim function.
.

Hi Marin
Where do I find this "Is Sim" function?
I'm obviously doing something stupid as I can't seem to find it anywhere.
Regards

What I do to use Is Sim function:
Click on the magnifying glass (Search) enter issim (no space between Is & Sim).
You should then see the is sim component.
You can also see it within Matrix Tools by selecting Runtime (Cog icon) components.

Hi

Is it part of a feature pack? as I don't seem to have it and I think I've updated all components to latest.

Regards

Hi

I have it in FC8 but not FC7.

I'm running FC 7.3.0.7 and I've downloaded latest components from here

https://www.matrixtsl.com/resources/fil ... -11-19.zip

Maybe it does need a feature pack I don't have on FC7

Regards

No, does not need a feature pack.
I was solely created for V8.
However you can get it to work in V7.
Go to this post
Download Open in V7.
Add your own image for the component
Use the component export option within File menu.
You can then use it in V7

Thanks (yet again) Martin

Much appreciated

You're welcome.
don't forget, after exporting you will need to reload Flowcode or flowchart for it to appear.