Stuck Transpiliing

Looks like a bug in my program has revealed a bug in XOD. This was working until I pulled the decode out into a separate node, now it just hangs with the debug window just saying “Transpiling…”

If I switch to a working project, it uploads fine. Switching back to this project hangs on Transpiling again.

I don’t believe I did that…I meant to attach the code that was getting stuck at Transpiling. Now I have a “working” copy and apparently I did not save a copy of the broken code :frowning: I will try to re-create…

ir-remote.xodball (9.7 KB)

I’ve attached this “working” copy because it is a mess & I’m hoping someone can explain what I’m doing wrong. I tried to just port the Arduino IDE code I had, but auto-converting between numeric types seems to be causing issues in XOD. The problem with the IR Remote randomly returning 2 different values for each button was a problem in Arduino IDE also. The new problem in XOD is that it sometimes returns the negative of the numbers also. I tried adding the negative numbers to the case statement, but it complains about duplicate values with the non-negated number. I’ve labelled what would be negative numbers with comment “negative???” in the decode node. By forcing assignment to an unsigned int, I’ve worked around the issue, but it is pretty ugly…

BTW: my remote will return 0xFFFF to indicate the same key is still being pressed, hence the code checking for that specific value in ir-read


I guess the problem is in ir-read:

        long int out = -1; // (1) signed integer
        decode_results results;
        if (irrecv->decode(&results)) {
            unsigned int in = results.value; // (2) unsigned integer with wrap
            out = in & 0xFFFF; // (3) `out` is signed, 0xFFFF is signed, `in` casts to signed
            if (out == 0xFFFF) {
                out = getValue<output_OUT>(ctx);
        emitValue<output_OUT>(ctx, out);
  1. out used to return results is signed 32-bit integer, but in all other code, you deal with unsigneds. I recommend using unsigned int out. -1 will cast to 0xFFFFu just fine.
  2. results.value is 32-bit unsigned integer (unsigned long), and you shrink in to 16-bit unsigned integer here. Try to use unsigned long in to match the IRremote type
  3. You use 0xFFFF signed literal. Use 0xFFFFu to explicitly indicate you’re using unsigned arithmetics

Having done that, you’ll have no chances to emit a negative number :wink:

I partially implemented some of these fixes after posting. I will finish the cleanup based on your recommendations. Since 0xFFFF is already taken for “repeat last output”, I changed “no output” from ir-read to be 0. My decode outputs 0xFF for “no output” since 0 is used for “0” key.

I have not been able to re-create the problem getting stuck on “Transpiling…”. Double-click to open a node also started working again; almost like the two might somehow be related…

I’ll quit posting type-casting issues here & update this thread if I re-create the Transpiling issue.

1 Like