Soft Declare with nested classes (Bluetooth LE and tinyb)

I’m still pursuing my objective of communicating with 3 Arduino 101’s via BLE. I can do everything I want via command line tools (note: not commands, but interactive tools), and a recent discovery: tinyb, a library and associated examples in C++ and Java, which I can also make do the things I want (at least the C++ version, I didn’t try Java). With this I was initially hopeful that I could make the necessary tinyb libray calls with soft declare (tinyb is shared so this could work).

However, it’s getting terrifically complicated. tinyb uses lots and lots of classes, some nested, and pretty well all methods (functions) are part of a class in which parameters and other items are part of the same class. Often there are no parameters because they are local to the class.

A typical, and fundamental, example is connect(). There is no parameter because the thing to be connected to is defined in the class, and the class instance is generated in response to another class, with the same type of logic.

I think I can eventually replicate all of this in Xojo, with a lot of effort, and probably a rather inefficient execution.

I have even thought about writing a C++ app to do what I want and have it communicate with a Xojo app via UDP, or something like that (if you wonder why I need the Xojo app in this case, it’s because it’s going to be part of a much bigger app, which also talks to other equipment via I2C, SPI and USB->Serial (with an extensive protocol at 115200 baud, which I can’t change, otherwise I would use the mini-UART), plus an LCD display, as well as a host via TCP – those bits are already running, except the TCP which I haven’t started yet.

I would certainly welcome any hints or tips.

Even better would be somebody who’s been down this path before. BLE on a Raspberry Pi is such a selling point I can’t believe I’m the first one doing this.

cheers,
Richard

When seeing this before my first thought was to write a Python script/program that did what you needed to do and then call that with parameters and read the results with shell execute. But I don’t know how to write C++ well so I’m just picking easy.

Reading your previous topic over again and what you wrote here, I agree that using declares or a separate program with some communication between them (sockets, shared file, etc.) would be the best approach.

I’m no help with your declares issue though. I’ve done declares before and it can be tricky to get them to work but I haven’t worked with the library you speak of. The separate program (C or otherwise) would work and I’ve certainly had to do that in the past. It gets complicated when you need to open back up the Pi’s Bluetooth to communicate with different Arduinos at any given time.

Hi Kevin, thanks for the response. It sort of confirms what I’m beginning to think is the best way forward.

A pity really, since a nice native way to use the Pi’s BLE capabilities would be a real winner for Xojo.

cheers,
Richard

PS: to clarify – I mean a helper app. Declares is looking really complicated in this case.

for declares a C interface, not C++ with classes, is really the only way to make it work

I feared as much. Actually I much prefer C (being a convert from FORTRAN :wink: – I actually hate using C++and make it as C-like as possible when I have to use it, but there we are. The library is deep into C++ territory and there’s nothing I can do about it.

cheers,
Richard

Well you can make C++ work but you need to expose a plain C interface
This is definitely possible
You end with the C interface hiding the classes and the API’s into them within plain C interface methods

Dont think there are any examples of this in the SDK examples

And if you go to this extent you might as well turn the code into a plugin

Yes, I had also thought about this: write my own library which does what I want, in C, and then use this via declare. It’s one route which could work.

I would go for a plugin, EXCEPT, this is a Raspberry Pi, and I’m compiling on a Mac. As far as I know (and I could be wrong) I can’t make a plugin which uses pi code and use it on a Mac.

Assuming that’s true, then of the options:

    • new C library to encapsulate the C++ tinyb library, which in turn makes BlueZ more accessible;
    • try to replicate C++ classes to such an extent that I can use tinyb in soft declares;
    • make a helper app communicating via UDP;
    • make a plugin to achieve the above, in native Pi code but implemented on a Mac (which I doubt I can do).

I think the trade off now, in terms of development effort and execution speed is likely to be option 3. Unless 4. is possible, in which case that’s the way to go. Probably.

cheers,
Richard

[quote=340885:@Richard Francis]Yes, I had also thought about this: write my own library which does what I want, in C, and then use this via declare. It’s one route which could work.

I would go for a plugin, EXCEPT, this is a Raspberry Pi, and I’m compiling on a Mac. As far as I know (and I could be wrong) I can’t make a plugin which uses pi code and use it on a Mac.[/quote]
well … sort of … a plugin can be x-platform so you can write & compile on a mac
plugins have several parts - one for each supported target
so if you made a plugin that has a mac os stub (empty functions but the right api) and a pi part that has the same api & real code then you can work on the mac & compile for pi
but you can only really TEST real functionality on the pi in such a set up

certainly lots of options with very different complexities
a helper that you can drive via the cmd line might be simplest IF you already have an app like tinyb

We’re converging. Actually tinyb is a library, but it comes with examples and one of them already talks to my Arduino 101 test target. With a small amount of work it will do what I need.

cheers,
R.