Understanding better Zerynth architecture


#1

Hi. I’m reading this page ( and others  ) to understand better how Zerynth works for personal and didactic aim. Is the order of the layers in this table right and…did I missed something?


Furthermore if I compare Zerynth with Arduino, in Arduino the “Arduino” layer" is on top of the hardware layer, right? 

Was the CHIBIOS RTOS for Arduino DUE, Photon, Core, UDOO, ST Nucleo, etc already available for those boards or did you have to write the porting of it? (Was CHIBIOS chosen because it was already ported on those boards?)

In the end of this page I read that:
*Zerynth VM currently support CHIBIOS and porting activities on FreeRTOS and other RTOS are ongoing
Is this needed to support more boards that are currently unsupported from CHIBIOS?

Does the “Zerynthation” process modify only the internal flash memory of the boards? ( The bootloader stays untouched as I can read here)


When I upload a python script to a Zerynth board is the script converted in C-like code?

Thank you!

#2

I am deeply happy that such a question came up  :stuck_out_tongue:

Your diagram is almost ok, let me redraw it (in ascii :P) to clarify it better:

|---------------------------------------------------------|
|          Zerynth bytecode   | C  object code      |
|---------------------------------------------------------|
|           Zerynth VM                       |
|---------------------------------------------------------|
|         VHAL     --|–>  VOSAL                          |
|                    |------------------------------------|
|                    | RTOS                               |
|---------------------------------------------------------|
|     Hardware: MCU + Peripherals                 |
|---------------------------------------------------------|
<br>When you click compile, your project is divided in Python code and C code (under the hood for drivers, or explicitly if you add your own C code). Both codes are compiled:<br><ul><li>Python to Zerynth bytecode, which is independent from the current board (you can explore it from the IDE debugger)</li><li>C becomes object code targeted to the current board.</li></ul>Both codes are uplinked to the VM on the board. The process is called uplinking because it is more than simple code uploading. During uplinking, the VM tries to resolve all the C symbols that are used in the C code and that are already contained in the VM. For example, if your C code uses "memcpy", the object code for "memcpy" is not generated during compilation because "memcpy" is already contained in the VM flashed on the board. At uplinking, the VM tells the IDE that the symbol "memcpy" is present in the VM so that the C object code to be uplinked can be changed accordingly (the process is transparent, the IDE just informs you of the number of symbols exchanged).<br><br>This mechanism is simple and very powerful, because you don't need a huge VM with all the drivers, but only a tiny VM with the minimum set of drivers (serial, gpio and flash) and all the others will be uplinked as needed. And not only drivers...when you use Wifi for the Photon, an entire TCP stack is compiled (actually..precompiled for licensing reasons) together with low level broadcom drivers.<br><br>Going back to the diagram...the Zerynth VM is built on top of an hardware abstraction layer (VHAL) and a RTOS abstraction layer (VOSAL). The vosal is responsible for the multithreading features used by the VM: threads, locks, semaphores, timers, mailboxes, etc... The vhal is responsible for the interaction of drivers with the mcu hardware: i2c, spi, gpio, serial, etc...<br><br>The VHAL uses the VOSAL for driver thread safety and parallelism (no VHAL driver uses polling, they all suspend for interrupts or are DMA based) and it is also in direct contact with the mcu peripherals.&nbsp;<br><br>The VOSAL is peripheral agnostic, it only depends on the mcu architecture (ARM Cortex Mx) and never access an mcu peripheral. It sits on top of a RTOS, which at the moment is ChibiOS. We are going to offer different VMs based on different RTOSes mainly for their difference on licensing. We chose Chibi because it is smaller and faster than FreeRTOS and it supports all Cortex Mx architectures; we will also support FreeRTOS and many others in the near future.<br><br>Supporting different boards is not much a matter of choosing a RTOS (it only interacts with the VOSAL that in turn only depends on architecture), but a matter of having a good VHAL for the peripherals. In theory, a VM not using peripherals is compatible with all the Cortex Mx from all the Chip producers. But if you want to use i2c on a mcu by FreeScale, you need to have the corresponding VHAL.<br><br>As for the Zerynth VM, it tries it bests to live together with existing bootloaders. However, we will soon add the ability to use JTAGs to virtualize a board.<br><br><br><br><br>

#3

Thank you for your exhaustive reply. I have another question: if Zerynth wasn’t a multi board project, would the RTOS have been enough, so no VHAL would have been required? (I’m trying to understand better why we couldn’t just have the RTOS to handle the MCU + Peripherals  ) .

Does JTAG stands for 
Joint Test Action Group?


#4

The RTOS usually imposes its own limitations on the provided hardware abstraction layer.

The first common limitation is that you must declare your peripheral configuration “statically” in C code and you have to recompile the project if you change something. This approach has the obvious advantage of using just the needed resources, nothing more; and it also makes debugging a lot easier. On the other hand, with this approach you would have to create a VM each time you need to reconfigure a peripheral and there would be no point in having a platform independent bytecode.

Another limitation that comes up is that many RTOSes have very low level hardware abstraction layers that have very basic functionalities. Often, in configuring for example a serial port, it is not enough to pass the baud rate, the parity and the stop bits; you could be required to pass a particular value of a configuration register of the specific mcu: again, not easy code and not much portable between different boards.

Finally, the level of functionality of VHAL is very high, it’s not just another hardware abstraction layer. Just check the ICU driver, there is not much like that around (especially implemented for more than one chip family  :smiley: )

However, if you target a single board, I agree the best approach is to use the hardware abstraction layer provided by the RTOS.

As for JTAG, yes. Zerynth will have support for JTAG probes to be used first just as board flashing devices and then as debuggers.