Here is my issue… What are all those reversed question marks?
This test writes 364 random a to z letters to the file then reads them back and writes them to the serial port…SO where are they? why do I only see 20 of the 364?
I need to read in a Json Config file and get the same results, only 25 or so characters are read in…the rest is this question mark thing??
I’ll need to test this circuit with a Qwiic OpenLog + ESP32 Thing Plus to be certain, but I think it may be related to [this issue with the Arduino Library. I am not certain if the engineers have tested this library with the ESP32 so if I were to guess, I think something is happening with the I2C bus either locking up or something with the timing is off. I’ll try and pull an ESP32 Thing Plus and a Qwiic OpenLog to replicate your results here and we can go from there.
I don’t have a red board. I do have numerous other boards, but I have no way to attach the quiic logger to any of them. In a few days I’ll have some Grove == Quiic wires, and can test the logger from an Uno, Wemos D1, Arduino, and others via a Grove Base Shield through the conversion cable to Quiic Logger.
I am unable to use standard jumpers due to ataxia (shaking hands), I am limited to connectors like Grove & Quiic.
I was able to test the Qwiic OpenLog with an ESP32 Thing Plus and am running into the same problem. I’m going to do some more digging to figure out what the issue is with the library and hopefully we can get this issue fixed quickly.
After some more testing, I’m not sure if the Qwiic OpenLog will work well with the ESP32 Thing Plus without some modifications to the code. The primary issue here is the Qwiic OpenLog uses clock stretching to read from the SD card so the clock line is held LOW by the slave device (in this case, the Qwiic OpenLog) for too long and causes timing issues with the I2C bus. The best way we can think of working around this would be to read the file from the OpenLog byte-by-byte so you do not have any periods where the slave is holding the SCL line LOW for very long. I’m not sure if that is something that would work for your project, though.
Depending on what you need to accomplish with your final project, you could either utilize the Flash memory on the ESP32 Wroom or, if you need to use an SD card, you can write directly to one using SPI since the SDFat library works really well with the ESP32. If you can provide a bit more detail on your project, I would be happy to try and point you to some resources that would help you with it.
I have a Json Configuration file, possibly 400-1k of data to load into my sketch, unique to each installation. If I understand, the problem is that my data is too large a read. Maybe breaking it up into multiple smaller files might work? or just get a SPI 3.3 Volt SD card reader and wirer it up. are my options, Right?
Unfortunately, we do not have an example of how to read a file byte-by-byte but it would just be a modified version of the [OpenLog Read Function. That could work if you set your I2C buffer length manually but it may be more trouble than it is worth.
I would honestly recommend storing the file on the ESP32 WROOM’s Flash memory and reading it with the EEPROM library. Here are links to a couple of tutorials that may help you get starte3d with that:
As TS-Mark points out the issue is clock-stretching. This is NOT support on the ESP32 standard I2C. It is not really related to the size of data, it is a mechanism for a “client or slave” to indicate that the “master” it needs more time handle a previous request. I run into this in a earlier project and handled it by porting the I2C from the ESP8266, which DOES handle clock-stretching. Check out viewtopic.php?f=74&t=51043 where it is handled for a CCS811.
Copy the SoftWire directory from that CCS811 src-directory into your openlog src-directory.
In the sketch you just indicate
#include <SoftWire/SoftWire.h>
instead of
#include < Wire.h>
Now I don’t know how much time Openlog needs, but as part of setup (), before just before myLog.begin();
Wire.setClockStretchLimit(200000), it will set 200ms (limit is in us). Make it larger if needed.
Just to bring to your attention that I’m experiencing the same issues with a new SparkFun Qwiic Micro SAMD21 + Qwiic OpenLog. When I run the Example5_ReadFile, I get the results shown below. I should also note that when writing to the default logfiles created on the OpenLog using the command: “myLog.println(“OpenLog Read File Test”);”, the log file only records the “O” and nothing else.
When connected to the Qwiic Micro, the Example9_ReadVersion shows the OpenLog version as 3.255. When I connect the Qwiic OpenLog to my Artemis Nano, the OpenLog version is 3.1.
No issues with the Example5_ReadFile and the Artemis Nano. See below:
I don’t have any other Qwiic based boards on hand, but I find it hard to believe that it wouldn’t work with the SAMD21. Glad I came across this post when I did, as I already spent the morning trying to figure out the problem. Curious to hear your thoughts.
I am experiencing the same problem with the Qwiic OpenLog library. I have the Qwiic OpenLog connected to a SparkFun Redboard Qwiic and can’t read more than 36 bytes back from it. I was already searching for specific commands, but could not find anything that would work with this library.
Did you already figure out anything? Does anyone know how to solve that problem?