With the standard image, the eMMC is 97% full. I suspect that it won’t all fit (though I have nothing more concrete than a gut sense that it’s too tight), and in general, I prefer to leave the eMMC for production images, not works-in-progress. It’s easier to recover from mishaps with an SD card. There are two options for making things fit in eMMC:
Trim down the install by removing things you don’t need and installing mono-runtime (or mono-devel) and selected lib packages.
Install snappy, yocto or some other distro that is slimmer and more tuned to IoT than hobbyist use.
Both of those are beyond the scope of the KB I was writing, though I do have articles in the works on both of those.
The eMMC boots much faster (10-20 seconds, depending on your network config and whether you are launching a gui), and I would prefer to use it as the primary OS partition, but for development, I care more about having all the tools there. Later, I will optimize down and spin a custom Yocto or Snappy image, with Docker for deployment and updating.
Note that the Verdant system will soon handle this all for you automatically. You will install a custom Yocto-based kernel with Docker and vpn support, and then Verdant deploys direct to your device. This is currently in testing, and will work alongside the current native and netmf support. Verdant will be in open beta in January 2017.
Hmmm. I did see that once too, when I tried to install on a system that had never had mono installed (as opposed to upgrading). It may have gone away when I successfully installed 3.2.8 before upgrading.
You can try this:
delete the file /etc/apt/sources.list.d/mono-xamarin.list
sudo apt-get install mono-devel
sudo apt-get install mono-complete
pick up again with step 2 of the mono upgrade, which will add back the mono-xamarin.list package repo and do the remaining steps to complete the upgrade to 4.6.1
That will bootstrap you with an earlier mono version, and then upgrade that version rather than trying a cold install of 4.6.1. It seems that there are some dependencies in the mono package repo that can’t be resolved in the BBB jessie repo. I’m going to have to format another ‘virgin’ SD card to see if I can work out a simpler way to make 4.6.1 install cleanly on Debian Jessie for BBB, but the above hack should get you unblocked. If it doesn’t, let me know and check back as I will re-test the steps on a properly ‘virgin’ OS install and revise the instructions as needed.
IMHO there is no simpler / faster / easier way to do all this without using VisualGDB. I have used it on several different Linux boards and it works like a charm! Its really worth checking out. After installing it and connection your BBB to your computer you are literally ready to start developing in less than 2 minutes.
Second this option. I recently purchased the software and it works great. I wanted to deploy and learn QT5 and there was an issue with Intelisense but the guys at visualgdb were great and had a fix within 2 days of back and forth testing. Well impressed and getting a QT5 app running on the Pi3 was all done with a few clicks.
Regarding Debian OS on an SD card, the default file size is 4gb. I ran out of space installing mono-complete (as predicted). So I used parted and resize2fs to make the partition larger.
VisualGDB is slick - I have a copy of that as well and use it almost daily (esp with native code), but I didn’t want to start out with something you have to pay for given that there’s a pretty solid free solutions too (for both managed and native code too, but that’s a future article). I will do an article on JTAG with VisualGDB sometime soon.
And @ Mr John Smith, there is another KB article up there on expanding the fs, but it basically boils down to what you did. I should probably add that to the pre-requisites list.
Deploy and debug QT4 or QT5 application into OSD3358 Dev from a host Ubuntu are good. We have tried it.
In my opinion, it is so much easier and faster than from VisualGDB,
Ultimately what we need is a method that is as simple as the .NETMF experience. Even if that means no over the air debugging. As far as I understand, we have all the technology (in the form of .NETMF) to make it happen.
@ Dat - There’s no doubt for that Linux folks, deploying from a Linux tools environment to a Linux OS is straightforward, but you are addressing a community that has been faithfully using your entirely-not-Linux-based toolchain for years, which is why I find it valuable to provide Windows-based solutions that allow a much softer learning curve.
For talented Linux-jockeys, authoring from Ubuntu (say, in Eclipse CDT) is one way to go, but for Windows-jockeys, “Learn Linux-based development” is a pretty steep, and not entirely necessary, first step.
@ Mr. John Smith - I mostly agree, but with a Linux core, there are much richer API surfaces (Mono instead of NETMF) and brick-proof IFU frameworks (Docker), that well exceed the capabilities of NETMF. I think it is more useful to make those “as easy as NETMF” than to make NETMF “as powerful as” those Linux frameworks.
I do believe it’s possible to make the step up to Linux softer and as easy as developing for NETMF. I am working to do that by facilitating direct deployment of Docker-encapsulated managed-code applications completely from within VS. Basically, under the covers, we would push to a Docker repository the same way you currently deploy to NETMF, complete with remote debug facilities. There are a few months of work ahead, but I have done one full-round-trip deployment, so it is possible.
For low end MCUs without an OS, I’d like to also see a brick-proof three-stage bootloader with built-in network IFU capability for NETMF - that would cover the low-end of the processor scale with similar capabilities, but I’m not working on that for now.
But that means you need to have a Linux machine running Ubuntu. As much as I like Linux & Ubuntu, my daily work horse is a Windows PC as all my development software will only run on Windows. This was the reason to pay for the VisualGDB in the first place.