Are the files in lib/ available for doing local builds? I have an arm cross compile setup for other projects and would prefer to run 'make' in my own build tree instead of copying things into include/ and src/, and then uploading them over and over until the L2CAPServer makes contact with the watch.

It would also be very useful if there were a way to flash the image over the USB. Going through the java bluetooth server is very slow and only seems to work about one of ten tries for me.

Unfortunately the USB port on inPulse is only for charging. We'll be working on improving the Bluetooth app transfer process, speed is definitely one of the things we'll be working on. In the meantime, I'd suggest working in the simulator while you're tweaking your app, then bring it to the device only when you need to.

I just found that they are available in the .vdi file for the simulator.

Except those are only for the i386 architecture and it doesn't do cross compilation... So that won't work.

I'm trying to debug a memory size issue, so it would be very helpful to have a full local cross compile environment, especially with the linker script lib/obj/firmware.ld. How much RAM is really available to the user apps?

Stubbing out all of the inpulse calls so that I can link locally, my app is well within the 32 KB flash / 8 KB RAM limitations:



But compileandload.py reports:


Building a completely empty app (just stubs for the functions) looks like 23 KB of flash are used by the pulse framework, leaving only 5 KB free for the user app.

Through binary search (sorry about hitting your compile server so many times), it looks like there is only 3060 bytes available in the data segment / BSS. Pushing an array into the text segment and redoing the test, it looks like 5200 bytes are available for user code. Is there a way to slim down the framework if there are parts that are not required?

EDIT: my build tree is https://bitbucket.org/hudson/inpulse

I found the problem -- I had changed a call from sprintf() to the safer snprintf(), but this is apparently not an inPulse optimized version and takes many KB of code space. Switching back to sprintf() allowed it to fit just under the 5 KB code / 3 KB data limit.