While thinking about ways to print a 32 bit value with only a 16 bit NUMBER_TO_STRING I found an opcode called RLx. Happily I thought it meant Rotate Left, and that is also what it says in the documentation.
/*! \page Logic
* opRL16 (SOURCE1, SOURCE2, DESTINATION)
*- Rotate left 16 bit value DESTINATION = SOURCE1 << SOURCE2\n
*- Dispatch status unchanged
* \param (DATA16) SOURCE1
* \param (DATA16) SOURCE2
* \return (DATA16) DESTINATION
Happily I figured I could rotate left and pick the lowest byte four times and convert those into figures that could be converted, but unfortunately it doesn’t really rotate left. By looking at the implementation I can see that it shifts left.
Tmp = *(DATA16*)PrimParPointer();
Tmp <<= *(DATA16*)PrimParPointer();
*(DATA16*)PrimParPointer() = Tmp;
So unless the left shift operator on the Brick is actually a rotate the RLx function won’t be of much use.
I guess what I can do is MOVE32_8 the 32 bit number to an 8 bit number, and then sign convert it to a 16 bit value that I convert and add to a string, then DIV32 the original 32 bit number by 256 and do the same procedure again until I’ve fetched all of the 4 bytes individually.
Luckily I love these kinds of quirky limitations. It just makes me more inspired to keep learning about things and think about what to build for the device. It changes my own expectations of the game I’ll make and takes some of the pressure off.
Tomorrow I’ll look into printing that 32 bit value.
After looking at the documentation generated by Doxygen I found the NUMBER_FORMATTED function that accept a 32 bit number and converts into a string. So that seems like it’ll do the trick.
Thinking back on what I’d done previously I remembered that I had included the LabVIEW DLL’s into a Unity project to peek at the symbols in the DLL’s. And today I remembered one of the very first things I was asked when I told people I had bought my Mindstorms. “Does it work with Unity?”
It can’t be that hard to write a simple program that runs on the Brick and relay the information from the ports back to a C# plugin used by Unity.
I think I’ll add that to my to do list too.
I’ve just started looking into including LMS files from other LMS files and there doesn’t seem to be a pre processor directive in the assembler that does it. I’m not very experienced with logo but from what I can tell the assembler is made up of three passes blllurb.
pass 0: process definitions
pass 1: fill in opcode, etc
pass 2: process labels
(copied from assembler.logo)
Considering how the C pre processors handle the include directive I looked into pass 0. It seems to be four things that the assembler looks for in pass 0.
So there doesn’t seem to be an include directive for LMS. I’ve quickly looked through the other passes but none of them seemed to do anything like it.
After that setback I remembered that I had found a file called template.lms. It was used by a LMS called Brick Program.lms, so I opened that one up and looked into it. Template.lms seems to include template code for the programming blocks you use when you use the Block Programmer on the EV3 Brick, so to the best of my knowledge it seems like the Block Program is the UI for programming the EV3 Brick on the brick, and it use the template.lms to include code snippets that in the end will make up the code that the user generated through the flow chart.
Then I remembered the LOAD_IMAGE function, that loads byte code for execution. But LOAD_IMAGE doesn’t seem to allow execution of selected functions in the loaded file, only executing the full file.
So for now there doesn’t seem to be a way to reuse LMS code in different projects. But since that is a matter of a simple text processing directive then perhaps I’ll look into writing my own pre processor that manages it. I’ll add it to my to do list.