Consolidation of AVR pin headers (AVR pin names) #25361
Conversation
- removed deprecated AVR fastio definitions - added AVR_CHIPOSCILLATOR_FREQ AVR board definition that matches the oscillation frequency on the XTAL1/XTAL2 pins (commonly drives MCU clock) - added board schematic links where they exist (since AVR is not an actively developed for platform anymore we can expect the set of board schematics to stay constant) - transformed AVR pin numbers to AVR pin names for solidification, future-proofing, distinctiveness (initial version)
- fixed some conflicting pin definitions based on RAMPS and board-specific specializations
… into bugfix-2.1.x-pinheaders
|
I'm all in for ditching of dumb arduino numbering! Just not quite what you named them, it should be exact same names as in datasheet, PA0......PL7 |
Sounds good that you share the vision! By the way, we cannot pick PA0 because the internal AVR toolchains clobbered those names. That is why Pin* has been chosen. No dependency framework would ever pick those names! |
|
Better PortA0 then, to not imply any physical pins. Or PA_0 |
That would imply many changes to the code based on a convention change. I could do that if you would help me change the current code (can prob. be safely done using search&replace). But let's first hear out other voices on this PR. :) |
|
O_O you did all pin changes manually, not with script? |
Yea, quite the effort... right? I mean I am that kind of guy. But I would appreciate any help on your end... Automation that is reliable. @EvilGremlin You are right about the name choice. Sorry about picking Pin. My intention was not to include the GND, VREF, etc pins into consideration. Picking PortA0, etc would clarify that even further. |
This nomenclature gets my vote.... |
I appreciate the participation! I want all of Marlin to be comfortable with the inner workings and designs. 😁 |
|
Not that I am fond of Arduino pins numbering, but here are tons of guides and documentation that use it. |
I think that we have to reach out to anyone, even those who like the Arduino-style pin referencing. The image you have shown is not a schematic... Thus I do not advise to take such a reference as example. Let me try to argue further why Marlin devs should think more clear than Arduino tinkerers. At Marlin implementation level we want to know what those numbers mean and dealing with a number system inside the firmware poses compatibility risks across AVR MCU families. The code may compile fine but is it actually correct? Having the pin names implies stronger safeguards. Now, is the Arduino-Marlin mapping truly something new? I would point out that it is has been around since the beginning of Arduino itself. The work I have done is expose it to the Marlin firmware, more clearly, what the numbers truly mean on HW level. So I don't think that it is too much to ask to learn it if you did not care about the HW specifics before. Every professional pinout should have those alternate pin functions displayed anyway, so people have cared.. for example... |
|
No that is a pin diagram, that is what we get provided with by board manufactures It uses standard Arduino A and D pin notation. As we should. Ie we should leave it alone, Anything else will just add more levels of confusion, especially to those just starting out. For better or worse Arduino A and D pin notation is the standard, we should follow it. |
In my opinion those "levels of confusion" will be dismantled for those who matter the most, being Marlin Firmware developers. This is about removing technicalities of the past, the design decisions not changed due to being a project of volunteers. But let's hear your view. By the way, you talking smack about MKS providing those weird "pin diagrams"... MKS has since been providing proper board schematics for their controller boards. |
|
perhaps a system like LPC uses for analog pins eg So both sets of information are in the define, Datasheet port name and Arduino Name Then both sorts of user can just see the information they want to see, without having to look up any translation tables. |
Your idea is possible in the current impl. The user can still pick. But the preference has to be set to be AVR Pin Names. Excuses are possible but should be proven that it is the definite way. |
thinkyhead
force-pushed
the
bugfix-2.1.x
branch
2 times, most recently
from
e90c213 to
4b9bb85
Compare
thinkyhead
force-pushed
the
bugfix-2.1.x
branch
from
faa3233 to
5abfc61
Compare
|
I am sorry but I have decided to halt my activities on this PR for an indetermined amount of time. You are free to decide whether to continue it yourself. Thank you to the Marlin firmware community for providing this interesting playing ground for testing my ideas and vision. I hope that Marlin will continue to go towards the best 3D printing solution! Hopefully my ideas have inspired you on how to continue this software! |
Description
Now that the AVR platform is not expected to grow any further it is a good idea to discuss consolidation for good support into the future. The biggest problem for support continuation are the AVR board definitions in combination with the "AVR pin peripheral conflict". Unlike more modern MCUs on the AVR the peripherals are tied to a fixed set of pins, their connection being always enabled, thus being a troublesome situation with all the varying pin mappins by boards. A good way to combat this misunderstanding is to clearly specify the MCU pin name for pin mappings. It is a clarification that we are not encouraging use of random GPIO pins for stable Marlin board configurations but want people to keep the AVR realities in mind.
I welcome discussion on this proposal.
More rationale behind this PR can be extracted from the following videos:
Benefits
Improve the support situation of the AVR platform.
Related Issues
#24911 (depends on this PR)