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.

Topics - cl-

Pages: [1]
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...

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.


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]