So....what do I do?

[Brian Beuken]

VisualGDB is for me the best option for coding on SBC targets. But it does come at a cost and not everyone can afford it.

The next best option is to use Visual Studio's cross platform development options for Linux.

This provides almost all the functionality that VisualGDB does, Edit and debug on the PC, console screen display, but only build on target so it can be a slow build.
It can be a bit clunky to set up, but there is a default raspberry project that can be used to get started, and most default linux projects will work on other machines. Do not use the Raspberry config, if you are not using a raspberry, not all ARM systems are the same, it don't work like that

It needs a tiny bit more understanding of the build process to get set up, so its best to use the 30days free VisualGDB trial to get familiar with what is happening during a build process, and this will be more understandable.

Its also a bit of nightmare if you have more than one device listed for it, but assuming most people are normal and not like me with 20 different system to target, if you have 1 system its ok, it just makes you jump through strange hoops to add others.

A few of the book and Magpi projects will be converted to this system to demonstrate how to get going.

[Brian Beuken]

Ok so I just spent a while getting a Linux build version of InvadersStart up and running, there were several small issues, but overall is not the most horrible thing, its horrible, but not THE most horrible.

But, you do need to make sure you get several things set up, You can use the Raspberry Blink as a base, but I decided to make it harder and went for a linux console build
I then included all the InvaderStart files, which is easy enough
Take care to note the readme help file it displayed when you start the new project, most of the connection issues can be resolved with that. (its in the zip file here)

You have to go to Tools->options and find the cross platform options which will let you set up a connection.

Once done, you then need to go to your project properties and set up the directories in the VC++ Directories..  which for a raspberry are
/opt/vc/include /opt/vc/include/interface/vcos/pthreads /opt/vc/include/interface /opt/vc/include/interface/vmcs_host/linux

and the lib dir, /opt/vc/lib

There are options to change the output dir on the properties->General settings but best leave them as it tends to mess up debugging  if you alter them, so your project will be sent to home/projects
In the C++ Proprocessor settings if you are porting any of the book code, you will need to define RASPBERRY and probably also a good idea to define another label so you know you are building on VSBUILD
There's a good reason to do this, since I can't really fiddle with output directory without breaking the debugger, which means you need to know if you are on the VSbuild when you are loading files as the path back to the Asset folder is different.

Now the real killer comes from the Linker settings, I had a devil of a time getting it to work, and even so it still reports a strange error after linking but says its successful? You need to add /opt/vc/lib again to the Additional directories,  even though you specified the dir already.

In the input section enter the library names but use the most current ones so GLESv2_static etc.
And from memory thats basically how you set it up.

Things to note, I don't have warnings enabled on VisualGDB (yeah I should) but here they will be and there's a lot, you must choose to deal with them or disable them

So far I can only get the system to do single thread on target builds, so a lot of files means will take a lot longer to build the project.

Intellisense does not work, though there is a way to get that working which I will research soon.

I can't get the terminal output to redirect to GDB, so no text output, though I know it can be done.

There's probably a few other issues, but I have to get on with other things now, so if you want to play around, I've attached a dual project version of InvaderStart for you to experiment with.

[jomoengineer]

Brian,

Thanks for the cool book and for the great info on this site.

I was curious if using Visual Studio 2017 with the Linux Development extension would be fine without using VisualGDB? 

i was able to build the starter Hello World program, compile it and it on the Raspberry Pi using this config, but I am not sure if I will run into a limitation down the road.  

Any thoughts on this? 

Cheers,

Jon

[Brian Beuken]

Hi Jon
Thanks, I am glad you like, it despite the really silly number of typesetter errors I keep finding.

As for VS2017 builds, well it works, but I do find it quite clunky, it only does on target compiles, and I have not found out how to get it to use multiple cores for a faster compile.

When all said and done though I would consider it better than working on the Raspberry itself. Having a dev and target set up allows you to visualise things better .

I detailed my own issues, namely no console output and intellisense not working but these are minor.

I promise to try and do a bit more on it soon, but been rather busy lately dealing with some issues with Ubuntu builds.

[jomoengineer]

Brian,

Yeah, I am actually more comfortable developing straight on a Linux system or using Eclipse for remote development, however I am interested in understanding how to use Visual Studio for cross and remote dev. 

According to Microsoft, you should be able to perform remote debug from VS 2017 but I am not sure how well it works.  I'll have to try this and see if actually is possible.

https://blogs.msdn.microsoft.com/vcblog/...bugoptions

[Brian Beuken]

It is on the Raspberry for sure which is a Linux system, it does work fairly well, but for me its just a step behind the ease of using VisualGDB

[Brian Beuken]

I've now added a dual config Space Cadet project to the downloads and will try to make several of the updated files dual config, or at least provide a non VisualGDB version.

I've also moved this forum topic up to the top so new readers can see they don't have to fork out any cash to work on their systems.

Also it has to be said with a bit more practice and digging around I have found it to be a more robust system than my initial thoughts. I worked out how to use the Remote target manager, found the concurrent builds settings and how to get it to reference resource directories easily. Though it is still annoying if you have multiple projects on the go as I tend to have. If you are working on 1 project, with one set of source files, and and target, its actually now quite usable after you work out how to set it up. Review the Invaders and Space Cadet dual config demos. More will come in the following weeks.

[jomoengineer]

Brian,

Cool.

What does the non VisualGDB code support? Is this a Linux based option or something that uses Visual Studio and something else?

[Brian Beuken]

Its still Visual Studio but without having to pay for VisualGDB (but really VisualGDB is brilliant)

When I get a bit of time I will look into using a Linux dev system, (I set up a laptop to do that) or a Pi to Pi coding system, but its not really my idea of fun
But for now I'm very busy reviewing the book code and filling in some blanks and updates that are urgently needed

[jomoengineer]

Ah, yeah, the Linux option from the newer Visual Studio seems to work fine.

My dev from the book has been on Ubuntu to Pi using Eclipse which works fine. It does take some effort to get it set-up though.