New native function to load a bytecode, from memory or from SD

[davidjsherman]

I propose a new, hidden system function _bytecode.load(number) that resets the VM an loads a new bytecode into memory. It would work analogously to the sound.{system,record,replay,play} functions:

1. if a file named Ax.abo exists on the SD, load it
2. if x = 0 and vmcode.abo exists on the SD, load it
3. otherwise, if x is in 0–6, load the corresponding system bytecode
   • 0: initial menu, 1: friendly, 2: explorer, 3:fearful, 4: attentive, 5: investigator, 6: obedient
4. otherwise, beep (play note A4 for 10)

There is no _bytecode.save! Bytecodes cannot be written by programs, they must be saved on SD cards.

Pre-compiled byte codes can be added to the firmware with a new static const struct bytecode, analogous to static const struct music in playback.c.

Firmware 10 has the initial menu interface and default LED behavior hard-coded in behavior.c, and the six basic behaviors are hard-coded in C in mode.c. This is hard to maintain. There is no guarantee that the hard-coded behaviors can be imitated by student programmers in Aesl. With this function and steps 3–4, above, one could replace the behaviors written in C with stored bytecodes that were generated from Aesl programs.

With this function and steps 1–2, above, one could update the standard behaviors by placing the improved bytecode files on the SD.

This function could furthermore be used to define a new second-stage boot loader, replacing the initial menu system. Bytecode vmcode.abo on the SD card is run automatically and could present a different menu system, with a different choice of pre-programmed behaviors.

The other standard behaviors, such as updating the charging LEDs and changing the circle LEDs according to the accelerometer, should still be implemented in behavior.c.

[mbonani]

I am not sure it is easiest to maintain to have compile code .abo in structure. And aslo I not sure for the memory places, should be investigated Also lot of customers were very afraid that they can loose the basic behaviour. So even do not connect Thymio to the computer... So all this seems to me complicated, if we explain there is a way to change the basic behaviors... Having fix behaviours that are always there is an marketing advantage. There is also something not clear for me how to manage the initial menu in a bytecode, how to return to it and how exit from a bytecode in aseba. I am also confused with A0.abo and vmcode.abo.

[davidjsherman]

This original idea comes from aseba-community/aseba#550, because the simulator does not have the target-thymio2 firmware code. So we will probably implement it this was in the simulator, since it is easier to write an Aesl program to simulate the initial menu than it is to simulate the PIC24 firmware.

If you prefer, in the real robot, we could disallow x = 0–6 in order to guarantee that the basic behaviors are always available. A0 is a reset to the initial menu, A1–A6 are the basic behaviors, in whatever way they are implemented in the firmware.

I don't think that we should try to suggest that one can change the basic behaviors! It is a consequence that, if an SD card has a vmcode.abo that is started automatically, and that vmcode.abo can use _bytecode.load(x) to freely load another bytecode from the SD card, then the startup behavior of the robot _could_ imitate a different initial menu.

But the hardcoded initial menu is always there, if the SD card is removed.

Since the system function is hidden, it will only be used by those who have read the documentation and its warnings against confusing the innocent.