Patches fssnap-1.0 / 7seg-1.0

[RudolphRiedel]

Posting here since I am using the patch found in patch_b2tf2.py, I converted it to binary for use from SD card.
I am using the patch with my own library written in C, running on a STM32F407 connected to a VM820C.

I started using the patch with CMD_FSSNAPSHOT and it mostly works fine.

• writing takes a while when the file does not exist
• saving "snapshot.bmp" results in a file "SNAPSHOT.BMP
• the bitmap file appears to have extra data between the header and the binary data that confuses some programs such as IrfanView

The second command I implemented is CMD_SEVENSEG and it is not working properly.
It displays nothing on a white background and the segments are not clean when using a black rectangle underneath.

        EVE_color_rgb(BLACK);

        EVE_begin(EVE_RECTS);
        EVE_vertex2f(650, 220);
        EVE_vertex2f(740, 330);
        EVE_end();

        EVE_cmd_fgcolor(RED);
        EVE_cmd_bgcolor(0x808080);
        EVE_cmd_sevenseg(660, 230, 40, 6);
        EVE_cmd_sevenseg(720, 230, 40, 4);

And the result is this with the original saved file opened in Paint.net and zoomed in:

Not only does the second digit vanishes on the white background, there are red dots that do not belong and the left segments on the second digit are drawn incorrectly.

And as a sidenote, I wonder why the black rectangle has a grey outline.

[RudolphRiedel]

I do not see how the linked commit is fixing the issue as it does not provide a new 7seg patch.

[brtchip-gdm]

Rudolph,

I have found the issue with the segments not drawing on top of a bright colour. They use a blend function to form the character. The behaviour was adding the colour in the final layer and to the background colour. However, as you point out it needs to replace the background colour.
The same algorithm is used in the example code in ‎examples/snippets/sevensegment.py. I have changed the final draw in there from a BLEND_ONE to BLEND_ONE_MINUS_DST_ALPHA to fix this:

- eve.BLEND_FUNC(eve.BLEND_DST_ALPHA, eve.BLEND_ONE)
+ eve.BLEND_FUNC(eve.BLEND_DST_ALPHA, eve.BLEND_ONE_MINUS_DST_ALPHA)

The same change will be made to the extension code and patches in due course.

I have verified that the bitmaps don't display with gimp and irfanview.

[brtchip-gdm]

Rudolph,

I've also fixed the CMD_FSSNAPSHOT output. The BITMAPV4HEADER bV4V4Compression was set to BI_BITMAPS instead of BI_RGB. This extension will be updated in due course with the seven segment one. I think Irfanview is stricter than the built-in Windows bitmap viewers.

[brtchip-gdm]

Github autoclosed the issue.

[RudolphRiedel]

Excellent. :-)

I will continue testing then, 34 patched functions of which 33 are new, I actually used four now.
For eight of these the patches have not been released, yet. For example CMD_TEXTTICKER and CMD_LEDROUND.

Oh, one question, I presume combining patches does not work, so using CMD_LOADPATCH more than once?
Using the patches that are in the repositories, I could currently not use for example CMD_TEXTANGLE with CMD_FSSNAPSHOT.
When the patches are released with EAB 4.1, I will probably just select them all from the new panel. ;-)

[brtchip-gdm]

If you look in the Programming Guides page there is BRT_AN_095 BT82X Firmware Update and Extension Guide.

I presume combining patches does not work

Correct, combining patches does not work. Loading another patch to overwrite a previously loaded patch is not recommended.

When the patches are released with EAB 4.1, I will probably just select them all from the new panel. ;-)

You can select the ones you need. There is a limit to the size of a patch.

[RudolphRiedel]

If you look in the Programming Guides page there is BRT_AN_095 BT82X Firmware Update and Extension Guide.

Yes, I implemented CMD_LOADPATCH and all the functions from that.
And I believe it needs an update, same as BRT_AN_086_BT82X-Series-Programming-Guide_1.1.pdf does, I had a couple of functions for which I deviated from the API given.
Like this;
void cmd_sevenseg( int16_t x, int16_t y, int16_t s, int16_t number );

That the size and number parameters are signed does not make sense, neither should be allowed to be negative.
So I am using uint16_t for my implementation.

Correct, combining patches does not work. Loading another patch to overwrite a previously loaded patch is not recommended.

I have not seen a warning regarding this.

There is a limit to the size of a patch.

And that limit seems to be 8kiB, at least all but one of the patches I found so far can be unpacked to 8kiB.
Well, another issue from combining patches might be that RAM_REPORT "only" is 128 bytes,

But well, in the introduction the guide says: "with the extension “.bin”, which can be dynamically added at runtime"

At least these are in different patches, some are probably used less often, like the LVDS extension or the touch extension.

[RudolphRiedel]

Any ETA on EAB 4,1?

I converted the latest patches from the patch_XXXX.py files to .bin and checked their contents.

I used the file patch_b2tf2_py.bin from sd-card and the string returned in mem RAM_REPORT is:
"patch_b2tf2;1.0;fssnap-1.1;7seg-1.2;"

7seg-1.2 - works much better now, no artifacts and also on white background
fssnap-1.1 - I can open the SNAPSHOT.BMP now directly with IrfanView, the only odd thing is that I am using the display with cmd_setrotate(1) and snapshot comes out upside-down.

The patchdata in patch_ledclock.py seems to be the same as in patch_b2tf2.py, except for that they identify as "patch_ledclock" and "patch_b2tf2" respectively, which looks a bit pointless to me - why is there a section to name the patch?
And that string returned in RAM_REPORT looked odd to me, "patch_b2tf2;1.0" does not seem to match the rest of the format.
But checking the unpacked files shows that "patch_b2tf2", "1.0", "fssnap-1.1" and "7seg-1.2" are separate strings.

I believe now that must be some kind of header followed by separate sections for different patches.
And what comes out as "1.0" now probably is the "base" patch that all the patch_XXXX.py files have.
So that probably should read "base-1.0" or in total: "patch_b2tf2;base-1.0;fssnap-1.1;7seg-1.2;"

[brtchip-gdm]

"patch_b2tf2;1.0;fssnap-1.1;7seg-1.2;"

Rudolph, you've understood the format correctly. The full explanation is in the V1.1 version of BRT_AN_095 BT82X Firmware Update and Extension Guide. The word "base" is implied.

[RudolphRiedel]

Interesting, but that is not yet released.

[RudolphRiedel]

examples/rotateselect/patch_rotate.py is using fssnap-1.0

And what is still missing are CMD_LEDROUND, CMD_LEDRECT and CMD_FEEDBACKICON

In light of EAB 4.1 not been released so far, please attach a patch for these, preferably combined with fssnap, textangle, textscale, textticker, dlg and kbd if that is possible.