2

I've learned a bit about Direct Commands in EV3 and understood the work of Local and Global memory. Using the Direct Commands I can access the memory using an offset of the accessing byte/bytes (like if I want to access the byte 4 - I could write smth like LVX(4) (if I use already prepared library)). Now I want to work with .rbf files and found a cool repo that can decompile it into something readable.
enter image description here
And then to this:
enter image description here
Now I really don't understand what is going on. I had some other programs decompiled and as I understood these thing like $LOCAL4 the number in it is directing not to a offset of bytes but bits. There were also some locals like $LOCAL120 and $LOCAL121.
I want to understand is there something common between these local things? And is there docs about memory used by .rbf files?

1 Answer 1

2

It looks like the disassembler you used doesn't show the complete picture. Like many programming languages, the lmsasm language allows allocating variables with either a global scope or a local scope.

I wrote a disassembler in Python that will create a .lms file that can be recompiled with the lmsasm assembler. Using this disassembler should show the actual allocations, although not with the correct data types.

To explain it better, consider this example:

DATA32 MyGlobalInt

subcall MySubroutine1
{
  DATA32 MyLocalInt

  // subcall can use both global and its own local variables
  ADD32(MyGlobalInt, 10, MyLocalInt) // MyLocalInt = MyGlobalInt + 10
  ...
}

subcall MySubroutine2
{
  ADD32(MyGlobalInt, 10, MyLocalInt) // ERROR! MyLocalInt is not defined

  // we could define MyLocalInt at the start of this subcall
  // to fix the error, but it would be a new variable, not
  // related to the one with the same name in MySubroutine1
  ...
}

...

Global variables are declared at the top level of the file and can be used in any blocks (subcall, vmthread, etc.) and will have the same value everywhere.

Local variables are declared inside of a block (between curly braces). Those variables can only be accessed in that block and the value does not persist between calls of that block.


Direct commands also run as a program. They just have more limited rules compared to a user program.

So, to answer the fundamental question: memory isn't directly shared between programs.

However, there are some opcodes that can be used to access memory in other programs.

From http://ev3.fantastic.computer/doxygen/VM.html:

opMEMORY_WRITE (PRGID, OBJID, OFFSET, SIZE, ARRAY)

Write VM memory

Dispatch status unchanged

Parameters

  • (DATA16) PRGID - Program slot number (must be running) (see prgid)
  • (DATA16) OBJID - Object id (zero means globals)
  • (DATA32) OFFSET - Offset (start from)
  • (DATA32) SIZE - Size (length of array to write)
  • (DATA8) ARRAY - First element of DATA8 array to write

Direct command example

opMEMORY_READ (PRGID, OBJID, OFFSET, SIZE, ARRAY)

Read VM memory

Dispatch status unchanged

Parameters

  • (DATA16) PRGID - Program slot number (must be running) (see prgid)
  • (DATA16) OBJID - Object id (zero means globals)
  • (DATA32) OFFSET - Offset (start from)
  • (DATA32) SIZE - Size (length of array to read)

Returns

  • (DATA8) ARRAY - First element of DATA8 array to receive data

Direct command example


Using these instructions seems dangerous since one program doesn't really know what is running in the other slot, so you may or may not be reading from the memory you intended to and writing to the wrong memory could cause crashes or other unexpected behavior.

Instead, I would recommend using the mailbox opcodes to transfer information between programs if needed.

2
  • Thank You for the explanation, but I still want to know is a user program shares memory parts with direct commands like imagine: a user wrote a program, deployed it to a ev3 brick and in the program there is a block like measuring touch sensor (the value of which is not wired to anywhere), so would the value placed anywhere in memory and if yes - could it be accessed by direct commands? Commented Nov 15, 2023 at 17:46
  • 2
    No, memory is not shared directly between a user program and direct commands. However, there are some instructions you can use to access memory in other programs. I will add these to my answer. Commented Nov 15, 2023 at 23:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.