Hi Darren,

We could reproduce the issue and are currently checking on the solution and we'll post an update here soon,

Best Regards, BRT Community

Hello,

The hardware library (libft900.a) has an API defined in the header files that utilises general purpose functions for accessing the hardware peripherals on the chip. The drivers, for instance the USB Host HID driver, sit above the hardware peripheral code and aren’t really optimised for any particular application and instead provide a simple method to do most tasks required for the operation of the peripheral.

During normal operation, the USBH_transfer calls are all blocking and are best used to read data from somewhere that you know there is data waiting. An alternative is the USBH_transfer_async function which is asynchronous, i.e. it has a callback when completed. At present the callback comes during the call to USBH_Process.

So, the USBH_HID_get_report function can be replaced by something that will send asynchronous reads and report back in another callback function. The endpoint information used in USB Host HID driver are available to the calling program in the USBH_HID_context structure.

Best regards

BRT Community

Hello Darren,

Thanks for your update, we are currently looking into this and will update you as soon as possible,

Best Regards, BRT Community

Hello,

Thank you for your feedback, I will liaise with the development team to see if we can add this feature into upcoming ESD releases.

Best Regards,
BRT Community

Hello Darren,

The development team have got back to me on this point.

They note that this is the intentional behavior for a generated MPSSE/Emulator project as they wish users to be aware of these dependencies.
As such users are required  to copy the dependency DLLs(such as ftd2xx.dll) for ESD generated MPSSE/Emulator project.

Best Regards,
BRT Community

Hello Darren,

thank you for your post.

I have managed to recreate this behavior, I believe that the appropriate DDLs should be copied into the executable folder once the build has completed.

I have passed this onto the development team for review.

Best Regards,
BRT Community

Hi,

Most of these items are positioned by the pixel rather than by 1/16th. When used in code examples, you will see that Vertex2F has the value multiplied by 16 e.g. VERTEX2F(20*16, 20*16) to place something at coordinate 20,20. Note that you can actually also display numbers and letters using VERTEX2F as they are made up of a series of images (one per character).

Also note that using the text command does all the character spacing etc for you. If you use Vertex2F this only places 1 character per vertex and so to make a string of characters you will need to call a Vertex2f per character.

It is possible to just add a value to the x coordinate each time but if you want the text to look proportional (and so spacing between each char related to the width of the char) then you can use the metric block data/font properties which is in the EVE chip. For numbers you might want a fixed position for each number so that the whole number does not move around and change in length (e.g. a 1 is narrower than an 8 ) but for text, having a constant spacing between characters may not look as good.

Best regards

BRT Community

Hi,

Here is a small code example.

It will tag the four circles and so when you hold your finger on them, you should see the corresponding tag displayed by the number command.
We set the clear tag to 100 and so if you touch an area of the screen outside of the circles, you'll get tag 100
With no touch, the tag will read 0

We also mask the tag so that the text and number are not tagged, this is useful if you want to turn off tagging for these after drawing the tagged items  (the tag 13 for the last circle would otherwise also apply to the text and number)

Best Regards, BRT Community


   uint8_t Tag = 0;
   
   while(1)
    {
        EVE_LIB_BeginCoProList();                                               // Begin new screen
        EVE_CMD_DLSTART();                                                      // Tell co-processor to create new Display List

EVE_CLEAR_TAG(100);                  // Set tag to 100 for any un-tagged pixels
EVE_CLEAR_COLOR_RGB(0, 0, 0);                                           // Specify color to clear screen to

EVE_CLEAR(1,1,1);                                                       // Clear color, stencil, and tag buffer

EVE_TAG_MASK(1);                                                        // Enable tagging

EVE_BEGIN(EVE_BEGIN_POINTS);
EVE_POINT_SIZE(800);
EVE_TAG(10);
EVE_VERTEX2F((100*16), (100*16));
EVE_TAG(11);
EVE_VERTEX2F((200*16), (100*16));
EVE_TAG(12);
EVE_VERTEX2F((300*16), (100*16));
EVE_TAG(13);
EVE_VERTEX2F((400*16), (100*16));
EVE_END();

EVE_TAG_MASK(1);                                                        // Disable tagging
EVE_CMD_TEXT(100, 200, 28, 0, "The Tag is...");
EVE_CMD_NUMBER(100, 250, 28, 0, Tag);

EVE_DISPLAY();                                                          // Tell EVE that this is end of list
EVE_CMD_SWAP();                                                         // Swap buffers in EVE to make this list active

EVE_LIB_EndCoProList();                                                 // Finish the co-processor list burst write
EVE_LIB_AwaitCoProEmpty();                                              // Wait until co-processor has consumed all commands

Tag = HAL_MemRead8(EVE_REG_TOUCH_TAG);
   }