Implement an AssetsPtr template that allows building on 64-bit systems

[Cat-Ion]

Fixes #107
Content warning: Templates

[Cat-Ion]

I can't build the actual firmware yet, so this has only been tested on a 64-bit Linux system so far.

[Cat-Ion]

Looks like there's still some issues with Values, presumably because of the same thing... are the pointers in Value also all allocated in the 8-64 MB region at MEMORY_BEGIN? :S

[mvladic]

There is an error when compiling using Visual Studio 2017:

2>assets.cpp(81): error C2440: '=': cannot convert from 'uint8_t *' to 'T *'
2>        with
2>        [
2>            T=const char *
2>        ]
2>assets.cpp(81): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

[mvladic]

Value has an union which can hold pointers. It is possible that one of these AssetsPtr's are stored in there.

[mvladic]

Same error when compiling using Atollic TrueStudio (armgcc):

..\..\..\eez\gui\assets.cpp: In function 'void eez::gui::NameList_fixPointers(eez::gui::NameList*)':
..\..\..\eez\gui\assets.cpp:81:77: error: cannot convert 'uint8_t* {aka unsigned char*}' to 'eez::gui::AssetsPtr<const char*> {aka const char**}' in assignment
         nameList->first = ((uint8_t *)&*nameList + (uint32_t)nameList->first);

[Cat-Ion]

@mvladic We still need to figure out the Value instances that are used in some widgets. Are all the pointers used there to other assets, or can they be to things not stored on the SDRAM?

[Cat-Ion]

Okay, there's definitely places where pointers outside of the SDRAM are stored in Values. The options that come to mind now are

• Add padding to the one widget that contains a value. This is a dirty hack and needs to be repeated for each widget that gets a Value in the future. Also need to adjust the assets, because they'll be incompatible with the new firmware.
• Make all Values 64-bits. Might bloat the memory by a bit, depending on how many are used in the firmware, but probably shouldn't be a huge issue. Also leads to incompatible assets.
• If we need to keep assets compatible, then we can introduce a new Value that can not contain pointers outside of the assets structure, and can stay 32-bit-sized. It would convert cleanly to the normal Value, and converting a Value containing an asset pointer to this one would work - but it will break for other pointers, and seems a bit more fiddly.
• Leave Value's size up to the architecture, but add an AssetValue that always has room for 64 bits, and only use that for assets. This will simply be a Value on 64-bit architectures, and a Value + padding + conversion operators on 32-bit archs. I like this one the most, at the moment.

[mvladic]

yeah, it'll crash when you... select yt-graph and start a channel, IIRC

I found the reason for this particular crash (and possibly some others in 64-bit build). This:

    Value() 
        : type_(VALUE_TYPE_NONE), options_(0), unit_(UNIT_UNKNOWN) 
    {
        uint32_ = 0;
    }

should be initialized as this:

    Value() 
        : type_(VALUE_TYPE_NONE), options_(0), unit_(UNIT_UNKNOWN) 
    {
        pVoid_ = 0;
    }

This fixed the bug. But, we should also make getOverlay more robust:

Overlay *getOverlay(const WidgetCursor &widgetCursor) {
    if (widgetCursor.widget->type != WIDGET_TYPE_CONTAINER) {
        return nullptr;
    }
    const ContainerWidget *containerWidget = GET_WIDGET_PROPERTY(widgetCursor.widget, specific, const ContainerWidget *);
    if (containerWidget->overlay == DATA_ID_NONE) {
        return nullptr;
    }
    Value overlayValue;
    DATA_OPERATION_FUNCTION(containerWidget->overlay, DATA_OPERATION_GET_OVERLAY_DATA, (Cursor )widgetCursor.cursor, overlayValue);
    if (overlayValue.getType() == VALUE_TYPE_POINTER) {
        return (Overlay *)overlayValue.getVoidPointer();
    }
    return nullptr;
}

[mvladic]

On STM32CubeIDE:

[mvladic]

Otherwise, I tested it on BB3 and it works!

[Cat-Ion]

Awesome! With the latest commit nothing should be able to complain anymore, either :)