Is it possible to install Cloud9 on the BBAI64?

General Discussion
1

The more I’ve been working with the BBAI64, the more I’ve been using that rather inept code-server program that’s installed on the BBAI64, but mainly just as a quick way to make code changes and get to the terminal. However it occurred to me that my development experience on the BBB was much better. And it’s because the BBB used the Cloud9 IDE which seemed much more integrated or at least more feature-rich than whatever code-server is.

I thought I can’t be the only person to notice this, so I search the forums for BBAI64 and Cloud9 and I only got one post where someone else was simply acknowledging the same thing, it’s not there. But I couldn’t find a thread about how to get it.

So can it be installed on the BBAI64/is it supported on BBAI64? I’m suspecting there are some unsavory caveats to it on this platform or it’d be here already. But knowing the details would help…

2

Long Story short… Amazon purchased the team behind Cloud9, brought it in house, and closed up shop.

Regards,

3

That’s disheartening, but good to know. Thanks for the link…

Looking at the comments on github, it seems that you build a Cloud9 deployment using the Cloud9 SDK. So it’s not as simple as just installing the IDE and voila, it works. Do you have more information about how this is done OR know where I can read more about it (beyond the steps in github)?

I found a website that claims to be the documentation for it, but the documentation declares Cloud9 as alpha which looks very similar to the link provided on github:
Getting started with the Cloud9 SDK
But I suspect this is badly outdated, since the current version of Cloud9 on git is v3 but the documentation refers to v0.1. Is it trustworthy or is there a better source for more up-to-date info on the latest version?

I also found an Amazon link to documentation here:
AWS Cloud9 Documentation
But I don’t know if this is a specific deployment of Cloud9 only for web-services or if this is relevant to the git source.

I can go through the steps on the github to see how well it deploys to my BBAI64. But before I “pollute” my BBAI64, has anybody else done this?
How well did it go?
Is it worth doing or is there too much missing and in need of development to be viable?
Are there developed plugins for Cloud9 targeting BBAI64 that are worth knowing about that might make this effort worth it?

4

My old repo with the build script, that generated our BeagleBoard specific builds is located here:

Our biggest change was working in a systemd activation hack, not really needed if you just run it at startup. (removing this hack would allow you to run a more recent source snapshot)

We only had it working with up-to nodejs v8.x.x, also needs npm 4.6.1…

Personally, i’d like to figure out a good combination of working VSCode extensions that could mirror what Cloud9 did. But sadly, a lot of the good VSCode extensions are stuck in Microsoft’s ‘internal’ build only repo., and not pushed to https://open-vsx.org/.

Regards,

5

Can you give me a subjective idea of whether it is worth installing?
Or is it too much of a work-in-progress for use by people not intimately familiar with how to deal with it?
Also is there a version of filesystem that installs those versions of NodeJS and npm? Upgrading packages in Linux usually goes smoothly. But I don’t generally have great luck reverting to older package versions. So if there’s a tarball of a filesystem that already has those versions, that might be preferable to trying to downgrade the versions (I realize I’m making broad-stroke assumptions about how difficult it’d be to downgrade as-is on my BBAI64). I’m just “thinking out loud.”

The main things I want to do is compile & deploy Linux application C-code & PRU C-code, monitor aspects of the system that Cloud9 has access to report on (i.e. debugging), and do so via a browser.

I have WinSCP and use that for file-transfers when it is convenient, but I’m not particularly impressed with its implementation of an ssh terminal window. They made too much of a compromise for the purposes of a simpler UI to be used on a regular basis (IMO).

Your thoughts?

6

Not really, with nodejs 12.x in Bullseye, vs the 8.x that’s required, it won’t work well or even build…

Exactly, i’d like to figure out how pre-setup VSCode to do this today, it’s mostly figuring out the right extensions and configure it for the different build settings of gcc/llvm on arm64.

Regards,

7

I was kinda getting that hint in your responses hence my pushing for more detail.

As for VSCode, I wasn’t aware this was a capability of VSCode (development via browser). Good to know.

I’ve tried using it in the past just as a generic C/C++/C# IDE and I was never impressed with it (as compared to full-up Visual Studio on Windows or Eclipse CDT on Linux).

However in the capacity of a browser-based IDE with plugin enhancement, my opinion of VSCode could easily be changed.

Is there any plans for those VSCode extensions to be released? Or is that wishful thinking?

8

I use Geany, it is very simple to cross compile then transfer to the target. 2 clicks and it is built and on the target.

Have not worked on the debugger yet or using the PRU. geany is a very good fit since you can find what you need and make it work exactly as needed for SBC work. I cover way too much ground then to spend all day trying to find what to change and how to change stuff using all those other IDE’s.

SIMPLE is the key to success…

Geany + BASH = you get the job done.

9

I really enjoy how much development VSCode see’s. I’ve been using it on other systems in local and browser based environments. While it has some weird quirks,

Sadly, that’s up to microsoft: FAQ - code-server Docs

Plug-in’s… This is one of pre-installed ones we add: (Code Runner) https://open-vsx.org/extension/formulahendry/code-runner , it should be the most easiest to create custom r5/pru/etc build targets.

Regards,

10

Thank you for sharing Geany, that looks pretty cool, wish we could access it from the browser…

Regards,

1 Like
11

I use Geany instead of Ubuntu’s latest version of gedit since it is much better. They really ruined gedit’s UI trying to simplify things, but for me, they made it outright unusable. Although this is the GUI version, not the CLI/Terminal version.

If all you want to do is edit files, Geany is fine.

However a good IDE is more than just a text editor that does syntactic color-coding and maybe some code-folding. IDEs can:

  • Display on-the-fly syntax errors
  • Perform cross-class renaming of variables/functions
  • Perform complex searches such as display usages of those variables & functions in other files within the project
  • Organize & orchestrate builds including writing your makefile for you if you want
  • Manage single-step debug sessions by letting you set breakpoints, show variable & memory values, the call-stack, and other threads active in the application being debugged…and even some profiling
  • Some can even do code-analysis and point out places where you inadvertently did something wrong.

I don’t think Cloud9 was ever all of these things, but it was more than just a code editor. And that’s all code-server appears to be…and not even that good of one. It’s only real “trick” is it can do what it does in a browser.

1 Like
12

Its powerful if you off load the other tasks to a BASH script. It does need a few more configurable buttons.

With an SoC its not very practical any more. The old days we would pop the chip out of the socket and plug in an ICE. Now that was valid information, now days way too much opacity in the SoC. Yes, its neat to know what that register has in it, but that is all you know. Problem lies in the fact you cannot touch the rest of the system.

An old fashion printf or printk and some logging will point out a good number of issues. Now when you find the problem, what can you do?? Most of time it is not even practical to address the issue. If the system does not work with a moderate amount of effort it is best to move on to another system. Unless you have a couple dozen people working on a project small road blocks become major obstacles.

13

In the case of a Linux-based application, it isn’t unreasonable for a local IDE running on the target to also perform its own debugging. That’s a pretty standard thing to do when developing a Linux application on a PC. It’s just a matter of having a debugging agent like gdb installed and preferably an IDE to drive it (otherwise you’ll have to drive gdb from the CLI). That’s pretty much all you need when debugging local Linux applications.

The IDE for BBAI64 would need to interact with gdb in the same ways other gdb-supporting IDEs do. Of course, in this case, the IDE’s UI would be running on a remote browser. I would assume based on this conversation that VSCode is likely already capable of this???

However it gets a bit more complicated when debugging code running on other processors. In these cases, the debugging agent tasks can be split.

For those not familiar, when performing remote debugging to an application running in a remote Linux platform, you have another program that gets invoked on the remote device called gdbserver. On the client, you run gdb, and instruct gdb to perform a remote-debug session by including the IP and Port to the target running gdbserver. Obviously the client and target will need to be accessible to each other on a network for this to work. Once a connection is established, the combination of gdb/gdbserver can perform the same basic functions to the remote application that could be done when debugging an application locally, such as setting breakpoints, monitoring the call stack of each thread, accessing variable values, etc etc.

When conducting a debug session of an asynchronous peer processor in the same microcontroller (e.g. one of the Cortex R5Fs or a PRU), you need a debugging agent application running in Linux to manage and monitor all the same controls that a JTAG connected debug agent would, just accessing those peripherals via physical memory addresses. I would think there are existing Linux based debuggers for doing this given this is becoming a common scenario for developers. What I don’t know is if these debugging agents mimic gdbserver’s API, thus allowing gdb to connect to them or if they implement gdb’s API so the IDE can connect directly to them without involving gdb at all??? Either would be viable solutions.

I have no clue if the PRU debugging offerings have been coded to implement gdb (or gdbserver’s) API, although I suspect not. The IDE would need a plugin written to know how to orchestrate the PRU’s debugging agent.

Doing these sorts of things is not out of the realm of possibility. The question is if it has been developed or not. And if not, is there someone with the knowledge, skill, time, resources, and motivation to do it.

1 Like
14

Hey, just to let you know that I’ve successfully built Cloud9 on the BBAI64 and it works just like on the normal BBAI. Are you still interested in having it ?

15

I’m interested as long as it functions and integrates just the same. However if it merely exists and launches, but aspects of it, at runtime, don’t work, then that’s not as useful.

16

It looks like it has all the features a little more. It still has tmux bug on “nano” like before though, because there’s a max version of tmux that you can build.

What would you like me to test?

17

The main things I’d be using it for is Linux app and PRU compilation (C-code for both), deployment, and debugging.

I don’t recall if Cloud9 ever allowed for single-step debugging of the PRUs, but if it did, knowing that this still works would be really nice to know.

Knowing which PRU to deploy to might be a change since there are now 6 possible PRU cores to target (PRU0/1, RTU0/1, and TX0/1) in each PRU subsystem vs just 2.

There’s also new features in PRU_ICSSG (Broadside memory and Register File swapping), although I’m not sure how much Cloud9 would need to know about those unless in a debug session.

Once my project is up and running, I’ll likely be developing most of the high-level application in Java, but once I’m in that realm, remote debugging is easier done on the PC, so I wouldn’t use Cloud9 for that. I’d definitely be writing and deploying Java code via IntelliJ IDEA, gradle scripts, and SCP connections to the target. But having the ability to make quick browser-based tweaks to PRU code and redeploy right on the target would be very convenient.

18

I don’t know how you would go about debugging the PRUs, but you can definitively open multiple terminals at the same time, side to side, unlike VS-code. I’ll get something for you, you can always delete it if it’s not satisfying.