Support i2cperipheral on RP2040 #4536
Comments
|
I'm eager to have i2cperipheral supported on the Teensy 4.X with CircuitPython, so I can use two Teensy 4.1 units as I2C Responders on a very short I2C bus. I'd like to know more about how I and my organization can increase the priority or this issue and/or support someone working on it. Just for background I'd also like to understand if it's not currently supported only because it's low priority or if it's because of issues with I2C in general on the Teensy 4.X. |
|
you can subscribe to #2470 |
|
Copied from #5410: from @domdfcoding:
|
|
@ifurusato suggests looking at https://github.com/adamgreen/i2cperipheral, which is a MicroPython implementation of I2CPeripheral. |
|
Hi all, any success getting |
|
Hi Wattsie,
I'm afraid I haven't been working on it. Truthfully, the availability of
Adafruit's QT Py ESP32-S2 has lowered the priority of this for me -- I
would still love to be able to chain 2040's together through their S-QT
ports, but the esp32-s2 aren't that much more expensive and can use WiFi
for communication, so I've been going in that direction.
But if you manage to get the I2C peripheral mode working, I'd certainly
love to have that as an option -- and can happily promise to sing your
praises.. (not that my singing is worth much ;-)
Best regards,
- Ken
…On Mon, May 2, 2022 at 12:32 AM Wattsie ***@***.***> wrote:
Hi all, any success getting i2cperipheral to work with an RP2040?
I have a project where I would like to use an RP2040 as an I2C slave
(ahem.. peripheral/target)
If not, I can try to look into it (if time permits), don't want to
duplicate effort if others are working on it.
Cheers.
—
Reply to this email directly, view it on GitHub
<#4536 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBX6BFAHDUYX3ZEBZQ47Y3VH5LHDANCNFSM42H3AKRQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
So far as I know Adam has managed to get his i2cperipheral library to at least a working state, but I myself haven't had the time to check into it at all, focused on an entirely different project right now, sorry. |
Would you be interested in collaborating on this? I could REALLY use the functionality but I'm not familiar enough with the circuitpython environment enough to tackle this myself. |
|
Unfortunately I haven't done anything serious with circuitpython either.
Also, I solved that particular problem with a different approach and
have moved on. Good luck.
…On Fri, Jun 17, 2022 at 10:23:39AM -0700, im-redactd wrote:
> Hi all, any success getting `i2cperipheral` to work with an RP2040? I have a project where I would like to use an RP2040 as an I2C slave (ahem.. peripheral/target) If not, I can try to look into it (if time permits), don't want to duplicate effort if others are working on it. (_PS: checked latest 7.3.0b2, not supported_) Cheers.
Would you be interested in collaborating on this? I could REALLY use the functionality but I'm not familiar enough with the circuitpython environment enough to tackle this myself.
--
Reply to this email directly or view it on GitHub:
#4536 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
--
Bill Mania
"It’s difficult to get a man to understand something when his
salary depends on his not understanding it." Upton Sinclair
|
|
I'm willing to try to help if I can. I've been playing a bunch with
Circuit Python, although thus far primarily as a developer using circ-py,
not *of* circ-py. I do know C/C++, although my experience is from a while
ago, and I'm not super-current on all the latest fancy auto-build systems
and the like.
one thing I was able to do a while ago was recompile a qtpy_m0 (atmel-samd)
uf2 file to include the i2c client code, and as I recall, I was actually
able to get this to work. But basically all that was involved here was
turning on a library that's turned off by default and recompiling the
uf2.. The problem with the 2040 is that the library actually hasn't been
ported- so there's nothing to turn on. I really have no idea how difficult
porting the library from atmel-samd to rp2040 would be.. but as I say, I'm
willing to try to help...
any suggestions on how to start digging in?
- Ken
…On Fri, Jun 17, 2022 at 1:23 PM im-redactd ***@***.***> wrote:
Hi all, any success getting i2cperipheral to work with an RP2040? I have
a project where I would like to use an RP2040 as an I2C slave (ahem..
peripheral/target) If not, I can try to look into it (if time permits),
don't want to duplicate effort if others are working on it. (*PS: checked
latest 7.3.0b2, not supported*) Cheers.
Would you be interested in collaborating on this? I could REALLY use the
functionality but I'm not familiar enough with the circuitpython
environment enough to tackle this myself.
—
Reply to this email directly, view it on GitHub
<#4536 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBX6BAR7QUMGPMOUYRIIFDVPSYBXANCNFSM42H3AKRQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
We're happy to give pointers on the Discord: https://adafru.it/discord That's the best place for fast replies. Generally you'll want to start by copying |
Discord is a great resource and feel free to ping me (there or here). My first real contribution was adding a module like this so willing to help you along if you need. I hopefully remember some of the pitfalls I ran into in the past. I've added some features to the RP2040 port before too so somewhat familiar with how it works. |
|
A quick status update --
many thanks for Scott's getting-started instructions! I've successfully
created a build environment and a hollowed-out version of I2CPeripheral.c,
and have confirmed that I can now "import i2cperipheral" on a rp2040
feather. It doesn't do anything, but at least I've got a working build and
test environment.
There are 9 functions in the .c file that need to be re-implemented. Most
of the logic in there is dealing with "sercom".
atmel-samd/peripherals/samd/sercom.c appears to be an SPI-based serial
communications library. I don't know much about SPI, but with a little
hunting, I found raspberrypi/common-hal/busio/SPI.c, which I think has
roughly equivalent functionality.
So theory #1 is that the job is to rebind I2CPeripheral.c away
from sercom.c to SPI.c. This isn't going to be trivial, as the code
documentation looks so-so, but I'm happy to give it a go, as long as no-one
is in a rush for this.. (I do have a FOSS project of my own that's getting
ready for its debut, so this will be playing 2nd fiddle for now).
*To the person who wrote the original note mentioning possible
collaboration* -- your identity was redacted by the github email relay, so
I can't reach out to you. If you would like to collaborate, I'd be happy
to move my setup to github, and we can plan how to divvy up the effort.
Please email me -- ken <at> point0.net
I'll keep folks informed here as I make progress or run into roadblocks.
And if I need tactical help, I'll reach out on Discord.
Thanks all! Best regards,
- Ken
…On Fri, Jun 17, 2022 at 2:45 PM Mark ***@***.***> wrote:
I'm willing to try to help if I can. I've been playing a bunch with
Circuit Python, although thus far primarily as a developer using circ-py,
not *of* circ-py. I do know C/C++, although my experience is from a while
ago, and I'm not super-current on all the latest fancy auto-build systems
and the like. one thing I was able to do a while ago was recompile a
qtpy_m0 (atmel-samd) uf2 file to include the i2c client code, and as I
recall, I was actually able to get this to work.
Discord is a great resource and feel free to ping me (there or here). My
first real contribution was adding a module like this so willing to help
you along if you need. I hopefully remember some of the pitfalls I ran into
in the past. I've added some features to the RP2040 port before too so
somewhat familiar with how it works.
—
Reply to this email directly, view it on GitHub
<#4536 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBX6BFBA77YPEB3RIAVORTVPTBT3ANCNFSM42H3AKRQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
@kstillson I'd recommend starting with: https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/common-hal/busio/I2C.c It already interfaces with the I2C peripheral in the RP2040. SERCOMs on SAMD21 are generic serial communication peripherals. They do SPI, I2C and UART. Modelling after that code may be more confusing than clear. |
|
Hi Scott-
Thanks to your excellent push in the right direction, Ryan (that's
"im-redactd") and I have made some okay initial progress (
https://github.com/kstillson/circuitpython/blob/main/ports/raspberrypi/common-hal/i2cperipheral/I2CPeripheral.c
).
We did manage to find busio/I2C.c, and we (well, Ryan mostly) have gotten
things far enough along that a client sees the server at the correct
address during an I2C scan. For reasons I haven't had the cycles to quite
figure out yet, we get timeouts when we actually try to send or receive
bytes.. But we can change the server I2C address and see the change in the
client's scan, so that seems to demonstrate that bits are flowing.. So I
think it's just a question of a bit more debugging, and then trying to
clean things up and generalize them sufficiently so that we don't get
laughed out of town if we generate a pull request for upstream. ;-)
At this point, I think the greatest challenge is just that midsummer has
quite a few distractions and other priorities.. :-)
Thanks again for getting us started!
- Ken
…On Tue, Jun 21, 2022 at 4:59 PM Scott Shawcroft ***@***.***> wrote:
@kstillson <https://github.com/kstillson> I'd recommend starting with:
https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/common-hal/busio/I2C.c
It already interfaces with the I2C peripheral in the RP2040.
SERCOMs on SAMD21 are generic serial communication peripherals. They do
SPI, I2C and UART. Modelling after that code may be more confusing than
clear.
—
Reply to this email directly, view it on GitHub
<#4536 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBX6BAKAQOREHV7TUMFW53VQIUMRANCNFSM42H3AKRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I'm glad you are making progress. Don't worry about getting laughed out of town. We appreciate contributions to CircuitPython and are happy to help refine things to get them merged in. |
|
update for the list.. nothing but frustration tonight.
I tried putting my test server
<https://github.com/kstillson/circuitpython-i2c-notes/blob/main/i2c%20test%20server.py>
(aka I2C peripheral) onto a qtpy esp32s2, which already supports the
library, and then trying to talk to it from my test client
<https://github.com/kstillson/circuitpython-i2c-notes/blob/main/i2c%20test%20client.py>
(aka I2C host), and couldn't get anything working, not even the address
scan which seemed to work earlier.
I eventually noticed this page
<https://docs.circuitpython.org/en/latest/shared-bindings/i2cperipheral/index.html>
which
says "I2CPeripheral makes use of clock stretching in order to slow down the
host. Make sure the I2C host supports this. Raspberry Pi in particular
does not support this with its I2C hw block. This can be worked around by
using the i2c-gpio bit banging driver." I have no idea how to implement a
protocol like I2c at the bit-banging level, and doubt I have the patience
for it.
So I went back to feather rp2040 boards on both sides. This time, I
started getting the error "No pull up found on SDA or SCL; check your
wiring." After some thought, I realized it's right -- usually the
peripheral board has the pull-up resistors built into the pcb. I think
this is actually a fatal problem for the use-case I was hoping to support:
a chain of 2040 boards powering each other and communicating through their
stemma/qt connectors with no other soldering / wiring required. If that
is just not going to work, my interest in the overall project is reduced.
Anyway, I do happen to have a stemma breadboard breakout
<https://www.adafruit.com/product/4527>, so I went ahead and wired up some
pull-up resistors. I tried every combination of 2k and 10k between 3.3v
and every combination of scl/sda/both.. and no matter what, I still get
the "no pullup found" message. I thought perhaps the host was using the
wrong I2C port (there are two of them on the feather), but same message
regardless of which one I use. Cold starting both boards doesn't seem to
make any difference. Nothing I do seems to make any difference.
So I'm stuck and can't even get back to what seemed to be working fine 2
days ago. Sigh. Gonna call it a night.
- Ken
…On Wed, Jun 22, 2022 at 12:47 PM Scott Shawcroft ***@***.***> wrote:
I'm glad you are making progress. Don't worry about getting laughed out of
town. We appreciate contributions to CircuitPython and are happy to help
refine things to get them merged in.
—
Reply to this email directly, view it on GitHub
<#4536 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBX6BBXPT52VTA4WQIQ7VTVQM7TJANCNFSM42H3AKRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Dear Ken, Some ideas for your project:
You could put any stemma sensor with two connectors, and put it in between your QT RP2040. My guess is that the pull-up present will help, also you will have a sensor and your i2cperipheral so you could test one or the other and compare.
Not exactly your project, more like my project but very similar... On most board the pin choosen for SDA/SCL are also capable of RX/TX and what you do is a Stemma QT cable that put RX on TX. Not really helping for i2cperipheral, but maybe interesting alternative. Don't hesitate to ping me on Discord. |
|
Hey, @kstillson do you have a logic analyzer that you can put on the I2C lines? That'll really help you understand what is happening. |
|
HI Scott-- thanks; good idea. I do have this little gizmo called a "Saleae
logic analyzer," although the last time I plugged it in was 2018, and I
recall it was quite frustrating to try to use.. But... I'll see if I can
dig it out and make it do anything.. Thanks for the suggestion!
- Ken
…On Fri, Jun 24, 2022 at 1:09 PM Scott Shawcroft ***@***.***> wrote:
Hey, @kstillson <https://github.com/kstillson> do you have a logic
analyzer that you can put on the I2C lines? That'll really help you
understand what is happening.
—
Reply to this email directly, view it on GitHub
<#4536 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBX6BBLQEXMVDGHMZ6WJDDVQXTU7ANCNFSM42H3AKRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@kstillson Download the latest software for the Saleae: they've made a lot of improvements. |
|
@kstillson I would be interested in helping test. I have an oscilloscope at my disposal, and possibly a little free time. |
|
@Billy-Bogardus well, any help would be most appreciated. yup- I keep my github repos up-to-date. https://github.com/kstillson/circuitpython has the modifications to try to get i2cperipheral working on 2040, and https://github.com/kstillson/circuitpython-i2c-notes has working notes and the code I've been using on both the host and the peripheral to try to make it go. Thanks-in-advance! :-D |
|
@kstillson Just had a little time to build for my RP2040 and it looks like something is being inverted on the reading address. Reading 0x3D 0b0011 1101 instead of 0x42 0b0100 0010 attached below are the scope plot and screen shot.
I only have one 2040 processor right now so I will have to work up another test script for the opposing device. |
|
@kstillson I use a Saleae so feel free to ping me on Discord if you need help getting it going. |
|
Thanks Scott & Billy.. I've got to make a bit more progress on my primary
project today. I'm hopeful/optimistic that I'll be able to get back to the
i2c project tomorrow.. :-D
- Ken
…On Mon, Jun 27, 2022 at 2:38 PM Scott Shawcroft ***@***.***> wrote:
@kstillson <https://github.com/kstillson> I use a Saleae so feel free to
ping me on Discord if you need help getting it going.
—
Reply to this email directly, view it on GitHub
<#4536 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBX6BAOJBDOWQAOBEZXM53VRHYINANCNFSM42H3AKRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
update- much more happiness this time, although not victory just yet.
Here's what I figured out about my problem with the pullup resistors: If I
start up our customized peripheral first (which seems sensible), then the
host will report missing pullup resistors no matter whether they're there
or not. However, if I start up the host first (and it has some sort of
retry loop that keeps looking for a peripheral), then it correctly detects
whether pullups are there or not. So presumably there's a bug in our
code that is interfering with the pullup detection on the host. I think I
found the detector code, and all it's doing is checking to see if the SDA
pin is high at some random moment, so presumably we're doing something
that's pushing it low when we shouldn't be....
In the meantime, I've studied the code in much more detail and have a much
better feel for it. I found that our _is_addressed() method was not
populating its output *address param, which was clearly causing everything
else to stop working. It wasn't immediately clear where to get the correct
address from the i2c_inst_t* value (and I had a devil of a time finding
where that structure is defined). But eventually
found sdk/src/rp2040/hardware_structs/include/hardware/structs/i2c.h (which
defines i2c_hw_t, which is what self->peripheral->hw appears to point to),
and made the guess that "sar" (slave address register) is what we want.
Anyway, I immediately started seeing data transferred between the two
sides. The data doesn't seem to be right (binary junk at first glance),
and the host board locks up after a few bytes are transferred.. But still-
progress usually comes in fits and starts.
Unfortunately it was a really nice day today, and I spent much of it
outside. And now it's past 1am, and I'm too tired to continue. Not sure
whether I'll have cycles to continue with this tomorrow, but surely within
a day or three.. and I'll keep letting this list know how things are
coming along.
As always, I've updated my git repos with the latest:
modified circuit python code adding i2cperipheral under ports/raspberrypi :
https://github.com/kstillson/circuitpython
informal notes on the project and the test code I'm using for my host and
peripheral boards: https://github.com/kstillson/circuitpython-i2c-notes
Thanks all!
- Ken
…On Mon, Jun 27, 2022 at 2:44 PM Ken Stillson ***@***.***> wrote:
Thanks Scott & Billy.. I've got to make a bit more progress on my primary
project today. I'm hopeful/optimistic that I'll be able to get back to the
i2c project tomorrow.. :-D
- Ken
On Mon, Jun 27, 2022 at 2:38 PM Scott Shawcroft ***@***.***>
wrote:
> @kstillson <https://github.com/kstillson> I use a Saleae so feel free to
> ping me on Discord if you need help getting it going.
>
> —
> Reply to this email directly, view it on GitHub
> <#4536 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACBX6BAOJBDOWQAOBEZXM53VRHYINANCNFSM42H3AKRQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
Just wanted to make sure you know that that struct is allowing direct access to the peripheral registers. The data sheet is a very good resource about what they all do. I tend to use registers directly because the datasheets are generally the best documentation. |
|
Haven't had much time this week, but was able to read some of the datasheet today https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf I2C details start on page 439. there is also some sample code on page 359. |
|
Tried to do a little bit of debugging today. I am struggling to understand how all the different files and libraries link together. |
|
@Billy-Bogardus I don't use a particularly fancy editor. We're happy to answer more specific questions on the Discord (https://adafru.it/discord) in #circuitpython-dev. |
|
(apologies, was traveling on vacation and taking a break from email)
@Billy-Bogardus <https://github.com/Billy-Bogardus> - like Scott, I don't
use a fancy/graphical IDE; I tend to work from the command-line, and do my
editing in Emacs. emacs does have a system called "etags", where you can
feed it a bunch of code, and it sort of semi-parses it, and creates a
database of where various symbols appear to be defined. Then you can do
things like point at a symbol and give commands like "take me to the
definition of this". I haven't actually used etags in a while, but if I
end up spending much more time on this project, I'll probably dust off my
memories of how to use it, because I was finding myself spending a lot of
time hunting around for where various structures were defined. I don't
actually know whether etags will scale well enough to handle something of
this complexity, although I expect so- I know lots of Linux kernel
developers use it, and that's much bigger and more complex than Circuit
Python.
The other IDE-like mode I use in Emacs is the debugging feature- it can run
a debugger (gdb) in one half a window, and automatically display the
matching source-code as you step through things in the other half.
Anyway, it is unfortunately true that the learning curve for Emacs is
pretty steep. Personally I think it's worth it- once you master it, it's
an incredible tool... But I haven't really played with VS Code (or other
fancy graphical IDEs) enough to do a fair comparison.
- Ken
…On Tue, Jul 19, 2022 at 8:53 PM Billy-Bogardus ***@***.***> wrote:
Tried to do a little bit of debugging today. I am struggling to understand
how all the different files and libraries link together.
Does anyone have any recommendations on a good way to navigate the circuit
python code base? I am using VS Code. I have used Microchip X IDE in the
past, but never for anything as complex and circuit python.
—
Reply to this email directly, view it on GitHub
<#4536 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBX6BBGCOXKVQQLBLZNDYDVU5EY7ANCNFSM42H3AKRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hmm I am also interested in creating an i2c slave using a seeed Xaio rp2040, I compiled and loaded @kstillson 's Fork. I have noticed when running the example code: https://docs.circuitpython.org/en/latest/shared-bindings/i2cperipheral/index.html#module-i2cperipheral The loop terminates because device.request is returning an address of 0x40 in the absence of an actual request (empty body). |
|
I started taking a look at this myself this weekend. I think it may be close. Please let me know if anyone has any updates they haven't posted. The datasheet does have a lot of good information. I hope to take a further look tomorrow and get my logic analyzer hooked up to get a better picture of what is being sent. |
|
I will most likely be dusting off my logic analyzer as well. Might we tweak the code to allow for a null address (just read everything going down the wire)? I feel this would prove advantageous for future diagnostics. |
Now that I think about it, it would also allow us to emulate multiple slaves with a little python support logic. |
|
For anyone looking at this be aware of #6721 that will affect any changes. I did make some small progress and I'll post a more detailed update later. |
|
I think I have it working, probably needs a bit of cleanup. The basics of what I did:
With #6721 there is probably a bunch of renaming work to do as well. Good job to everyone who helped contribute to this, I think it is close. |
|
I will deploy this to my avionics microprocessor in the morning and run it through the paces, see how it goes.
… On Aug 9, 2022, at 9:45 PM, Mark ***@***.***> wrote:
I think I have it working, probably needs a bit of cleanup.
@kstillson or @im-redactd would you like me to push into your repo so you can create a PR to the core? Or else I can create a PR myself to the core.
The basics of what I did:
in the is_addressed method found the correct status bytes to check if we have a read or write request (or nothing)
in read and write, address the hw->data_cmd register directly. The API does not really have good methods.
Some general cleanup in the constructor and deinit functions.
With #6721 there is probably a bunch of renaming work to do as well.
Good job to everyone who helped contribute to this, I think it is close.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
|
Closing this issue as support has been merged with the core now. If there are issues with it please open up a new issue and tag me on it. |
|
thanks @gamblor21 ! |
|
Mark- fantastic. You're certainly welcome to create a PR to my repo, or
just send me a pointer to yours.. Either way, I'd be delighted to give it
a test and confirm whether it works for me.
I do apologize for disappearing of late; I've been busy getting my big
project to its first release. I succeeded, btw. The project is here:
https://k3n.cc/0 . A part of this that Circuit Python folks might be most
interested in is this:
https://github.com/kstillson/ktools/tree/main/pylib/circuitpy_sim
It's a Circuit Python simulator. Basically you put the contents of this
directory into your PYTHON_PATH, and you can then run (at least some)
Circuit Python code under regular CPython. , e.g. if you create an array of
Neopixels, it'll use the Linux tkinter graphics package to draw simulated
pixels. This allows you to develop things like complicated animations on a
full Python system with a nice editor and full access to PDB, and only
actually upload to the hardware board once you're mostly done.. Which I
find much more convenient.
I also have a wrapper around circuitpy_sim
https://github.com/kstillson/ktools/blob/main/pylib/kcore/neo.py, that
allow you to use the same API for addressing real neopixels under Circuit
Python or Raspberry PI's, or virtual ones under CPython. And it has
wrappers for things like web servers and web-clients that again provide the
same API for any of those platforms. Yeah for platform independent Python
code that uses GPIO's! :-D
Anyway, sorry to hijack the thread for something concerning my own project,
but I thought folks on this thread might be interested.
Mark- thanks again, and looking forward to giving things a try!
- Ken
PS- On Friday I disappear again for a little more than a week, doing some
traveling. I should have loads more free time when I get back. Apologies
in advance for being such a flaky so-and-so...
…On Tue, Aug 9, 2022 at 9:46 PM Mark ***@***.***> wrote:
I think I have it working, probably needs a bit of cleanup.
@kstillson <https://github.com/kstillson> or @im-redactd
<https://github.com/im-redactd> would you like me to push into your repo
so you can create a PR to the core? Or else I can create a PR myself to the
core.
The basics of what I did:
- in the is_addressed method found the correct status bytes to check
if we have a read or write request (or nothing)
- in read and write, address the hw->data_cmd register directly. The
API does not really have good methods.
- Some general cleanup in the constructor and deinit functions.
With #6721 <#6721> there is
probably a bunch of renaming work to do as well.
Good job to everyone who helped contribute to this, I think it is close.
—
Reply to this email directly, view it on GitHub
<#4536 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBX6BGN4DWGPQ7WZLGKGPLVYMCVJANCNFSM42H3AKRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
https://forums.adafruit.com/posting.php?mode=quote&f=60&p=864733#pr864799
The text was updated successfully, but these errors were encountered: