Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - cl-

Pages: [1]
Besten Dank!

Ich selber nutze eure C++, Rust und MATLAB bindings.
Bedarf bestünde bei mir momentan primär mit Rust und MATLAB.


Is this topic solved or documented? I'm struggling with exactly this.

How do I get the data from the callback function back to the main function in MATLAB? I like to write all accelerations into an array while the callback function is active. After the sensors stopped sending data, I like to run some statistics on the entire data stream.

Code: [Select]
% Register 16-bit continuous acceleration callback to function cb_continuous_acceleration
    set(a, 'ContinuousAcceleration16BitCallback', @(h, e) cb_continuous_acceleration(e));

Within the callback, I can get access to the sensor data using the "e" object. However, how do I get the data back to the main function?

Brilliant! Thanks a lot for the quick response and solution!
I tried the changes and the performance increased immediately.

First of all, I love the HAT Brick! Thanks!

I have a general question related to its performance:

Do you know whether there are technical limits on how much data I can get through the GPIO of the Raspberry Pi? I'm using the new Version 4 Raspberry Pi (2 GB RAM) and the HAT Brick. I tried to get the full rate of 25.6kHz out of an Accelerometer V2 bricklet, but it wasn't possible. It seems strange to me, as the Master Brick has no problems at all (at least when connecting only one Accelerometer V2 with continuous acceleration callback). I know about the technical limits for more than one Accelerometer V2 bricklet.

When compared to the Master Brick, however, the data throughput with the HAT brick seems to be much lower. I was expecting it to be the other way around (as there isn't a USB connection anymore that limits the number of messages per second). Is there a technical reason why the HAT Brick doesn't get the (at least equal) amount of data through the system that is needed for the Accelerometer V2 bricklets? How does Debian (or Brick Daemon on the Pi) read the GPIO? I'm guessing it iterates over the SPI pins one by one?

For comparison: I connected a Master Brick to the Raspberry Pi and it gave me the expected "Master Brick" like performance I was used to in the past.

Thanks for your support!

EDIT 1: I'm using your Rust API bindings.

EDIT 2: Does it have to do with the maximal SPI clock of 1400000?

Code: [Select]
// On RPi 3 make sure to set "core_freq=250" in /boot/config.txt.
// The SPI clock is scaled with the variable core_freq otherwise
// and the SPI clock is not stable...

Das würde mich auch sehr interessieren.

In der Firmware habe ich nicht gefunden, aber wo die beiden Bits 7 und 6 für IIR_BYPASS (filter bypass mode) und LPRO (low-pass filter roll off control) gesetzt (oder nicht gesetzt) werden.

Thanks for this clear and detailed answer!
I'll go ahead with the "same bricklet kind and same UID" approach to implement the behaviour I was aiming for.


Thanks for the fix!
It works for me.

Good morning!

I updated brick daemon to 2.4.0 on macOS (10.14.5) today.
Brick Viewer works as expected and it shows connected devices.

However, when checking the version (brickd --version), it fails with the following error message:

Code: [Select]
dyld: Library not loaded: @executable_path/libusb-1.0.dylib
  Referenced from: /usr/local/libexec/
  Reason: Incompatible library version: brickd requires version 3.0.0 or later, but libusb-1.0.dylib provides version 2.0.0
Abort trap: 6

Temporary solution:
I have libusb installed via homebrew. I can't uninstall it though, as it has dependencies (dfu-util for instance). When temporarily renaming libusb-1.0.dylib (inside /usr/local/Cellar/libusb/1.0.22/lib/), brick daemon does load its own libusb version again.


Thanks again!

I fully understand your warning that hot plugging might damage the electronics. What I noticed just today is that you even display a message in Brick Viewer in the bottom left corner saying "Hot plugging is not supported! Please reset ...". This small message can easily be overseen though. Maybe it's worth to display this message in a new window with bigger font size.

Just another quick question regarding your

hot plugging devices to already powered stacks is not supported (for electrical reasons ...)


Would it help to use Isolator bricklets between the master brick and my Accelerometer V2 bricklets? Could it make the unsafe hot plugging of co-processor bricklets a little less unsafe with an isolated bricklet? Although there is an "Open Bricklet" button in Brick Viewer (plugins folder,, line 72), the API doesn't give a hint on its ability to manually control the isolator state. Does the term "Open" in this case indicate that the port is open and power/data is connected?

My use case would be to check whether a co-processor bricklet got replaced by another one of the same kind (using the very same uid and brick position). The hardware replacement would only happen in case the bricklet got damaged. Say, the software wouldn't get connection to the bricklet anymore, even after re-establishing the IP connection to the brick daemon and resetting the master brick. In that case, I would just replace the bricklet and - in best case - wouldn't have to disconnect the RED and master brick from power supply.

What one could additionally do is to reset the master brick after the replacement and reopen the IP connection to go back to its default state.

Thanks for your support!

Thanks for clarification!

Unfortunately, hot plugging devices to already powered stacks is not supported (for electrical reasons as well as in software). The EnumerationType::Disconnected is only sent, if the Brick Daemon on a PC notices that the USB connection to a stack is lost.

Brick Viewer creates new tabs with data plots, after you connect bricklets to the powered brick. At least it does it for coprocessor-based bricklets (Accelerometer V2 in my case). It doesn't remove tabs from the GUI for previously connected bricklets though (they just stay there and won't update). Is that what you mean with "hot plugging devices to already powered stacks is not supported"? At least your software supports adding new devices while in operation.

Bricklets without a co-processor won't automatically show up in Brick Viewer while in operation (I tried with some older bricklets).

Hi Erik,

thanks a lot. I tried your fix and it works nicely.

Another question came up when using the new version:
What happens with the thread (that was spawned from within the enumerate callback function), when the bricklet cable gets disconnected? One could check for EnumerationType::Disconnected and do some manual clean up work (that's not the problem). But how do I make sure, that the spawned thread (related to the previously connected bricklet) will be joined? Is manual clean up required?

In cases without using the enumerate callback function, I guess the spawned thread joins automatically when the callback_receiver object (ConvertingCallbackReceiver) is dropped, which in turn happens after the bricklet object goes out of scope? How will the binding handle the "enumerate callback function" case?

Will the callback_receiver object be dropped automatically after the cable is disconnected? Or do I have to store the JoinHandle so I can do the manual clean up inside the "EnumerationType::Disconnected" condition?

Background for my question:
I'm trying to develop Rust code that properly responds to changed hardware components while running, so one could achieve Hot Plugging support.

Thanks again for your great work. I really appreciate it!


Hi all,

After years of using the C++ API bindings for my projects, I gave Rust a try some weeks ago. Your API for Rust is just great! Thanks a lot for this!

I've ported all of my projects, but I'm missing one last thing:
What's the best way to implement the brick and bricklet configurations in the enumeration callback (as described in your rugged approach)? To be able to create bricklet objects, for instance, access to the IpConnection is required.

One could use an atomic reference pointer to be able to clone the IP connection as an input for the spawned enumerate callback receiver (to avoid Rusts' "lifetime conflicts"). However, at least at the moment, that doesn't play well with some of my other struct implementations and rustc doesn't like it. It's not unlikely that I'm doing something wrong, given that I started working with Rust only three weeks ago. I'm a very experienced C/C++ developer, but the way Rust does some things is really different!

As a starting point, I've used your authenticate example ( In your example in line 8, you used an IpConnectionRequestSender as input for the authenticate callback function. I'm looking for something similar for the enumeration callback. Unfortunately, I can't figure out a good way that is both elegant and thread-safe. How can I get thread-safe access to the IpConnection object in my spawned enumeration callback?

Has someone found a good way to do it? I would appreciate any suggestions.


Pages: [1]