[New Variant] generic STM32F401R pinout #784
Comments
|
@MCUdude |
OK, That's a huge bummer... But why don't every pinout have its own pins_arduino.c/h file, like other cores have? This makes custom boards and pinouts much more flexible because we don't have hardcoded pin definition rules in the core files. It's not important for me to have access to the A0...A15 macros, what is important is to keep the pinout as clean as possible while still be able to read every analog pin. |
|
When thinking a bit more about it; all existing variants use the same pins_arduino.h. It should be possible to make a copy of these two files and move them into each variant folder. This would let the actual pinout definitions control how pins_arduino.c/h should work. |
|
I know but for Arduino compatibility, I had to do like this. I never found another way to met all requirement and allowing to be generic. |
The problem is that the pins_arduino files set all the rules, and it's not possible to change them in the variants file. However, I may have found a solution that works well. I moved the pins_arduino.c/h files out from the core files folder and into the Nucleo F401RE variants folder and to the folder where I keep the generic F401 pinout I'm working on. By doing this each variant can have it's very own pins_arduino rules, and therefore allow any combination of digital and analog pins. I successfully modified the pins_arduino files used for my own generic pinout, and it does not affect any of the other variants. The standard Nucle F401RE variant still remains untouched, even though I've copied a version of pins_arduino.c/h to this variant. All existing variants will have their own pins_arduino.c/h files. What do you think about this solution? The only downside I can think if is that it will generate some more files. On the positive side;
I can be helpful by providing a separate PR for this if you like. Looking forward to your reply @fpistm ! |
Wrong. Some are defined if the variants does not define them. Variant.h is the first included.
I'm not sure. You will break some arduino compatibility.
for (uint8_t i=0; i<NUM_ANALOG_INPUTS; i++) {
Serial.println(analogRead(i));
}I do not want add more files in the variant folder except if there is no other choice. |
This will indeed NOT work on the generic pinout I'm working on. It will still work on every other variant that exists today. This is simply a sacrifice that has to be made on a generic pinout like this. IMO it is difficult to combine both A0..A15, PA0..PHx, 0..49 and PA_x..PH_x to work perfectly with analogRead. Personally, I prefer to use Ax or the actual pin number (14 for instance) when using analogRead. This has to be properly documented for this particular pinout of course.
If the pins_arduino.c/h files are not moved to to the variants folder, I would have to rewrite the global pins_arduino.c/h files completely so that everything that is defined in variant.h will "override" what is defined in pins_arduino.c/h. Chances for breaking things are much higher. It would be much easier to keep backward compatibility if we decided not to touch the global pins_arduino.c/h and instead move it into the variant where it belongs. (I just had a look at some other STM32 families, and their pinouts are VERY similar to the F401C and F401R. This means that with some solid groundwork it should be fairly quick and easy to use these new generic pinouts with other STM32 families. I may even create some nice pinout diagram to help developers using the generic pinouts. For reference, here's some other pinouts I've made for some new 8-bit AVRs. |
So I could not support that, several third party library use that. |
|
maybe we can introduce analogReadPort(PC0) ? |
Wait, it IS possible to support all this, we just have to be a little clever. First, I'll have to have control over the pins_arduino.c/h file. Then we can map the input of the analog pins this way.
The key here is that the "next" analog pin after A7 is actually digital pin 16, which leaves 8-15 free for mapping to the other analog pins. This way the user can use 0-15, A0-A15 and the digital pin number. I implemented it this way in MegaCoreX for the ATmega4809. It works great, but it requires full control over the pins_arduino.c/h |
|
@MCUdude |
It would work just fine! It would be exactly the same as writing analogRead(8), analogRead(16) or analogRead. See table below. I can push some samples to my fork of this repo tomorrow so you can see yourself. All these variants will work for each analogpin:
|
|
Ok 😉 |
Great! I will continue working on it tomorrow. I can provide the necessary PRs, but first I'll have to sort everything out. I'll pretty much have to redesign the entire pins_arduino.c/h for the generic pinout, I'm working on. But hey, I've done this several times before 😉 |
|
I'm soon finished working on the generic pinout. All analog pins behave like they should (according to the table above). Is it OK if I move the contents from pins_arduino.c into pins_arduino.h instead, and delete the pins_arduino.c fir this pinout? This means one file less to handle (for this particular pinout). |
|
@MCUdude |
Hi!
As mentioned in #722 I'm working on a new pinout for a generic F401R. The pinout is not "board oriented" but rather "chip oriented". This means the Arduino style pinout matches the port numbers as closely as possible.
I've gotten all digital pins to work as they should, but I'm having a hard time getting the analog pins to work, due to the way the analogRead function is implemented. Is there a way I can get the pinout below to work by using
analogRead(A0)oranalogRead(PA0)without having to "align" all analog pins so that A0, A1...A15 comes after eachother?The text was updated successfully, but these errors were encountered: