Closed biot closed 1 week ago
Sure, it's up to you to decide on design stuff like that. I've actually got the pinmux stuff working now (changing pin functions), so I'll hold off on that.
Keep in mind though, if that's how BBOS will show info on and change hardware, that interface needs to support all of that. For example this:
pinouts enable uart1 pins 36,37
How would that go? I was planning to change that to "mcu pins 36,37" or "board pins x,y" or "gpio x,y" (because MCU pins really isn't handy without the datasheet). But how would you do that via a /dev
node?
Yes maybe we make a separate /mcu
node to hold the chip config/interaction/pinmuxing stuff, could even break it into multiple commands, and then /dev
is dedicated to the actual hardware interface instances. We will have to figure out how to dynamically change the contents of /dev
. Right now it is just a mount/unmount of the entire directory, the files within are in a static const struct so I'm not sure yet how that would be done on the fly.
FYI I have invited you as contributor, will have to adjust branch permissions once you accept. I have also created the pinmux branch for this feature.
Well, I would say make a decision and implement my dump_pinmap() on top of it. I really can't continue with my pinmux stuff until you show the way here. I might take a look at modularizing the driver_lib stuff, unless that's also slated to go from cli to /dev nodes?
I have declined your kind invitation to contribute. Please don't take this as any kind of rejection, just a decision for personal reasons.
Understood. Can you adjust the PR to target the new pinmux branch? I'll merge it in and then take a look at how to organize it.
Hi @biot are you still interested in pushing your work? I'd like to start working off the pinmux branch if so. I'd love to keep you on as a collaborator!
@biot your changes are currently on the pinmux
branch, didn't realize I could edit the PR and change the target branch myself. I will start taking a look at organization so we can add this feature.
This adds the basics for the pinmux stuff I mentioned in discussion #5. Actual changing of pin functions to follow shortly.
This goes on top of PR #6, only the top two commits should be in PR #7. Don't know how to tell github not to present the other 7 commits.