UART (RS232) component interrupt during sim not workig

[streammaster]

Hi Ben,

I noticed that if I stimulate the UART functionality using Flowcode 7.2.1.4 Pro, from 'UART to USB Serial Data Bridge' example, the interrupt UART RXINT0 would never be called and no data will be entering circular buffer, however, if I run the same code on physical hardware everything is working as expected.
The PIC which I'm testing with is 18F47J53. I'm not using Injector, but PCs Comm ports to enter data in and out from simulated comm ports.

I made a workaround so I can simulate UART receive.

Uart Rx.PNG

(19.37 KiB) Downloaded 3116 times

I made non-interrupt based receiving (from the main loop) periodically testing the UART reading from it if there is no 255 in the "ReceiveChar" return. I noticed that the PC would buffer Comm receiving data and nothing will be lost, but really this is not how it will be on PIC since there is no handshaking and there is no buffer on sending device.

Any idea how I can get the UART Rx interrupt working during simulation so it matches actual hardware environment?

Regards,

Igor

[medelec35]

Hi Igor,
I have an idea which might work?
Can you post a flowchart that works on hardware, and I will try and add simulation capabilities for you.

Martin

[streammaster]

Hi Martin,

here is the application which I made. There are two commas, but you can be focused on UART1 only.
I made this as preparation for debugging my hardware. I will use USB port to 'sniff' comms to and from UART 1 and UART 2. Also, I will be able to send data from USB to UART.
On hardware, I tested it by looping back UART 1 TX and RX (physically connected pins together. I was able to dump 250 characters on USB side (Using the terminal PTTY) and everything worked without dropped character.

[medelec35]

Hi Igor,
For simulation. do you want to add numbers via com pot or enter a number via console?
I may be able set simulation up for either,
For the moment I have edited your Flowchart so you add the numbers via console,
The update variable will only ever change to 1 during simulation.
Therefore on hardware the call UART_1_Rx will never be accessed so should not be affected
All you do is add numbers to the RS232 RX Queue

Martin

[streammaster]

Hi Martin,
Thanks for posting this. I still need to have a deeper look what you actually did. First view looks like you call only once the RX UART_1_Rx. As you explained this is OK since the data can be entered only before simulation. I noticed that you created 3 additional macros , but i'm not sure where this are called in particular the Ev_Timer (or this is related to the simulation only?). I relay do not understand how the Update becomes '1' when the Ev_Timer is not executed and default for this Byte is '0'. I noticed that when i step in, on first step, the Update variable is already 1, perhaps if you could explain this; how it works?

However I need to have a live data arriving randomly from external RS232 (where real device is connected), and the simulation needs to work in real time. One of this UARTs is SigFox modem and a second is LoRa modem.

The main question which I had is it 'normal' that the simulation is not working for interrupts, or I'm doing something wrong? I believe the component could be easily fixed that it works correctly during simulation, but this needs to be done by Matrix guys i presume.

Regards,

Igor

[medelec35]

Hi Igor,

First view looks like you call only once the RX UART_1_Rx. As you explained this is OK since the data can be entered only before simulation.

No, Makes no difference.
The data can be entered before or during simulation.

I noticed that you created 3 additional macros , but i'm not sure where this are called in particular the Ev_Timer (or this is related to the simulation only?).

These are for simulation only.
The three macros will be totally ignored when during compiling.
The Ev_Timer has been enabled to run during simulation only.
The Update variable will get updated to 1 every 50ms during simulation, but will always remain as 0 on actual hardware.
As previously mentioned, This means during simulation the UART_1_Rx will be accessed, but on hardware it will not.

The main question which I had is it 'normal' that the simulation is not working for interrupts, or I'm doing something wrong? I believe the component could be easily fixed that it works correctly during simulation, but this needs to be done by Matrix guys i presume.

No you have not done anything wrong.
This issue has been known for a very long time.
RX interrupt has never worked from the very first version of flowcode.
I did post a feature request for Flowcode V6 about Rx simulation.
I guess its just complex to implement.
Maybe someone at Matrix could explain the reason for not implementing?

As for RX interrupt simulation via comport.
The best I can offer is a permanent tight loop every few ms which risks the data being missed.
It should not affect the rest of the simulating.

Martin

[Benj]

Hi Martin,

Maybe someone at Matrix could explain the reason for not implementing?

I think to implement this properly we need to implement it in the executable, we can't add it in via a component, unless I am missing something obvious.

There are currently 2 engineers working full time on the Flowcode executable however they are working their way through an ever increasing bugs list and also implementing new headline features to help sell Flowcode 8 and ensure we stay in business.

We can certainly add it to the list, in fact it's probably already on there from Martins last request but the list is prioritised at least partially in terms of number of effected users and number of sales. This is a bit of a marginal request but certainly would be very useful to some users however I also think it would be fairly complicated to implement well. Currently all our simulated (COM) serial comms comes from a DLL we have written. Implementing the interrupt would require the DLL to have some kind of timer and call back mechanism to interrupt Flowcode and tell it new data has arrived. Me and Leigh currently manage the DLLs to take pressure off the executable team so it would have to be a joint effort which means it's even harder to orchestrate. It's even harder when you add that the Flowcode executable programmers are Windows programmers and have no experience of the embedded world so me and Leigh would have to guide them through it, made worse in that we don't do Windows programming.

Anyway hopefully some reasons for you there and not just excuses

[streammaster]

Hi Ben,

thanks for hands up.

I understand now the technical difficulties behind creating real interrupts when the PC UART is used. It is unfortunate but understandable. Perhaps you should properly let people to be worn and provide the simulation work around examples instead as currently the simulation just not work.

However, I believe that there may be an easy way that this can be created in component simulation: we could implement an endless loop in the component main, which will permanently check the (PC) UART (and should run as much the PC allows in separate thread) and then when the PC buffer data is detected create the 'soft' interrupt which then can be used internally in FC during target simulation. After all, FC could store all this serial communication in internal circular buffers, and present it to the simulation. The component main should be used for simulation only and ignored when the code is compiled for actual target. The timing for simulation is not important and actually desirable that the communication data is not lost when we step through the code. This is the actual case already, but no interrupt . If you need to do it from scratch then we should be able to create the simulated interrupt condition which can be assigned to another special variable as a simulation interrupts inside the component. Then this variable can be assigned to actual MCU property as any other pin property in the target simulation and problem solved.
Maybe this is when are you referring to the 'exe' modification?

Perhaps for FC V8 you may improve a bit the power to change capability and user flexibility of creating such simulations like a hardware interrupt, being regardless MCU internal or external interrupt. To have interrupt properly simulated it is probably the most crucial feature, which is really hard to debug once it is running on real hardware. Communication in general terms is a key feature of today MCU, switching LED on and off is really not achievements any longer for anyone.

When it comes to the reason why I purchased the FC pro version with all these components modules is that I expect to fully work. I haven't seen anywhere in FC presale papers that the FC simulation is not simulating real MCU capabilities, and it may actually not work as expected.
Not that this fact would stop of purchasing it, but at least I will not spend many long nights of scratching my head; way something is not working.

All good!

Igor