I'm working on a sizeable project with six UART ports, with much time expended to check and prove configurations (etc) without conflicts.

However, in addition to the six hardware UARTs, I've added a 7th software 'UART' (Tx only) to drive a Parallax LCD display.

A few times now I've re-opened and ...

Thank you Chipfryer - very much appreciated.

Further investigations suggest something could be going on with the stack/heap however, particularly as the main branch forcibly clears the circular buffer and associated variables at the end - well after possible reception of further data, yet loops and ...

Hi ChipFryer,

Unfortunately, this is for a professional project and I'm prohibited from publicly sharing project details, so I've just shared the debug code added to the end of the main loop to exemplify the issue and test results. The main program loop was simply jumpered with a go-to from start ...

Hi Guys.

I presently have six active hardware UARTS on an STM32F407 micro.

Each UART is served by an Rx-Int, each calling a separate dedicated interrupt service macro for each port, and the data is captured to separate circular buffers for each UART.

In the main thread, it was my intention to ...

When cleaning up code by group-selection of often hundreds of variables for redundant deletion, hitting delete, and relying on Flowcode to find/confirm variables in use, the resulting pop-up states where variables are used but not the name of the variable itself.

Flowcode Pop-Up No Var Name.png ...

When working with macros it is required to re-enter input values in all parameter fields every time.

However, I'm finding that if it were possible to set editable default value(s) within the macro itself (i.e. highlighted default entries specified in the macro edits), then could save considerable ...

UPDATE...

I can confirm the following, per Kersing's experience and advice:

1. I created a new macro, setting the .return type to 'string' immediately on creation , and with added local vars the same as the problem macro.

2. Copy-pasted the flow from the problem macro to new macro.

3. Removed ...

Thank you Steve and Kersing.

Kersing's suggestion could indeed work, as originally .return was declared as integer until changed and macro code modified to pass back a string.

Will update once tried and tested against your suggestions

Many thanks!
Brendan

Thanks Chip...

The .return is declared within the macro editing pane, the var type set when creating the macro (i.e. drop-down at the bottom of the macro edit pane), and the name .return is therefore reserved for this purpose and data type already declared.

Various data types are available and, as ...

I tried to return a short string compiled inside a macro.

The .return type parameter was appropriately declared as 'string'.

However, when I try to copy the compiled string to .return in a calculation, the following results...



Thanks and regards,

Brendan