swire support about gy521

[netpipe]

i forgot to enable swire in the examples uncomment the #define swire in the demo

#ifdef SWIRE
sensor.begin(A3,A4);
#else
Wire.begin();
#endif

[netpipe]

oopd forgot this part b705d0f

[netpipe]

updated hopefully its working 100%

[RobTillaart]

It looks like you did not copy the latest version, at least not for all files.

saw you used swire instead of Wire
Can you explain the differences?

---

OK it is a software I2C I get it.

[RobTillaart]

Interesting code,

however a "rewrite" of the library should not be needed.
It should be possible to create an softWire object and just give it to the constructor of the GY521 class.
maybe the software Wire should derive from TwoWire to make it match?

Something like

//
//    FILE: test1.ino
//  AUTHOR: Rob Tillaart
// VERSION: 0.1.0
// PURPOSE: minimal demo
//    DATE: 2020-07-01

#include "GY521.h"
#include "SWire.h"

SoftWire  myWire;        // create software wire object

GY521 sensor(0x68, (TwoWire *) & myWire);   //   <<<<<<<<<<   this is the critical part

uint32_t counter = 0;

void setup()
{
  Serial.begin(115200);
  Serial.println(__FILE__);

  myWire.begin(4, 5); 

  delay(100);
  while (sensor.wakeup() == false)
  {
    Serial.print(millis());
    Serial.println("\tCould not connect to GY521");
    delay(1000);
  }
  sensor.setAccelSensitivity(0);  // 2g
  sensor.setGyroSensitivity(0);   // 250 degrees/s

  sensor.setThrottle();
  Serial.println("start...");
  
  // set callibration values from calibration sketch.
  sensor.axe = 0;
  sensor.aye = 0;
  sensor.aze = 0;
  sensor.gxe = 0;
  sensor.gye = 0;
  sensor.gze = 0;
}

void loop()
{
  sensor.read();
  int ax = sensor.getAccelX();
  int ay = sensor.getAccelY();
  int az = sensor.getAccelZ();
  int gx = sensor.getGyroX();
  int gy = sensor.getGyroY();
  int gz = sensor.getGyroZ();
  int t = sensor.getTemperature();

  if (counter % 10 == 0)
  {
    Serial.println("\n\tACCELEROMETER\t\tGYROSCOPE\t\tTEMPERATURE");
    Serial.println("\tax\tay\taz\tgx\tgy\tgz\tT");
  }

  Serial.print(counter);
  Serial.print('\t');
  Serial.print(ax);
  Serial.print('\t');
  Serial.print(ay);
  Serial.print('\t');
  Serial.print(az);
  Serial.print('\t');
  Serial.print(gx);
  Serial.print('\t');
  Serial.print(gy);
  Serial.print('\t');
  Serial.print(gz);
  Serial.print('\t');
  Serial.print(t);
  Serial.println();

  counter++;
  delay(1000);
}

[RobTillaart]

Had a quick look at the softWire library and it has a pretty clean setup, well done.

Some things popped my mind

in the .h file you could use #pragma once instead of the ifdef .../endif construct.
Compiler just needs to read one line instead of the whole .h file.

There are some functions like beginTransmission that appear twice, one with and one without parameter.
C++ allows default parameters for functions.

uint8_t beginTransmission(bool shouldstop = true)

Several functions are oneliners - you might add the inline keyword so the compiler can optimize call stack.
(in fact I hope most compilers will recognize these oneliners themselves)

Think I would add pin parameters to the constructor too.
Constructor should set the SDA and SCL in a defined initial condition.
(e.g. floating lines can trigger sensors or devices like the PCF8574 in an unexpected way)

The Wire lib has a function called setClock() https://www.arduino.cc/en/Reference/WireSetClock
Would be nice if the speed could be tuned, e.g. long wires typically need lower frequency
And recently I created a library for a sensor that needed only 30 kHz.

---

Did you do performance tests with the library?

[netpipe]

a freelancer is working with it now to build a virtual reality glove for my project https://github.com/netpipe/HappyHands we should be able to see it working soon, I'm glad you kept working on it because we bumped into issues from 0.2.3 :) you are welcome to the changes for the main repo if you like.

[RobTillaart]

you are welcome to the changes for the main repo if you like.

If time permits I might (maybe now winter is coming)
unfortunately the libraries are one big repo. I had that too in the past, and it became unmanageable in practice.-

I'm glad you kept working on it ...

Yes, I try to keep bugs out of my libs and features and performance in, with 100+ libraries under support issues still come in regularly. Sometimes bugs pop up under specific use, hard to recreate. Especially Heisenbugs, they only appear if you do not look, right after a 4 hour debugging session or so.

Coming time I will spend time to visualize CI-build results (under actions) and add support of build process for ESP32. Especially the latter I expect it will expose some weak code parts. At least this helps to keep code quality at a "certain level"

Is there functionality missing in the GY521 library for you?
Or any other lib?

[RobTillaart]

BTW, are you familiar with https://github.com/Testato/SoftwareWire ?

[mdjavedakhtar]

BTW, are you familiar with https://github.com/Testato/SoftwareWire ?

i have used the library previously and it works fine !!
BTW i am the freelancer working on the VR glove (https://github.com/netpipe/HappyHands) as mentioned by @netpipe
Really interesting project and progress so far is good.

hope to finish by weekend !!

[netpipe]

libraries.zip

i have this working at 2.3 , going to update it a bit. found that newer swire was giving issues.

[netpipe]

examples.zip

updated example

examples2.zip
s

[netpipe]

GY521-newestfixed.zip

[RobTillaart]

libraries.zip

i have this working at 2.3 , going to update it a bit. found that newer swire was giving issues.

Note that the last library released is 0.3.4 and that 0.3.5 is under development

See - #28
and - #29

[netpipe]

the newestfixed version is all the new code you had basically copy and pasted in without the updated comments. the main changes was getting rid of the micros() and changing it back to milis to make it work properly.

[netpipe]

if you like i can make a fork and put it all in for you with a pull request ?

[RobTillaart]

if you like i can make a fork and put it all in for you with a pull request ?

Yes that is preferred, than it is easier for me to analyse your changes and if and how they affect the library.

[RobTillaart]

I need to merge #29 before you should fork as the build-CI is broken and I need to fix that first.
This PR will also update the begin() function to include a wakeup() call - see #28

[RobTillaart]

Merged #29 - closed #28

[netpipe]

GY521-SWIRE.zip here is an updated swire branch my other repo has a better copy still though.

[RobTillaart]

Installed the GY521-SWIRE.zip as GY521 library (moved mine) , and my existing code that does not use SWire breaks.
That should not happen.

C:\Users\Rob\Desktop\GY521___\examples\GY521_performance\GY521_performance.ino: In function 'void setup()':
GY521_performance:22:3: error: 'Wire' was not declared in this scope
   Wire.begin();
   ^~~~
C:\Users\Rob\Desktop\GY521___\examples\GY521_performance\GY521_performance.ino:22:3: note: suggested alternative: 'SWire'
   Wire.begin();
   ^~~~
   SWire

[mdjavedakhtar]

With swire you have to replace all instances of wire to swire

[RobTillaart]

That is not acceptable as when I have a system with 2 busses, one SWire and one hardware Wire I cannot configure the library to handle both.

With the dependency injection, giving the right wire object as parameter this does work.

So you should make your SWire library derived from the TwoWire class and then you can just "inject" it.

[RobTillaart]

There are at least 2 other software I2C libraries.
If those would be embedded in the same way into the library GY521 would become much harder to maintain.
Furthermore it would introduce a compile time dependency while my solution has the dependencies only runtime,

[RobTillaart]

i forgot to enable swire in the examples uncomment the #define swire in the demo

It is not the examples I worry about, it is about the real projects people have made with the library.

[RobTillaart]

If you derive swire from TwoWire, you can injcect the dependency runtime. Not only in this library but in many more.
you have written most functions already, so I would propose you investigate that path.

[RobTillaart]

I close this issue as I will not integrate the current swire solution in the library.
When an Twowire derived SWire class is available, I might have time to test it.