Remaining Features and Properties #4
Conversation
|
hihi @FoamyGuy - i poked more at this this morning and ended up switching to mainly manual reads and adding some remapping to return the read bits as values in the enumerations. i ended up using chatgpt to help so i updated the top of the library to note that with the link to the chat. i also started on a full test example that will run through all the possible modes and print out the result. i checked off a couple of the remaining functions in the issue to get us back on track. everything here was tested with hardware if you could please also verify. if you want to pick up from here that would be great! |
|
@BlitzCityDIY I added the multi pulse property and tested it successfully. At first I did it without register. But looking at the code got me thinking about the register way a bit more, and I think I figured out what was at least 1 of the things that made it unhappy about the register way with RWBit and RWBits. The chip seems to really prefer that you always read / write 2 bytes for the register. Even if the values you're interested in are within a single byte, or even single bit. Testing this theory by using RWBits with I also went back to Would we want to prefer the register / RWBit(s) way for any given property if that way works and only fallback to the more manual implementation if that isn't working? Or is it better to keep the more manual implementations which offer the reverse dictionary lookup for the value constants, and validation for the input values? Or maybe a combination of the two with _private RWBit(s) instances and the property definitions for the public API that handle the validation and reverse lookup, but rely on the RWBit(s) for the actual reading and writing of registers? I've currently committed a version that includes the manual implementations but they are commented out and the register / RWBit(s) versions are in use and appear to function correctly. Let me know which way to go for the remaining ones, and I'll update those existing ones as appropriate too. |
|
@FoamyGuy great, thank you! yes, the preferred way is to use register rather than manual reads. if something needs to be tweaked, like returning a mapped value, then you use a private register and wrap it in a property. why don't you try using register with the 2 bit width and see if that works for the remaining/any ones we are reading manually. this is often the case with drivers like this, a lot of testing with hardware and this happens to be a trickier one with a lot of settings |
…_persistence to wrapped RWBits. Change sunlight_double_immunity, prox_active_force, prox_smart_persistence
|
@BlitzCityDIY I'm working through the rest of these and have gotten the process down fairly well at least for this driver and the 1-3 bit values. I was able to swap over all of the existing properties to use plain or wrapped RWBit(s). While adding the remaining properties I think I've ran across an inconsistency between the arduino driver and the datasheet from here: https://www.vishay.com/docs/84430/vcnl4200.pdf, At least my (granted quite limited) understanding of them. In the arduino driver here: https://github.com/adafruit/Adafruit_VCNL4200/blob/ce01bddc838f508cebdb08ab3c149a8c5a19e84d/Adafruit_VCNL4200.cpp#L791 and again down a little bit in the getter, it notes the PS_MS bit location as bit 7 of the second byte. But in the datasheet on page 11 table 9 it lists PS_MS bit location as bit 5 of the second byte: |
…x_interrupt_logic_mode, prox_cancellation_level, prox_int_threshold_low, prox_int_threshold_high, and interrupt_flags.
|
i'll be the first one to admit i'm not 100% secure in my interpretation of datasheets 😅 i'm inclined to go with the arduino function and we can test with hardware if the pin is being set properly |
|
@BlitzCityDIY okay, the rest of the ones in the list from the issue are implemented. They appear to work correctly as far as I can tell with some testing by flipping their values to different things in the fulltest script. The interrupt flags is the part that I have the least confidence in. I'm not sure if the way I've returned a dictionary is really what we want. I'm also not sure if the those flags are working correctly, although I don't think I fully understand how they are intended to operate either. I've tried various different values for the thresholds and turning on the interrupt for proximity, but for me the value of all of those flags is always I have not tried hooking up the interrupt pin though, and it's possible that I'm not understanding the right way to configure / enable the interrupt capabilities. |
|
@FoamyGuy okay, no worries! i can take a look tomorrow and test things out and then we can go from there. great work! this is a tricky one. |
|
@FoamyGuy hihi- i did some tweaking with the interrupt flags and was able to get them to consistently trigger/reset. i also wrote an example specifically testing them. everything else was working as expected. if you want to check things out too then i think we can start adding typing/getting the docs set |
|
@BlitzCityDIY nice! the interrupt test is working as expected for me now. Thank you! The full test is working as expected too. I can work on typing and docs if you'd like. Do you know if it's possible / how to add docstrings for the ones that are only RWBit(s) and don't have a wrapper property function? |
Looks like a string underneath should work https://stackoverflow.com/a/6061254/507810 I'll try that out and build the docs locally. |
|
@FoamyGuy that would be great if you would like to. you can add docstrings for register objects. you add """ """ comments under the object. for example: any internal ones we don't need to add docs to |
|
@BlitzCityDIY docstrings and typing annotations have been added. I had one question about the name of two of them in the inline comment above. |
|
One thing that is a bit odd is that it's showing some (seemingly random) numbers as the default values for the direct RWBit(s) ones: After a while I think I figured out it's the register indexes, but I didn't check all of them to see if that held true for all. I'm not sure if there is some way we can show something more relevant for the default, or maybe omit it if not since those numbers could be confusing to the user. |
|
that is bizarre. i just checked another library (vcnl4020, this one's cousin: https://docs.circuitpython.org/projects/vcnl4020/en/latest/api.html) and its docs do not show the register numbers. maybe it will be different once its on readthedocs? |
|
@BlitzCityDIY okay, those are renamed and I removed the docs conf. Re the docs: it's possible that I have a weird version of sphinx or one of the other modules used as well, I do sometimes find differences between my locally built docs and the ones that end up in RTD after they build it in their container. |
FoamyGuy
changed the title
|
great, i just pulled and it looks good. great work! |
No description provided.