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]

Would it be possible to make the path to the docker executable editable for your docker based build environment?

At the moment, the command in your makefile configuration files (inside the bricklib2/cmake folder) include the static path, that is /usr/bin/docker. On a mac, for instance, docker doesn't install into /usr/bin though.

It would be possible for me to change all these occurrences, that's not the question. However, I don't want to change that many files, given that I don't want conflicts in the cloned git repository.


Es gibt eine Fehlermeldung in Brick Viewer Version 2.4.9 (aktueller Commit von gestern) unter macOS 10.14.6, nachdem mal auf den Updates/Flashing Button geklickt hat im ersten Fenster. Aufruf des Brick Viewers mittels python3 (Version 3.7.4 installiert über Homebrew).

Beste Grüße

ps: Sorry, ich bin im falschen Forum! Bitte entsprechend in den Softwarebereich verschieben. Danke!

Die gestern veröffentlichte Firmware V2.0.3 des Industrial Dual Analog In Bricklet 2.0 verhält sich komisch im Brick Viewer Version 2.4.9.

Wenn die Anschlüsse offen sind (also keine Kabel außer dem Bricklet Kabel angeschlossen) liegt der Pegel bei 0V. Wenn man jetzt die Sampling Rate verstellt (unterhalb der 122 Hz), springt der Pegel im Plot runter auf unter -20V (siehe Screenshot). Ab 244 Hz Sampling Rate geht es wieder zurück auf 0V.

Das ist womöglich den Änderungen der neuen Firmware entsprechend (MCLK divisor depending on oscillator).

Hallo zusammen,

ich habe Probleme mit dem Industrial Dual Analog In Bricklet 2.0 Bricklet.
Mit einem Funktionsgenerator habe ich ein 0.3 Hz Sinus erzeugt (zwischen -1V und +1V), mittels analogem Scope entsprechendes Signal kontrolliert und dabei keinerlei Auffälligkeiten entdecken können (hätte ja durchaus sein können, dass der Versatz schon in der Signalquelle war).

Im Brick Viewer bekomme ich immer wieder einen horizontalen Versatz im Signal (siehe Screenshot). Ich habe Software-Updates eingespielt, die Bricklet Firmware erneut geflasht, konnte aber so keine Verbesserung erzwingen.

Ich sehe hierbei drei mögliche Fehlerquellen:
  • Hardwarefehler (Bricklet): Macht der ADC alle x ms Pause? Gehen bei der Kommunikation Daten verloren?
  • Softwarefehler (Brick Viewer): Kann es sein, dass die GUI irgendwas verschluckt? Für mich sieht das nach einem horizontalen Versatz aus, einem Sprung der Kurve nach links und rechts.
  • Hardwarefehler (Grafikkarte): Ist das ein OpenGL Bug (macOS)?

Kann das jemand mal bei sich testen? Besten Dank!

Hallo zusammen!

Die neue Brick Viewer Version 2.4.7 hat Probleme bei mir, sich mit dem Internet zu verbinden. Das von euch erzeugte Build verhält sich hierbei anders als die Version, die man im entsprechenden Ordner per Python aufruft (GitHub Source Code, letzter Pull vor einer Stunde).

Anbei ein Screenshot. Rechts euer Build, links der Aufruf mittels Python (dark mode). Beide wurden zeitgleich am gleichen Computer aufgerufen. Nur das Build gibt die Fehlermeldung.

Vielen Dank für das Update!

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]