If you mean getting the Flowcode version, then the "GetFCVersion" function provides it. My debug build is showing 0x0B0001 which means v11.0.1 (treat the returned value as 0xAABBCC where the version is AA.BB.CC).
Screenshot 2025-12-04 091038.png (19.58 KiB) Viewed 315 times
For a macro name, it depends on exactly what you want to do. The Expand.MacroName might be what you need - this expands a macro to the function name used in the generated code.
I want to call the macro (in this case i2c_master::Transaction_write/read) with different arguments - to avoid having to copy data to / from a byte array.
The name is 'expanded' to FCD_0051_i2c_master__TransactionWrite or something like - and ideally would like to be able to pop this into a component (which I've seen done I think....) in a C block.
Ben is the master of this kind of thing, but I think you can use it in conjunction with the Ev_AddHeader event. This allows you to change or add to the C code generated for the component.
Here's a snippet from the GLCD_Base component:
Screenshot 2025-12-04 103037.png (25.91 KiB) Viewed 310 times
In your case, you could potentially create a new function maybe something like this:
.HeadCode = .HeadCode + "int MyNewTransactionWrite(int NewParam1, char* NewParam2) \n"
.HeadCode = .HeadCode + "{\n"
.HeadCode = .HeadCode + " //do something to create the actual params from those passed to this function\n"
.HeadCode = .HeadCode + " MX_UINT8 myfont = 5;\n"
.HeadCode = .HeadCode + " MX_UINT8 mychar = NewParam[2];\n"
.HeadCode = .HeadCode + " " + .str + "(myfont, mychar);
.HeadCode = .HeadCode + "}\n"
And then call "MyNewTransactionWrite" from a C block. But you could possibly do this instead with a normal Flowcode macro, so I'm probably not fully understanding what you're trying to do.
You can also do some neat things with the C preprocessor - e.g. using ## to concatenate two bits of text before it is passed to the C compiler itself.
No matter though. Hopefully the above gives you some ideas on how you can do what you need.
Thanks - that looks like what we need. I'm trying to cheat on the TransactionWrite taking an array of bytes as a parameter - getting it to take a pointer to the data to be written so - in effect - I can do
while data_length {
// Select FRAM chip and send start address
Write(ptr, length);
ptr += length;
data_length -= length;
}
Which allows the use of multiple FRAM chips - but also (and probably more importantly) allows things like WriteIntArray(intAarray, length) -> Write(&intarray, length * sizeof(MX_UINT16)); and WriteLongArray(longArray, length) -> write(&longArray, length * sizeof(MX_UINT32))
Otherwise we need to copy the data to a byte array buffer and potentially split the writes depending on how much RAM we've allocated to the buffer.
Or is there a way another way around this?
Might just change to using a buffer approach - see if it actually works first
Back from my travels and the FRAM chips had arrived
I wired one up - and using an Arduino and a logic analyser found LOTS of problems with my former code (oops).
So - this works - with the proviso that I've only tested writing and reading arrays of 20 bytes to address 0 - the values of the array are incremented on each loop.
The Write macro - I had to convert to using 'basic' i2c commands (Start, Stop and TransmitByte) - which means it won't work on chips that only allow transactions (esp32 and ARM) - this is because the TransactionWrite always includes the device address at the start of the data - and it isn't needed here! Again - I'm trying to avoid copying the data from one buffer to another.
There is still the issue that I use the i2c command in a C block (and it's name might vary) - use TransmitByte (in Write) or TransactionRead (in Read) and then right click - modify code.
The program outputs the data 'read' to UART (at 115200) - it was easier with an Arduino than wiring up a PIC.
I'll have another play!