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.

Just tested the update - and the problem still seems to exist - with commas at the end of each line - just newline works (and compiles correctly)

So
1,2,3,
4,
5,
6

In the above sample - in simulation - Main.str is "1 2 3 0 4 0 5 instead of "1 2 3 4 5... "

Just newline at the end of a line works well - as do comments / blank lines.



Martin

Something odd too..

I removed the trailing commas - and re-exported my LUT in a component. This gave (when used in a chart):

error: hexadecimal floating constants require an exponent

With the code generated:
The actual data seems to be okay - so not sure why it won't compile (the FLOATFIXEDLIST constant should just be superfluous?)

Martin

Commas and newlines are both treated as delimiters and so use one or the other. If you have a trailing comma and then a newline, Flowcode sees this as having nothing between those 2 delimiters and inserts a zero. (I might change Flowcode so a future release will treat a comma followed by a newline as a single delimiter, but I will need to check and make sure it is still ok for the LUT and other components that use this).

I'm not sure about the float issue. Please post (or PM) the generated code and msg.txt and I'll have a look.

Sorry - I'd misunderstood - I thought both styles were supported.

I can't replicate the issue - I replaced the LUT (using undo - so not too onerous) - re-exported and worked perfectly....
Code generated as before too (including the FLOATFIXEDLIST definition)

I also tried changing GetInt to GetFloat - just in case I'd 'missed' - but not that either (a different error message )

A mystery?!