I'm making good progress with my mbed and a serial camera, doing a bit of image processing work.

Because of the tragic lack of a built-in screen on the mbed, I'm building the same code in two environments:

(1) The mbed compiler, for deployment on the real device

(2) In a testframe app on my desktop, where I can see and debug image issues

I've built cheap emulations of the mbed libraries that I'm using, so the bulk of the code can be identical in both places.

Right now I am moving code between the two environments by copying and pasting the contents of editors, which is obviously a bit fraught and error-prone. The code moves back & forth quite often.

To add to the complications, I now have a collaborator, so the desktop codebase is in a Google Code repository.

Is there any tidier way to solve this problem ?

Thanks!

Richard

Hm - I guess I will take that silence as a no... :-)

So, here's another question - can I access my mbed progams via svn, so as to check them out into the desktop environment ?

thanks,

Richard

You could probably do it the other way around as to access your svn repo via your mbed by connecting it to the internet. This wouldn't help tho since you would still have to update the svn manually.

Vlad - I'm not sure what you mean - let me clarify.

Once I have built a program in the mbed compiler, can I check my code out directly to my desktop with svn, so as to compile that same code into a desktop app ? If so, how do I find the url to check out from ?

Thanks,

Richard

Sorry Richard I through you wanted to save new bins on your mbed through an svn repo. It seems you are looking for a way for the compiler to save directly to the svn which would update your desktop application and mbed.

Vlad - yes, more or less.

When I'm building fo rmbed, I'll use the mbed compiler in the usual way to make an mbed bin.

And when I'm buildign on the desktop, I would like to get my source out of wherever the mbed compiler keeps it, and then compile it with my desktop tools (actually Visual Studio) to make a desktop executable.

So, I think the real question is, where does the mbed compiler keep my source, and is there some way I can update from it and commit to it from the desktop ?

Hi Richard,

This is a great thread; I think there are actually a whole load of discussion points here.

Richard Sewell wrote:
Because of the tragic lack of a built-in screen on the mbed, I'm building the same code in two environments:

I liked this comment :) Some alternatives to desktop compilation for diagnosing/looking at images assuming that is what you are doing could be something like:

• dump data in to a .bmp file on the mbed disk so you could just open it with a picture viewer on the pc
• dump it over the USB uart to some simple viewer script on the PC
• attach a screen :)

You also talked about code and different ways of getting access to it:

Richard Sewell wrote:
Right now I am moving code between the two environments by copying and pasting the contents of editors, which is obviously a bit fraught and error-prone. The code moves back & forth quite often. To add to the complications, I now have a collaborator, so the desktop codebase is in a Google Code repository. Is there any tidier way to solve this problem ?

At the moment, you can impoort and export code as zip files, or import from svn from the mbed website. You can also publish projects to the mbed website directly from the compiler, so you can let other people import them easily too (some more updates for the website coming soon in this area!).

We don't yet support integration with version control in the compiler, but as you can imagine, we've thought about it quite a lot. The white board has various ideas on how we might do it, but it has never made it that far up our priority list as up until now we've just been trying to get a first product out that people can use. With no users, collaboration is not such a hot topic!

But now mbed is out, we're interested in what we should do in this area. So I'd be very interested to hear what you and others are doing (collaboration, working on two platforms etc) and the sort of things you'd like to see in this area. We've got to strike the right balance between functionality and simplicity, but there is some excellent potential in this area.

For example, what is the (most basic) workflow(s) that would give you what you are after?

Simon

Simon - I'm glad I have an interesting problem... ;-)

The secret other virtue of the desktop app is, of course, a debugger. Though i thank you for the suggestions. I did start on the mbed, dumping images to files, but it is hard to find the stupid bugs when working that way.

I did think of one candidate for your Whiteboard of The Future, if it isn't there already - provide an emulation of the whole mbed environment as a set of headers & libs for the desktop, with proxying to the real mbed down the USB cable.

It woudn't be a perfect emulation, especially in the timing department, but would be a great way to do debugging.

Closer to home, I can see two ways to do the workflow for the current project. Let me tell you what we have right now, probably in more detail than you need.

There's the mbed code:

http://mbed.org/users/jarkman/published/1a04748bdf30c12230994b6731b67d20/ucam.zip

which talks to the  4DSystems uCam camera module over a serial port. That code also contains a bit of elementary image analysis. Its destiny is to end up running a motorised eyeball as part of a Dorkbot Bristol project.

I feel as though I ought to separate the parts, so that there's a distinct camera-interface module available for anyone else who wants to do the same thing on an mbed (the camera thing, not the eyebvall thing), and I'd welcome your thoughts on that. Is that best done as a solitary standalone project, with a bit of demo code in its main() ?

Then there's the test frame, which exists right now as a Visual Studio C++ project:

http://code.google.com/p/theeyestheeyes/source/checkout

That code also contains the mbed code. Oh, and my collaborator, Ben, will probably add another testframe built with some Unix toolset, which will exists in the same source tree at Google Code. And when his mbed turns up (Farnell are out of stock), he will also want to work on the mbed code in the mbed compiler, which raises a different collaboration question.

So, ways to make it work:

(0) Copy the shared code back and forth between Visual Studio and the mbed compiler, and try never to copy it the wrong way.

(1) Keep the mbed code in mbed's repository (assuming there is such a thing), and the rest of the code in Google's repository.

In the mbed compiler, have it automagically appear all up-to-date automatically, and commit back to the repository when it is saved.

On the desktop, check out the two parts of the source tree separately from the two repositories.

(2) Keep all the code in Google's repository, and create a project in the mbed compiler which uses that repository for a store instead of the bit of your disk it uses now.

(3) Keep all the code in Google's repository, and give the mbed compiler explicit update and commit buttons.

I think (3) is the most rational. If you're going to provide version control in the compiler, you need to do most of the update/commit UI work anyhow, and then you just need a couple of extra knobs to let projects specify an external repository instead of the mbed repository.

That model also supports the collaborating-in-the-mbed-compiler case for pure-mbed projects. Say, for example, I make a project in the compiler, put it in the mbed repository (or find you have magically put it there already), then give Ben a link to it. He works on it in the compiler, and we share via the mbed repository.

Does that help ?

Richard

I too would love to have access to the mbed svn outside of the compiler.  Basically so I could use Visual Studio and TortiseSVN/VisualSVN to tie into the repository and work from my desktop.  Then when I think I've got a good piece of code working, just commit it back to the mbed repository for safe storage/online editing and compiling.  I also like Richard's idea of specifying an external repository as opposed to the internal mbed one.  I could definitely see this helping with collaboration down the road.

-Taylor

An observation, if I may.

I feel like I am observing folks asking for features from a closed source system.

What happens when it isn't Subversion but is Mercurial, Git, or another repository? Maybe one where they don't want to hope the password is safe on the mbed site?

IMHO, if the mbed compilation tool chain and libraries were Open Source and supported, users would have an escape hatch, and the mbed team could reasonably put a boundary on scope creep. If the tools and libraries are available, folks could use whatever editor they wanted, store code in any repository, anywhere convenient, build emulators with common headers, take responsibility for security if necessary, or anything else that made sense to get their mbed system working, and have a route to avoid problems. The mbed team could say, we don't plan to do that, but here's a way that you could, and it works just as well (on these platforms).

Mbed - why not put your tool chain and libraries out under an Open Source license which you feel comfortable with? Then Richard Sewell and others can avoid having problems to solve.

My $0.02 worth, GB

GB - I think the online IDE and the overall push to flatten the learning curve for easy startup is a huge virtue for the mbed world.

The binaries are already compatible, so I expect I could (if I wanted) go find OS ARM tools and get a build environment going. But I don't want to. I'm far too lazy. I like the simplicity of building projects in the mbed world. I suspect it will be a big selling point in attracting new users, especially ones who are not professional developers and who are currently suffering with tools like the Arduino ones.

In my imagination, the ideal mbed source-control experience has three levels:

(1) A new user starts a new project. It has source code control running behind the scenes, perhaps, but they can't see any evidence of it in the UI, so it is not there to confuse them.

(2) They want to collaborate (or just manage their history) on a project, so the check the 'enable SCC' button in the project settings. Now they get commit and update buttons in the editor, and they get a URL they can give to collaborators. The collaborators use a new button, 'make project from SCC', which prompts for the URL.

(3) They want to integrate with some more complex project, so they get their own repository going. Then they use the ''make project from SCC button', and supply the URL for their own repository.

Of course, there are lots of complications I haven't thought about - conflicts and permissions and reverting and branching and stuff - but I'm sure Simon can fix all that... :-)

Richard