i2c: Fujitsu FRAM based I2C Bus driver testing #68021
Conversation
teburd
changed the title
teburd
force-pushed
the
i2c_fram_test
branch
3 times, most recently
from
1188d66 to
2472cc2
Compare
zephyrbot
requested review from
57300,
jeremybettis,
nashif,
nordicjm and
tejlmand
teburd
force-pushed
the
i2c_fram_test
branch
3 times, most recently
from
976cc1c to
aa0b046
Compare
|
@teburd, as we discuss in test working groupd, we can use https://www.mikroe.com/fram-3-click as candidate. and as not all evk boards has such FRAM on board, it is also recommand that add this bridge card for https://www.mikroe.com/arduino-uno-click-shield, so that click interface can goes with arduino interfaces. what is your testing setting? |
| tags: | ||
| - drivers | ||
| - i2c | ||
| filter: dt_alias_exists("mb85") |
There was a problem hiding this comment.
we need add harness requirement for click_mb85
such as
harness_config:
fixture: click_mb85
There was a problem hiding this comment.
I think leaving the fixture as mb85 is ok, there are other breakouts, the key here is that the board has a i2c bus alias labeled mb85, that could be the i2c bus connected to a particular click board socket or arduino shield header.
Speaking of click boards, it seems like we might want an added alias for click_i2cX as there's the strong potential, e.g. the nucleo 144 shield, where more than one i2c is possible.
Can we set the default to be arduino_i2c though and overlay board specifics if needed? That seems like a reasonable plan?
I don't know the best route to deal with multiple shield boards though and multiple shield board sockets, maybe @jfischer-no would have some helpful hints on that front.
There was a problem hiding this comment.
maybe just put arduino will be ok
There was a problem hiding this comment.
@teburd sorry, not sure I understand, maybe boards/shields/arduino_uno_click is an example of what you are looking for.
There was a problem hiding this comment.
I'll take a closer look at that, thank you
I have those on order, I had the adafruit breakout (i2c fram https://www.adafruit.com/product/1895) which I think I might've dorked up as I kept moving the wires around. Exactly why I like the sockets and board to board interfaces better... |
|
I did some adhoc runs with this test and... already finding bugs it seems, required a patch to mimxrt1010 evk pinctrl. The transfer cb setup is likely a bug in the test I'll work out.
|
zephyrbot
requested review from
danieldegrasse,
decsny,
DerekSnell,
EmilioCBen and
yvanderv
|
#68400 , I propse to switch such apparch for all peripheral cases |
|
I'd note the uno click shield uses the wrong pins for our arduino shield i2c and instead one of the frdm click shields should be used. https://www.mikroe.com/frdm-kl46-click-shield or https://www.mikroe.com/frdm-k64-click-shield The i2c pins for the kl46 shield connect to the arduino_i2c aliased i2c pins as would be expected for both clicks, the k64 click shield would work only with one slot for i2c with our arduino_i2c setup today. |
teburd
force-pushed
the
i2c_fram_test
branch
2 times, most recently
from
28d6643 to
59c9d38
Compare
The current system seems to always find the wrong interpret for me, and cmake (since 3.18) has a sensible FindPython module with the potential to use a version range. So take advantage of both of those as our current minimum cmake version is now 3.20. Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
RAM allows for very fast reads and writes and lets us explore most of the I2C controller APIs including RTIO. Theoretically supports any form of i2c connected RAM but requires some tweaking to work with specific parts potentially. Tested with Fujitsu's MB85 FeRAM part using an arduino breakout. Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
I2C pads were incorrectly configured, particularly the scl was not configured to be open drain which would have prevented the scl from working correctly. Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
|
Was merged in as part of #68776 |
Ignore first commit, twister fails to run without it for me atm.See #65995The current test for I2C driver testing is based on a "gy271" which I don't have on my desk for one thing.
There's a variety of RAM like i2c parts (FRAM, SRAM with flash write on power out, etc).
Adds a second test, and includes the callback and RTIO APIs being covered using RAM like reads and writes to an external memory device over i2c. Tested with fujistu mb85 fram module.
In draft until I work out some things, e.g. how to choose which addressing scheme (1 or 2 byte memory addressing) and such.
Sadly my initial plan to use the fram click 3 and arduino fram breakouts didn't quite pan out as the fram click 3 uses a mb94 which is a bit more than a simple fram part and requires sending formatted commands rather than simple read/write memory addresses.
My new plan is a general RAM test where the external device needs to respond to 2 byte memory address read and write requests just like the mb85, there just happens to be a few parts that work like that besides the mb85 that also have mikrobus breakouts.