It was pretty easy to simulate a UART over BLE. Nordic had made an example service, but there was no corresponding “central”.
Lashing together the central was actually pretty easy – I stole some fragments from the web, and it came together quickly, but getting the right mix of components proved to be tricky. Of course the “central” uses a different soft-machine, and has to be matched with the right API so the calls get vectored to the right place.
When eventually it would compile, then it wouldn’t load producing the useful message “ld.exe: region RAM overflowed with stack“. It took me a while to figure this one out. The stack grwos down from the top of RAM, and the rest of the RAM allocations grow up from the bottom of RAM. This message means that there was not enough RAM to run it. So for the last two days I have been trying to figure out how to save RAM.
Simply optimizing the code of course makes no difference because this is data. The obvious wheeze is to get rid of the heap which consumes 2K of RAM and is not used. That seems like an easy thing to do – and it is – just change the value of the compile-time constant: __HEAP_SIZE=0
Problem is that it is not a compile-time constant, it is an assemble-time constant. So I chased by own tail for hours trying to understand why the heap stuck around. Of well – another painful lesson, but at last the program is working.
Here’s a demo of the TS connecting to my Android. It works in both directions echoing back whatever the Android sends it. Also, when the button on the TS06 is pressed it sends a canned string to the Android.
The big triumph is that I can now send strings of characters between TS06 and the Nordic eval board PCA10001. Both are connected to my PC using USART-to-USB adaptors and so in this demo all you can see is two typescript windows showing that TS06 is sending a string to PCA10001. Gives you some idea of the possible data rate.