Internal documentation

[hiperiondev]

I have seen that Tamosta integrates Berry. Along with that it adds a new data type (int64) and does it "internally". Is there documentation on this process? I would be interested in integrating the data types defined in IEC 61131-3

[hiperiondev]

I did a quick implementation for ESP32 (a job of less than 3hs....taking a bit from here and a bit from there :-) ) and I was surprised how it works. Documentation is very important for this type of expansion.

This is my project: https://github.com/hiperiondev/esp32-berry-lang

[s-hadinger]

Hi, int64 is still an experimental implementation. Tasmota runs in 32bits mode, but for some specific use cases, I needed support for 64 bits ints.

Any feedback to improve documentation is welcome.

There are a few additional tweaks in Berry for Tasmota, specific to ESP32. Namely:

• storing compiled bytecode and constants in IRAM instead of standard RAM. This allows to use ~40kb of RAM which is otherwise unused
• linked to the previous, a fix for float access from IRAM for early revision of ESP32

Edit: https://github.com/berry-lang/berry_mapping might be useful too

[hiperiondev]

I was looking at the Tasmota code but some things are not clear. In particular how it adds the new class internally. I can see that it adds strings in be_const_strtab_def.h and be_const_strtab.h but there is no information about those structures. It also defines entries in be_modtab.c. About all this there is no internal documentation. It would be nice if there is at least a minimal example of how to implement a be_fixed_be_class.

[hiperiondev]

• storing compiled bytecode and constants in IRAM instead of standard RAM. This allows to use ~40kb of RAM which is otherwise unused

  • linked to the previous, a fix for float access from IRAM for early revision of ESP32

There is any documentation about this?

[s-hadinger]

• storing compiled bytecode and constants in IRAM instead of standard RAM. This allows to use ~40kb of RAM which is otherwise unused

  • linked to the previous, a fix for float access from IRAM for early revision of ESP32

There is any documentation about this?

No, it's purely internal implementation specific to ESP32. However the differences are very light, I can give you some links about the changes.

[s-hadinger]

I was looking at the Tasmota code but some things are not clear. In particular how it adds the new class internally. I can see that it adds strings in be_const_strtab_def.h and be_const_strtab.h but there is no information about those structures. It also defines entries in be_modtab.c. About all this there is no internal documentation. It would be nice if there is at least a minimal example of how to implement a be_fixed_be_class.

Sure, but it's not the first thing you should focus on for now. Doing a proper be_port.c is the first thing to do. Then I moved all the Tasmota specific to berry_tasmota lib to make updates of the core Berry easier. The script generating the internal tables is here https://github.com/arendst/Tasmota/blob/development/lib/libesp32/berry/gen.sh

[hiperiondev]

No, it's purely internal implementation specific to ESP32. However the differences are very light, I can give you some links about the changes.

That would be very helpful

[s-hadinger]

Here is the Tasmota PR https://github.com/arendst/Tasmota/pull/14307

[hiperiondev]

Thank you very much

[hiperiondev]

I have tried adding berry_int64 and berry_mapping. I have modified gen.sh and the generate files now look correct. Add missing entries in be_modtab.h. It compiles without problems but doesn't seem to recognize int64:

berry> assert(int(int64()) == 0) syntax_error: stdin:1: 'int64' undeclared (first use in this function) berry> a = int64() syntax_error: stdin:1: 'int64' undeclared (first use in this function)

something else seems to be missing

[hiperiondev]

Also add be_ctypes. Same result

[s-hadinger]

DId you register ctypes like here https://github.com/arendst/Tasmota/blob/d8332bf94cafca91c39df2e66145a962ceb30f7e/tasmota/tasmota_xdrv_driver/xdrv_52_9_berry.ino#L292

[hiperiondev]

Added : be_set_ctype_func_hanlder(vm, be_call_ctype_func); be_load_custom_libs(vm); // load classes and modules

Same error.

It is very dfifficult customize Berry without a minimal documentation of internal API or a complete example. I did many projects with LUA and the best feature is its internal documentation. I see that Berry can be much better but this is essential.

[s-hadinger]

Thanks for your feedback. The Berry community is still small, and focus on documentation was primarily on using the language and integrating the Berry core. Integrating specific extension built for Tasmota was not at the core of the documentation. Does the rest of the language work?

int64 is very experimental.

To make it part of the build, you need to add it to be_modtab.c:

be_extern_native_class(int64);

And add it to the class table:

BERRY_LOCAL bclass_array be_class_table = {
[...]

    &be_native_class(int64),

[...]
};

Please see: https://github.com/arendst/Tasmota/blob/dc217655a090caa6658235fbb50f745133f7e19c/lib/libesp32/berry/default/be_modtab.c#L221 and https://github.com/arendst/Tasmota/blob/dc217655a090caa6658235fbb50f745133f7e19c/lib/libesp32/berry/default/be_modtab.c#L288

[hiperiondev]

What little I have used the language seems to work correctly. As an embedded language for MCUs, it has very interesting characteristics and seems to me to be a good option to replace LUA. In my case (and I suppose it is the same for all of us who are dedicated to professional or semi-professional development) a good scripting language is essential for many applications. I could contribute with internal documentation, since I am very interested in the project. Of course I'm going to need a lot of help with this.

[hiperiondev]

I can also contribute with translations into Spanish and Italian

[hiperiondev]

To make it part of the build, you need to add it to be_modtab.c:

be_extern_native_class(int64);

And add it to the class table:

BERRY_LOCAL bclass_array be_class_table = {
[...]

    &be_native_class(int64),

[...]
};

Now works!

[s-hadinger]

What little I have used the language seems to work correctly. As an embedded language for MCUs, it has very interesting characteristics and seems to me to be a good option to replace LUA. In my case (and I suppose it is the same for all of us who are dedicated to professional or semi-professional development) a good scripting language is essential for many applications. I could contribute with internal documentation, since I am very interested in the project. Of course I'm going to need a lot of help with this.

Thanks for your feedback. After more than a year of using extensively Berry in Tasmota, including the mapping of 1000+ C functions for LVGL, I can confirm it is very stable: no known bug, no crashes, no memory leaks.

[hiperiondev]

All ok