Flowcode Support Board

More of a gotcha than a bug -

defining data in LUT I would typically have:

0x1,0x2,0x3,0x4,0x5,
0x6,0x7,0x8,0x9,0xA

The newline throws simulation out - although the data works correctly when compiled to hardware... I rather like being able to add newlines (and comments) to the LUT data.
Long data doesn't wrap - so is rather ungainly to view / edit as a single line.

I had:

0x0..0xn // '0'
0n+1..0xn+19 // '1'
etc

Which worked well on hardware - but created confusion in simulation..

As a 'wishlist' - the data window for the LUT opens very small - and would be nice to remember the size dragged too for larger data sets....

Martin

Hi Martin,

Thanks for letting us know.

We're looking into it for you

Thanks, Martin. I can see what's going on.

The list for values is parsed using an internal function in Flowcode that expects to the values to be either comma-separated or newline-separated. In fact, you could have some values delimited with a comma and some delimited with a newline.

You could remove the commas from the end of any newlines and it should simulate fine.

However, that will currently cause problems with the generated C code because the component that is generating the C code is expecting the entries to be comma-separated and simple adds the values (as-is) to the C code. The compiler will treat any newlines as white-space.

We have a few ways to solve this. It could be we create a new LUT component that parses the list of values and adds any commas that are missing from newline-separated values. Or if could be an EXE fix that is more careful when there are trailing commas at the ends of newlines in the list.

But either way, we're on with it.

I'll also look into your wishlist request and see if I can add that.

Hi Martin,

Right I have made a change, I'm hoping it solves the problem and allows your project to both simulate and compile.

It should auto detect when you put something like this.
And convert to be like this.
And auto convert it back when you compile.

Would it be easier to treat CR/newline as whitespace - and require a comma after all but the last entry.

Blank lines are quite nice as a divider? - Although comments could be used:

// This line intentionally left blank

Sort of thing....

Martin

I think I've fixed the issue I mentioned before now.

The problem is that if you take values for example directly from a CSV file then they don't have the commas at the end of the line so there are multiple standards.

Hopefully what we have now should work with both standards.

The only outstanding thing it won't like is a blank newline at the end of the LUT data string. I can maybe find a nice way to eliminate this issue too.