Please bear with me, my coding skills is VERY limited, hinges on non-existing actually
I am using a MAX17201A fuel gauge in an application with the B524 as uC. Reason for the external fuel gauge is due to the primary cell application (Li-SOCL2 and LiMnO2). I found a library on Github and have been trying to import that into WebIDE so I can included it in my project, but have had no luck. Below is the link to the Github page. Would appreciate some help
@friedl_1977, the easiest way is to copy the library files to your project via cut and paste. First, add files to your Web IDE project by hitting the “+” sign in the top righ-hand corner. One file will have the .cpp extension while the other will be .h. Name the file “max1720x”. The other tab will automatically be named the same.
Go to GitHub and select the max1720x.h file to open it and copy its content using the “Copy raw contents” button.
Now do a paste in the (newly added) “max1720x.h” WebIDE file tab and save (I hit Ctrl-S to do this). Now do the same but with Github "“max1720x.cpp” file. The library is now copied to your project and you will find this at the top of the .ino file:
// This #include statement was automatically added by the Particle IDE.
#include "max1720.h"
Using the Github example and compiling for a BRN404x with DeviceOS 5.2.0 (prerelease), I had not compilation errors.
Great thank you!! I will do this and let you know should I encounter any issues. I2C has really been giving me problems in this particular board and not sure why to be be honest.
I am hoping to target the fuel gauge directly as for some reason, the “scanner” is not detecting it. I reflowed four boards and double checked the schematic with Maxim but the problem persists
Indeed I do, 10k. The scanner I use is a very simple one, suppose to detect all I2C addresses connected directly to the uC. It does pick up some addresses but not all.
For some odd reason, 0x77 stopped showing up as well Maybe worth mentioning, some devices are connected to I2C via the multiplexer due to them having the same fixed address. The ones I am looking for now are simply the ones connected directly to the uC.
Based on the datasheet, the I2C address should be 0x6C and possibly 0x16 for reading a higher memory range, though that is somewhat unclear in the datasheet. Not sure what it isn’t found.
Exactly the reason I prefer sticking to PCB design, but always happy to make the universe smile I suppose. Just let me know when you need another laugh, I am sure I can come up with another stupid mistake
Thanks for the help and thanks @peekay123 for the advice on the library, will test it today. Suppose it is better to learn the Workbench environment in the long run.
I copied the contents of the PCA9547.h file into the newly created file in the WebIDE already and hit “save”, just don’t know what to do with the .cpp file now? I am receiving errors while compiling so assume I did something wrong… again
../hal/b5som/pinmap_defines.h:46:13: expected ',' or '...' before numeric constant
When you look into the header file, you’ll notice that it doesn’t only contain the definition of the PCA9547 class but also the implementation. Hence, no .cpp required.
That error message rather indicates something else, which would require more background.
Probably only a missing semi-colon or something like that.
With Web IDE you can always post a SHARE THIS REVISION link for anybody willing to investigate what may be going on
Since I neither have a B5SOM nor any of these expansion boards I could only focus on the build problems you experience tho’ - not the actual readings and publishes.
The problem in that library is that the function setAddress() uses A0, A1 and A2 as parameters, but these are already in use as pin definitions (i.e. #define) and hence trip the compiler.
You can changes these into a0…a2 in the parameter list and implementation and then the build should go through.
You also need to revisit your publishing logic. As is you are running into the rate limit as you are trying to publish six events in one second - the burst limit is four with four seconds cool down.
This should work better
void scanner_2() {
i2cSelect.enable(ch % 4);
char msg[128];
snprintf(msg, sizeof(msg), "set ch <%02X>, cur ch <%02X>, status <%d>", ch % 4, i2cSelect.channel(), i2cSelect.getStatus());
//Serial.println(msg);
Particle.publish("I2C", msg); // ONE instead of SIX publishes ;-)
++ch;
delay(1000);
}