I used the wire. h library of AMB82 to write a subfunction for reading registers. AMB82 was used as the host, and the compilation prompted the following warning, but it still passed. I tested the actual communication with the device and it showed that it could not be read properly. What I don’t understand is that the same code runs normally on ARDUINO UNO, but there is an exception when using the wire. h library of AMB82, I would like a friend to point out where my code is not correct when using the wire. h library of amb82. Attached are screenshots of my iIC reading subroutine and exceptions
May I know is there any error log? From what I see from your screenshot, it appears to be warning messages. Are you requesting data from your slave device, which is actually reading the register values? How many bytes of data are you expecting?
Can you follow how the example is written for MasterReceiveData.ino?
I verified my hypothesis using a logic analyzer. When both write and read operations exist, the read operation will fail, but it is normal to use independent programs for read or write operations. I merged a test code using a routine and captured the logic analyzer packet. After modifying the data type of len to int, the previous issue was resolved without any further error prompts. Therefore, after troubleshooting this issue, I merged the wire. h read-write routines and found that the read function was invalid. Attached are my test code and packet capture
Thank you very much for your feedback. I am currently working on comparing the wire. h file that comes with Arduino Uno with the file corresponding to amb82. I believe this may involve the logical issue of stopping the header file when handling write operations. When I am writing and do not call the Wire. endTransmittion() function, the Wire. requestFrom() function can capture packets and run several times, but the loop of the main function cannot continue to run, I will continue testing and try to resolve this issue.
After testing, I have roughly identified the possible issue. Before performing write operations and requesting read operations, Wire.begin() needs to be run once; So I think the Wire. endTransmission() function killed the iic connection, causing subsequent request read operations to fail. If it’s convenient for you, you can take a look at the logic of the Wire. endTransmission() function.I checked the wire. c file of amb82 and found that there are actually two void TwoWire:: end() functions in the Wire. endTransmission() function. I think one of the end() functions here should be deleted, so I tried deleting the second one. After testing, I found that the loop of the main program can run normally when both read and write functions are present.But when I made this modification, all the read and write operations captured by the logic analyzer were changed to write operations. As I couldn’t see the file # include “i2c.api. h”, it was temporarily difficult to locate the problem.
This problem has been bothering me for a long time. If any friends are interested, they can try to reproduce my problem, which is the problem of read failure when both read and write exist. I think if this problem cannot be solved, I can only find a way to use the secondary master to process the iic information, and only use the serial port of amb as the output of the local AI model calculation results. This may be an impossible solution, In fact, I recently discovered a local AI computing module for ESP32S3, but honestly, I still hope to use AMB82
Apologies for any inconvenience caused, rest assured that we are aware of this issue. We are caught up with a lot of problems to be solved and please allow us more time to fix this. We cannot guarantee a timeline yet, but we will definitely work hard to solve this issue.
Thank you for your time and effort in helping to troubleshoot this far. Can I check with you how urgent do you need this? Hopefully, we can come up with a solution before your desired timing.
Thank you very much for your reply. First of all, I believe AMB82 has great potential. Its multi in one design will be a versatile chip in my ideal after the software ecosystem is perfected, at least covering a lot of advanced projects for makers. So I am looking forward to that day, so I am also a bit anxious. I just want to confirm that you have discovered this problem and I want to do my best to solve it. In short, thank you for your reply. I think I will continue to wait for your latest progress.
Perhaps it’s just a coincidence that I solved the problem of read invalidation when both read and write exist by modifying the requestFrom() function in the wire. c file. Attached are the changes I made and the packet capture situation. I tested the maximum delay setting and found that the minimum setting was 1ms, and the test was still normal. I also tested Wire1, which was also normal. So I continued to test the three built-in routines of AMB and found that the iic scanning was normal and the writing of routines was also normal. However, the serial port of the reading routine reported a pin definition issue.Although the serial port reported an error, what I captured using a logic analyzer seems to be normal, so I think there may still be some issues with my current modifications. I will continue to analyze where the problem lies.
I conducted a read and write communication test with my peripheral IIC device using amb82, and everything was normal. The loop function ran normally without getting stuck, and the read and write data was also correct. I think the next step to this problem should be to solve the serial port error of the reading function in the routine, which seems to meet the usage requirements.After all, serial port errors only occur when reading exists separately. When both reading and writing exist, the serial port is normal and will not report errors
Please note that the delay after the request function cannot be omitted. At least my current testing situation shows that omitting it will cause data misreading.
I tested the latest Arduino SDK version 4.06, which was released on January 18th, and found that the issue of read failure still exists when both iic reads and writes are present. I think perhaps this issue can be resolved in the next iteration. Thank you.
