The Bela project started in 2014, and there were not many tools available out there at the time, so the first writing of the PRU code was done in assembly. The same code was later expanded to support new peripherals and features, but it is still written in assembly.
If we were to do it from scratch today, we would probably still use assembly, at least for the long WRITE_ONE_BUFFER
loop, that is the real-time critical loop in the PRU code. This loop contains some finely timed operations, whose timeliness can only be guaranteed insofar we have control on the code at an instruction level. Any higher level language (be it C, or this "javascript-like"* language used by the Cyclops IDE), would potentially generate non-real-time-safe code paths that would be hard to detect, debug and avoid. For this reason, we never looked further and never used any of the higher level tools available for the PRU: they just could not guarantee the same level of timing accuracy and control that we currently have and that is so critical for the functioning of Bela.
If the code for your specific PRU application is not so time critical (e.g.: it can accept jitters in the order of a few microseconds), then I am sure these tools are a great way to get into PRU programming, and can give you a head start. It seems like the Cyclops IDE can also " automatically configures the Beaglebone’s pinmux controller to use common I/O peripherals". If you use it, be careful that these automatic settings don't override any of the finely crafted pinmux settings needed for Bela to run. Also, make sure that the Cyclops IDE itself allows you to run an arbitrary piece of software on another PRU, while you control one with Cyclops: you wouldn't want it to take control of the whole PRU subsystem and prevent the Bela PRU firmware from running. Additionally, be aware that the Bela code uses all of the RAM of the PRU it is running on and all of the RAM shared between the two PRUs. It doesn't, however, use the RAM that belongs to the other PRU. Will Cyclops do the same?
You can see from the paragraphs above the type of caveats there are when using higher-level tools that make on-boarding more user-friendly. This is yet another good reason for us to stick to PRU assembly for the foreseeable future, when developing the Bela core. However, please feel free to experiment with more user-friendly tools, I would be happy to hear more about that, but be aware that - if you cannot control them with fine granularity - they may end up getting in the way of the basic Bela functionalities.
* hey, is it just me who thinks the idea of running "javascript-like" code on a 200MHz CPU that is supposed to be used for real-time critical tasks is just a ... bad idea?