On sixteen function limitation with DUELink scripts

DUELink
1

Yes, the current limit is 16 functions in a DUELink script. That’s what the documentation states, and I verified it. While 16 is true, it’s not entirely accurate.

To better understand developing standalone scripts for a DUELink module, I decided to port a Raspberry Pi Pico application I had developed to a DUELink module.

I started by setting up the application structure, including a substantial number of functions, keeping the 16-function limit in mind. After correcting some syntax errors and running the application, I immediately encountered a “Too many functions” error message.

“Too many?” I carefully counted the methods and found only nine. Why the “too many functions” error?

I won’t delve into the details of how I discovered the cause of this message, but let’s get to the point.

The internal engine of a DUELink module has two regions for code: a driver region and a user region. While I hadn’t given it much thought, I had assumed that the driver region was entirely separate from the user region. This assumption was incorrect. The 16-function limitation is a combination of driver and user functions. For instance, the TFT N18 display module driver has nine functions, leaving seven available for a user script.

What should I do if I need more than the available function count on a module with the drivers installed?

At this point, I see two options: I can refactor my program to reduce the number of functions or reload the firmware without the drivers.

Operating with a reduced number of functions might result in repeating code snippets, which could potentially improve performance. So, it might be something I have to do anyway.

If the drivers are not loaded, I can copy the necessary code from the drivers into my script. The copied code is likely related to hardware initialization.

At this point, I’m not sure what I’ll do.

Here are some things for the community to consider:

  • How important is it to write scripts with up to 16 functions?

  • Should GHI increase the maximum number of functions, assuming this is technically feasible?

  • Should GHI review the current drivers and consider eliminating optional functions?

Please let me know your thoughts.

2

We will improve the docs but the engine does not see “regions”. This feature is only to make it easier to update your code without touching the driver. The engine sees what you see if you “list all”.

It is all about different uses. Some users want more memory for applications, other want more functions but are okay with less memory. We thought 16 is a good number for most. Power users like yourself can get to what they need with some tricks. Func(feature)is a function that has multiple “functions” internally. This will be very ugly and slow but you can potentially have unlimited functions. Is this the right answer? I would say no in many cases but there is a way!

It is easy to increase but we have to remember this is memory is used up no matter if you have functions or not. The list can be be dynamic but this has its own implications as well. Note that each function has a string length and then an address and other things. Lets say it is 20 bytes each. Multiply this by 16 and you now have hundreds of bytes that are taken away from the application.

This is an option. We have built display drivers to be generic and unified width/height/color …etc. But this has very little use. If this is needed by the user, they can use the PID to determine what module is connected and therefore know what is its width and height. We can remove 3 functions if not more! The display can just have init. Actually init can be removed! We could even replace DVer() with a fixed variable _v=1.2 for example. But this means that once the user overwrites _v variable they will lose the “driver version”.

Please share your thoughts and keep in mind we are trying to cover most uses the best we can.

1 Like
3

Great answers!

GHI needs to make sure that the user has the option to load the firmware with and without the drivers.

The console says it is loading both, but is not loading the drivers. The programmer only does both.

4

Only a power user would need the driver and if they want it removed then it is a single click on the console or a single command “new all”.

By the at, we are completely redoing the firmware/driver update experience this week. We already have the new cloning feature on the firmware, just need to be utilized on the website.

5

When discussing this with the team, they decided that the priority is the typical user who will likely access the driver functions from external sources. Power users can easily modify the driver to whatever they see fit. For example, you could completely remove functions from the driver and just init display using the top-level-statements. In this case, you will have all 16 functions to yourself.

I hope this works for you.

1 Like
6

Yes, this makes a lot of sense.

For my application, I did exactly what you described.

Might be useful to put a note into the documentation?