FRAM COMPONENT

[mnfisher]

this might lead to some difficulties when converting to a component - is there a 'correct' way to get the full macro 'name'?

Or when running in a different version I'll have another play!

If want to try - do TransactionWrite (or Read) - right click and do modify code - and change the parameters as per my code....

Martin

[Steve-Matrix]

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 883 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.

[mnfisher]

Thanks Steve,

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.

Martin

[Steve-Matrix]

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 878 times

In your case, you could potentially create a new function maybe something like this:

Code: Select all

.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.

[mnfisher]

Hi Steve,

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

Code: Select all

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

Martin

[mnfisher]

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.

Martin

[mnfisher]

WriteString needs the '&' removing from the code block too

[pmgreene01]

I want to use a FRAM and found this thread. However, I am not sure how I take the file FRAM_2.fcfx and use it as a component in my project.

When I chose a FRAM for storage, I didn't realize that the built in EEPROM components couldn't be used to write and read to the device. I have no idea how to write the low level code to do this without a Flowcode component. It would be helpful to have a FRAM component that could be used on the 2D panel. I agree with an earlier post that the performance specs of FRAM devices seems far superior to traditional EEPROM.

[mnfisher]

Hi,

No - it's not a component (and by the time it is Ben will probably have come up with something better ) - I wanted to show the development of some (hopefully useful) code - from 'first contact' through the development to the final code. You 'could' use the current code by adding the macros to your code but the ultimate aim is to produce a component for access to the FRAM.

I was hoping to get others onboard to help with either testing / ideas / code - volunteers welcome ! The above code seems to work - but I've done very limited testimg - so if you (or anyone else) could do some more testing that would be very helpful.

I've tried to outline some of my design decisions above - and some of them don't fit easily into the Flowcode world - two of the biggest issues are
1) i2c::TransactionWrite taking an array of bytes rather than a pointer (which I've sidestepped in code - although it makes the transition to a component rather more difficult)
2) TransactionWrite always outputs the device address as a first byte - which I've avoided by using lower level i2c code - but this excludes ARM and esp32 MCUs from using it.

Whether my ideas are 'good' is debateable of course - my idea is that macros such as WriteIntArray , WriteLongIntArray etc are trivial - and add very little code.

So yes - please play along - if you can try the code and make suggestions about the 'user interface' that would be great

Martin

[pmgreene01]

Thanks for the reply. I will look at incorporting this.

I went down a rabbit hole with ChatGPT and got a writeString and readString macro working, but there is a ton of C-code, so I would like to be able to do it more with Flowcode. I can share the c-code if it is of any interest. However, it takes over the I2C bus during the FRAM operations and then hands it back to Flowcode which is awkward. I am using an I2C LCD display during development, but in the final deployment, the LCD would be off by default and only turned on for diagnostics.