Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Elmryn]

Hi,

is it anyhow possible that CMD_FILLWIDTH can handle '\n' in a way, that it starts the line-break-stuff new?

Example:

Code: [Select]

std::string my_string = "Please do some stuff here and there.\n\nAnd now do print something with a blank line above.";

With the \n\n I want a blank line between the two sentences.
But when I use CMD_FILLWIDTH, the bt815 seems not to start its calculations new after a \n. This leads to a result like this:

Please do some
stuff here and
there.

          And now
do print ...


What I want is this:

Please do some
stuff here and
there.

And now do print
...

Is this anyhow possible with CMD_FILLWIDTH?

[BRT Community]

Hello,

Thank you for your post.

I performed a quick test of this scenario in EVE Screen Editor (see Capture.jpg), and the behaviour was as expected.

Can I ask what value for CMD_FILLWIDTH that you are using?


Best Regards,
BRT Community

[Elmryn]

Hi,

I tested it again, and now it works just fine. Don't know, what I did wrong before.

Is there a way to find out, how many lines or area in pixels or height CMD_TEXT will generate or use when using CMD_FILLWIDTH and OPT_FILL?

Best

[BRT Community]

Hello,

Thank you for the update.

The height of a resultant depends on the number of words and characters contained in the input text command, each character has a width associated to it which can be referenced in the IC datasheet, or in the font header files for a custom font. The co-processor will use the length of input words into CMD_TEXT (de-lineated by the space character), to determine when to add a new line into the text block. For example if the CMD_FILLWIDTH is set to 100 pixels, and the first word within the input text string of CMD_TEXT is 40 pixels wide, followed by a space (5 pixels for example) and another word that is 30 pixels wide, these two words would render on the same line. If the next word in the input string is 35 pixels wide, this would then render on the second line, as this third word would have crossed over the CMD_FILWIDTH threshold setting.

Note: if a input word is longer than the CMD_FILLWIDTH setting in pixels it will not be separated on to two lines when rendered.

I can provide a draft application note which details how to read character widths from a custom font file if required, please let me know.

Best Regards,
BRT Community

[Elmryn]

Hi,

Okay, I understand that. But is it somehow possible to get the number of lines that FILLWIDTH will result in? Lets say I know my font is X pixel high. So for each line I need X pixels. So it would be nice to know how many lines my text with FILLWIDTH needed to calculate my total height. Or better, to just get the total used height, that CMD_TEXT+FILWIDTH needed.

For Example:

Code: [Select]

std::string text = "This is my beautiful text on the BT815 chip.";I don't know the exact width of that text and with FILLWIDTH I do not have to care about it. But if I want to display a button directly under the text, I need to know the height that CMD_TEXT+FILLWIDTH take for the text to display.

Of course I can calculate that on my own by calculating the real text-width of my text, then do linebreaks by my own code according to a given max_width. Thus I would now how many lines or height I need for this text.
But since there is something like FILLWIDTH, which does part of the job by its own, it would be really nice to get the lines or total used height for the text from it.

I hope you can understand what I mean. Feels difficult to explain...

Best

[BRT Community]

Hello,

Thank you for your reply.

Unfortunately the CMD_FILLWIDTH computation occurs on the fly within the EVE GPU, and there is currently no method available to extract the total number of lines that may be rendered based upon an input string from the co-processor for this operation.

I can ask the development team if they could provide the algorithm that CMD_FILLWIDTH uses to render text and establish newlines, but in any case I will suggest that a return value be included for this command for future revisions of EVE.

Best Regards,
BRT Community

[Rudolph]

Please do not add more "return values" to any commands.
I would rather see all "return values" to be removed from commands.

Why?
Because these are a pain to implement on the host processor, you need to traverse back the RAM_CMD after executing the commands.
And even for the BT82x programming guide the given "C prototype" functions are still wrong, as it is difficult to describe what actually
needs to be done.

Commands for single execution like CMD_GETIMAGE are not an issue, still complicated to implement, but least not part of a display list.

Now commands for display list are a completely different story.
Single execution? Fine, works.
But a CMD_TEXT() that would allow to read back "return values" would be impossible to be used when transferring display lists by DMA.
Heck, it would even be impossible to use when using "burst-mode", aka you only send the address once followed by a whole bunch of commands.
There is no way to tell from where in the RAM_CMD to read when you transfer a buffer in order to not block the host controller from doing anything else
during SPI transfers.

And now we just got 16kiB of RAM_CMD and RAM_DL, actually using that with sending command by command is not really feasible.
At least not if the host controller is supposed to do anything else.

What then?
Registers!
Please provide a whole bunch of extra registers that the co-processor is writing to when executing commands.
The memory map of the BT820 reserves 6k or REG_CORE in two regions, this is room for over 1500 32 bit registers.

REG_LOADIMAGE_SOURCE
REG_LOADIMAGE_FORMAT
REG_TEXT_LINE_PIXEL
REG_TEXT_LINES
REG_BUTTON_LINE_PIXEL
REG_BUTTON_LINES

Hmm, ok, fine, with multiple commands one might need to execute the needed command outside of a real display list update, like this:

EVE_cmd_dlstart();
EVE_cmd_fillwidth(331);
EVE_cmd_text(50, 50, 31, EVE_OPT_FILL, "Please do some stuff here and there.\n\nAnd now do print something with a blank line above.");
EVE_execute_cmd();

lines = EVE_memRead16(REG_TEXT_LINES);

This would also provide the value before doing the actual display list.

Ok, sure, that defeats my argument for display lists as the return value could be ignored for buffered transfers and only used for separate commands.
But just reading a register still is more straighforward than for example what I had to implement for EVE_cmd_bitmap_transform():

spi_transmit_32(0UL);
EVE_cs_clear();
EVE_execute_cmd();
cmdoffset = EVE_memRead16(REG_CMD_WRITE);
cmdoffset -= 4U;
cmdoffset &= 0x0fffU;
ret_val = (uint16_t) EVE_memRead32(EVE_RAM_CMD + cmdoffset);

Yes, that spi_transmit_32(0UL); is part of this as you now have to transfer these "return values" in order to advance the FIFO pointer correctly.

With a modified CMD_BITMAP_TRANSFORM that makes the co-processor write to a register instead of RAM_CMD,
this would look like this:
EVE_cs_clear();
EVE_execute_cmd();
ret_val = EVE_memRead16(REG_BITMAP_TRANSFORM_RESULT);

And the co-processor likely would also need a few lines less when writing to a fixed memory location.

So, anyways, please, no more "return values".

[Elmryn]

Hello,
Thank you for your previous explanation of how

Code: [Select]

cmd_fillwidth works. However, we're experiencing behavior that doesn't seem to match what you described.

In our implementation, we're calculating the width as follows:

• We add up the width of each word + the width of a space character
• For the last word, we don't add the space width (since no trailing space is needed)
• We compare this total to our max_text_width (which is 520 pixels, the same value we use for cmd_fillwidth)
• We added a line above the text to visualize the max_text_width value of 520 pixels

Looking at our debug output:

Code: [Select]

DEBUG: Line 0: 'Sorry, the scanned code seems to be wrong.'
DEBUG: Line 1: ''
DEBUG: Line 2: 'To add a new user, please scan the correct'
DEBUG: Line 3: 'QR code from the Nutrio App.'

max width is 520

DEBUG: Starting new line with word 'Sorry, ', width = 72, line_count = 1
DEBUG: Adding word 'the ' to current line, width now = 115
DEBUG: Adding word 'scanned ' to current line, width now = 215
DEBUG: Adding word 'code ' to current line, width now = 275
DEBUG: Adding word 'seems ' to current line, width now = 352
DEBUG: Adding word 'to ' to current line, width now = 382
DEBUG: Adding word 'be ' to current line, width now = 416
DEBUG: Adding word 'wrong.' to current line, width now = 494

The final width is 494 pixels, which is less than our max_text_width of 520 pixels. According to your explanation, all these words should fit on one line. However, as you can see in the first image, the text is wrapping unnecessarily.

Is there something we're missing in how cmd_fillwidth calculates word widths?
Could there be other factors like internal padding or margin that we need to account for?

We'd appreciate any insights on why our implementation isn't matching the expected behavior of cmd_fillwidth.

Thanks for your help!

[BRT Community]

Hello,

Thank you for the update, can I just ask which font you are using in your application?

Is this one of the built in fonts, or a font conversion? if it is the latter can you please provide the converted font files?

Best Regards,
BRT Community

[Elmryn]

Hello,

we use a custom font, Nunito Sans. I have the font-files attached.
(We load xfont and glyh file to RAMG and use CMD_SETFONT2 to attach it to bitmaphandle 28.)

Best

[BRT Community]

Hello,

Thank you for the font files, we are currently investigating this behaviour internally and hope to have an update soon.
Currently we believe that we may need to investigate the IC microcode and how it deals with the '/n' character in input text strings.

Best Regards,
BRT Community.

[BRT Community]

Hello,

Thank you for your patience.

After some further discussion with the development team on this issue, they have confirmed that there is a limitation in the BT81x firmware where the '\n' character cannot be used in conjunction with CMD_FILWIDTH, as the character is counted as having the maximum font width in the conversion.

• Customers can use the newline ‘\n’ characters to control line break by manually calculating each line pixel width.
• Customers can also use spacing (space character) to adjust line break when using CMD_FILLWIDTH.

This limitation has been resolved in the BT820B firmware, which includes a new command to calculate the area a input string will occupy in pixels when using CMD_FILWIDTH.

Best Regards,
BRT Community