Go Down

Topic: Simba Experiences/Feedback? (Read 1 time) previous topic - next topic

hichhiker

I recently came across Simba and it looks great. I am curious to how popular/functional it is? I wrote a lot of code trying to implement a lot of same sort of functionality and would prefer to use something already made and tested  by someone better at it than me :-). But I having hard time finding much information about beyond the ReadTheDocs and a few announcements.  It seems to have been around for a while, but lack of chatter about it is making me a bit nervous... Has anyone used it in serious projects? Any feedback?

I am specifically interested in drivers. My project will need some drivers that wrap around the serial port and it seems to be pretty different in Simba, so I doubt I can use existing libraries as they expect Arduino HardwareSerial object - so not without some mods in best case scenario... So how easy is it to write custom drivers for Simba?


I am also curious how compatible it is with C++. I am having a very hard time even building some of the canned examples due to C++ vs C issues and much of my existing code is C++ - code I would like to keep if possible. Anyone using Simba with C++?

Any feedback would be appreciated before I sink too much time into testing it out..

Thanks,

-HH

eerimoq

Hi,

first of all. I'm the main author of Simba which makes me very subjective on this matter.

Simba is a fairly active project on GitHub, with a handful of contributors. I've used it in a few projects, and it has been working very well, I must say. That said, other users may very well have a different opinion (which I don't know about, the little feedback I've received has been positive).

There are some discussions on GitHub and PlatformIO about Simba, but very few shares their projects and gives feedback.

Here are a few of my "bigger" project using Simba:

- https://github.com/eerimoq/pumbaa
- https://github.com/eerimoq/romeo
- https://github.com/eerimoq/simba/tree/master/examples/synthesizer

As for drivers, there are two alternatives of how to implement them:

1. Build the driver on top of an existing driver, for example the UART driver. Existing driver API:s can easily be extended to add missing functionality. Sometimes even non-backwards compatible changes are accepted.

2. Perform hardware register accesses directly from the driver. This is not recommended since it makes the code less portable to other boards.

As you pointed out there are numerous drivers written for Arduino. These have to be rewritten in Simba, I'm afraid. It's theoretically possible to provide the Arudino API in Simba, but there are no plans on doing so.

Feel free to submit a pull request if you implement any drivers. They are very welcome! =)

And last, it should be possible to mix C++ and C in Simba. I've done it once or twice.

hichhiker

first of all. I'm the main author of Simba which makes me very subjective on this matter.
Wow, didn't expect the author to chime in :-)  Thanks for an interesting project :-)

Simba is a fairly active project on GitHub, with a handful of contributors. I've used it in a few projects, and it has been working very well, I must say. That said, other users may very well have a different opinion (which I don't know about, the little feedback I've received has been positive).
Good to know it has not been abandoned :-)

There are some discussions on GitHub and PlatformIO about Simba, but very few shares their projects and gives feedback.

Here are a few of my "bigger" project using Simba:

- https://github.com/eerimoq/pumbaa
- https://github.com/eerimoq/romeo
- https://github.com/eerimoq/simba/tree/master/examples/synthesizer
I'll check them out, thanks.

As for drivers, there are two alternatives of how to implement them:

1. Build the driver on top of an existing driver, for example the UART driver. Existing driver API:s can easily be extended to add missing functionality. Sometimes even non-backwards compatible changes are accepted.

2. Perform hardware register accesses directly from the driver. This is not recommended since it makes the code less portable to other boards.

As you pointed out there are numerous drivers written for Arduino. These have to be rewritten in Simba, I'm afraid. It's theoretically possible to provide the Arudino API in Simba, but there are no plans on doing so.

Feel free to submit a pull request if you implement any drivers. They are very welcome! =)

And last, it should be possible to mix C++ and C in Simba. I've done it once or twice.
Specifically I need to implement, at the very least, the XBee driver. For the most part it just sits on top of the Serial driver - but since the serial driver looks different in Simba vs Arduino - I imagine there will need to be some rewrite of the existing libs, but much of the code should end up being same... And I imagine it would be useful though to many people...

But before I get that far I need to get it to work and right now I can't even get the examples to compile
proper. I am trying to compile

Code: [Select]

/var/folders/ls/l_9lw6yn0232t9gzgmkzdzkm0000gn/T/arduino_build_562770/preproc/ctags_target_for_gcc_minus_e.cpp:43:115: error: storage class specifiers invalid in parameter declarations
 static int cmd_hello_world_cb(int argc,
                                                                                                                   ^
/var/folders/ls/l_9lw6yn0232t9gzgmkzdzkm0000gn/T/arduino_build_562770/preproc/ctags_target_for_gcc_minus_e.cpp:43:115: error: storage class specified for parameter 'cmd_hello_world_cb'
/var/folders/ls/l_9lw6yn0232t9gzgmkzdzkm0000gn/T/arduino_build_562770/preproc/ctags_target_for_gcc_minus_e.cpp:43:116: error: expected ')' before ';' token
 static int cmd_hello_world_cb(int argc,
                                                                                                                    ^
/var/folders/ls/l_9lw6yn0232t9gzgmkzdzkm0000gn/T/arduino_build_562770/preproc/ctags_target_for_gcc_minus_e.cpp:44:31: error: expected unqualified-id before 'void'
                               const char *argv[],
                               ^
/Users/hichhiker/Library/Arduino15/packages/Simba/hardware/avr/14.0.0/libraries/Simba/examples/shell/shell.ino:34:28: warning: 'cmd_hello_world' defined but not used [-Wunused-variable]
 static struct fs_command_t cmd_hello_world;
                            ^
/Users/hichhiker/Library/Arduino15/packages/Simba/hardware/avr/14.0.0/libraries/Simba/examples/shell/shell.ino:36:23: warning: 'shell' defined but not used [-Wunused-variable]
 static struct shell_t shell;
                       ^
/Users/hichhiker/Library/Arduino15/packages/Simba/hardware/avr/14.0.0/libraries/Simba/examples/shell/shell.ino:41:12: warning: 'int cmd_hello_world_cb(int, const char**, int (*)(int, const char**, void*, void*, void*, void*))' declared 'static' but never defined [-Wunused-function]
 static int cmd_hello_world_cb(int argc,
            ^
exit status 1
Error compiling for board Arduino Mega.


I fixed the immediate issue (use of "static" but it just chained down to other issues)

I am compiling on OSX using Arduino IDE 1.8.1, in case that matters.

I guess the first question - is it supposed to work?

The other immediate question/concern is over the lack of Arduino API - is there still access to pins and things like that? That seems like basic stuff, but I am not sure what qualifies as "Arduino API" in this case.

Thanks,

-HH

hichhiker

FYI - finally got the sample to compile under Sloeber by removing CSTR/OSTR macros :-/ Seems like those do not play nice with what Simba API expects...

eerimoq

Thanks for the bug report, will fix it today and create a new release.

There is a problem compiling far strings (far_string_t and "const FAR char *") with g++ it seems. I usually write in C ,and gcc does not have this problem.

eerimoq

Okay, so install version 15.0.1 of Simba and the compiler error should be gone.

hichhiker

Okay, so install version 15.0.1 of Simba and the compiler error should be gone.
I will make it a point to actually file future bugs in Github. Confirmed that 15.0.1 compiles and runs :-)

I have a ton of questions already, and I just glanced at it so far. As this is probably not the right forum(or at least not right thread) for this, and I am sure you do not want me PMing you - so what is the proper/preferred channel to get some basic questions answered as I move forward with this?  :-)

Meanwhile I will start messing with it and see how far I will get before reality comes calling... :-)

Thank you,

-HH

eerimoq

The Simbaa forum is preferred for general questions, and GitHub for features and fixes related to the Simba repo.

hichhiker

The Simbaa forum is preferred for general questions, and GitHub for features and fixes related to the Simba repo.
Exactly what I was looking for. Thanks again.

eerimoq

I started designing an XBee driver. The interface and example usage is part of this commit.

As I don't have any experience with XBee modules I might have misunderstood how it works, so let me know if the driver should be redesigned to be useful.

Example: https://github.com/eerimoq/simba/blob/master/examples/xbee/main.c

Interface: https://github.com/eerimoq/simba/blob/master/src/drivers/xbee.h

/ Erik

hichhiker

I started designing an XBee driver. The interface and example usage is part of this commit.

As I don't have any experience with XBee modules I might have misunderstood how it works, so let me know if the driver should be redesigned to be useful.

I will take a look.

Meanwhile - a crash course on XBee(as much as I know) - XBee has its own MCU/ code and is communicated with via some form of serial port, usually UART (but sometimes I2C or SPI). It has 3 modes of operation - direct mode, and 2 api modes - API1 and API2. API2 is same as API1 but with escapes for special characters) - Most code I have seen assumes API2 and it is the only one I really worked with.  XBee in API mode is mostly ASYNC. You submit a command frame to it with a frame ID and at some point you will get a response with a matching frame ID - but there is no guarantee it will be the next packet out of XBee. Xbee willl handle retransmits and other things for you and return to you information about what it took to send out (or not send out) a transmission. When it receives a transmission or when some internal events happen, it may spit out frames not matching requests.

Personally I would handle XBee driver as two layers/drivers - a low level one, that simply handles basic interactions with the hardware in the simplest possible terms, and an optional higher level one, that would keep track of the XBee state and handle queues TX/RX/AT queues, handles synchronizing of the requests to responses, and so on. The higher one could be argued is really part of the code, but it is going to be same for most people, so it would be nice to have a generic version.

In addition to basic RX/TX - there is also more advanced messaging like MANY-TO-ONE messaging and routing information. I am not sure Arduino has sufficient resources to deal with all of that, so it may be worthwhile to ignore it for now and let the app devs handle it if they want.

One more bit that may be worth knowing. Zigbee typically uses 16 addresses that are assigned when the device joins network. XBee, in addition, has 64bit MAC addresses that are fixed for a device and could be used instead of 16bit addresses. But typically you cannot use both 16bit and 64bit addressing at the same time and if you are using 64 bit address, internally XBee will first resolve that to 16 bit address. When you are using one address, the other should be set to one of the fixed  "broadcast" values. If both 16 and 64 bit addresses are set to broadcast, then the packet would actually be broadcasted. There is also a special 0x0000 16 bit address which is a unicast to coordinator.

Hope this is useful,

Thanks,

-HH

eerimoq

Very informative, thank you!

The driver I wrote is the lower layer, exposing an interface for sending and receiving XBee commands. The driver adds the frame delimiter, the crc, and, since it implements API2, escapes data bytes (all inverted for received frames).

It's of course possible to implement the high level driver in the same driver, but let's first make sure the low level driver works as expected. I wrote a unit test suite to easily test the protocol implementation on the host PC.

/ Erik

Go Up