Open jacobrosenthal opened 9 years ago
It uses latest 9.x.x SDK. When you build it in Keil then everything is fetched and linked automatically. To build it with gcc you would have to install sdk manually and list all required files in makefile. I think that files from arm5/RTE overrides files from SDK.
I have recently picked up my earlier efforts of creating a gcc makefile, and succeeded in compiling and linking successfully (that is, no errors or whatsoever). I have yet to try and upload the firmware to the watch, will probably try that tomorrow.
@Cacowned Please share. I just got mine this week and would love to play
It's in my fork, but it's highly tailored to my local environment. I have to clean it up quite a bit, since I just committed it to have a working history.
It would be really great if you create a small wiki page with all the steps necessary to build the source code and deploy the firmware with an example of a makefile.
I finally got around to trying the firmware out, but the watch keeps resetting, so no success yet. I'll try to clean things up asap so others can look into this as well.
I have begun to create a wiki page on my fork of the firmware to describe the steps and problem areas with my current make file. I'm missing some files in the repo that I have on my laptop that are in a common location, so I have to figure out where to put them. It's also difficult to test the firmware myself, since I don't personally own any android/iOS devices, but do have an android tablet at work, but I can't take that home. I've yet to try uploading via Ubuntu (since Windows can't somehow), so if anyone has figured that out, I would be happy to know.
If you're not familiar, mbed is Nordic (and Arm's) open source replacement for Keil. Its a command line build system (python scripting cmake) with a dependency manager called yotta. Im really enjoying it. I put together a test that 'blinks' the motor. https://github.com/jacobrosenthal/tommy-test
You shouldnt upload this over the air, mbed uses softdevice 130 and a different sdk version and even then it would be super easy to kill the dfu service.
Howver, this seems like a great way to modularize functionality and get off keil?
I'm porting ossw to sma-q and about a week ago I played a bit with mbed os. I really liked it because of this dependency management and the fact that is supports both nrf51 and efm32 (after some small fix because there was some bug in the gg330 version that is in sma-q). But I'm not sure that RAM that is available in nrf51 (about 6kB) will be sufficient. The biggest issue I have now with adding new features is that I have to optimise other parts to free some ram. So for now I'm making some abstraction that will allow me to use the same code both on sma-q and nfr51 and after that I will check if C++ and event scheduler (minar) will not be too much for this small chip. When S130 v2 will be available there's a chance that we will have 1kB RAM more for application but the downside is that it may take some additional months before it will be available in mbed. Definitely it's worth checking if it's possible and if someone have time to check it, it would be great.
Yeah s120 isnt generally available currently (s130 default, s110 selectable) but can always hack it in.
On Sat, Feb 13, 2016 at 2:40 AM, Krzysztof Szczesniak < notifications@github.com> wrote:
small fix because there was some bug in the gg330 version that is in sma-q). But I'm not sure that RAM that is available in nrf51 (about 6kB) will be sufficient. The biggest
Hi Jacob,
That's a nice simple project. Maybe I should've started with that aswell instead of jumping right into trying to build the ossw as whole with gcc. Does mbed take care of the nitty gritty details like memory allocation for stack/heap, and other stuff? I suspect that's where the problem is why my firmware doesn't function properly. I ordered a nrf ble development board from aliexpress to see if I can debug the firmware on there.
If you follow up the abstraction its all defined in the target definitions. This is based on a fork of this target if you want to see what its initialization is https://github.com/ARMmbed/target-nordic-nrf51822
On Mon, Feb 15, 2016 at 3:30 AM, Cacowned notifications@github.com wrote:
Hi Jacob,
That's a nice simple project. Maybe I should've started with that aswell instead of jumping right into trying to build the ossw as whole with gcc. Does mbed take care of the nitty gritty details like memory allocation for stack/heap, and other stuff? I suspect that's where the problem is why my firmware doesn't function properly. I ordered a nrf ble development board from aliexpress to see if I can debug the firmware on there.
— Reply to this email directly or view it on GitHub https://github.com/ossw/ossw-firmware-s120/issues/7#issuecomment-184154444 .
And you said that breaking the DFU would make it impossible to upload a new firmware, but I thought that the button combination (hold all three for a few seconds and then release only middle button) to boot the watch in DFU mode was in the bootloader or is that an incorrect?
I havent looked deeply at the code, but by definition the application code is running to receive those button presses. If you blow it away with another application, then its not running anymore.
The bootloader might run on startup, but I dont know a way to power cycle...
This up+down button reset is hardware based so even if app will be broken when you press them there will be a hardware reset on the processor and bootloader will start
I know this threads old and sorry if this isn't the right place but - did you get mbed or ossw working on the SMA Q Watch? Thanks
Im playing with getting a gcc Makefile going. A few questions