Does this library works with arduino due

[acollazomayer]

Hi im trying to use this library with an arduino due, and its seems that is not working. Nothing gets printed on the serial monitor. while if i use it with an arduino uno its works

[jpk73]

Works on my DUE.

[acollazomayer]

@jpk73, can you pass me the code. to at least try it? thanks

[bogde]

@acollazomayer i think you should provide your source code and describe your wiring, that would allow people to help you out. i never tried the code on due, and i dont own one, but others could help you out.

[acollazomayer]

@bogde HI thanks for answering me, I just upload the example code in sparkfun library:

And with the arduino uno it is working spectacularly, but i when i upload the same code into an arduino due, Nothing gets printed in the serial monitor. Its like it is not working at all

#include "HX711.h"

#define calibration_factor -7050.0 //This value is obtained using the SparkFun_HX711_Calibration sketch

#define DOUT  3
#define CLK  2

HX711 scale(DOUT, CLK);

void setup() {
  Serial.begin(38400);
  Serial.println("HX711 scale demo");

  scale.set_scale(calibration_factor); //This value is obtained by using the SparkFun_HX711_Calibration sketch
  scale.tare(); //Assuming there is no weight on the scale at start up, reset the scale to 0

  Serial.println("Readings:");
}

void loop() {
  Serial.print("Reading: ");
  Serial.print(scale.get_units(), 1); //scale.get_units() returns a float
  Serial.print(" lbs"); //You can change this to kg but you'll need to refactor the calibration_factor
  Serial.println();
}

[bogde]

when you say "nothing gets printed" do you mean nothing at all? does this get printed "HX711 scale demo"?

are you sure you're using the same wiring as on uno?

[acollazomayer]

@bogde, nothing at all, The HX711 scale demo does not get printed. Yes the exact same wiring. Anyway, if the wiring is wrong at leas the Serial print in the set up should be printed.

[bogde]

with the current wiring, if you don't include the library and just try to output a static text to the serial port, does that work?

if yes, what if you just include the library but dont call anything related to the HX711?

[acollazomayer]

@bogde once i do scale.begin(DOUT, CLK); then the program stop serial printing

[bogde]

are you sure your DOUT and CLK wiring is correct?

On 10 Dec 2017, at 22:26, Agustin Collazo Mayer notifications@github.com wrote:

@bogde once i do scale.begin(DOUT, CLK); then the program stop serial printing

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[acollazomayer]

@bogde yes i am

[jpk73]

Here is my code:

define DOUT 28

define CLK 29

define calibration_factor 48600 // 48600 auf Holzmaschine MK1

define zero_factor 15700 // 17500 auf Holzmaschine MK1

HX711 scale(DOUT, CLK);

void setup() { scale.set_scale(calibration_factor); scale.set_offset(zero_factor); waage(); if (kilogramm <= 1) { scale.tare(); } }

void waage() { kilogramm = scale.get_units(); // auf eine Nachkommastelle runden: kilogramm = kilogramm + 0.05; kilogramm = (int)(kilogramm * 10); kilogramm = kilogramm / 10; // auf eine Nachkommastelle gerundet kilogramm = abs(kilogramm); // ggf. negatives Vorzeichen entfernen bzw. absoluten Betrag der Zahl bilden sprintf(W_buf, "%4.1f", kilogramm + 0); // "+ 0", damit kein Minuszeichen bei 0Kg angezeigt wird redraw_display(lcd_waage); }

[acollazomayer]

@jpk73 @bogde so now the weirdest thing is happening. I try this on another arduino due and three different cables. So the code takes a little bit to load and once it loads it starts reading, however the tiniest movement in the serial cable makes it to stop reading. if i do serial print with delay 10 its prints fine in both arduino due, no stoping. However with this library, it stops reading whenever it wants to.

[acollazomayer]

@jpk73 @bogde, for you to see that im not lying with the two arduino due

[bogde]

i guess we all tend to trust each other here :)

can you try a different serial port or a different computer? can you upload a sketch that only sends some data to the serial port, once per second or so, and see if touching the cable stops the communication?

[AlbiBone]

Dear @acollazomayer , how do you solve the problem?

[amotl]

Dear Agustin,

Constructor initialization

once i do scale.begin(DOUT, CLK); then the program stop serial printing

Just wanted to let you know that by [1], we let the constructor-based initialization go completely. So, it can't even be used by accident anymore. You are totally on the right track when using scale.begin(DOUT, CLK); already, the library has a great chance to block when initialized using the constructor (before).

Weird timing behavior on faster microcontrollers

However, we also put some efforts to collect and solve different things circling around here which might well have caused any weird behavior you observed before, especially on the Due, which is actually an Atmel SAM3X8E ARM Cortex-M3 CPU, so it is way more powerful than the Atmel AVR chips this library was originally developed for. As we incorporated some timing-relevant amendments for Atmel SAMD from others already, chances are actually high it could work for you as well. So, it could be worth to give it another try with the updated version [1].

With kind regards, Andreas.

[1] https://github.com/hiveeyes/HX711/tree/spring-cleaning

[CFTechno]

Would like to point out that I used this lib from the beginning on a DUE and never had any problems with it .

[amotl]

Dear @CFTechno,

Would like to point out that I used this lib from the beginning on a DUE and never had any problems with it.

Thanks for letting us know, this is valuable information from our perspective, especially when others have been struggling. Do you have any news, @acollazomayer?

After sublimating ourselves into this topic before doing the refactoring outlined above, we too believe the Due would have made the least problems in general. However, many people using faster MCUs reported problems with register shifting being too quick. So, while 16777092 probably was introduced back then to actually speed things up, we now obviously have to slow things down - at least sometimes.

Saying that - and taking into account that the improved implementation based on valuable information from #75 should account for processor speed already - it still would be perfectly valid this library would work on any microprocessor, as whether it works or not would obviously depend more on the actual clock speed the thing is running on in a specific configuration, right?

Saying that - and again taking into account that the new implementation considers the M3 (going by ARDUINO_ARCH_SAM) to be a FAST_CPU - this is very valuable information to us as we kind of made this refactoring to aim at a universal library working flawlessly on all platforms currently around. Thanks!

Coming from your experience with this library on the M3, we learn that we should reconsider whether the M3 should be flagged as a FAST_CPU at all. However, may I humbly ask you about the clock speed you have been running your configuration at, in an attempt to improve the overall understanding of this topic regarding system behavior?

By reading the issues here and crosschecking with the development progress of the Espressif SDK, we learned that even now the behavior of the watchdog timer with respect to the Arduino sketches running on the ESP is discussed again - at least for the ESP32 SDK. So, even there things are still in flux and might change the behavior of even core libraries underpinning the whole Arduino ecosystem.

While this specifically holds true for the upcoming ESP32 dual-core chip and might not be relevant for other architectures, we found bringing in #62 would be way more important for all CPU architectures likewise. While things might have worked before in general, things like that should account for subtle bugs not always obvious and only sporadically visible, if visible on just slightly interrupt-loaded systems at all.

Before writing to the hardware, the improved code will now toggle interrupts using the regular noInterrupts() vs. interrupts() primitives when running the vanilla Arduino HAL on the M3.

While there already is a port of avr-libc's ATOMIC_BLOCK macros to the ARM Cortex M3 implemented by util/atomic.h, it's apparently only provided by the Teensyduino HAL and so will only get enabled on AVR and TEENSYDUINO.

So, if this still sparks your interest, we would really like to know whether this multi-architecture variant we put into [1] would still work on your specific hardware configuration.

With kind regards, Andreas.

[1] https://github.com/hiveeyes/HX711/tree/spring-cleaning

[amotl]

If you are still with us, we would also love to hear from you in this context, @jpk73 and @AlbiBone. Thanks!

[CFTechno]

DUE standard clockspeed, the hx board sampling at 80hz, testing the scale ready in de code and if it is ready only then read the scale value

[AlbiBone]

@amotl, in the past I tryied to use the HX711 with my DUE but as described, after the setup loop it does not work. I am still interested to find the solution. However I am new of this world (i.e. Arduino and more in general elettronics) and I am can not help you a lot in this discussion...

[amotl]

Hi there,

thanks for your feedback @CFTechno regarding DUE clockspeed.

What you are saying here in respect to the code snippets displayed in this thread: @CFTechno is absolutely right, you should wait for the scale to become ready before reading the sensor value, @acollazomayer and @AlbiBone.

You might find appropriate examples at HX711_basic_example.ino and HX711_timeout_example.ino.

With kind regards, Andreas.

[amotl]

you should wait for the scale to become ready

read() already does while (!is_ready()) upfront, so it will wait for the HX711 to become ready. I conclude this detail should be fine already?

testing the scale ready in de code and if it is ready only then read the scale value

Or do you mean one should explicitly run the waiting poll in the main sketch like outlined in HX711_timeout_example.ino?

[acollazomayer]

@amotl Hey thanks for fixing the library, However its been a while since I used this and I do not have the components anymore. So i can not test this.

Anyways Thanks!

[CFTechno]

@amotl

read() already does while (!is_ready()) upfront

Yes, but using the DUE to also control a few motors, touch screen and has data interfaces with other boards you do not want to write code that goes into a while not ready loop :) Better check it yourself in the code when needed and then read the scale when it's ready.

[amotl]

you do not want to write code that goes into a while not ready loop :)

I second that and believe the spinlock shouldn't be part of the read() function at all. To follow up on that, we also created https://github.com/bogde/HX711/issues/125 today.