Hi All,

Having just written the core of my project, I'm moving into the debugging phase ... The first thing that struck me is how "old" this approach is with Unit testing and all of the JTAG like functionality that just isn't there in Mbed.

So I have few "shoot the breeze" ideas:

1) Using the "Magic" chip to support Hardware debugging I don't know how this chip is entwined into the "main" LPC but would it be possible (even with a hardware spin) to have this chip support hardware debugging such that it generates debug to the serial port or dumps a file to the flash or some other functionality that allows developers, at a hardware level get amongst the code? The ability to configure a breakpoint that sends the value of various variables would be awesome.....

2) Enable Unit testing In my "work life" unit testing is a core part of development - in most projects, the unit tests are actually coded before the code gets written. Could we have some sort of framework for this built into the IDE? I understand that this would be tough to scale, but the code doesn't really have to be compilied and run on an ARM - you could compile to say Intel and farm the execution out to a bunch of VM's

3) Provide a debug "channel" The current "printf" is rather rudimentry, what about a second (eg stddbg) stream that wrote to a file on the flash. Preferrably without getting mangled by interrupts (which kinda links to item 1 above)

Lastly, I've tried to used the DBG(...) macro provided in the NetServices code but it gets stuck. Would I be right to assume that the vprintf() that it uses isn't as "clean" as the printf() recommended by MBed ?

Cheers,

Anthony

Hi Anthony,

Re: debug. The magic chip is connected via JTAG, so some options are open to us in the future. This is definitely something we want to look at but needs proper thought/effort. FYI, the current priority is all the cool DVCS collaboration stuff we're in the final stages of developing :) (i.e. we almost certainly won't be releasing anything debug in the first half of the year). In the mean time, I think someone was playing with the M3 Monitor based debug, so that might be interesting if you can find it.

Re: Unit testing. I'd be interested in what you think would be nice. Definitely interested in use-cases here; depends whether it is static, dynamic, running on a real hardware rig, virtual platform etc (all of which is possible). This really comes down to what workflows and benefits are useful in reality vs. science fair. For example, a virtual mbed may be of limited use to test whether your accelerometer library works, and even a hardware rig may not be that useful unless it has it connected (which may well be possible; I have thought of building a massive mbed test-rig with every sparkfun component in it!)

Thoughts on concrete use cases could be great here; any ideas welcome as definitely up for something in this area if it is sane.

Simon

Hi Simon,

Good to hear that the magic chip is hooked into the JTAG. I've had a Google and saw that the Beaglebone (http://beagleboard.org/bone) have this. I guess that the challenge is to then do something with the JTAG output given the cloud-nature of the Mbed IDE. I'll keep watch on that front.

On the Unit testing: Unit testing is usually (or should that be 'ideally') limited to testing things that are self contained and thus a "stand alone unit" - thus making the tests repeatable and the outcomes predictable. So connected hardware isn't realistic and ideally, not part of unity testing. But in the hardware's place would be a library of stubs that can be used to substitute external dependencies - which developers would hook in to allow their tests to pass. I've worked on Java projects where we stub out a databases, network servers and other external systems as standard practice - I envisage that similar constraints would be used for Mbed unit tests.

So the emphasis would be on the stub library to provide a rich compatibility to the forsaken hardware.

For that concrete example: Let's say I created an "elastic circular window buffer" class and wanted to wrap it in unit tests. When I click "compile" the code is compiled, and if successful, has the defined unit tests run against it. Like the debug, because of the "cloudy-ness" of the MBED environment, the test run would be run on Mbed's servers. I haven't used it but QEMU (http://wiki.qemu.org) looks interesting from perspective of using a virtual farm rather than real hardware.

So a combination of IDE support, Unit-test stubs and somewhere (or should that be something) to execute the tests is where I was looking to go - at least I thought it was sane :-)

Anthony

PS: I never saw the notification from your response in my email on this. I just so happened to stumble back over it and see if anyone had responded...